Connecticut Department of Social Services
Enterprise Program Management Office
Requirements Traceability Matrix
Purpose of the Requirements Traceability Matrix
The Requirements Traceability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Traceability Matrix is to ensure that all
requirements defined for a system are tes ted in the test protocols. The traceabilit y matrix is a tool both for the validation team t o ensure that requirements are not lost durin g the validation
project and for auditors to review the validation documentation.
Information to Include
The requirements traceability matrix is usually developed in concurrence with the ini tial list of requirements (either the User Requiremen ts Specification or Functional Requirements
Specification). As the Design Specifications and Test Protocols are developed, the traceability matrix is updated to include t he updated documents. Ideally, requirements s hould be traced to the
specific test step in the testing protocol in which they are tested.
How the RTM is used
A requirements traceability matrix is u sed to check if the current project requirements are bei ng met or to help in the creation of a request for pro posal, software requirements specification,
various deliverable documents, and project plan tasks.
Change Impact Analysis – if a requirement is changing , trace links inform about related and dependent art ifacts. These artifacts can easily be verified and if requ ired, be adjusted. The probability
to overlook related artifacts is redu ced.
Coverage Analysis – Traceability ensures that no requirements are overlooked. Especially when certify ing safety-critical products it is necessary t o demonstrate that all requirements are realized.
Project Status Analysis – Tracking of the pro ject status is possible: analyzing t he traceability data allows the project manager to s ee the completion status of the requirements . Requirements
without links or with incomplete trace chains (e.g. requirements with implementation but without tests) indicate that further work is necessary. The missing links show which concrete artifacts
are missing and need to be realized.
Reuse of Product Components – it is possible to structure requirements and their linked artifacts into packages. These packages can be used for different products.
Persisting Relationships
– Often knowledge of a project or product is in the head of specific persons. By use of traceability this knowledge is saved by visualizing the relation between the different
artifacts. This knowledge remains even if a person leaves the project.
Test Optimization – By linking requirements, sou rce code, test cases and test results it is eas y to identify affected parts of the source code i f tests fail. Furthermore, redundant test cases can be
identified and eliminated.
Instructions
Enter the information defined below in the corresponding field on the appropriate requirement type tab.
Requirement Types -
Functional: a functiona l requirement is any requisite which specifies what the system should do. It describes a particular behavior of function of the solution when certain
conditions are met, for e xample: “Send email when a new customer sig ns up” or “Open a new account”.
Non-Functional: A non- functional requirement is a requisite which spe cifies how the system performs a ce rtain function. It describes how a sys tem should behave and what
limits there are on its functio nality. Non-functional requirements genera lly specify the system’s quality attributes o r characteristics, for example: “ Modified data in a database
should be updated for all users accessing it within 2 seconds.”
Technical: Technical r equirements are the technical issues that mus t be considered to successfully c omplete a project. These are arc hitectural aspects the solution must
meet in order to pass acc eptance. E.g. the system's compo nents must be modular and support loosely c oupled integration with an Enterprise Service Bus (ESB) through
RESTful Web Services . It is important to note that many technical requirements can also be considered no n-functional requirements. It is upon the pro ject's analysts to choose
the appropriate level of dis tinction between the two.
Other: Any other type of require ment not listed above
DSS Project Management recommends the fil e name be added to the page footer during requirements traceability matrix set up.
Fields
ID - Enter a unique ID number used to identify the requirement in the requirement traceability matrix
Associate ID - Enter the ID of any associated utilities used for requirements tracking such as a repository, pipeline document, contract reference number, etc.
Business Topic - Enter a business topic or category to group requirements
Rqmt Description - Enter the description of the requirement. When a requirement is "In Test", in the Notes field, indicate the type of test that is in progress, i.e. System,
Rqmt Status - Select the current status of the requirement
In Backlog: The requirement has been recorded in the project requirement backlog
In Development: Development has commenced on the requirement
In Test: The requirement is in test
In Acceptance: The requirement is in acceptance criteria review
Complete: The requirement is complete
Rqmt Source - Indicate the Source of the Requirement. In the case of "Discovery" annotate the change request in process or approved change control linked to the new
requirement
- Contract
- RFP
- SOW
- Project Charter
- Discovery
Rqmt Owner - Enter name of person responsible to manage the requirement
Work Product/Artifact Name - Enter the Work Product or Artifact Name for cross-referencing; such as name of the requirements document or user story or use case.
Test Case ID - Enter the Test Case ID that will include this Business Requirement. In the event of multiple test IDs against a single requirement, list each ID comma-delimited
OR break the requirement into smaller requirements for each test ID and list on separate lines. For example: "Rqmt AAA" becomes "Rqmt AAA:Child Rqmt 001", "Rqmt
AAA:Child Rqmt 002", "Rq mt AAA:Child Rqmt 003", ...
1 of 11
