Chapter 14. Reviewing the Specification


in which we decide whether our specification is correct and complete, and set the priorities of the requirements

At some stage in your requirements process, you will want to release your specification. It does not have to be complete at this stage: it could be a partial version for the next iteration; a version of the specification you want to publish for marketing reasons; or any other version. But before releasing the specification, you need to review it.

We use the term "specification" here to mean whatever collection of requirements you have. It does not have to be a paper specification. It does not even have to be formal; it could be a blog, wiki, or something similar. It might hold only the requirements for the next release. Whether it is complete remains to be seen. Whether it conveys the correct information also remains to be seen. This review ensures the specification is fit for its intended purpose before you hand it over to anyone else.

Figure 14.1 illustrates how the Quality Gateway and the specification review work together. The Quality Gateway tests an individual requirement, ensuring it is correctly stated, unambiguous, within scope, testable, traceable, and not gold plating. When a requirement successfully passes through the Quality Gateway, you can have confidence in the correctness and viability of that requirement.

Figure 14.1.

You have arrived at the point in the process where you want to consider the specification as a whole. The Quality Gateway has tested and accepted individual requirements, which were then allowed into the specification. Now it is time to assess the requirements as a complete specification.


Chapter 11 discusses the Quality Gateway in depth.


But what about the specification as a whole? You know it is made up of correct requirements, but collectively do they tell the whole story? Before passing the specification along, you must review it with following points in mind:

  • Determine whether any requirements are missing.

  • Prioritize so the builders understand the importance and the urgency of the requirements.

  • Check for conflicts between requirements that could prevent one or the other from being satisfied.

Additionally, your project management should perform two tasks:

  • Estimate the cost of construction.

  • Evaluate the risks faced by the project.

This review of the requirements specification can be carried out at any time; ideally, it should be an ongoing activity. You might, for example, review the specification as a check on the progress of the requirements activity. The quality (or lack thereof) of the specification tells you more about progress than its volume does. You might also review a partial specification. That is, given that you are working with an iterative cycle and want to review the requirements for a small number of selected product use cases, you might wish to proceed with building them while the analysts continue gathering the remainder of the requirements.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net