Download presentation
Presentation is loading. Please wait.
Published byRolf Allison Modified over 9 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.