Requirements Traceability Guideline


Quick Summary
Tracing your requirements to tests, to code, or to other requirements, can be a complex and time-consuming effort. If you're contracted to a government project you may not have a choice. But is it worth it in the private sector? This guideline discusses traceability processes, requirements, and how to weigh the costs and benefits.


This template requires a Premium Subscription
Please log in. Don't have a log-in? Sign up now. Already a Member? Log in to upgrade immediately and get the file! A Premium subscription is only $14.95/month or $149/year and gets you over 200 templates, guidelines, and checklists.
15-day free trial period for new Premium subscribers! Learn more
Log in to download this file

Username:  
Password:  

What this is

Requirements traceability refers to the practice of systematically ensuring that each requirement is explicitly covered in subsequent project documents such as specifications, implementation pieces, and/or test cases. Traceability provides a way to ensure–and prove–that all original requirements were implemented and ultimately tested.

Tracing requirements to test cases is the most commonly used form. Tracing requirements to code is a more difficult sell; government projects often require it, but it's rarely done in the commercial world except in safety-critical applications such as medical device and software design. Is it worth the effort? This guideline discusses traceability in all its forms, and presents information to help answer that question.


Why it's useful

Tracing provides a methodical way to ensure that the project is delivering on the original customer needs and requirements each step of the way. This guideline can be useful for many different project sponsors or participants:

  • Executives who want to minimize maintenance costs by ensuring all requirements are tested.
  • QA/Test managers who need to understand/report how much of the product has been tested.
  • Program managers (titled or informal) who want to be sure requirements are implemented as agreed.
  • Developers who want to ensure that they are building the right product.
  • Program managers (titled or informal) who want to ensure extra requirements aren't added.

How to use it

  1. The project manager and related functional managers (such as test managers and software development managers) should review this guideline and discuss what level(s) of traceability should be considered for particular projects. See in particular the section on Deciding What and How to Trace on page 9.


  2. Based on those decisions, assign responsibility for creating and maintaining labeling guidelines and for definition, initial creation, and upkeep of any traceability matrix (or matrices) to be used. Ideas and models are included.


  3. Team members creating key documents like detailed implementation specifications or test plans should be briefed on the tracing benefits as well as the standards decided upon.


  4. Tracing should start with labeling of requirements in the initial project requirement documents, and proceed as subsequent documents (specifications, etc.) emerge from those requirements.


  5. Tracing matrices should be part of key reviews. Any item the team has decided to include in tracing (e.g., lower level specifications, designs, code modules, test cases) should not be considered complete until review has verified that all higher level requirements have been properly accounted for.
About the Author
Anita Wotiz has held high-level management positions at a variety of companies and has transitioned from large, government research firms to small start-ups. With over 20 years of software engineering experience, she is adept at tailoring best practices to meet a company's needs regardless of size, and at implementing cost-effective practices. Her years of experience have taught her what works and what doesn't (which is sometimes just as important). Anita holds a BS in Mathematics and an MS in Computer Science. She is currently the Coordinator of the UC Santa Cruz Extension Software Engineering Management program, where she is also an instructor.

This template requires a Premium Subscription
Please log in. Don't have a log-in? Sign up now. Already a Member? Log in to upgrade immediately and get the file! A Premium subscription is only $14.95/month or $149/year and gets you over 200 templates, guidelines, and checklists.
15-day free trial period for new Premium subscribers! Learn more
Log in to download this file

Username:  
Password:  





Related Templates
Configuration Management Plan
A Configuration Management Plan attempts to avoid lost time and expensive rework by documenting procedures the project team will use to control critical components of their project's "products"—hardware, software, documentation, written products, etc.

Requirements Measurement Plan
This template is designed to help you think through how you will ensure that the documented requirements meet the expectations of your stakeholders, both in content and in quality.

Requirements Change Management
Condenses 20 years of lessons learned to provide a complete overview of change management components, processes, and controls.

Software Requirements Capture Guideline
Detailed guidelines from an experienced software development executive.




©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
888-722-5235
Learn more about ProjectConnections, our contributors, and our membership levels and product options.