Team Skill 6: Building the Right SystemAssessing Requirements Quality (29)

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

Assessing Requirements Quality•How to define quality?

▫Absence of defects

▫System conformance to requirements

▫Good enough software

▫Situational and objective

▫Others??

3

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

Assessing Requirements Quality•Quality Artifacts

▫Problem statement Root cause analysis

▫System model▫Business use-case model

Stakeholders & users Design & development constraints

5

Assessing Requirements Quality•Quality Artifacts

▫Understanding needs Interview

Questionnaires

User needs

Use cases

6

Assessing Requirements Quality•Quality Artifacts

▫System Defined Use Cases

Additional Technical Documents

7

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

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

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

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

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

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

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

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