Finding Traceability (harder than ammunition!)

One of the greatest challenges we face as Business Analysts is finding out if something has been left out, whether it’s a requirement, feature or business objective. (hopefully not the last one)  A common method for validating this is to do a traceability check.  You may be familiar with the concept of tracer ammunition – the idea is to have bullets that are visible in their flight path so you can easily identify where they are ending up.  Traceability in software projects is essentially the same: identifying where requirements end up as part of features and where those features end up as part of business objectives.

At some point in a project, a business analyst will need to review the requirements and make a check to see if they’ve “got everything.”  As we all know, it is nigh upon impossible to truly have gotten everything whether it’s due to constraints of time, money, manpower or the value of doing a double check has diminished to the point of worthlessness.  Traceability bridges that gap by enabling people to perform a simple check that validates that the details are part of a bigger picture and vice versa.  For example if we have identified 50 features and 500 requirements as part of our project, we would assume that each feature has on average 10 requirements.  Basic statistics suggests this is not the case, that an even distribution of requirements to features is improbable; a bell curve distribution is far more likely.  We could expect 5 features to have 20+ requirements and another 5 features to have fewer than 5 requirements.  We are primarily interested in those latter 5 features – a wagering person would bet that there are additional requirements that need to be created for those features.  That is the first half of traceability, identifying higher level objects that don’t have enough detail around them.  By tracing features down to requirements, you can drive a sufficient level of detail on all of your features which now show a level of completeness.

Since we’ve covered 1 direction of a 2 way street the logical thing to do is to look the other way.  This scenario is where you have drafted requirements but cannot find an appropriate feature to attach them to.  In such a situation you have stumbled upon a missing feature; something that is adding value to your business but does not have much clarity around it.  Working with your subject matter experts, you can discern whether or not this feature will add enough value to be included as part of the project.  Naturally each feature will prompt this discussion; some features are low priority and may never get worked, others will inevitably be a high priority and will lead to multiple discussions on how to incorporate them into the project and ultimately draft requirements.  These high priority features are important because if they are not present when the project goes live means they get discovered in production.  As we are all aware, making a change to a live system is CONSIDERABLY more expensive; this is easily one of the biggest pitfalls a successful software project will need to hurdle.  By making this perfunctory check the problem is nipped in the bud and the necessary requirements are created.  By tracing requirements up to features, you will get a sense that your project is really meeting all of the needs of the business.

Taking the topic further, traceability is a concept that can be applied in many other ways.  Any time you have two things that link but are at differing levels of details, a step to trace the gap between the two is always helpful.  After all, you may think your aim is true when you fire a shot, but unless you can see where the bullet flew through and ultimately hit, you won’t truly know.