Maintaining traceability up-to-date as project evolves

Question

During various projects, I needed to make sure that the use case model I developed during the analysis phase is covering the requirements of the project. For that, I was able to have some degree of traceability between requirement statements (uniquely identified) and use cases (also uniquely identified). In some cases, enabling traceability implied some additional effort that I considered (and later proved) to be a good investment.

Now, the biggest problem I faced was to maintain this traceability later, when things started to change (as a result of change requests, or as a result of use case changes).

Any ideas of best practices for traceability maintenance?

(It can apply to other items in the project - e.g. use cases and test cases, or requirements and acceptance test cases)

Later edit Tools might help, but they can't detect gaps or errors in traceability. Navigation... maybe, but no warranty that the traceability is up-to-date or correct after applying the changes.

Answer 1

We have used three years ago a Rational tool for writing requirements. In those tools, many features concern traceability.

We found that the usability of these tools is not perfect. Although they did provide the basic functionalities we needed, we lost a lot of time going around their limitations.

---

I assume you are not asking about traceability up to the code, so I exclude this from my answer.

---

As you mention unique ids for your statements and use cases, you might already use a tool to manage them.

In essence, a simple relational model (possibly in a database) could cover the relations between your uniquely identified pieces.

I would look for a simple tool that does that. If only one person can modify it, it could simply be an Excel sheet!

---

Note that linking two documents types is probably not enough.
You mentioned 5 types: statements, use cases, test cases, requirements, and acceptance test cases.
We constantly needed transitivity (in the relational world, to JOIN tables), to have a view including several steps.

Answer 2

You want to add a version # to the requirements statement and for each use case - the most up-to-date ones being communicated to all and stored at some easily accessible area (physical and/or computer/web). You will need to add a change document that includes what the prior requirement statement and/or use case was, when it was changed, by who and who approved.

So when looking at the requirements spec and use cases you/all have the latest view and if there is a question to a change, you have the change doc to refer to (don't overburden the requirements or use case spec with historic info, but keep the historic info around as reference in an easily accessible, meaningful form)

Answer 3

I think traceability is one of the toughest things to manage in requirements, second to making sure the requirements are correct in the first place. In my experience, the best traceability tool is a human being.

I don't have any panaceas; just some tips for what's helped me in the past.

• Keep documents in a central area where everyone can get to them easily. I don't care if it's Sharepoint, a wiki, or a network drive (although I like something that provides version control if possible). Keep it in one place and market the heck out of it so everyone knows to go there for answers rather than using old copies or interrupting the developers.
• If you have a central point of contact for managing the artifacts or functional groupings of them, that helps a lot. Someone that understands them and the issues will know where to go, what to update and if there are dependencies that need to be carried forward.
• The custodian of the artifacts needs to be committed to them and to keeping them up to date. A year after I set up some requirements documents on a site, I still kept them up to date. I know most developers would dread having to do that, but a year after that, I'm STILL benefiting from looking back at those to see how a functional requirement changed over time.
• Not required, but it is helpful to quickly identify changes over time: use the document processor's version tracking if it has it. If not, I would at least include a change log for the document or simply mark new text with a reference to the version number.
• I have tried to put dependency references into my artifacts in the past, such as references to other documents or artifacts, but found that they either became outdated or were hard to keep track of and therefore were often not updated. Discipline can overcome this, but most of us have too much to do, eh? So I think that building in cross references between documents/artifacts is where I would like a tool or some yet to be released free requirements management utility to do the job :)

Answer 4

I'd say the best way is to use a bug tracker. Each requirement is tracked as a bug, development modifications are associated with it, and changes can be kept with bugnotes.

A lot of bugtrackers allow you to associate multiple bugs together (eg as duplicates) so this can be used to keep discrete requirements combined and still separate for tracking individually.

If you store all your other artifacts in a SCM (ie design documents, etc) then you can trace these through too by associating them with the requirement.

There are tools to help with all this, ut I've found these "full lifecycle" tools are really unusable as they try to do far too much in one app, or as related apps that "integrate" together, and are incredibly expensive.