Creating a solid requirements traceability matrix is so valuable and important, yet so few business analysts and product managers do it. Why is that? Probably because it’s not just creating the traceability matrix, but getting the rest of the software development team to change their process to require this.
Simply stated, the requirements traceability is so important because it creates a downstream flow of connecting software requirements to product requirements and test cases to software requirements. (And) by doing this, the correct requirements are built and tested instead of having the wrong product built.
The creation and implementation of requirements traceability techniques originated in the early 1970s to influence the completeness, consistency, and traceability of the requirements of a system. They provide an answer to some of the following questions:
- What mission need is addressed by a requirement?
- Where is a requirement implemented?
- Is this requirement necessary?
- How do I interpret this requirement?
- What design decisions affect the implementation of a requirement?
- Are all requirements allocated?
The purpose of this technology description is to introduce the key concepts of requirements traceability.
Requirements traceability can be defined as the ability to describe and trace the life of a requirement, in both a forward and backward direction (e.g. from its source, through its development and specification, to its actual deployment, and then into the product cycel of ongoing refinement and iteration in any of these phases) . Requirements Traceability can be achieved by using one or more of the following techniques:
Cross referencing . This involves embedding phrases like “see section x” throughout the project documentation (e.g., tagging, numbering, or indexing of requirements, and specialized tables or matrices that track the cross references).
Specialized templates and integration or transformation documents. These are used to store links between documents created in different phases of development.
Restructuring. The documentation is restructured in terms of an underlying network or graph to keep track of requirements changes (e.g., assumption-based truth maintenance networks, chaining mechanisms, constraint networks, and propagation).
A very typical problem is the situation of runaway requirements comingled with scope creep. What invariably happens is that there will be a business analyst responsible for collecting and managing the requirements. If that business analyst leaves or hands off their task to someone else who has to then manage that project, it becomes impossible to know where requirements came from. A document of hundreds of requirements will be developed and nobody knows for sure where certain requirements came from.
If the initial objectives are defined, prioritized and assigned an originator, you can then map the features to those objectives and the requirements to that feature. What this will do is always provide insite into where the requirement came from and what overall objective it satisfies.
So that developers can always know what they are working on and the project team to understand what the developer is working on, you can map the requirement specfication and components up to the feature and objective level. This requirements traceability is a great way to measure completeness and fill in any gaps.
If requirements change, it is important to identify when and why they changed. Will someone remember in 4.5 weeks time why we chose to raise the top credit days from 90 to 120? Will they have it changed back to 60 days only to find payment cannot be made on a contract that was set at 76 days?
Unless there is traceability, how will the QA staff know what to test? The test plan should be a reflection of the requirements. If the requirements say 55 days credit then the testing needs to test 55 days. As the test plan is built during the development of the system, the testers need to know when things change. They will need to alter their test plan. If there is a late change to 180 days, unless it can be identified, the testers may well miss it.
Every programmer has had to carry out maintenance on a system that had documentation that old. If maintenance needs to be carried out on the credit days section, and the tester is looking to find out how many days, then out of date requirements can lead to an exception. The requirements need to become system documentation and be kept up to date. Changes need to be tracked.
I had to fix a billing system in a major domestic bank. They had a system to calculate bills based on complex actuarial tables. There was a development environment, a test environment and a production environment. Each had their own sets of reference tables, and each set was different. The first thought was to go back to the system documentation but this had never been kept up to date. We had no idea which actuarial data was current. In the end, we had to have the analysts re-create all the data and then load it into all three environments. Probably for reasons associated with self preservation, management were not keen to know how many pensions had been paid incorrectly.
There are many tools available to manage requiremnets traceability. The GatherSpace.com system is a very affordable and simple way to accomplish requirements traceability. For less complex systems, some basic documentation will suffice.
Another technique if Excel is being used is to hide the old row or column and add a comment to the cell with the purpose for the modification. If a personal database like MS Access is used, a relatively simple database can be developed that holds prior versions of requirements.
For any project, a key milestone is to determine and agree upon the requirements traceability process. Initially, three important questions need to be answered before selecting any particular requirements traceability approach:
What needs to be traceable?
What linkages need to be made?
How, when, and who should establish and maintain the resulting database?
Once the questions are answered, then selection of an approach should be made. One way could be the structured use of general-purpose tools configured to support cross-referencing between documents. For large software development projects, an alternative approach could be the use of a dedicated workbench centered around a database management system providing tools for documenting, parsing, editing, decomposing, grouping, linking, organizing, partitioning, and managing requirements.
The Requirements Traceability Matrix is the heart of being able to visually know how requirements trace. The matrix will present to you the table of features and for each feature you will see if there is backward and forward traceaibility — meaning is each feature mapped back to an objective? and is each feature complete with requirements?
Any time you see a feature without any traceability that should signal to the project team that the requirements are incomplete.
Every major office tool manufacturer has spreadsheet and/or database capabilities that can be configured to support requirements tracing. There are at least ten commercial products that fall in the workbench category and support some level of requirements traceability . At a minimum, they provide
bidirectional requirement linking to system elements
capture of allocation rationale, accountability, and test/validation
identification of inconsistencies
capabilities to view/trace links
verification of requirements
history of requirements changes.
Different types of setups to support requirements traceability past the requirements gathering phase of the software life cycle are being researched. Areas include the development of a common language, method, model, and database structure, as well as mechanisms to provide data exchange between different tools in the environment. Prototypes exist and at least one commercial product provides support for data exchange through its object-oriented database facilities.
In general, the implementation of requirements traceability techniques within a company should facilitate reuse and maintainability of the system. However, additional resources to initially implement traceability processes will be required. One case study found that the cost was more than double the normal documentation cost associated with the development of a system of the same size and sophistication. However, this was determined to be a one-time cost and the overall costs to maintain the software system are expected to be reduced. Almost immediate return was observed in the reduced amount of time to perform hardware upgrade