Think Traceability

Wearing a “business analyst” hat, many of us often find ourselves on projects tasked with defining a set of requirements to address a given need.

I like to go into these engagements looking forward to the great adventure that will surely unfold.  There is usually an interesting cast of characters who bring valuable insight and perspective from various angles, boots-on-the-ground knowledge, experience and history, and often a passion for the topic at hand. Getting the chance to sit down with stakeholders as we embark on our adventure is truly a privilege.

But it’s seldom without challenges. The potential for conflicting opinions on priorities and scope, biases, a wide range in the level of interest among stakeholders, and strong personalities can throw off our compass and quickly cloud our direction.


It’s good to have a purpose!

We all know that we need clear objectives to guide us when defining a solution.  And, usually, we start out feeling reasonably confident that we have this covered (more on this later). So why is it that we often find ourselves surprised by some of the paths we go down as we try to separate the “wheat from the chaff?” And how do we keep ourselves on track with confidence?

Enter our impartial friend: Traceability.

For the uninitiated, requirements traceability refers to the creation and maintenance of relationships from high-level to detailed requirements, among related requirements, through to design components, code, test cases, business rules, etc.  Traceability can be done in both directions – forwards and backwards – so that we may see that business objectives are being met by specific functionality and that functionality exists for the purpose of meeting business needs.  As solutions go into production, traceability also becomes critical for assessing the impacts of change.  In certain industries, it is mandated. It’s easy to imagine that on large complex projects, it is necessary.

Even if a project is small, in an environment that has not been rigid about traceability, it serves us well to integrate it into our approach and keep it on our minds during each conversation, meeting, workshop or other stakeholder interaction.  If I am on a project as a BA developing requirements, I want to make sure that, at the very least, I’m tracing backward from detailed solution requirements to high-level business requirements/objectives. Beyond missing the mark entirely, even seemingly small errors in solution requirements can be very expensive to fix downstream.


Applying simple logic

When we treat traceability as a principle to which we aim to comply, we can say that if a stated requirement cannot be traced back to one or more high-level business objectives, then either:

  1. The requirement should be dropped; or
  2. There’s something wrong with the high-level business objectives.

It may not always be this cut and dry, but I’ve found that taking this position as simply as it’s stated, particularly #1, helps to force difficult conversations about scope and move toward defining a focused set of needs.


Keeping an open mind

Carrying on from #2 above, what if the high-level business objectives don’t line up with what the boots on the ground are conveying about their needs? Projects are not always initiated for the most compelling of reasons.  Or sometimes those reasons are not well-articulated.  Other times, the implementation of solutions can offer benefits that have not been thought through at the time business requirements were penned.  If we are hearing compelling requirements from stakeholders that do not line up with the business objectives for the solution, there may be a need to go back to management to validate these.  In some cases, the business requirements need to be re-examined and adjusted.


The benefits

When we start applying the concept of traceability as a principle on projects big or small, the following benefits tend to be realized:

  • It reveals purpose – When we are constantly mindful of the overarching business problem and know how success has been defined, we are in a position to “spread the word” as we engage stakeholders.
  • It drives and focuses the conversation – The need for traceability allows us to put boundaries around our discussions with stakeholders and provides guidance on where to “reign things in.”
  • It empowers us to play devil’s advocate – With a mandate of traceability, it becomes easier to challenge stakeholders on their views and statements of needs, placing us in a position to ask hard questions without appearing judgmental.
  • It solves the “doing things right vs. doing the right things” problem – Traceability keep us focused first on “doing the right things”.
  • It forces us to validate the key business objectives and refine as necessary – Traceability keeps us coming back to the business requirements.  If there is an obvious problem with them, we are forced to address it.
  • It can identify holes or missing requirements – When there is a lack of solution requirements tracing back to a defined high-level requirement, it is an indication that we have not sufficiently covered our needs.


Although it feels vaguely like I just stated the obvious, I have witnessed projects where traceability just didn’t seem to be a priority.  And, predictably, the solution suffered.  It’s a simple concept: think traceability.


Leave us a comment: * Your information is never shared