Read this Knowledge nugget if you want to learn what Requirements Traceability is, what the objective of requirements Traceability is, how it works and how you can do it.
The aim of Requirements Traceability in a Software Development project is to document where – and if – in the solution particular requirements are addressed. Since we have different types of requirements with different granularity, Traceability can have multiple dimensions. To illustrate what I have said above, we can imagine it like this:
- Business Requirements are created on based on business cases
- Business requirements are refined into system requirements for particular systems.
We distinguish two kinds of system requirements:
- Functional Requirements, and
- Non-Functional Requirements.
- System requirements
- Functional Requirements are refined as Use Cases, possibly Business Rules and Functional Components.
- Non-Functional Requirements are refined and documented as Architectural Decisions, Architectural Designs and Technical Components.
Reversed, this means:
- Trace a Use Case, Business Rule or Functional Component back to the Functional Requirement it originated from.
- Trace a Technical Component and/or a Technical Decision back to the Non-Functional Requirement it originated from.
- Trace Functional and Non-Functional Requirements back to the Business Requirements they originated from.
It is important to note that the cardinality between the different levels of refinement is not limited to 1 to n or 1 to 1. It can also be n to 1. For example a business requirement can result in many system requirements, but a system requirement can also implement many business requirements, etc.
This enables you to reach two objectives:
- Identify where in a system a particular requirement has been implemented. This lets you, for example, judge the impact a change to a particular requirement is going to have on a system because you can see which parts of a system are going to be impacted.
- Make sure that all the business- and/or system-requirements have been covered by the solution developed.
There are a number of very good Requirements Management Tools on the market that assist you in doing this. But, at the least, it should enable you to reach the two objectives stated above.
Requirements Management tools do, however, add some overhead and complexity to a project. If a project is of significant size it will in most cases be more manageable to use a tool because it will assist you in keeping the large amount of requirements, system components and their relationships consistent.
If the project is of small scale a simple spread-sheet may do as well.
Figure 1 shows requirements traceability for a simple example. The scenario is that of a start-up E-Learning business which wants to provide its user a particular service level. The tables
- show some of the initial business requirements (BR),
- some system requirements (Functional Requirements (FR) and Non-Functional Requirements (NFR)) and how they trace to the business requirement,
- some Use Cases (UC) and how they trace to functional requirements,
- some Architectural Decisions (AD) and how they trace to Non-Functional Requirements.
[Pic2010] Pichler, M. 2010, “How to document Software Architecture (for Business Applications)”, A Practical Guide to Software Architecture [online] available at http://applicationarchitecture.wordpress.com/2010/02/04/documenting-software-architecture-for-business-applications/
[Pic2010] Pichler, M. 2010, “Introduction to the process of developing Software Architectures”, A Practical Guide to Software Architecture [online] available at http://applicationarchitecture.wordpress.com/2010/01/19/introduction-into-the-development-of-software-architectures/
Copyright © 2010 Michael Pichler