Performing the Assessment


The elements of the requirements sets in the rightmost column of Table 29-1 are tangible artifacts that can be reviewed, assessed, and reasoned about. However, since the process is iterative, the question naturally arises as to how to measure artifacts that are changing over time and are, technically speaking, never complete. In other words, can we actually measure something that is moving without stopping it first? Well, of course, we have to try. The answer to our dilemma is twofold.

  1. We have already put in place an iterative process whereby the objective evidence of the iterations themselves are the primary quality measures. Everything else is secondary.

  2. We can apply secondary measures by assessing each of the requirements artifacts at each iteration, or at any iteration we choose, by looking at the various aspects of quality that each artifact should contain at that point in the development process.

With respect to the latter, we'll see artifacts with varying breadths and depths of completeness over time. In order to assess them, we just have to know what to expect and when to expect it, and that depends on what iteration we are in. If we look to the iterative model for hints, you can envision that the state of these artifacts evolves over time, perhaps as Figure 29-2 illustrates. At each checkpoint we simply need to understand what level of completeness we should have achieved by that state and then assess accordingly .

Figure 29-2. Completeness of requirements sets at various iterations



Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257 © 2008-2017.
If you may any questions please contact us: