Requirements traceability – why and how to do it?

Posted on by

Most probably, at some point in their careers, the majority of Business Analysts have found themselves in a situation when someone (Project Manager, Sponsor, Product Owner, other Analyst, etc.) posed one of these inconvenient questions which usually go along the following lines: “Where does this requirement come from?”, “What will happen if we change it?”, “Can we give it up? What will happen then?”. The right answer to these questions, surprisingly, may be quite significant. Especially, in case of large projects where multiple requirements are involved. In all these scenarios, the traceability of requirements may come handy.

“Vertical” requirements traceability

In one of my previous posts, I’ve described the classification of requirements and their hierarchy. The hierarchy itself, along with creating links between higher level requirements and their lower level counterparts allow to trace the way how the higher level ones were decomposed. Therefore we can create a relation starting from the business needs through to the business requirements related to them, and further, from particular business requirement to the stakeholders requirements (which play a supporting role), ending on solution requirements.

Thanks to relating requirements this way, we are able to trace the origin of lower level requirements (decomposition of which higher level requirement resulted in certain lower level requirements?). Additionally, we are able to tell which set of the lower level requirements must be implemented in order to have the higher level requirement fulfilled. This in turn, allows us to determine consequences of making changes to particular requirements, or removing some of them altogether. Being aware of how the requirements relate to each other allows us to know which elements are connected to the bit we want to change or remove. It also enables potential impact analysis of the proposed change.

An additional advantage arising from requirements tracing of this type, is that it facilitates the search for inconsistencies (for example, inconsistencies occurring between the different level requirements) and allows easier identification of potential gaps. We may, for example, realize that a certain higher level requirement (e.g., business requirement) does not have any related lower level requirements. This may signal that the requirement was not decomposed correctly and might have been skipped. It is always worth further investigation.

“Horizontal” requirements traceability

The „same level requirements” may also be traced. Two types of relations are usually identified then. First of those is called the necessity of implementing one requirement so the implementation of another one becomes possible. The other type is lessening the implementation effort invested in one requirement by implementing another. This type of tracing is also very useful when assessing the impact a change in one set of requirements may have on the implementation of other requirements.

Tracing requirements and other artifacts

The third type of relations which may occur are the ones linking the requirements and other artifacts. These artifacts may be, for example, designs, tests or code (for example, revisions or commits). When creating and tracing these type of relations, we can easily verify if for a given requirement there is one or maybe more designs, or whether a test exists which verifies it, or a piece of code which implements this requirement.

Naturally, the relation between a given requirement and other artifacts is not the only relation that may occur. There are also relations between particular artifacts, like for example, between design and the code which implements it or between the code and the test procedure which is there to verify its correctness.

The right level of detail

To be able to trace the requirements effectively, it is essential to reach the right level of detail. This means staying reasonable and not trying to relate each requirement with every other one, just for the sake of it. Admittedly, it may seem sometimes that one requirement impacts almost all others but also the other way around, almost all requirements may seem to impact this particular one. Nonetheless, when tracing requirements, try to be sensible. The mutual dependencies of related requirements should be clear, understandable and transparent to the recipient.

The more carried away you get, creating surplus, non-transparent relations, the more difficult it will be to manage them. They soon go out of date and in consequence, become useless. This should be avoided, in accordance to the rule described in one of my previous posts.

The summary of benefits

To sum up the benefits of tracing the requirements, I would first name the following advantages: easier to assess what impact a change to some requirements will have on the others, easier to find inconsistent or ambiguous requirements, increased chance of discovering gaps or identifying skipped requirements. Additionally, we can track the work progress of a given requirement by checking the artifacts linked to it (e.g. designs, tests or code).

How to trace requirements?

Off course, there are many advanced systems to manage requirements, such as for example, Jira (and the entire Atlassian ecosystem), solutions provided by Microsoft company, or the Enterprise Architect program, to name just the few. These tools allow to create and manage relations between the requirements in a convenient and effective way.

However, the “basic” version of tracing the requirements may be conducted even when maintaining our requirements as simple text files. It is a good practice though to give each requirement a unique identifier just to distinguish it from others. You can use this identifier as a reference in other requirements and create relations this way. It’s not the most convenient or effective way, but still possible.

My recommendations

  • Create and manage relations between more general requirements and those resulting from their decomposition
  • Create and manage relations between requirements if the implementation of some of them is essential or facilitates the implementation of others
  • Link other artifacts to your requirements, such as solution proposals or tests
  • Define the right level of detail, stay reasonable, do not link the requirements just for the sake of it

Sources

Agile Extension to the BABOK® Guide. Version 2. 2017.