Requirements – part 1 – can requirements ever be efficient

When we say bicycle we all agree on what that means ... right?

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 need to be able 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.


About Admin

Web Admin
This entry was posted in Business and Technology and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s