1. Team Skill 6 - Building The Right System Part 2: Traceability, Change and Quality
Sriram Mohan

2. Outline Tracing Requirements Managing Requirements
Assessing Requirements Quality

3. Tracing Requirements

4. Traceability: Primary Questions
Why is tracing important?
What mechanisms are used for tracing?
Why we care – remember this triangle?

5. Traceability: The Problem
How do you know, if you’re at one of these later stages, that you have a requirements fault?

6. In general, how to trace…
Use Traceability matrices

7. With use cases, for instance…

8. Managing Requirements

9. Managing Change: Primary Questions
How do you capture change requests?
How do you respond to these (individually & overall)?
How does this tie-in with tracing requirements?

10. A Process for Managing Change – 1/3
Step 1: Recognize that change is inevitable, and plan for it

11. A Process for Managing Change – 2/3
Step 2: Baseline the requirements
This means they are signed-off on, and
From then on, they fall under change control – see below
Step 3: Establish a single channel to control change
No ad hoc additions
No ad hoc fixes, either

12. A Process for Managing Change – 3/3
In  this big picture, you especially need to know what “release management”  is!
Step 4: Use a Change Control System to Capture Changes Step 5: Manage Change Hierarchically
Figure on middle right from

13. Follow the link
There is a dependency between the various artifacts involved in requirements mgmt
Follow the chain and make sure that the change is propagated

14. Assessing Requirements Quality

15. Quality Issues
Products vs. Processes
Review Methods
Checklists

16. Products vs. Processes
Organizations that produce high-quality products invest in high-quality processes.
Product quality can be measured through testing.
How can we measure process quality?

17. Review Methods Informal Formal Active
Ask a peer to read and give comments
Formal
Ask a peer to prepare for review
Record and report results of review
Active
Interrogate reviewer

18. Checklists Look for anticipated defects
Some defects apply to almost all artifacts
Does the artifact exist?
Some defects are artifact-specific
Have you identified all stakeholders?

19. Problem Statement Checklist
Has a problem statement been drafted?
Is it written in an easy-to-understand way?
Does the team understand it?
Has it been circulated for agreement to the key stakeholders, including management?
Do the team members have agreement that this is the problem they are trying to solve?

20. Supplementary Specification Checklist (1/2)
Have you established an appropriate template?
Are all non-functional requirements included in the supplementary specification?
Have requirements for usability, reliability, performance and supportability been captured?

21. Supplementary Specification Checklist (2/2)
Have design constraints been identified?
Have supplementary requirements been linked to use cases where appropriate?