Connect the Dots; Five Tips on Requirements Traceability

Written by John Simpson on November 17, 2009. Posted in Articles.

As a business analyst do you ever feel like you are Russell Crow’s character in the movie A Beautiful Mind where it takes a genius to track and relate all the information you’re managing within your projects?

Welcome to the World of Requirements Traceability and Impact Analysis

In this article, our goals are to demystify traceability and its related concepts, and provide insights and examples for five tips to help you take control of requirements and keep everyone in sync. Traceability is a hearty topic, so along the way, we’ll try like heck to keep things educational and entertaining, such as other movie references to The Matrix and Quicksilver.

Have we piqued your interest? Read on my business analyst friends…

What the Heck is Traceability?

It sounds so clinical and complicated. Why do teams do it? It sounds like a lot of work. Is traceability really worth the effort? Good questions. The short answer: Yes. And, here’s why it’s so important in one word: Change.

If managed poorly, change will wreak havoc on even the most talented and experienced development teams. If change is managed skillfully, using tools like traceability, teams are better equipped to assess the impact of changes, track the history, keep everyone in sync and (deep breath) consistently improve the quality of the products they’re building – every project, every release. Sign me up.

In some industries, traceability isn’t an option, it’s mandated. I’d recommend that regardless of the industry you’re in or the process you use – whether you’re building components for commercial airplanes using Waterfall or designing the next killer iPhone app using an Agile method – traceability is an industry best practice that will benefit your team greatly. But, like everything it comes with its challenges.

CHALLENGES

Swimming Upstream or Downstream without a Trace is Risky Business

You can probably relate to these scenarios. You get a great new insight from your best customer mid-project, and a high-level business requirement needs to change. How will this change impact the functional requirements your developers are working on right now? Your QA team just found a deal breaker of a bug in your most popular feature and you’re two weeks away from launch. Do you ship with the known bug or delay the launch? Who is working on that feature? Who else needs to be notified and weigh in on the decision? What else does it affect? These scenarios occur daily for development teams. So, how do you deal with them? How do you minimize risks and manage change effectively? One of the tools in your arsenal is traceability.

One common challenge that teams face in implementing traceability is the incremental time and costs involved. There’s no question that in order to do traceability well, there is a time investment that’s needed upfront to set up the trace relationships and configure coverage reports. However, the incremental costs incurred with using traceability are significantly outweighed by how much time and money you will save further along in the development process, due to the benefits that traceability provides.

BENEFITS

Traceability is Your Ticket to Greater Project Success – On Time, On Budget and Within Scope

For most organizations, the benefits outweigh the time required to set-up traceability by at least 2X. With a consistent process, structured templates and the help of a modern requirements management tool, much of the process can be automated and streamlined. Even if you opt to manage it manually, traceability offers several valuable benefits to your organization:

Minimize Risk. Assess risks and the overall impact of a change before it’s made
Control Scope Changes. Manage change throughout the process and avoid scope creep
Improve Quality. Ensure quality standards are met or exceeded to achieve industry compliance
Reduce Development Costs. Avoid gold plating and costly engineering rework
Increase Productivity. Keep the team in sync and reduce administrative overhead
Complete Test Coverage. Ensure all requirements are properly tested before a release
Greater Visibility. Gain end-to-end visibility into the process for the entire team and stakeholders
Accelerate Innovation. Cut product planning and developments cycles in half

TERMINOLOGY

Before we dive into the five tips, let’s take a moment to define a few terms.

