Traceability: Join the dots


Definition: Traceability is the ability to verify the history, location, or application of an item by means of documented recorded identification


This article provides an in depth study on the concept of traceability, together with its implications and applications within a business context. Traceability is a term used in the IIBA BABOK, among other professional practices, in the context of requirements where requirements are said to be traced that provides alignment of requirements to each other. This implies that there are different classes or abstractions of requirements such as stakeholder, business and functional requirements. Traceability allows the alignment between all types or abstractions of requirements, telling a kind of story to how they all interrelate.  Traceability is a powerful phenomenon that is generalized and presented as a universal tool in making sense of information in ambiguous and sometimes complex business scenarios. Indeed its implications and applications go far beyond mere requirements.

The Concept

Business Analysis Context

Returning to the IIBA context of traceability in Business Analysis, as the definition presents, it allows the alignment between requirements to be known. It is said that traceability exercised by either moving forwards (Allocation) and backwards (Derivation) in abstraction. This can be illustrated by the image below;

Higher level abstraction                                                         Lower level abstraction







Generalist Context

Traceability also can be extended to a more general context where the act of tracing can occur not just backwards and forwards, but also up, down and around, or any way from a point of origin to a destination. This implies that a series of concepts can be coupled through associations or links. (I.e. mind map.) This allows concepts to be interrelated through associations that loosely couple concepts together. For example a mind map could have the following concepts; building, architect, materials and bulldozer.

These associations are all different and have little to do with abstraction, but allow concepts to be linked with a level of coupling that established a relationship between two or more concepts.

This forms the more generalist definition of tractability where the act of traversing or ‘tracing’ between related concepts is consistent.

Taxonomy of Traceability

Expanding on the business analyst and generalist versions of tractability, the following elements define the fundamental taxonomies of what makes traceability possible.


The concepts represented as dots form the basis of traceability. Without concepts, nothing can be connected to nothing else. An example of a concept would be a business requirement or a functional requirement.


This is the second essential constituent of traceability. The connection between one or more concepts or dot’s. The connection can be seen as a relationship that gives meaning or significance to the two or more connected concepts. An example of this would be the expression, “An ‘architect’ designs a ‘building’”.

As more connections are made between concepts within the same domain or scope, a picture is formed that unites concepts at a higher level of meaning and order. Greater connectivity between concepts increases synergies and alignment providing greater and greater meaning. Considering the expression “Join the dots”, is a clear indicator that as more and more dots are joined and more relationships are established, high levels of order and connectivity are established revealing a deeper and convergent underlying meaning.


Once concepts have been connected with meaningful relationships, movement or traversal is possible between them. As more and more concepts are connected with relationships, traversal is possible not just between two concepts, it can occur up to N connections. (N is the number of possible hops in the relationship chain.)

This implies that relationships can actually extend across multiple concepts thus changing the scope of the relationship. For example 6 concepts connected in a linear series implies 5 individual relationships in one direction and another 5 in the other. One can derive 10 individual relationships in total. If one considered pairs of relationships instead (Two connections equals a high order relationship) there is a different implication. If the series of concepts were all interconnected with each other, the number of relationships, combinations would be an order or magnitude greater. i.e. 6^6. And so on. As the number of concepts increases, so does the possibilities for interconnections.

The important point here is that if concepts are presented within a domain, they potentially can be connected, and where there is connections, this traversal can occur that can be visualized like a frog leaping from lily pad to lily pad.

For business analysis, stakeholder, business, functional requirements can be traced. This implies the following;

·        All stakeholder requirements can be traced to all business requirements

·        All business requirements can be traced to all functional requirements

·        All stakeholder requirements can be traced to all functional requirements

·        All business requirements can be traced to all stakeholder requirements

·        All functional requirements can be traced to all stakeholder requirements

Example One

Business Requirements and Solution requirements traced together;

Business Requirement

Solution Requirement

BR1: The business must have a report to show last month’s sales figures

SR1: The solution must run a query to return search results for sales figures

SR2: The solution must allow present the query results in line with the businesses reporting template


The following table allows the following statements to be made;

·        BR1 must have SR1 & SR2 to allow the business to display last month’s sales figures.

·        SR1 & SR2 allow for BR1 to be realized.

·        If BR1 is de-scoped, SR1 & SR2 are impacted

·        If either SR1 or SR2 are not supported by the solution, then BR1 is impacted.

Example Two

The generalist example of the building, architect, materials and bulldozer.


Everything is connected

Everything can be related, in some which way, to everything else. The implications for this are profound and outside the scope of this article. Next time you walk down the street, take a look around and you will discover that there is an interconnected web of information that derives meaning. This is no different in business analysis where a company’s business, its market, employees, systems, technology, finances, etc., are all related in some way, albeit at different levels.

For instance, an elephant and a building are very different and one would not usually associated them together. This depends on the coupling. Objects that are loosely coupled can be associated through some level of commonality. Back to the example, one could say that an elephant and a building are associated since they are both composed of matter. In this context they are equivalent. A lion and a tiger however have a much tighter coupling and are both living animals, of a similar species.

