Link: http://www.sysflow.com/blog/lies-and-traceability/
From Systems Flow, Inc. » Blog
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:
| ID | Title | Trace to n Functional Requirements |
|---|---|---|
| Bus001 | Show Account Balance on All Systems | 2 |
| Bus002 | Print Application Summary After Customer Submits It | 3 |
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:
| ID | Title and Text | Trace to These Functional Requirements |
|---|---|---|
| Bus001 | Show Account Balance on All Systems: System A, System B, and System C | Func526: 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.