Terminology	Definition
Traceability	Traceability is a sub-discipline of requirements management. Traceability documents the life of a requirement, tracks every change and links its relationships with other items within a project.
Trace Relationship	A link between items within the scope of a project, used to help assess impact on other items when a change occurs.
Upstream	Upstream relationships, a.k.a. backward traceability, look at the links between detailed functional requirements back up to the original customer need and high-level requirements captured. It’s used to ensure that the evolving product remains on track in regards to the goals of the product and what customers need. Helps to avoid scope creep and gold plating.
Downstream	Downstream relationships, a.k.a. forward traceability, look at the links between a high-level requirement and the functional requirements, test cases, tasks, defects and other items that support it. It’s used to ensure that you’re building the right product.
Traceability Matrix	A traceability matrix is created by associating requirements with the work products that satisfy them. Often it’s used to track tests associated with the requirements on which they are based and the product tested to meet the requirement.
Impact Analysis	Using impact analysis, traceability links between requirements, specifications, design elements, and tests are captured, and these relationships can be analyzed to determine the scope of an initiating change.
Version History	Used for change control, a detailed history of each version of a requirement, or other types of items, is documented and stored in a system of record, enabling complete audit trails used for change management over the lifecycle of the requirement.
Suspect Links	Suspect links help to manage the impact of requirement changes. A trace relationship (or link) becomes suspect after a requirement in the relationship changes. A suspect links report is often used along with Impact Analysis for assessing impact before making a change.
CMMI	Created by the Software Engineering Institute, CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. As it relates to traceability and requirements management maturity, see Levels 2-3.

TIP #1. It’s like the Six Degrees of Separation from Your Business Objectives (instead of Kevin Bacon)

Look at that, we managed to slip in a Kevin Bacon reference. It isn’t just because we’re fans of the movie Quicksilver, it actually has relevance here. As in many aspects of life, your product development success is highly dependent on relationships. All of the details such as user requirements, functional requirements, test cases and other items that define the scope of what you’re building are related in some fashion, either directly or indirectly. Here’s an example of a common process flow.

Using trace relationships you can connect everything together to map out the interdependencies between the different items. These relationships are the foundation for doing traceability effectively. As another example, here’s a screenshot of a Visual Traceability Layout showing both upstream and downstream items related to this requirement.

In addition, trace relationships are as much about connecting the people involved as about connecting all the items. Each requirement in the system has customers, stakeholders and members of your team associated with it. There are analysts who own defining it. There are developers building it. There is the QA team testing it. And, there are stakeholders and customers who care about its status.

When one item changes it has a ripple effect on other related items and the people associated with it. Keeping track of this ripple effect is crucial to the success of your projects. That’s one of key reasons to do traceability.

TIP #2. Mr. Anderson – Welcome to the Traceability Matrix.

Wow! And now a reference to The Matrix movie; we’re on fire. In all seriousness, a Traceability Matrix isn’t science fiction. It’s very real, and can be a valuable report for helping you ensure complete test coverage. For a manual example of a Traceability Matrix, you can build one in Excel such as this one courtesy of Joyce Ludwig.

ID	User Requirements	Forward Traceability
U2	Users shall process retirement claims.	S10, S11, S12
U3	Users shall process survivor claims.	S13

ID	System Requirements	Backward Traceability
S10	The system shall accept requirement data.	U2
S11	The system shall calculate the amount of retirement.	U2
S12	The system shall calculate point-to-point travel time.	U3
S13	The system shall calculate the amount of survivor annuity.	U3

This simple insurance claims system example shows both forward and backward tracing between user and system requirements. User requirement identifiers begin with “U” and system requirements with “S.” Tracing S12 to its source shows this requirement is problematic, and should be rewritten to support the processing of survivor claims or the traceability link corrected.

Here is an example of an automated Traceability Matrix generated from Contour. In this example, the matrix is reporting on the relationships between Features and Test Cases. This is useful to identify gaps in test coverage, which is a popular use of a trace matrix to ensure each feature is properly tested.

TIP #3. Impact Analysis – Your Virtual Crystal Ball into the Future.

What if you could anticipate the impact a change would have on your project and the entire team before it occurred? Would this potential change send the development team over the edge or would they have bandwidth to squeeze it into the next release? These insights are possible and the tool to get them doesn’t require a Weegie board or any magical pixie dust, just Impact Analysis. Impact analysis relies on the trace relationships you’ve set-up prior and reports on the complete picture of all the items that are affected – both directly and indirectly.

