Traceability: Keeps Project Scope & Requirements In Sync
For Business Analysts writing business requirements, one of the concepts they are asked to respect is “traceability.”
Traceability is the connectedness of scope and requirements among all project documents. Traceability provides the ability to find the origin of each business requirement in the approved project scope, and to follow the development of each scope item as it progresses through the life of a project.
How Traceability is Managed
Some organizations manage traceability very carefully using a traceability matrix. A traceability matrix has columns for each project document (like scope document, business rules document, functional requirements document). Columns in the matrix for each project document are populated to show how each requirement in the scope document is connected (or “traces”) to one or more specific rules in each of the other documents. And working backwards, the matrix also shows how each rule in a project document traces to one or more specific requirements in the scope document.
Some organizations use the traceability matrix in a limited way, and use it just to track traceability of scope requirements to business rules. Other organizations use it comprehensively, and track traceability from scope document, through business rules and functional requirements, and right on through to test cases.
Traceable Value
The value of a traceability matrix, and of traceability as a concept, is that throughout the process there is a control on scope being added or missed. So if you have a scope requirement, and the traceability matrix shows that no business rules trace to it, there is project scope that was missed in the requirements. And if you have business rules that do not trace to a scope requirement, that means you have “scope creep,” rules that introduce functionality into a project that is not part of the approved project scope.
Tracking traceability between the project scope document and the business rule document is enormously helpful, and should be done even if it is not required for the project. Whenever I track traceability, it reveals scope elements that I have not addressed fully, or areas where my business rules are bringing into the project functionality that is not part of the approved project scope. Going through the exercise of checking traceability always improves the quality of my business rules document.
This is a simple manual way to keep track of your requirements. This method works best with a waterfall methodology, but it can be applied to Agile as well.
What is your favorite way to ensure you have documented all your high level requirements?
This article was originally published on the DefinedLogic blog.
