ProjectConnections Print View
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.
Learn more about ProjectConnections and who writes our content.
Site Help
| Content Levels | |
 | Register for free access to papers, case studies, and almost 50 templates. |
 | Subscribe for complete access: $14.95 monthly or $149/year |
| Risk-free 15-day trial!
Compare levels View sample templates Corporate subscriptions | |
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.
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
- 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.
- 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.
- 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.
- Tracing should start with labeling of requirements in the initial project requirement documents, and proceed as subsequent documents (specifications, etc.) emerge from those requirements.
- 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.
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-2008 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