How can CIOs and project managers ensure requirements gathering and management is carried out in the most efficient way for their application lifecycle? What variables must be considered?
When we ask the business, “What do you want the new system to do?” we get too much information. What we want the business to tell us is what they need and what the priorities are. It takes great skill and discipline to focus on just these two things.
In the world of application lifecycle management (ALM), requirements is the last frontier. Increasingly, CIO’s are focusing on perfecting requirements gathering and management. And for good reason. In the last year, my team and I have done detailed assessments of ALM practices for 40 large organizations. The consensus results are fascinating:
- 70% of requirements are incomplete, inaccurate, untestable or un-implementable
- 40% of requirements change after they have been approved
- 75% of reported defects are due to requirement errors
(Source: Serena Software: 40 Value Engineering Studies 2011)
All of this leads to significant rework which, according to the same data, poor requirements management practices puts as much as 10% additional effort on any project.
Addressing this waste requires that we look at how we do requirements gathering. We have to start by getting the best tools in the hands of the analysts. Prototyping and simulation tools allow analysts and users to collaborate on the design and the requirements simultaneously. It is a lot easier to get a business user to sign off on a working simulation of the future system than a 400-page PDF. Prototype Composer, iRise and Blueprint are excellent solutions.
Defining use cases with UML has become a mainstream requirements activity. Great tools like the Eclipse-based ones from IBM are particularly strong. One huge advantage of using UML is the enforced rigors of the process, which ensures all the “corner cases” are derived as well as the mainstream activity. However, the IT-centric diagrammatic nature of UML can be daunting for some business users.
With Agile requirements tools comes the need to be able to decompose requirements, order and prioritize them, and show waterlines above which requirements are likely to be implemented and below which there is no current capacity. But requirements management is as much about the process as it is about the tool, so ideal requirements tools are process-centric, that is, they enable your process to be implemented, managed and enforced. Stakeholders in the business, product management, development and in QA need to be able to be assigned to requirements and be notified of changes. Integration with development and testing tools is also critical.
The key to effective requirements management is collaboration. The tools we use need to foster and enable that. Whether it is an analyst sitting down and collaborating on the development of a prototype, or the Agile product owner collaborating with the business on priorities, or the developer and the tester collaborating on the detailed definition of a requirement, the requirements management tool is at the heart of all we do. Choose wisely.
Dig Deeper on Gathering Software Requirements Use Cases
Related Q&A from Kevin Parker
Add controls to the business of delivering software, and teams will scream about delays. However, fast development is often the result. Continue Reading
Kevin Parker discusses the pros and cons of industry analyst reports and advises when it might be best to trust your own instincts. Continue Reading
Actually, application development veteran Kevin Parker says ALM is really a part of the APM process when you look at it from a distance. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.