1. Software Requirements Specification Quality Measures Derived from Dr. Fawcett’s slides Phil Pratt-Szeliga Fall 2009

2. Requirements Quality Measures: Overview  Requirements should be Legally complete Unambiguous Absolutely consistent Testable and no design detail

3. Requirements Quality Measures: Legally Complete  All requirements are specified with binding “shalls”  Complete description of behavior and appearance Allocated (A-Spec) requirements full elaborated Adequate derived requirements  Traceability between A and B levels

4. Requirements Quality Measures: Unambiguous  Requirements need no interpretation and should be read very literally  This depends partly on the expertise of the participants Customer Developers

5. Requirements Quality Measures: Absolutely Consistent  Context Diagram and all levels of Data flow diagram balance. Flow names match in spelling and case  Data dictionary lists all data flows as shown in the above diagrams with exact spelling and case  Fairly uniform level of detail in each leaf node process description  Paragraph numbers match data flow diagram numbers

6. Requirements Quality Measures: Testable and No Design Detail  Requirements have no adjectives or adverbs: no best, maximum, highest, lowest, etc  No design details. No requirements on: Data transfer Implementation strategy Data structures Control  Most requirements should be tested by Demonstration

7. Testing Requirements  Qualification test types Inspection Demonstration Analysis Test  Inspection and Demonstration are the cheapest and most reliable test types This pleases both the customer and developers  As the number of Tests by Analysis and Test increases the quality of the specification decreases