A review of the Software Requirements Specification (and/or prototype) is conducted by both the software developer and the customer. Becaus...
A review of the Software Requirements Specification (and/or prototype) is conducted by both the software developer and the customer. Because the specification forms the foundation of the development phase, extreme care should be taken in conducting the review.
The review is first conducted at a macroscopic level; that is, reviewers attempt to ensure that the specification is complete, consistent, and accurate when the overall information, functional, and behavioral domains are considered. However, to fully explore each of these domains, the review becomes more detailed, examining not only broad descriptions but the way in which requirements are worded. For example, when specifications contain “vague terms” (e.g., some, sometimes, often, usually, ordinarily, most, or mostly), the reviewer should flag the statements for further clarification.
Once the review is complete, the Software Requirements Specification is "signedoff" by both the customer and the developer. The specification becomes a "contract" for software development. Requests for changes in requirements after the specification is finalized will not be eliminated. But the customer should note that each afterthe- fact change is an extension of software scope and therefore can increase cost and/or protract the schedule.
Even with the best review procedures in place, a number of common specification problems persist. The specification is difficult to "test" in any meaningful way, and therefore inconsistency or omissions may pass unnoticed. During the review, changes to the specification may be recommended. It can be extremely difficult to assess the global impact of a change; that is, how a change in one function affects requirements for other functions. Modern software engineering environments incorporate CASE tools that have been developed to help solve these problems.
