Software Requirements Traceability Matrix

Software Requirements Traceability Matrix

Definition of a Requirement

As per IEEE Std 610.12-1990, A requirement is defined as a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. Desirable qualities of requirements include the following:

·  Correct – Each requirement should be stated without error

·  Complete – The set of requirements are considered to be complete when if all possible states, state changes, inputs, products and constraints are described by some requirement.

·  Consistent – There should be no conflicting or ambiguous requirements

·  Realistic – can the requirement actually be implemented

·  Verifiable – A test must be able to be written that demonstrates that the requirement has been met

·  Traceable – Each system function must be traced to a set of requirements that mandates it.

System requirements are obtained from any or all of the following customer artifacts:

·  Statement of Work (SOW)

·  Change Requests

·  Customer Meeting Minutes

·  Operations Requirements Documents (ORD)

·  Proposal/Request For Proposal (RFP)

During System Requirements Analysis and System Architectural Design the system level requirements are analyzed. The system requirements are then documented in the System/Subsystem Requirements Specification (SSS). The SSS:

·  Contains the System Level Requirements

·  Defines the overview of the system’s behavior

·  Includes the requirements for hardware, software, program management, operators and networks, etc.

Also during this timeframe, the system analyst creates a Requirements Traceability Matrix (RTM) that allocates all requirements into categories such as the following: hardware, software, documentation, quality assurance, testing, project management, etc.

Definition of the SRTM

The Software Requirements Traceability Matrix (SRTM) is a tool that will be used to trace software requirements back to the Source Document(s) and forward to the software requirements, software design and software test documents. The software requirements are derived from the System Requirements Analysis and System Design activity. Only those requirements, which have been allocated to software will be carried through to the SRTM.

Add text here to address COTS, MOTS, and legacy code

Source Document Reference / Source Requirement Description / SRS / IRS Reference / SDD / IDD / DBDD Reference / Software Test Procedure / Other Reference /
Comments
Parent document identifier and specific section number (and paragraph number if necessary) (lowest resolution possible) of the requirement that was assigned to software during the System Requirements Analysis and System Design. / Description of the requirement from the parent document (summary or complete text) / The unique requirement identifier and document identifier (SRS / IRS) for this software requirement. / The design entity(ies) identifier(s) and document identifier (SDD / IDD / DBDD) for the design which implements this software requirement. / The software test procedure identifier(s) for the tests which validate this software requirement. / References to other documents or additional comments

DEFINITION OF EACH COLUMN:

Source Document Reference

This column shall contain a backward reference to appropriate Source Document and the specific section from which this requirement was derived. The Source Document may be the Scope of Work, the Operations Requirement Document, the Request for Proposal, the System Specification, etc. The section reference should provide a reference to each sentence within the Source Document that represents a software requirement.

Source Requirement Description

This column shall contain either the exact requirement text from the Source Document or shall contain an abbreviated description of the requirement. The content of this column shall be defined by the Authority having jurisdiction. When deciding whether to break a statement into individual requirements, the analyst should consider how the requirement would be tested. If the requirement will be tested by a single test procedure, then the requirement probably does not need to be broken down further. If the requirement will be tested by multiple test procedures, then the requirement should be broken down into multiple requirements. It is important to follow a consistent and documented methodology for breaking down requirements.

SRS/IRS Ref.

The software supplier may elect to create an IRS in addition to the SRS. This column shall contain a forward reference to the document identifier (SRS/IRS) and a requirement identifier within the document. All software requirements must be mapped to one or more section(s). The reference to the SRS/IRS section number shall correspond to the lowest level of detail defined within the SRS/IRS Table of Contents.

SDD/IDD/DBDD Ref.

The software supplier may elect to create an IDD and/or DBDD in addition to the SDD. According to IEEE Std 1016, “In a complete SDD, each requirement must be traceable to one or more design entities... Entities can exist as a system, subsystems, data stores, modules, programs and processes.” This column shall contain a forward reference to the document identifier (SDD/IDD/DBDD) and a unique reference to one or more design entity(ies).

Software Test Procedure

This column will provide a forward reference to the Software Test Procedure identifier in which this software requirement will be validated.

Other Reference/Comments

This column will provide references to other documents or free-form comments as necessary.

EXAMPLES

This section will address different ways of viewing the information contained in an SRTM.

Source Document Reference / Source Requirement Description / SRS / IRS Reference / SDD / IDD / DBDD Reference / Software Test Procedure / Other Reference /
Comments
Springfield TS 17XB.1.3-12 / The automatic restoration mode shall be the default mode of operation. / CDRL010-SRS-0567 / CDRL008 -HLSDS -0144 / CDRL021 & 019 TEST FAT 03-02-01-03-1
Springfield TS 17XB.1.3-7 / An authorized user shall be able to place each FCU individually into either a manual or automatic restoration mode. / CDRL010-SRS-0567 / CDRL008 -HLSDS -0144 / CDRL021 & 019 TEST FAT 03-02-01-03-1
ES-3.1.3 / External Output Signals
ES-3.1.3.1 / Speedometer / SRS-P-3.2.1.3.10
ES-3.1.3.2 / Odometer / SRS-P-3.2.1.3.9
ES-3.1.3.3 / Sanding Control / SRS-P-3.2.1.3.19
ES-3.1.3.4 / Propulsion Fault
ES-3.1.3.5 / Dynamic Brake Fault
ES-3.1.3.6 / Ventilation Fault / SRS-P-3.2.1.2.20
ES-3.1.3.7 / Maintenance Required Fault / SRS-P-3.2.1.2.15

here’s another example: note that document identifier is in the column header. In this example there is no IRS, and there is only one SRS.

Subsystem SFD Ref.
999-ABC-0000 / Requirements Description
(From SFD) / SRS Ref.
999-ABC-xxxx / SDD Ref.
999-ABC-xxxx / Software Test Procedure(s)
999-ABC-xxxx / Comments /
Interfaces
7.2, 8 / Serial / 0004 - 3.1.1 / 0005 - 6.2 / 0042 - 9.1.7, 9.1.8
7.2, 8 / Digital Module Interface / 0004 - 3.1.2.1 / 0005 - 6.2 / 0042 - 9.1.9
7.2, 8 / Slave B / 0004 - 3.1.3 / 0005 - 6.2 / 0042 - 9.2.8
7.2, 8 / Slave P / 0004 - 3.1.4 / 0005 - 6.2 / 0042 - 9.1.10, 9.1.11
7.2, 8 / SPI HMM / 0004 - 3.1.5.1 / 0005 - 6.2 / 0042 - 9.1.12
7.2, 8 / SPI RTC / 0004 - 3.1.5.2 / 0005 - 6.2 / 0042 - 8.2.1
7.2, 8 / LVDT Signal / 0004 - 3.1.6 / 0005 - 6.2 / 0042 - 9.1.4
7.2, 8 / Sensor Power Supply / 0004 - 3.1.7 / 0005 - 6.2 / 0042 - 9.3.2.2, 9.4.2.2
7.2, 8 / Self test push button / 0004 - 3.1.8 / 0005 - 6.2 / 0042 - 9.1.6
7.2, 8 / Fault Status Indicator / 0004 - 3.1.9 / 0005 - 6.2 / 0042 - 9.1.6, 7.8