5.1.1 Purpose
The purpose of Trace Requirements is to ensure that requirements and designs at different levels are aligned to one another, and to manage the effects of change to one level on related requirements.
5.1.2 Description
Requirements traceability identifies and documents the lineage of each requirement, including its backward traceability, its forward traceability, and its relationship to other requirements. Traceability is used to help ensure that the solution conforms to requirements and to assist in scope, change, risk, time, cost, and communication management. It is also used to detect missing functionality or to identify if there is implemented functionality that is not supported by any requirement.
Traceability enables:
- faster and simpler impact analysis,
- more reliable discovery of inconsistencies and gaps in requirements,
- deeper insights into the scope and complexity of a change, and
- reliable assessment of which requirements have been addressed and which have not.
It is often difficult to accurately represent needs and solutions without taking into account the relationships that exist between them. While traceability is valuable, the business analyst balances the number of relationship types with the benefit gained by representing them. Traceability also supports both requirements allocation and release planning by providing a direct line of sight from requirement to expressed need.
The following images show examples of visual representations of traceability for a process and for software requirements.
5.1.3 Inputs
- Requirements: may be traced to other requirements (including goals, objectives, business requirements, stakeholder requirements, solution requirements, and transition requirements), solution components, visuals, business rules, and other work products.
- Designs: may be traced to other requirements, solution components, and other
work products.
5.1.4 Elements
.1 Level of Formality
When tracing requirements, business analysts consider the value that each link is supposed to deliver, as well as the nature and use of the specific relationships that are being created.
The effort to trace requirements grows significantly when the number of requirements or level of formality increases.
.2 Relationships
There are several types of relationships that the business analyst considers when defining the traceability approach:
- Derive: relationship between two requirements, used when a requirement is derived from another requirement. This type of relationship is appropriate to link the requirements on different levels of abstraction. For example, a solution requirement derived from a business or a stakeholder requirement.
- Depends: relationship between two requirements, used when a requirement depends on another requirement. Types of dependency relationships include:
- Necessity: when it only makes sense to implement a particular requirement if a related requirement is also implemented.
- Effort: when a requirement is easier to implement if a related requirement is also implemented.
- Satisfy: relationship between an implementation element and the requirements it is satisfying. For example, the relationship between a functional requirement and a solution component that is implementing it.
- Validate: relationship between a requirement and a test case or other element that can determine whether a solution fulfills the requirement.
.3 Traceability Repository
Requirements traceability is documented and maintained in accordance with the methods identified by the business analysis approach. Requirements management tools can provide significant benefits when there is a need to trace a large number of requirements that may be deemed unmanageable with manual approaches.
5.1.5 Guidelines and Tools
- Domain Knowledge: knowledge of and expertise in the business domain needed to support traceability.
- Information Management Approach: provides decisions from planning activities concerning the traceability approach.
- Legal/Regulatory Information: describes legislative rules or regulations that must be followed. These may need to be considered when defining traceability rules.
- Requirements Management Tools/Repository: used to store and manage business analysis information. The tool may be as simple as a text document or as complex as a dedicated requirements management tool.
5.1.6 Techniques
- Business Rules Analysis: used to trace business rules to requirements that they support, or rules that support requirements.
- Functional Decomposition: used to break down solution scope into smaller components for allocation, as well as to trace high-level concepts to low-level concepts.
- Process Modelling: used to visually show the future state process, as well as tracing requirements to the future state process.
- Scope Modelling: used to visually depict scope, as well as trace requirements to the area of scope the requirement supports.
5.1.7 Stakeholders
- Customers: are affected by how and when requirements are implemented, and may have to be consulted about, or agree to, the traceability relationships.
- Domain Subject Matter Expert: may have recommendations regarding the set of requirements to be linked to a solution component or to a release.
- End User: may require specific dependency relationships that allow certain requirements to be implemented at the same time or in a specific sequence.
- Implementation Subject Matter Expert: traceability ensures that the solution being developed meets the business need and brings awareness of dependencies between solution components during implementation.
- Operational Support: traceability documentation provides another reference source for help desk support.
- Project Manager: traceability supports project change and scope management.
- Sponsor: is required to approve the various relationships.
- Suppliers: are affected by how and when requirements are implemented.
- Tester: needs to understand how and where requirements are implemented when creating test plans and test cases and may trace test cases to requirements.
5.1.8 Outputs
- Requirements (traced): have clearly defined relationships to other requirements, solution components, or releases, phases, or iterations, within a solution scope, such that coverage and the effects of change are clearly identifiable.
- Designs (traced): clearly defined relationships to other requirements, solution components, or releases, phases, or iterations, within a solution scope, such that coverage and the effects of change are clearly identifiable.
