Importance of Requirements Traceability

Requirements Traceability

Requirements Traceability is one of the most vital activities of effective requirements management. It pertains to recording links/associations among business needs/requirements, solution requirements and components used for implementing the solution requirements. Requirements Traceability is used to help ensure that the solution conforms to business objectives and assist in managing requirements, ensuring scope coverage and foster thorough impact analysis.

All projects do not require same degree of traceability. Some small & less complex projects apply traceability by just linking functional requirements to individual tests that verify the correct implementation of those requirements. Projects of large size or high complexity or those which are a part of highly regulated environment may require traceability to be employed at a more in-depth level. Moreover, it needs to be considered that conducting nominal traceability may lead to project risks and carrying out heavy traceability may be cumbersome and require extensive management. Hence, key business stakeholders need to determine the appropriate level of traceability to be performed taking the aforementioned factors into consideration. Depending on the level of traceability to be maintained, the decision can be taken on whether a spreadsheet will serve the purpose or requirement management tool need to be employed which can manage large number of requirements with ease.

The essential components/deliverables that can be linked as a part of traceability activity include business needs or business requirements, stakeholder requirements, solution requirements (Functional requirements/Non-functional requirements, high level/low-level design components, code/Implementation components, test cases (unit test cases, integration test cases, system test cases and user acceptance test cases).

Requirements Traceability Classification:

Requirements Traceability can be classified as –

Forward Traceability:

It refers to tracing the requirements sources i.e. business requirements/needs to their resulting solution requirements or tracing each solution requirement forward to the work products i.e. design, code and the test components for that requirement.

Backward Traceability:

It refers to tracing each unique work product i.e. design element, code element, test case back to its associated requirement or tracing each requirement back to its source.

Bi-directional Traceability:

It is a unification of Forward Traceability and Backward Traceability. It refers to both tracing the requirements forward to work products and tracing the work products back to the requirements. Same goes for requirement sources and the requirements.

Benefits of Requirements Traceability

Business Value:

• Ensures that each requirement provides business value – Tracing each requirement back to the business need or objective helps ensure that the requirement is relevant and adds business value. If a requirement is unable to be traced back to the business need, It should be validated if the business needs were stated at all or if stated, was it accurate or not. There may also be a possibility that a business need does not have associated requirements in which case these should be captured to ensure that business objectives are met. Also, traceability also helps validate that the business needs that are mapped to the requirements belong to the project or are misaligned mistakenly.

Scope Coverage:

• Ensures that scope coverage is as per the stakeholders expectations – Since traceability artefacts contain business requirements as well as solution requirements, it help the stakeholders ensure that complete business and solution scope has been covered and there are no misses whatsoever. It helps discover requirement dependencies as well any missing, inconsistent and redundant requirements that might affect project delivery and the ultimate business goal.

Thorough Impact Analysis

• Faster and thorough impact analysis by providing deep insights into scope and  complexity of change – If there are changes in a business objective/need or business rule or regulatory standards or any other change that affects the business requirement, then traceability can help understand the impact of this change by tracing the business requirement forward to the associated requirements and all of the work products that are impacted by that change. This reduces the amount of effort required to do a thorough impact analysis considerably. It also reduces the likelihood that one of the impacted work products is missed thereby resulting in an incomplete implementation of the change. In another situation, if a defect is identified in code and it looks from the first level analysis that the cause lies within design or requirements then these documents can be identified by tracing backwards. If it is indeed a design or requirements defect, than the other work products impacted by it can be identified by tracking forward and changed accordingly.

Release Planning and Requirements Allocation

• Supports release planning and requirements allocation – Requirements traceability act as a single source of complete set of requirements for a project. It thereby enables allocation of requirements to releases since the requirements as well as the dependencies among requirements are mentioned in the traceability artifacts.

Reliable Assessment of Requirements

• Provides a reliable assessment of which requirements have been addressed – Provided the stakeholders are in agreement on this, traceability artifacts can also be used to assess the status of implementation of requirements and get a clear picture of which requirements are implemented and which are yet to be implemented. Thus, the stakeholders can get a fair idea of the overall implementation status.

Requirements Traceability Matrix

Requirements Traceability is carried out through construction of what is known as a Requirements Traceability Matrix (RTM). As the name suggests, it is a grid that enables linkage of original business needs to their associated solution requirements and then on to other work product elements that implements them. The requirement matrix is a single repository for enabling both forward and backward traceability across requirements and associated work products and hence it is a very valuable artifact.

In case an organization has already defined an RTM template then it can be leveraged by the business analyst but in absence of such a template, it needs to be created in consensus with business stakeholders. While defining an RTM template, the concerned decision makers should exercise caution in selecting the attributes that should be included in RTM.

RTM creation can start as soon as first requirement is defined. As existing requirements are further elaborated and new requirements are added, RTM keeps getting upgraded. As new requirements are added, they are evaluated for dependencies. Business Analyst collaborates with the required stakeholders to determine at what point the traceability matrix can be deemed as complete.

Attributes of RTM

Typical attributes used in an RTM may include (but not limited to):

• Requirements ID (for unique identification of requirement)
• Requirements Type (Functional/Non-functional/Transition/Any other)
• Requirements Summary
• Business Requirement (Business need or objective)
• Design – High-level design and Low-level design
• Test cases – Unit test cases, System test cases, User acceptance test cases
• Related Requirements ID
• Priority
• Status (Open, Completed, Deferred, Cancelled)
• Date Completed

Each requirement, requirements source and work product element must have a unique identifier associated with them to identify them in a unique manner. As regarding relationships/dependencies between requirements, requirements source and work products, BABOK (Business Analysis Body of Knowledge) v3 has fittingly defined the below relationships –

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.

Below is an illustration of how a basic requirements traceability matrix looks like (as explained earlier, it may vary based on project requirements)

Final Thoughts on Requirements Traceability

Despite of the multi-fold benefits that requirements traceability provides, it continues to be one of the most under-utilized concepts of requirements management. Most organizations put it to practice only when they have to act in accordance with the regulatory compliance and standard needs imposed on them. Organizations should definitely give a thought to include requirements traceability as a practice, especially in large-scale projects, in order to reap benefits in the form of ensuring scope coverage, increased ability to perform meticulous impact analysis, identifying gaps & inconsistencies in requirements and most importantly, achieved the desired business objectives.