8 years, 4 months ago

Lies, Damn Lies, and Traceability

Link: http://www.sysflow.com/blog/lies-and-traceability/

In my last post, Traceability 101, I talked about the essential role traceability plays in the success of a project. By writing business requirements, functional requirements, and then drawing traces between them you can create a traceability matrix that reveals 1) business requirements that are not covered by functional requirements, and 2) out-of-scope functional requirements that creeped into your project.

Too often, however, project managers see the steps in a project from the point of view of items that simply need to be checked off:

  • Business requirements. Check.
  • Functional requirements. Check.
  • Traces drawn. Check.
  • Gap analysis created. Check.

Unfortunately, project failure can hide behind any one of those ‘s: traceability being no exception.

Let’s look at a typical traceability matrix that one might create in order to discover gaps between business requirements and functional requirements. At the highest level the matrix might look something like this, where the table lists each business requirement and the number of functional requirements each business requirement traces to:

IDTitleTrace to n
Functional Requirements
Bus001Show Account Balance on All Systems2
Bus002Print Application Summary After Customer Submits It3

From a gap analysis perspective, things look great. Business Requirement Bus001 traces to 2 functional requirements and Bus002 traces to 3 functional requirements. No gaps here! Time to check off gap analysis and move on to the next step of the project… or maybe not. Let’s dig a bit deeper.

Instead of just confirming that Bus001 traces to two functional requirements, let’s take a look at the actual text of Bus001 and the text of the two functional requirements it traces to:

IDTitle and TextTrace to These Functional Requirements
Bus001Show Account Balance on All Systems: System A, System B, and System CFunc526: The xyz screen on System A will display the customer’s account balance
Func742: The xyz screen on System C will display the customer’s account balance

It turns out there is a gap between our business requirements and our functional requirements. Bus001 speaks of showing an account balance on three separate systems: A, B, and C. But there is no functional requirement for System B; only functional requirements for systems A and C. (I’ll leave it to a separate post as to whether Bus001 should have been split up into three separate requirements.)

The moral of the story? It’s not enough to rely on a project’s ‘s; there needs to be a thorough analysis behind each one of those ‘s, especially in the critical area of traceability.

Check out some of our other articles on requirements or please contact us, if you want to learn more.