1. Team Skill 6: Building the Right System Assessing Requirements Quality (29)

2. Assessing Requirements Quality Key points ▫The end of each iteration can be used as a point to check quality  Beta issues  Defects found in GA version ▫Devise metric for quality and accuracy of each iteration ▫Refinement of requirements happens each iteration 2

3. Assessing Requirements Quality How to define quality? ▫Absence of defects ▫System conformance to requirements ▫Good enough software ▫Situational and objective ▫Others?? 3

4. Assessing Requirements Quality How to measure quality? Measurements ▫Time to market ▫At or under budget ▫Requirements scoped out are realized The quality of the software is a reflection of the quality of the process that created it 4

5. Assessing Requirements Quality Quality Artifacts ▫Problem statement  Root cause analysis ▫System model ▫Business use-case model  Stakeholders & users  Design & development constraints 5

6. Assessing Requirements Quality Quality Artifacts ▫Understanding needs  Interview  Questionnaires  User needs  Use cases 6

7. Assessing Requirements Quality Quality Artifacts ▫System Defined  Use Cases  Additional Technical Documents 7

8. Assessing Requirements Quality Quality Artifacts ▫Managing Scope  Prioritization / estimation of Use Cases  Risk  Effort  Baseline Requirements  Scope  Meets your resources  Agreement on what will be done 8

9. Assessing Requirements Quality Quality Artifacts ▫Refining the system  Use Case Model  How all the Use Cases interact  Defining our system boundary and all actors on the system  Supplementary specification (URPS+)  Technical specifications 9

10. Assessing Requirements Quality Quality Artifacts ▫How we ensure we have Build the right system  Traceability!  needs - features - reqs – use cases - code - tests  Code that captures the design of the Use Cases  Test cases test the results of the Use Cases  Change control process 10

11. Assessing Requirements Quality Page 361-368 A lot of these are very course ▫Not detailed enough to get actual quality measurement ▫Basically was this process done  What metrics are they using for measuring quality? 11

12. Assessing Requirements Quality Leffingwell address quality on a very basic level ▫If no measurements are provided no assessment can be done Remember we compared developing software to manufacturing ▫Manufacturing is highly monitored to develop the best process 12

13. Assessing Requirements Quality Quality product needs quality process How is this done? ▫We must gather data throughout the process that we can compare against Then we can analyze the data ▫Determine what’s working ▫Determine what’s not working Then we can identify areas that need improvement 13

14. Assessing Requirements Quality A process that does not include metrics, cannot substantiate a claim for the quality of the process. This then trickles down into quality of the software product 14

15. Assessing Requirements Quality Some benchmarking includes ▫The number of defects in the code ▫Common measurement is  Defects / KLOC This gives you a good quality measure because ▫Code comes from Use Case and traced back to other artifacts (TSP/PSP other standards to improve coding) ▫Code is the final artifact and is the actual system ▫If you have poor code it is probably the result of poor documentation leading up to development phase 15