The Community Blog for Business Analysts


Is Traceability Possible Without a Requirements Tool?

I have spent the last year and a half working on an enterprise software solution development effort where we do not use a Requirements Management tool like Caliber or Visual Studio TFS. Our requirements are created in Word using standardized templates and distributed to Development and Test teams for consumption.

Test cases are written in Excel and tied to the requirements in the documents. In general, I would have to say that coverage is good but not complete (I know this anecdotally since there is no good way using Excel and a bunch of Word documents to know for certain). In theory, a failed test case should mean that a requirement is not satisfied and pinpoints a missed feature or requirement.

This system breaks down totally when it comes to Change Requests that are created during the course of the project. Change Requests are entered directly into a defect tracking system. Change Requests are usually supposed to have detailed requirements associated with them but in practice the quality of the supporting documentation has varied widely. So, Change Requests have little to no systematic traceability associated with them. This is not to imply that the Change Requests are poorly implemented. Just that doing any kind of systematic tracing exercise against them is near impossible.

The key problems I have found with using Excel to perform traceability are as follows.

1. Forward traceability from Business Objectives or High Level Features to specific requirements is very difficult to do and in many cases is just not practical.
2. Managing requirements as they change is very difficult to do. You could have false positives where the spreadsheet tells you there is good coverage without realizing that the underlying requirement itself has changed.
3. Managing multiple tests for a single requirement because very difficult. For example, if a single requirement has to pass 3 test cases for it to be considered fully implemented, the spreadsheet approach becomes error prone and hard to understand very quickly.
4. The spreadsheets themselves become unwieldy as multiple requirements and tests are entered. The volume of data becomes hard to manage and consume.
5. Reporting becomes a hit and miss process. It requires a lot of manual effort, is time consuming and error prone.
6. Requirements that do not start life in a requirements document (Change Requests) are seldom tracked as rigorously as standard requirements.
7. Historical analysis is very difficult to do. On projects that last several years, digging up an old Excel spreadsheet to determine if specific requirements were implemented or not a year ago can easily become a week long exercise in futility.

So what then is the answer to the question I posed at the beginning?

Excel is fine for small projects but larger enterprise grade efforts require a specialized requirements tool with good tracing features.

The odds of performing good traceability on your project are significantly improved when using a requirements management tool. There are real costs associated with unimplemented or improperly implemented requirements. A good tool gives you a better chance of catching these kinds of errors with good traceability features. So, when considering a tool to manage your requirements, do not overlook the quality of their traceability features.

For more check out our blog:

By Abadri

Like this article:
  7 members liked this article

Related Articles


Leslie posted on Tuesday, January 11, 2011 12:11 PM
An idea: Insist that "Change Requests are entered directly into a defect tracking system." ALWAYS trace to a requirement, even if they do not change that requirement.

This will enforce traceability from requirements through to design on anything that is changing. So long as the traceability is in place at the beginning, it should in theory still be there after all the change shave occurred.


Another tool to consider is SharePoint, which may help solve the configuration management and version control problems.

Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC