I ran across this topic in the Seilevel forums and thought it would be of interest to the Catalyze community.  The initial post and all replies have been copied below.

I've been playing with this thought. Are there situations in which traceability simply isn't worth the cost?

The benefits of tracebility include:

• Risk reduction (don't miss something)
• Scope reduction (don't include something you shouldn't)

What are the characteristics of a project which make traceability compelling?

Well, I work in a regulated environment where we're subject to audits by customers and the government, so we don't have much choice.

Traceability can get costly, but if you have it built in at the beginning and have a good set of tools, it can be managed without too much work.

The main thing about traceability is that it shouldnt cost very much if you are using the right tools. The cost of a missing requirement vs 16 hours of time to make the links is a pretty good tradeoff I would think.

What if you're not using a tool?

Tool is used pretty generically here. You can do traceability in notepad, it just isn't easy.

Yup. I've done traceability in Excel. Again, if you set up your process early on and have traceability built in, it doesn't have to take that much time. All you really need is numbering or IDs for your requirements, and a means of relating the requirements to other artifacts. Of course, when it gets more complicated - e.g. requirements spanning across projects - a tool is much more handy.

Furthermore, you have to maintain the traceability during change control - it needs to be part of the process of updating.

Where traceability is not important? In small, quick hitting projects where the development cycle is so short that it's simply quicker to compare the requirements to the implementation than to look at a trace matrix.

In truth, I see most of the value in traceability to management - it's always seemed like a cover-your-ass type of exercise. I do it now because we're legally obligated to, but I've done it where the managers and executives simply got addicted to the reports and demanded it.

When I first started doing traceability, it was more for tracking what requirements didn't get implemented so that we could track what we needed to build in later iterations. We started using ReqPro extensively as a tool, and were able to start generating reports out of it, which management started to pay attention to. Being able to compare what was built, when it was built, what was asked for, and what we didn't get was a big deal to managers. Things took off from there, and it became a required part of every project.

This is an interesting thread. It may be helpful to think about traceability from a conceptual perspective and from a practical perspective.

I think we'd be hard pressed to argue with the concept that requirements should be associated with business objectives, design should address each and every requirement, development should ensure that they build what was designed, and test should verify that the requirements were met. I'm talking conceptually here - I'm not saying how you should do it. If we don't do this, things go awry (human sacrifice, cats and dogs living together - mass hysteria).

The other side of this is the mechanics of doing traceability. Do we invest money & time in a tool, spend the time building/maintaining an Excel matrix, or just simply sit down periodically as a project team and check progress? I'm used to doing fairly large, complex projects, so I have preferences towards a tool, but I can certainly see if you were doing a short project with a small team - maybe you don't need to invest the time in a tool/matrix. But you still have to make sure that everything is there - that doesn't change.

Ditto Brad, this is a very interesting thread.

I would like to expand on the scope of traceability during a requirements definition exercise. Most of the comments in this thread on traceability are addressing this subject at the level of individual requirements. Long before we get to this stage, I believe that we need to be looking back over our shoulders from day one.

For example, once the project has been kicked off and the initial vision articulated every next level of specificity the Product Manager deals with needs to be traced back to immediately higher level that preceded it. You really do not need a tool to make sure that the first level business requirements tie back to the project vision. A few minutes spent comparing meeting notes on both the sessions might suffice. Quick and dirty trace backs can be done after every session that is held to gather requirements. This kind of simple sanity checking after each session is concluded or document is created will alert you to any major forks in the road that you may have inadvertently meandered into.

It is at the level of individual requirements that the need arises for a tool or a complex spreadsheet to trace a requirement back to its source. But if no tracing is done till we get to this point in the game, we may already be off the reservation and all we are left with are a detailed listing of how exactly we got there.

One way we handle the workload is by distributing it. As a Systems Analyst, I'm responsible for tracing my detailed requirements (user stories, use cases, whatever) to the requirements document created by the product manager. Testers are responsible for tracing their test cases to my detailed requirements, and engineers/UI designer are responsible for tracing their design to my detailed requirements. So, the Analysts are not solely responsible for traceability - it's a task shared by all.

Certainly agree with that! I think one of the problems may be that since Product Managers generally start the trace matrix, we're seen as the ones that "own" it (read - do all the work). It's a project artifact, not a requirements-only artifact, so the whole team has to own it (and recognize the value in doing so).

Has anyone had measurable success on using traceability?
For example, did you actually find missing requirements or requirements you did not need?

one of the work products is/are requirements that will be implemented and the implementation will be tested?

I think traceability in terms of being able to trace UAT test plans to requirements is worth the cost. I also feel the same about heirarchical traceability (meaning ensuring all requirements trace up to features then business objectives.)

I agree, the folks writing reqs tend to have a pretty intimate knowledge/familiarity with them and I've experienced too many of the "connections" that you've mentioned to count.

I have worked on a project recently where circumstances dictated that a number of different requirement analysts managed a single topic over time--not AT ALL RECOMMENDED, btw. Anyway, that is an example where we had to explicitly rely on what was documented for our context and connections.

My thoughts on requirements traceability are here (at the Cauvin Blog)

The Ultimate in Requirements Traceability: DBA

Requirements traceability refers to the ease of tracking the relationship of artifacts to product requirements throughout the development process. One form of requirements traceability involves slavishly documenting each design decision and precisely which requirement(s) it addresses. There's got to be a better way. And there is.

If your team isn't communicating well and your process is broken, you are likely to have some of the following problems:

1. Features that are "neat" but don't address requirements.
2. Designs that don't address requirements.
3. Difficulty adjusting to changing requirements, priorities, and scoping.
4. QA that doesn't know what to test.

For this reason, some managers are enamored with the concept of requirements traceability. An untrusting manager tries to impose some heavyweight processes to ensure these problems don't occur. Usually, the process usually involves some huge, complicated spreadsheet with all sorts of links between various items in artifacts.

Instead, why not nudge the team into adopting a few simple, lightweight practices?

Realize that test-driven development (TDD) goes a long way towards establishing a de facto requirements traceability. Encourage your team to "document" its requirements and interaction design decisions as test cases.

But you'll want to test frequently. Use demonstration-based agile (DBA), in which the team delivers a demo and submits things to QA for testing on a weekly basis.

Let's examine the effects of adopting these practices.

First, if design and implementation decisions conflict with the requirements, it will show when the tests fail.

Second, when requirements change, the test cases change, and any other changes that must happen will happen, otherwise the tests will fail.

Third, the weekly demos will ensure that product manager is able to trace or track adherence to the requirements.

Finally, and most importantly, your team will communicate frequently, which will likely improve the quality and efficiency of its output.

Rather than imposing requirements traceability in a heavyweight manner, use DBA.

hmm, i agree with your high-level assertions about TDD and DBA "being good ideas," but I don't see them as being replacements for traceability, but complementary.

In fact, the only things that makes TDD effective as a quality mechanism is traceability of reqs to test cases/scripts.

And after your demos, when the feedback hits the fan, you need some mechanism to trace the features that were exhibited in the demo back to the reqs, right?

I know your comments in your blog were pretty high-level, and that there is probably some detail that wasn't communicated, but if not, how does a failed test help you know what reqs weren't met? And likewise, how does a demo review allow you to systematically determine which reqs were fulfilled/not fulfilled?

i appreciate the clarifications. we must have slightly different definitons or interpretations of the term "traceability." When I implement traceability it is always in terms of a well-defined and somewhat rigid plan with a clearly elaborated methodology for what is traced and how that traceability is used.