Effective requirements management includes selective requirements measurement. You can make sure your project is staying on track by counting the number of requirements you plan to implement and tracking their status during construction. You can stay focused on meeting delivery targets by monitoring requirements change requests. You can even estimate future projects better by tracking the time you spend on requirements engineering and correlating requirements definitions with development effort. Or alternatively, you could just ship the product when it "feels" done. It's your choice.
Many disciplined software organizations collect a focused set of metrics on their projects. These metrics provide insight into the size of the product, the effort and time the project or individual tasks consume, and the product's quality. Since requirements are an essential project component, you should measure several aspects of your requirements development and management activities to help you judge product size and project status. Here are some tips on how to do that.
Although you might represent requirements using a mix of use cases, business rules, event tables, functional requirements, and analysis models, you primarily implement functional requirements. So begin your measurement effort by simply counting the individual functional requirements that are allocated to a product release. Knowing how many requirements are supposed to go into your product will help you judge when it's done.
Of course, not all functional requirements are the same size or consume the same implementation or testing effort. A requirement that says "A valid color code shall be 'G' for green" is tiny compared to "The system shall respond to editing directives entered by voice" (both real examples). So, if you're going to count functional requirements as an indicator of system size, your analysts will need to write them at a consistent granularity level. One guideline is to decompose high-level requirements until the underlying "child requirements" are all individually testable. That is, a few logically related tests can verify whether a requirement was correctly implemented. Then count the total number of child requirements because those are what you'll implement.
To monitor overall project status, track the status of each requirement. This can help you avoid the pervasive "90 percent done" problem of software project tracking. Each requirement will have one of the following statuses at any time:
- proposed (someone suggested it)
- approved (it was allocated to a baseline)
- implemented (the code was designed, written, and tested)
- verified (the requirement passed its tests after integration into the product)
- deleted (you decided not to include it after all)
- rejected (the idea was never approved)
When you ask a team member how she is coming along, she can say something like, "Of the eighty-seven requirements allocated to this subsystem, sixty-one of them are verified, nine are implemented but not verified, and seventeen aren't yet completely implemented." If I were a project manager, I'd feel like we had a good handle on the size of that subsystem and how close we were to completion. A body of work is done when all of the allocated requirements have a status of verified or deleted.
Because so much of requirements management is change management, track the status of your change requests. How many of them are open and how many closed? How many requests were approved and how many rejected? How much effort did you spend implementing each approved change? How long have the requests been open? Change requests that remain unresolved for a long time suggest that your change management process isn't working effectively. I recently visited a company where a manager wryly admitted that they had enhancement requests that were several years old and still pending. If you can convert some open requests to "deferred," and convert long-term deferred requests to "rejected," you can focus on the most important and most urgent items in the change backlog.
Monitor how many changes are incorporated throughout development after you baselined the requirements specification. You should become more resistant to making changes as development progresses, so this trend should approach zero as you near the planned release date.
Changes become more expensive as the product nears completion, and a sustained high