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 level of approved change requests makes it difficult to know when you can ship. Receiving many change requests also suggests that your requirements engineering process may need improvement because elicitation overlooked many requirements or new ideas kept coming in as the project dragged along month after month. Record where the change requests come from: marketing, users, sales, testing, management, engineering, and so on. The change request origins will suggest with whom you need to work to reduce overlooked, modified, and misunderstood requirements.

Finally, record the time your team spends on requirements engineering activities. I'm frequently asked how much time and effort a project should allocate to these functions. The answer depends enormously on the kind and size of project, the developing team and organization, and the application domain. If you track your own investment in these critical project activities, you can better estimate how much effort you'll need for future projects.

As you accumulate this measurement data, try to correlate the requirements information with your project development effort. You could base such correlations on the count of individually testable requirements, the estimated number of GUI elements or function points, or the number and complexity of use cases. In one group, we found that we spent an average of six hours designing, coding, and testing each functional requirement on most projects. Such correlations will help you estimate and scope individual release contents.

In the end, your metrics should be no more complicated than necessary to help you keep your project on track and make future projects even more successful. What do you need to know about your requirements?