Statistical Process Control (SPC) for Software Process improvements is still considered as a somewhat esoteric subject amongst Software Engineering companies, especially when most of them don't apply the simplest standards and procedures in Quality Assurance. It's not enough to say or think quality, when you can't describe the activities you do to attain this goal.

In manufacturing industry, SPC has proven itself beyond doubts when it comes to turning out products of high quality and value to consumers. Without it, we wouldn't have the cars and consumer electronics we have today. But Software Engineering isn't manufacturing, as I have pointed out many times before, and SPC is probably not the quick fix organisations expect it to be. It's hard to implement, and the return may not be that obvious at first glance.

For Statistical Process Control to work at all in an organisation, I believe it need to be highly integrated and automated with existing tools, whatever these may be. It is not enough to have a standalone tool, where someone, usually in Quality Assurance, collects the metrics and feeds it to the system on a regular basis, like some hungry beast. We all know what happens when people are obliged to report such data on a manual basis in a project. It isn't done, and the data gets corrupted. It becomes a constant source of friction and irritation. We all hate when someone nags us for not doing a routine task we never see the benefit of.

So what type of metrics can you report when it comes to software requirements? There are many measurements a project can do, most of them you probably wouldn't think of. The most obvious ones are:

1. •The number of issues per requirement;
   

2. •The number of changed, added and deleted requirements per revision of the Requirements Specification (RS);
   

3. •The total number of requirements per revision of the RS;
   

4. •Readability metrics.
   

What does these measurements tell you? If you plot the number of issues per requirement in a u-chart, it will quickly tell you if the RS writing is stable or not. If the individual values fall outside the upper or lower control limits (UCL and LCL), you know if the RS isn't stable and how much it needs to be improved.

Similarly, if you plot the total number of requirements per revision of the RS in a trend-graph, you will know if the writing of the RS is levelling off or if new requirements keep coming in. It gives you a rough estimate of how much writing there is left.

Exactly which type of metrics that is important for you, is something you need to find out for yourself. Maybe you decide to measure ten different properties, but only one or two of them are used by the Project Manager to base his/her decisions on. Even this information can be used to change what you need to measure. Metrics are a great way to visualise what is happening in a process, and although it may not tell you the whole story, it can be sufficiently to help you produce outstanding software.

References: Measuring the Software Process, by William A. Florac and Anita D. Carleton.