I have heard a leader describe the technology / software world as a practice of "dark art". I agree with the perception and can see how it may appear to be a world of esoteric mysticism. However, as a technologist, let me reassure the reader that the existence of any successful technology has a clear, business-level, plain-language explanation. One of the main methods to provide clarity is the use of Traceability:

"The ability for tracking the relationships between sets of requirements and designs from the original stakeholder need to the actual implemented solution." (IIBA)

This is the Business Analysis Body of Knowledge (BABOK) definition of Requirements Traceability. Implicit in the definition is that the stakeholder's (business) objective gives meaning and purpose to the implementation: thereby a hierarchy with the organisational Need being the key reference point to deliver on the overall Business Value (Marchewka 2003).

What is it? Key to the understanding of traceability is its relational nature. It shows how something is linked to something else. Typically, the relationship is illustrated as a matrix: a tabular, two-dimensional view of an implementation mapped to a requirement (Marchewka). In the below example, the implementation is a Product Description. This expression is very useful for project managers as it provides just enough detail to plan and maintain the high-level scope, and thereby risk, change requests and their impact.

Traceability Matrix (Marchewka)

Beyond the Requirement / Implementation mapping, it becomes evident that these relationships flow in multiple directions vertically and horizontally through the hierarchy. The below diagram shows the hierarchy of User Needs and the relationships through to analysis, design and test cases.

"Task: Structure Requirements for Traceability" (BABOK)

For larger and more complex projects, it becomes easier to see the true nature of these relationships as more than a two-dimensional view. They are more accurately represented as a relationship Network. One of the common expressions is Graph Theory. This is how Samuel Brown expressed some of the complexities of traceability in his projects at the National Aeronautics and Space Administration (NASA) as can be seen in the below diagram. Each box represents a requirement and the number is the requirement identifier.

Brown S. (2016)

OK, so what? So now we have some context around what it is and how it is commonly represented, let us discuss how it is used.

How: A reader of the traceability graph can quickly find out the design, implementation method or engineering that explains the realisation of the original organisation need or objective, simply by following the links from the need to the final implementation. For example, in the above Brown diagram, the requirement with the red box #2295 may not yet be implemented.

Why: A business person may enquire "Why?" as to the reason for an implementation or design. This can be answered by the traceability graph because the reader can trace the links back to the original organisational need or objective.

Unfinished Business: incomplete or unfinished implementations are quickly visible where there are nodes that are at the end of a line of traceable elements or "orphan" nodes.

Over-engineering: Implementations or designs that have no links to the original business need may not deliver measurable organisational value for the organisation. Another way of viewing this and other risks revealed by raw traceability is often termed "requirement misalignment".

Hot Topics: Some nodes in the traceability graph may have a large number of links, which may be an indicator of importance and / or high investment. These nodes may be worth some deeper analysis to confirm that the high investment is warranted.

So have a chat today with your solution architect or project manager about how they are reporting traceability. Chances are you will be able to get better clarity and shed new light on your project or system. The information they share may lead you to a new understanding of how effective your project will be able to deliver value to your organisation.

References