EPLC_Requirements_Traceability_Matrix_Template.xls

Instructions

(H – High, M – Medium, L – Low).

Requirement_Traceability_Matrix

This column should contain the unique idenfier of the requirement. It could be a system generated number if using a utility, or manually assigned in a requirements document by the requirements author/analyst.

This column should be used to identify the requirement as a Functional, Non-Functional or Global Requirement.

This column should be used to identify the category of requirement such as: Performance, Interface, Data, Environmental, Human Engineering (Ergonomic), Security, and Special (e.g., conversion).

This column should be populated with a brief description of the requirement.

If the item is a “Functional or Non-Functional or Global Requirement Type,” then identify the associated Functional, Non-Functional or Global Requirement(s) Source(s).

Identify the Design Specification that verifies this requirement. This information is entered after Design Specifications are baselined.

Identify an individual or group responsible for fulfilling this requirement.

In this column assign the requirement to a configuration control request.

This column should be populated with any additional comments that may be useful throughout the life cycle (e.g., the requirement may change in priority based on pending legislation or organizational changes).

This column should be populated with the complexity of the requirement. Rate the difficulty of implementing the requirement as designated by the assigned individual (H – High, M – Medium, L – Low).

This column should be populated with low-level details to be considered during development or implementation of the requirement.

This column should indicate when the requirement was incorporated or changed during the development life cycle (e.g., Requirements, Design, Development, and Testing).

This column should be populated with the name of the module, which either fully or partially satisfies the stated requirement. A blank module name indicates that the specified requirement is presently not mapped to a module.

This column should be populated with the importance of the requirement as designated by/or agreed upon by the users.

(H – High, M – Medium, L – Low).

This column should be populated with a description of any related requirements (e.g., dependencies).

In this column list the specific software release in which the requirement was implemented.

This column should be populated with any high-level outputs produced by the requirement.

This column should be populated with the name and/or organization of the stakeholder(s) or documents upon which the requirement was based. (i.e., CCB, UAT, Development, Design, Testing, JAD).

These columns describe how and when the requirement will be verified/validated.

This column should show where in the system the requirement will be allocated or reallocated along with the version. This information is entered during the System Design Phase.

This column should be populated with description of "how" a requirement was verified (examples include analysis, demonstration, inspection, and test).

This column should be populated with the phase during which the requirement has been verified.

Examples of “when” can be at various test phases (e.g., unit, module, system, or acceptance).

This column should be populated with any high-level input needed to implement the requirement, if applicable. For example, an input to generate past due mailing notices is a list of past due customers from another system.

Larry.Radford_c:

Tested In: This column should be populated with the module that the functional requirement has been tested in.

Larry.Radford_c:

This column should be populated with the module that the functional requirement has been implemented in.

This column should be populated with the test case number linked to the functional requirement.

A unique ID number used to identify the requirement in the requirement traceability log.

This column should be populated with the associated requirements that will be affected if this requirement is changed.

This column should be populated with a description of the technical specification linked to the functional requirement.

This column should be populated with a description of the architectural/design document linked to the functional requirement.

This column should be populated with a description of the system component(s) linked to the functional requirement.

This column should be populated with a brief name or title of the requirement.

This column should be populated with a description of the technical assumption or customer need linked to the functional requirement.

Identify the Integration Test Script that verifies this requirement. This information is entered during the test planning and test procedure development phase.

Identify the System Test Script that verifies this requirement. This information is entered during the test planning and test procedure development phase.

Define when the requirement has been allocated (assigned to either hardware, software, and/or a manual operation), reallocated (changed) or deallocated (removed), or not allocated (never implemented). This information is entered during the System Design Phase.

This column should be populated with the current status of the requirement. Examples: Allocated (assigned to either hardware, software, and/or a manual operation); Reallocated (changed); Deallocated (removed); Not allocated (never implemented).

This column should be populated with the current status of the requirement. Use the following format: DD/MM/YYYY

Allowed Values Table

• Status: This column should be populated with the current status of the functional requirement.

Requirement Type: This column should be populated with the type of requirement: functional, non-functional, etc Complexity: This column rates the difficulty of implementing the requirement as designated by the assigned individual.

(H – High, M – Medium, L – Low).