Requirements tracing

7 Pages·0.435 MB·English

by  Starrett C.

W H I T E P A P E R
Requirements Tracing
Cort Starrett
System-Level Engineering Division
Mentor Graphics Corporation
www.mentor.com
Requirements Tracing with BridgePoint
Requirements tracing is accomplished in different ways within different development organizations.
This note describes requirements tracing and one example of its deployment within an engineering team.
This process uses common issue tracking and configuration management tools working together with
source code editors and UMLmodeling tools.
Aclass diagram is supplied below which outlines the entities involved in development in the context of
requirements tracing. This diagram will be referenced throughout the note.
2 Requirement Tracing
Connecting and Reporting (Forward and Reverse Tracing)
Requirements tracing requires two operations, "requirements connecting" and "requirements reporting".
Such connecting and reporting allow the life of a requirement to be traced both forward and backward.
Requirements connecting occurs in real-time while developers are creating and modifying engineering
artifacts such as code, documents and models (hereafter "source"). Looking backward, reports are
generated that interrogate the connections between the source and the input requirements.
See the following figure showing an example of a source artifact being committed (to CVS in this case)
and simultaneously being connected to requirement number 2336. (Note "issue:2336".)
Requirement Tracing 3
Step-by-step Process
1. Requirements are established in specification documents and enumerated in a requirements
tracking system (issue tracker). Example issue trackers include DOORS, ClearQuest, Gnats,
Bugzilla and similar tools.
2. Source artifacts are created by developers. This source comes in the form of C source, models,
documentation and other information stored in files for a project.
3. All source is maintained within a configuration management database such as ClearCase, CVS,
Subversion or another similar tool.
4. Source is tagged with the identifier (issue number) of the issue for which the source is a
requirement. In models this is done in a number of ways. In BridgePoint, the issue number is
added to the description of the artifact being edited. (See figure showing a class being tagged
with a requirement. Specifically, see the "issue:2336" tagging in the Model Class Description.)
4 Requirement Tracing
5. As source is created, links to the precipitating requirements are established as requirements
connections. This is done through "commit time scripts" which are explained below.
6. As source is changed, requirements are linked to these changes to the source using the same
commit time scripts mechanism.
7. As code is generated from models, the requirement issue number is generated from the models
into the code. Also, the issue numbers can be generated into the code as hyperlinks into the
requirements issue tracker. This allows developers to simply click on the issue link from inside
the generated code. (See example generated source code highlighted below.)
Note on the class diagram in the first figure the association (R7) between the classes "model" and
"generated code". This link shows that a trace from the generated code back to the model and then back
to the requirement can be made. With the identifier of the requirement generated into the code from the
model we can connect all source artifacts back to fundamental input requirements. As requirements
change, which they do, the model can emit the appropriate requirement identifier automatically each
time the code is (re-)generated. The above example generated code also demonstrates this capability.
Reporting
As soon as one requirement exists and one source artifact exists, a report can be created that traces the
requirement to the source artifact. Any requirement in the issue tracker that does not have a requirement
connection with the same identifying number is an unmet requirement. Reports need to reflect and draw
attention to unmet requirements.
The above process has been used in development for several years. One team uses CVS and Subversion
as the configuration management databases. Bugzilla is used for issue tracking. Each issue has a
number. As models, documents and hand crafted code are edited and "checked in" to CVS, a "commit
time script" runs automatically. The script asks for the issue number and logs the change to the source
artifact against that issue (requirement).
This same type of connection is built in to ClearCase/ClearQuest. It can be enabled for code, models
and documents.
Requirement Tracing 5
Commit Time Scripting
Virtually every configuration management tool provides "commit-time scripting". This is simply a hook
into the tool to run scripts as a gate to committing changes into the database. Commonly, this hook is
used to run lint or other source code checkers. Some organizations compile the source and run unit tests
as a gate to commitment into the config management system.
The above mentioned team runs a CVS/Bugzilla bridge at commit time. This bridge forces developers
to associate the source code being committed to the Bugzilla issue that precipitated the change.
Note the issue number 2336, in the example (showing Bugzilla, though the idea is the same with other
issue trackers).
6 Requirement Tracing
Process Benefits
The above process ensures the following:
h All requirements (new functionality and/or defect) get an issue in the tracker.
h All changes committed into the source code repository have an issue tracking them.
h Every change is logged against an issue.
h Requirements can be traced from the issue tracker into the source code answering the requirement.
Reporting
Reports can be run from the issue tracker and configuration management systems that indicate progress
against requirements input. Search tools can scan the source code to identify the requirements issue
"tags" throughout the source artifacts (code, models and documentation).
Thus requirements lifecycle tracing is accomplished. Requirements can be connected to source artifacts
in the forward direction. Source artifacts can then be traced to their "parent" requirement through the
tracking databases and directly in the source. This technique for providing tracing is not overly
burdensome to developers and has proven practical and effective through several years of practice in the
development shop.
For more information visit: www.mentor.com
Copyright © 2007 Mentor Graphics Corporation. All Rights Reserved.
This document contains information that is proprietary to Mentor Graphics Corporation and may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that
this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent the unauthorized use of this information. Seamless and Mentor Graphics are
registered trademarks of Mentor Graphics Corporation. All other trademarks mentioned in this document are trademarks of their respective owners.
Corporate Headquarters Silicon Valley Europe Pacific Rim Japan
Mentor Graphics Corporation Mentor Graphics Corporation Mentor Graphics Mentor Graphics (Taiwan) Mentor Graphics Japan Co., Ltd.
8005 SW Boeckman Road 1001 Ridder Park Drive Deutschland GmbH Room 1001, 10F Gotenyama Hills
Wilsonville, OR 97070-7777 San Jose, California 95131 USA Arnulfstrasse 201 International Trade Building 7-35, Kita-Shinagawa 4-chome
Phone: [phone] Phone: [phone] Munich No. 333, Section 1, Keelung Road Shinagawa-Ku, Tokyo 140
Fax: [phone] Fax: [phone] Germany Taipei, Taiwan, ROC Japan
PSaleesr afnod Prrmoduact nInfcormea tiPonrofiNloertrh American Support Center Phone: [phone] Phone: [phone] Phone: [phone]
Fax: [phone] Fax: [phone] Fax: [phone] MGC 7-07 TECH
Phone: [phone] Phone: [phone]