Trends in the Requirements Management Discipline

The requirements management discipline takes on even more importance on a project employing iterative development, such as projects that use the Rational Unified Process. On iterative development projects, requirements are not static, and they are not all collected up front. As a result, requirements must be carefully tracked. One metric I have used in the past is to plot the number of requirements successfully implemented and tested on a project. An example is shown in Figure 15-7. I like to print graphs like these on a plotter and post them in public areas in the project facility, such as near printers or break/conference rooms.

Figure 15-7. Graph of implemented functionality over time

Tracking requirements in this fashion serves three purposes. First, it gives the team a sense of accomplishment. Although developers focus on technology and building things, most want to know that their efforts are accomplishing something useful and are helping further the project's goals. Second, such a graph can be included in presentations to customers. (However, not all customers are interested in demonstrations, particularly finance and contracts personnel.) Graphs such as these provide another sense of getting closer to the project goals. Finally, you can study the graph to ascertain and provide data on the time and resources required to produce something tangible on a project. This can help with estimates for future projects and proposals.

Finally, note the "glitch" in the first iteration in this project's Elaboration phase. It is not uncommon to have some occasional "backward" progress early in the project. This is not a reason to panic, provided that it occurs for the right reasons. Figure 15-7 represents an actual project. On this project, a candidate architecture was chosen, and some key requirements were implemented to test the architecture. Problems were encountered during the testing of these requirements. This led to a decision to partially change the architecture and reimplement the requirements to test it. This second attempt was successful.

This is an example of "healthy" failure. It was discovered early in the project, through a deliberate effort to implement a high-risk portion of the system. If this situation occurred many times, or occurred much later in the project's life cycle, it would be cause for concern and would warrant investigation to take corrective action.

Another interesting item of data to collect is the amount of time between when a requirement is identified and when a tested, correct implementation of that requirement appears. Again, individual data items are not terribly useful, but together they are illustrative.