Proceeding without Traceability Tools


Of course, you may not have a tool specifically constructed to support the types of operations identified in the preceding sections. Without such a tool, how should you proceed?

As we've described, many of the matrix relationships could be easily handled with a spreadsheet. We've used spreadsheets extensively in the past and found them to be a useful aid in managing projects.

The problem with spreadsheets, however, is maintenance, especially in extensive hierarchies of relationships. Changing a single linkage could have far-flung impacts in the relationships at issue, as well as other relationships in other parts of the hierarchy. It could become a nightmare if extensive changes to the linkages had to be made.

Since it can be difficult to manually keep track of the changes and their "ripple effects," it is likely that the team would either:

  1. Fall into a pattern of resisting any discussions to change the relationships, or

  2. Abandon the matrices as the work becomes overwhelming

Of course, we always came to regret both of these behaviors, as they inevitably led to subsequent problems in the project.

The other alternative is to use a database. We used relational databases extensively and found it fairly easy to construct them and to input the data. Indeed, in the pre-tool days, we used relational databases to support traceability requirements for human-critical medical device development projects. Relational databases worked pretty well. Even though it was more difficult to expand the database application to include recursively tracking ripple effects from changes, it could be done. The problem, however, was that we ended up spending disproportionate amounts of time improving the tool's capability. Good for the ego, and downright fun at times, but bad for the project resources that should have been doing something else.

Therefore, although you can use spreadsheets or databases to maintain the traceability relationships, it won't be easy. If you have a small project, the pain and suffering will be minimal, and it might be worth considering simpler alternatives. On the other hand, we do not recommend tackling larger projects without the use of specialized requirements management tools.


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257 © 2008-2017.
If you may any questions please contact us: