At Object Consulting, we advocate that teams clearly articulate their traceability strategy to avoid pursuing traceability for traceability’s sake.
Starting with the basics - Why do traceability?
Traceability is:
-
Useful to support the ripple effects of changes during discovery and definition of requirements
-
Useful to highlight problem areas, e.g. understanding Use Case interactions
-
Useful to assess whether all requirements have been covered (e.g. high level user requirements through to functional Use Cases and design)
-
Typically complex and only effective if it is manageable!
-
Possible to do manually – but not much fun without an appropriate tool!
The following are some key considerations (derived from Requirements Engineering) that I recommend every team consider – and periodically revisit throughout a project – when pursuing, developing or reviewing a traceability strategy:
Two-way traceability can and typically should be established between requirements for:
-
Impact Analysis - to assess the impact of changes and defects.
-
Coverage Analysis - to assess whether all requirements have been covered (e.g. high level requirements through to lower level functional Use Cases).
-
Derivation Analysis - ability to answer the question “Why is this here?” in support of cost/benefit analysis.
-
Consistency – to ensure consistency of terminology and key concepts between different requirements artifacts.
Additionally, Traceability from the requirements to other project deliverables, such as the design and testing deliverables, can and typically should be established for:
- Impact Analysis - to assess the impact of changes and defects.
- Coverage Analysis - to assess whether all requirements have been covered by design / implementation / testing etc.
- Derivation Analysis - ability to answer the question “Why is this here?” in support of cost/benefit analysis.
- Consistency – to ensure consistency of terminology and key concepts between different all project artifacts.
However, every project IS different, and careful and ongoing consideration of the above should be given to ensure that you derive real benefit from your traceability initiative and avoid simply pursuing traceability for traceability’s sake!
Carl Rogers - Principal Consultant & Process Development Architect