The point is that the constituent parts of organisations can be modeled in a way that shows the parts themselves and their relationships. This is evident when one considers capabilities; people, process and technology, or any kind of architectural domain. (The TOGAF standard defines four dimension of organisations being business, application, data and technology.) In this arrangement the architect would define a range of models containing taxonomies of concepts that can be associated, interrelated and traced.  This enables the architecture to understand, if we change process A, then it impacts these people, this technology and these systems.



Scope is the boundary that distinguishes concepts and connections that are within the domain of consideration. Since all concepts and connections are visualized one can draw a boundary create a division; within scope and outside of scope. This gives a clear distinction what information to consider. Based on the established connections, the scope may have to be adjusted based on the relevance of the information close to boundaries.

For example, the business analyst might think that only functional and business requirements are relevant when a solution component is no longer supported by the vendor. When tracing the business requirement the analyst discovers that there are a number of stakeholder requirements that are associated. The business analyst then realizes that expectations need to be managed with the original stakeholder to which the stakeholder requirements were originally communicated and confirmed. This is an example where a connection and relationship crosses a boundary and therefore the scope need to be expanded.

Root Cause Analysis

This technique assesses the apparent effects or symptoms and traces back to the underlying cause. Asking a series of ‘Why?’ questions until the desired answer is found allows the traversal of a series of concepts and relationships until an answer found is deemed acceptable to answer the question. Once can consider this traversal as a kind of routing, from the obviously detectable symptom to the underlying cause.

Impact Analysis

Change is the only certainty. It’s also commonly understood that change is constantly occurring at different levels within organisations. That being said, organisations need to improve their ability to change.

Since change is immanent, organisations need to employ tools that have provide modelling capabilities of organisational architecture within modern tools where the concepts or traceability is enabled within a relational database. If designed and executed properly, an impact can be fully analysed, assessed and a report generated in the time it takes run a query.

Having the organisation mapped and modeled is a proactive step in readying the organisation for change. This is a great example of how organisations can invest in the future by building agility in good times, preparing for when changes need to occur rapidly.


Drawing relationships to analyse a problems or show some kind of alignment is a great way to provide value in addressing business needs. Alignment is akin to the mathematical operation of fractions where we reduce two different fractions to the same denominator. Initially you’re looking at an apple and an orange; how can we compare them? Aligning separate concepts or artifacts allows meaning to be applied collaboratively.

Spreadsheets are also great tools for traceability, alignment and impact analysis. Consider the following column titles to show how an organisations solutions align to organisational strategy;

·        Vision -> Mission -> Business driver/goal -> Business Objective -> Business Requirements -> Functional Requirements


Traceability is a very simple concept with profound implications when scaled and enabled with technology. As a business analyst traceability is used frequently with requirements, as well as ‘tracing’ between artifacts. A good example is tracing between a process maps and functional requirement specifications. This allows us to answer the questions, what functional requirements are realized in this process? Or what processes are dependent on these functional requirements?

Returning to the original concept, it’s about concepts and their connections with each other. It’s these connections that we can look at; individually or together to make assessments and establish causal relationships to events and impacts. Making sense of how an organisation works is an essential part of readying for change and building agility.

Traceability allows for understanding to be attained about the current state as well as future scenarios the can be modeled. Modelling for future scenario also has beneficial precursors risk management and mitigation. Mitigation strategies, instead of being static statements in a project plan they can actually be detailed plans on how to execute a change if the associated impact is sustained.

Traceability is a powerful concept that draws its origins from the childhood game “dot to dot”. There is where a paper scrap book filled with pictures that contain no visible lines with the simple instruction of, “join the dots.” This allowed the dots and connections to reveal the underlying picture. That was the challenge then, and it still is today – Just join the dots. 

Author: Matt Fishbeck, Sr. Business Analyst

Matt Fishbeck, Sr. Business AnalystMatt is a senior business analyst with 5+ years experience in transport, telecommunications, utilities, technology and automotive industries working with stakeholders to meet the objectives of organisations. Matt is competent across the spectrum of competencies and possesses sound alignment to IIBA best practice. He has engaged stakeholders in large transformation projects to facilitate change by delivering value through best practice. He provides thought leadership through research and development, academia and knowledge of open standards. 

Matt has extensive technical knowledge and is passionate about technology, business, business analysis and business architecture. He takes a dynamic high energy approach to delivery and providing exceptional value to clients through consulting. Matt leverage’s the creative process to innovate and deliver solutions to business. He has worked internationally in organisations in Melbourne, Germany and the UK.
Like this article:
  20 members liked this article


Guy Beauchamp posted on Monday, September 7, 2015 4:47 AM
Another good article, Matt, thanks! Just a couple of follow on thoughts:
1. traceability of requirements though to design and crucially test cases (i.e. delivery). This proves that the requirements are being designed in to the solution and tested as being delivered. I have done this once and it is hard, detailed work, but it does raise interesting questions and cause corrections as people do the mapping and realise there are gaps!! Once the mapping is complete however it did not seem to have any inherent value in itself though in theory you could (as you suggest) use it for impact analysis.
2. There is cardinality in the connections between elements that are being traced. E.g. one business requirement may be tested as being delivered in many test cases. To take this concept a stage further you can build a logical data model of how all elements in analysis and design relate together (I have done this and it is available on my website free of charge if anyone wants to look at it).

Thanks again for the thought provoking article.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC