What's Your Requirements Architecture Mean to You?
|
Situation: You want to understand how organizational influences impact your work. |
What Matters When Defining Requirements?
Categories:
Requirements Management
Categories: Requirements Management
| Situation: You want to give your approach to requirements a little more thought. Is requirements definition your biggest challenge when defining success on your project? Or is that that one concern among many? JAMA software and Raven flow are conducting a survey related to requirements gathering that you may be interested in. At the very least, its a quick way to give some thought to what matters to you relative to requirements gathering. Here are some early results from John Simpson of JAMA ... Respondents are: 37% are Analysts, 24% Project Managers, 12% Product Development/Engineering, 6% Product Managers, 5% Exec Mngt 54% of respondents work for companies with $100 million annual revenue or more (25% are $1 billion +) so a good range of large and small companies The biggest requirements challenges were: 70% gaining a clear understanding of what our customers want 64% ensuring what’s being built is what was planned 63% documenting all the requirements The goals of their projects: 75% are for enhancing existing products 59% bringing new products to market 25% reducing costs of producing existing products 29% of them considered their companies “Risk Takers” when it comes to innovation, the largest camp was “Market Readers” at 36%, 16% were the “Low Cost Provider” 73% rely on customers and partners for new product ideas – so external collaboration is critical In terms of complexity, 39% of respondents on average had 500+ requirements for typical project, 22% have 1,000 or more requirements In terms of the burden of change management, over a third of respondents spend 25% or more of their time dealing with changes to requirements How they measure success: 87% customer satisfaction 52% quality/safety ratings 34% cost savings 32% revenue 25% speed to market (interesting in terms of positioning) And the one they personally cared the most about was “customer satisfaction” at 61% – I thought it was interesting that “revenue” wasn’t higher (it was only 6%) In terms of delivering projects on time and on budget: For over half of respondents, the project success rate is 40% or less; so they’re feeling the requirements pain The top reasons were: 74% scope creep 64% missed or poorly defined requirements 61% unrealistic schedules or expectations 51% team communication/collaboration an issue 44% Misunderstanding of what customers want 39% Issues w/ change management 29% Lack of executive support What they personally find most frustrating: Missed or poorly defined requirements was #1, unrealistic schedules #2, misunderstanding of the customer #3 The majority define “collaboration” as these 3 things: everyone is in sync on the latest version of the requirements(80%), all items in centralized place (72%), everyone has access (66%) No surprise, 80% currently use Word or Excel to define and communicate requirements; 31% currently use requirements definition software, 35% use a requirement management software, 40% using email On the list of tools they’d like to use in 2008 – 59% chose requirements modeling & visualization, 62% requirements collaboration & management In terms of processes: 37% are using a mix (so having tools built to handle various processes is probably a good thing) 26% traditional Waterfall 16% using RUP or some variation of it And despite all the attention around Agile these days, only 5% answered using some flavor of Agile process currently – was a bit surprise Agile wasn’t higher |
Managing An Entire PORTFOLIO of Requirements
Situation: You Have a Need (perhaps an ITSM push?) for Highly Integrated Change Management. MKS Integrity helps you manage software development at every level of the process, even giving you a portfolio view of what's going on based what's really happening on the ground at the task level on all portfolio projects. IT Service Management is still very hot across the industry right now and software like the MKS toolset plays a huge role in supporting those efforts. Recently, Doug Akers, Tactical Product Manager for MKS spent some time with us answering some questions about the tool and what makes it unique. As will most tools, it is broadly applicable across IT and gets a lot of traction in engineering organizations who are delivering many similar products - industries like Telecommunications, automotive, medical devices, and embedded systems. Q. What differentiates MKS from other requirements management software vendors? Less in terms of technical features, but what do customers say they like better about it? Customers, in my experience, tend to like the connected nature of the MKS Integrity solution and the fact that everything is right there at their fingertips. There is a huge difference between integrations and a truly integrated solution and I think the demands of visibility, transparency and communication that fall out of our solution are proving to be differentiators for our customers and their ability to deliver projects on time. An integrated offering is still many tools, and users have to weed through the complexity of those tools while with MKS Integrity, it’s all one platform, one interface, one way of working. Test management, source control and requirements management all use the same platform capabilities and all benefit from the versioning, reuse, change management and process control that is part of that platform. Q. Tell us about the “unified approach” to requirements management. Traditionally, the tools across the application lifecycle have been very siloed, very purpose built – you have your RM tools, your versioning tools, your testing tools – and although these tools work for their discipline they also put up barriers to collaboration, optimization and the ability of the organization to be productive. There is tremendous benefit to the developer when they can easily click up the tree to see the requirements driving their tasks – it gives them context for their work and allows them to deliver more optimal solutions that meet the business needs. You can’t get that in a siloed world and you can’t get that easily with traceability alone, which is a commodity feature in today’s RM market. A unified ALM platform that addresses RM, as MKS Integrity does, enhances traceability with concepts like transparency and visibility at all levels of the organization. The unified approach gives you a lot of free stuff too that maybe weren’t high on your list. Single administration, single security, integrated process across groups………… Q. “Reuse” is a hot topic lately. How are project documents and code reused using MKS Integrity for RM? How is that different from competitive tools? Reuse is a widely abused term, what does it really mean in practice? I mean, open Microsoft Word and copy/paste a paragraph from one document into another, is that reuse? Some competitive tools would try to tell you it is. MKS, as a company, has a very strong foundation in the software configuration management arena – MKS Integrity has been doing version control and configuration management for more than 20 years. All we did to address the needs of our customers was apply those concepts to the RM space – we’re treating a requirement the way we treat source code though with a business user interface. Requirements are truly versioned, branched and shared across projects, across documents, across the organization and their genealogy is preserved and leveraged. It’s real reuse, not just copy and paste. Q. How do users connect requirements and other life-cycle artifacts such as test cases, defects, release definitions, UML or design models, etc.? How does that compare to establishing relationships between requirements? MKS Integrity, to over simplify things, tracks items and has relationships between these items. It doesn’t matter whether these items are test cases, defects, requirements or source code objects they all benefit and leverage the same set of platform capabilities. Traceability is a fancy term for connecting artifacts across the application lifecycle. In the MKS solution, making those connections between requirements or to artifacts in other disciplines is a simple drag and drop gesture if the system doesn’t already take care of it for you, which in many cases it does. Q. What words of advice would you give to someone struggling with requirements management issues? Don’t eat the elephant all at once… but know that you have an elephant to eat. There are several RM issues that I find within the organizations I talk to – anything from not being able to effectively capture requirements, not being able to know when things change, to not being able to leverage the investments they do make in good requirements – and underlying all of them is process. Process is not a tool dependent thing, it’s a business dependent problem and you will want a tool that can enforce your process rather than a process that conforms to the limitations of a tool. |
