The requirements traceability matrix is probably one of the most valueable 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 they you can see how they interrelate and impact each other. There are many uses for it. Change managment might use traced requirements to know what business requirements might be affectd 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 because 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.
If you working in your standard Word document (or equivalent word processing file), the one method to by creating internal document links. For example if you start with your high level required capabilites 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.
Managing the traceability in excel is a better, because excel is meant for slicing and dicing important data, but now your having to managing 2 separate documents, on for the requirements themselves and one for the traceability, so it still sucks. It's most 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
In my experience and in hearing from other business analyst, the only valuable way to properly trace requirements is with a requirements management tool. When I say "valuable" I'm really refering 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 busines requirements to solution requirements, to business rules, to business process, etc. Then some time after the fact you can create reports that are actually valuable to someone and can be used to make 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.