The requirements traceability matrix is probably one of the most valuable things people almost never do. If you are not sure exactly what it is, it’s basically being able to connect all of your work products (rules, requirements, processes, etc), so that you can see how they interrelate and impact each other. There are many uses for it. Change management might use traced requirements to know what business requirements might be affected by changing a particular system capability. You might also what to see all of the solution requirements (functional requirements, system specifications), that satisfy a particular business requirement.

It’s super valuable in terms of knowing the job is complete, managing changes, and assessing impact. The reason people don’t do it is that it is a monumental pain in the behind to manage with the most common tools available to use (Word and Excel). Based on responses from professionals in the field, its managed in usually one of three ways.

In Document Requirements Traceability

If you working in your standard Word document (or equivalent word processing file), the one method is to by creating internal document links. For example, if you start with your high-level required capabilities at the top of the document, you can either list each requirement that relates to it that exist in the sub-requirements or you can list the related high-level requirements within the sub-level requirements [pictured below]. Because requirements gathering is such a dynamic sport, trying to keep up with all of the changes can become a whole job on its own, so people tend to become lazy about it as the project progresses or just don’t even bother.

Excel (Spreadsheet) Requirements Traceability Matrix

Managing the traceability in excel is better because excel is meant for slicing and dicing important data, but now you are having to manage 2 separate documents, on for the requirements themselves and one for the traceability, so it still sucks. It’s mostly used as transition verification in a waterfall methodology. For example…

• Do the solution requirement cover all the business requirements?
• Do the system specifications cover all my solution requirements

Requirements Management Tool Traceability

In my experience and in hearing from other business analysts, the only valuable way to properly trace requirements is with a requirements management tool. When I say “valuable” I’m really referring to the cost-vs-benefit of doing it. Sure the end product can be valuable, but the cost of maintaining outside of the tool is often too high in the long term.

Requirements management tools not only give you the ability to create relationships on the fly. You could trace business requirements to solution requirements, business rules, business processes, etc. Then some time after the fact you can create reports that are actually valuable to someone and can be used to make an informed decision about your solution. For example…

• Business user:  “I want to change this functionality to be like this because it will be better for me this way.”
• Future business analyst: “Well we need to keep in mind that it works that way because of policy X and to satisfy business object Y, so the new functionality must also satisfy those needs”

A solid requirements management tool with good tracing capabilities can be infinitely valuable if you manage your deliverables or work products effectively within the tool. Different stakeholders can see information as they need it instead of having to get value our of a deliverable that was intended for a different audience.