9.13 CONSOLIDATE REQUIREMENTS

< Day Day Up >

Having got a good idea of what the requirements are and what they may involve you will need to pull it all together into a consolidated requirements specification.

The exact form of this will vary depending upon the culture of the organization, the profile of the Software Metrics project and your own personality. It may be that a structured, documented discussion session with your own manager, as the customer authority, will be sufficient or you may need to prepare a full requirements specification document with (heaven help you) a cost/benefit analysis that is supported by presentations at board level.

If at all possible, I would suggest that you aim for a middle ground. Going to the board of directors at this point can be dangerous because you have really only identified the problems that need to be addressed. You do not have solutions. Simply talking things over with your manager means that the requirements may be subject to fairly dramatic changes and this can cause serious problems later.

I would suggest that you group the various identified requirements into goals. For example, you may have the following set of identified requirements linked to specific customer groups:

Improve cost estimation techniques for enhancement projects — Product Development Team Leaders.
Improve cost estimates that feed into the planning process — Planning Manager
Sort out our estimates, if we get hit by another fiasco like that last fixed price contract we won't need a metrics program because we won't be here! — Systems Development Director.

With any luck you have identified a common theme here. The goal or consolidated requirement becomes:

"To improve the cost estimation process."

Alternatively, you may have identified requirements that go something like:

We need some way to focus limited testing effort on the components that need testing most rigorously — Test and Integration Manager.
We are discovering faults too late, we need to sort them out earlier — Software Development/Enhancement Manager.
Our inspections are a joke. We need some objective criteria that will get rid of the subjectivity in deciding when a design is good enough — Senior Software Engineer.
Why don't we use Information Flow Metrics like they said at university? — Junior Software Engineer.

Now this one is a bit more difficult to consolidate, but it does illustrate that you should have talked to all the levels in the organization. What it boils down to is something like:

"Identify and implement non-subjective techniques that can identify error-prone components at the inspection stage, or earlier, of the design phase."

You may also make a note to ask that junior engineer what these Information Flow metrics are! A typical set of consolidated requirements, expressed very loosely, may look like this:

"Improve cost and size estimation."
"Improve project control procedures."
"Provide management information about performance, covering productivity and achieved quality."
"Address the prediction of quality attributes prior to release."
"Address the assessment of designs and requirements."

Of course this may not be an exhaustive set and each goal should be expressed more precisely, at least as precisely as the earlier examples. There may well be sub-goals or requirements within the high level expression, for example management information about achieved quality may be confined to reliability and maintainability or it may cover many more of the so called "-ities."

You should also link each consolidated requirement to a set of primary and secondary customers. The primary customer will effectively be the individual, or functional group, that will decide whether or not you have satisfied the requirement. The secondary customers are those who have a view of what you deliver and will be expected to provide information to help you satisfy the requirement. For example, the primary customer for productivity information may be the Product Group manager, he or she being the person who has asked for that information. However, project managers and engineers are also customers, albeit secondary in this case, of the system that will be put in place to satisfy the primary customers requirement. It is the project managers and the engineers who will have to supply the information that will eventually result in productivity reports to the Product Group Manager.

< Day Day Up >