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?