Here’s an example of an automated impact analysis report for a high-level business requirement. If it were to change, four directly related system requirements would be affected and one indirect use case would also be impacted.

Now if only we could apply impact analysis to other aspects of our lives, like the decision to have that second helping of pumpkin pie on Thanksgiving. What’s the impact on “project reduce fat tire”? Oops, better expand the scope on that one and push out the release date until New Year’s.

TIP #4. Version History – Your Complete Audit Trail in Rich, Glorious Detail. Whoohoo!

If you prefer things at a high-level and don’t like to dive into the details, look away. This tip isn’t for you. This tip on version history is for those among us that like to roll-up their sleeves and get deep into the glorious details of every little change. It’s also been humorously referred to as the “CYA tip”, for coverage of a different kind.

Personal motives aside, capturing a complete and detailed record of all changes is a critical element for reaching higher levels of requirements maturity within your process, such as CMMI. It’s also helps companies meet industry compliance standards in specific fields, such as aerospace and medical devices. One of the benefits of doing traceability is having a comprehensive audit trail of changes, so you can analyze who, what, when and why a change occurred. At the same time, you can easily roll-back to an earlier version if needed because it’s all stored in the unified system of record.

Here’s an example of seeing a side-by-side comparison of two versions, using an automated process within Contour. For efficiency gains, the specific field that changed is highlighted in yellow, so you don’t have to spend time hunting around the full requirements specification document to pinpoint and understand precisely what changed. Viva la details!

As with the other aspects of traceability, you can track version history manually through static documents using versioning. It’s just more cumbersome and time consuming to manage complex projects that way.

TIP #5. Avoid Noise. Communicate Changes Quickly, Intelligently and to Those Who Care

How often have you been involved in a project where “change notice paralysis” sets in after about two to three weeks of inbox overload? Usually it occurs when the entire team is on a project-wide distribution list and the project manager is on the hook to send out an email with the complete 200-page Software Requirements Specification document attached for every little change that occurs. Right intention, wrong solution. What happens next? People waste time hunting around in the requirements spec, trying to determine if the latest change is relevant to them, which is costly. Or, they tune out the email barrage as noise and become vulnerable to missing a change that is important to what they’re working on, which is also costly.

There are smarter ways to keep everyone on the same page. You need to ensure that everyone impacted by a change is in the loop. At the same time, you don’t want to flood the entire organization with emails. What do you do?

In this example using Contour, when a change occurs, you can instantly send a direct link to the specific requirement that changed with version notes to just the relevant groups or individual users that are affected by it. The notification step is then part of the overall change management workflow. Stay in the loop. Avoid noise.

Let’s Automate!

You can manage traceability manually using Microsoft Word or Excel documents. That’s a real option. For small teams and simple projects, that’s probably all you need. We’ve provided links to a few free templates courtesy of industry experts that you can use to manage traceability manually:

Traceability Matrix Template (.xls) from the CDC.gov, requirements management templates
Impact Analysis Checklist (.doc) from Karl Wiegers, Process Impact

The challenge with a manual process is it can be extremely time consuming and cumbersome if your projects have any level of complexity – meaning you have many requirements, frequent scope changes or if members of your team are remote working from different locations. In these scenarios, automation can provide a huge boost to productivity, saving you valuable time and money. Automation also minimizes the risks of human error.

What’s the ROI?

The return on investment is different for every company, but through our experience, we’ve seen as high as a 42:1 benefit-to-cost ratio for a global entertainment company. For most organizations, as a conservative benchmark, you can expect to speed development cycles by 50% and improve quality by 2X or more within the first six months, using a requirements management application.

Take Action!

Concepts are nice, but actions are what matter most. Take action today to become a traceability master.

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 14 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware