Traceability is a necessary component for complete and accurate requirements. Traceability is used in many aspects of requirements development and management. A simple definition is that “tracing requirements” means that we show relationships or links between different requirements components. Examples include:
Which data requirements are used in each process?
Which business objectives are supported by each business rule?
Which technical requirements are derived from each business requirement?
This is one area where a requirements development or management tool can be very useful. But even with a tool, tracing requirements can be complex and time consuming. An effective BA plans for the types of relationships that are going to be documented and maintained before getting started with requirements elicitation. It is easiest to “trace as you go” and the only way to accomplish this is to know ahead of time what type of tracing you are planning to perform and maintain.
- Selecting a Vendor Package (COTS) - June 7, 2010
- When do you learn the business? - April 6, 2010
- Free podcast on Application Modernization - March 15, 2010
- IIBA and Business Rules Community 2010 Conference - January 11, 2010
- BAs NEED management support - December 4, 2009
- WIBADD is really Great!! - October 22, 2009
- Why status reports? - September 25, 2009
- BA Interns - July 20, 2009
- Who performs business analysis work in your organization? - June 26, 2009
- User Stories - April 14, 2009
I must admit that requirements traceability is still a dubious subject for me, could you suggest some sample techniques or tools which could be helpful in the process?
Jakub,
You are not the only one learning about traceability. The easiest tool is a matrix (you can use an Excel spreadsheet or Word table). Any of your requirements components can be traced. For example, if you have high level project objectives you can matrix them against detailed requirements. You are showing which requirements will support each objective. If you find an objective without any requirements than you missed a requirement. If you find a requirement that doesn’t support an objective, you have an unnecessary requirement or missing objective. Try it out and see how you like it! Let us know how you do.
Thanks Barbara! i love a good RTM. One of the most useful management and comms tools a BA can have.
Jakub – How about excel as a starter. You know the tool and requirements themselves can vary by project. put in a column for each phase of the project and tick or comment as you pass through it.
Here is an example software dev process with milestones for a reference point.
Barbara, Craig,
Thanks very much for your suggestions, will definately give them a try.
Actually the first technique will be perfect for me right now as I’m thrown into an already ongoing project and I’m not quite clear about where all the ideas originate from 🙂
I’m with Jakub, requirements traceability is not clear for me too. Each new project seems to show me the need for more traceability. One tool I’m using now is a simple table, as suggested by you, that contains the scope items (user requirements), the use case it affects and a description of how the requirement affects the use case. It is particular useful when you are modeling changes in a system that already exists because the system analyst does not have search for modifications in the use cases or compare the current documentation with the previous one. Kerber ITBA – Digitro Technology http://www.digitro.com http://www.kerber.com.br
Kerber Extend the columns out to the testing phases and then to implementation. Plan your requirements’ journey right through to the end. When things get dropped off you are alerted. Also it helps you get your test plan and test cases organized early.