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.
October 9th, 2007 at 12:47 pm
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?
October 9th, 2007 at 10:58 pm
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.
October 9th, 2007 at 11:00 pm
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.
October 10th, 2007 at 2:35 am
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
October 10th, 2007 at 4:29 pm
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 www.digitro.com www.kerber.com.br
October 11th, 2007 at 8:54 am
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.
October 15th, 2007 at 8:26 am
Craig, this column's extension seems to be powerful because it gives, not only to me but for everybody involved, a good vision of the different abstraction levels of the costumer needs through what you have well called journey. "From text to code." I'll use it on my current project and check if I can extend it to the system analyst area where he can add more "low level" columns. thanks, Kerber ITBA / Digitro Technology www.digitro.com / www.kerber.com.br
October 24th, 2007 at 5:47 pm
[…] Traceability must be planned http://www.b2ttraining.com/page/business-analyst-blog/archives/111/traceability-must-be-planned#comment-5849 […]
October 24th, 2007 at 6:03 pm
[…] Post original: Traceability must be planned […]
October 25th, 2007 at 1:11 pm
I use the following basic hierarchy for tracing:
Goals to
Use cases to
Use case steps to
Features to
Requirements / Data / Business Rules
There is more (test cases, terms etc.) but this gives you the idea.