REQUIREMENTS COLLECTION Template

A GUIDE FOR REQUIREMENTS GATHERING AND TRACE-ABILITY MATRIX DEVELOPMENT

Revision: 1.0

About this document 3

Guidelines for using the Requirements Collection Template 4

Requirement ID: 4 Requirement Type 4 Parent Requirement#: 5 Source and source Document: 5 Dependencies: 5 Definitions of Priorities: 5 Tracking Requirements and status 6 Status Options: 6 Change History: 6 Clarification/specification of Requirement 6 Rationale: 6 Acceptance/Fit Criteria: 6 Dependencies: 6

The requirements collection template form 7

Requirements Traceability Matrix 8

About this document

Requirements are the foundation of the project and the development of the product that the project has been organized to develop. The purpose of this document is to present a standardized requirements collection template.

The template proposed in this document serves a variety of purposes. It is intended for all types of project requirements:

• Business

• User

• System

• Functional

• Non-Functional

The template is useful for the development of a traceability matrix because it tracks a requirement to its parent requirement, and requests the source and or document from which the requirement came.

The template also supports specific, measureable, attainable, realistic and testable requirements by asking for supporting clarifications for the requirement.

Recognizing that not all requirements are included in the final product, the form also tracks the priority and the history of the requirement.

The collection template is intended to be copied and pasted into the various documents that form the chain from business requirements, to user, system requirements and operational requirements. Part of the template references use cases if the project calls for them and traces these back to a specific requirement.

Guidelines for using the Requirements Collection Template

Requirement ID:

Every requirement needs to be uniquely identified. The Requirement ID is the unique label given to that requirement. Each team can develop its unique numbering convention. Here is an example naming convention:

Business Requirement = B1a

(B=Business, 1=Business req. number, a=first revision)

Note: Business requirement number should always be a whole number value.)

User Requirement = U1.1a

U=User, 1=business req. number (detailed by this user requirement), 1= User req. number, a=first revision)

Note: User requirement number should always follow a business requirement number, and always be in the second position.)

System Requirement = S1.1.1a

(S=System, 1=bus. req. num., .1=User req. number (detailed by this system requirement), 1 =System req. number, a=first revision)

Note: System requirement number should always follow a user requirement number, and always be in the third position

Requirement Type

For requirements derived from the business, users, and system requirements, use the requirements type field. This will enable you to place the form in the appropriate section of the user and system requirements document.

Requirements Types:

• Functional Requirements

- Behavioral

- Data

- User Interface

• Non-Functional Requirements

- Hardware - User Security

- Software - Legal

- Network - Privacy

- Integration - Software Licensing

- Architectural - Documentation

- Performance - Cultural/Political

- Data Management - Internationalization/Localization

- Production Support - Safety

Parent Requirement#:

• Requirements have a natural hierarchy. They flow from high-level business requirements to user requirements, ultimately to system requirements. This field captures the higher level requirement for the one described. (e.g., The business requirement # (Parent) that a user requirement (child) provides additional detail for should be place in this field.

Source and source Document:

• Source would be individuals or groups who have proposed this requirement.

• The source document is any reference document that either generated the requirement directly, or was the impetus for its creation. (e.g., A user requirement developed from a process work flow model should reference the work flow model in this field.)

Dependencies:

• Dependencies are other requirements (not contained in the parent-to-child relationship) that are critical to successfully implementing the stated requirement. (e.g., This system functional requirement has a dependency on a specific data system requirement, in which if the data requirement is not satisfied, the functional requirement cannot be satisfied.)

• Dependencies are usually only captured for the same level of requirement hierarchy (e.g., user req. dependant on another user req., system req. dependant on another system req.).

Note: It is not necessary to capture all requirement relationships in this section. It is only required to capture critical dependencies.

Definitions of Priorities:

• Essential = System not acceptable unless this requirement is provided in an agreed manner.

• Conditional = would enhance the system, but would not make it unacceptable if absent.

• Optional = Might be worthwhile if resources permit.

Tracking Requirements and status

Status Options:

New, agreed-to, base-lined into project documents, rejected.

Change History:

This field is used to track any changes in wording or detail including requirement status.

Clarification/specification of Requirement

Rationale:

What is the importance, value or purpose of the requirement?

Acceptance/Fit Criteria:

How will we know if the requirement has been met? Are there measurements?

Dependencies:

What other requirements or factors will this requirement be dependent upon in the project?

The requirements collection template form

This table below is intended to be copied into other documents such as a collection of requirements, the business requirements template, the user and system specifications document.

|Requirement ID | |Requirement Type | |Use Case # | |
|Status |New |
|Description | |
|Rationale | |
|Source | |Source Document | |
|Acceptance/Fit Criteria | |
|Dependencies | |
|Priority |Essential | |Conditional | |Optional | | |
|Change History | |

Requirements Traceability Matrix

Ultimately all the requirements that have been gathered need to be accounted for. Some might be prioritized as being of low priority and rejected as they are reviewed or later in the project. Part of the accounting would be dealt with in the history section.

For those accepted and base lined into the business, user and system requirements, each will need to have identified the parent requirement. This allows for a bi-directional traceability as illustrated below in a typical V chart.

[pic]

The illustration below diagrams the process of moving from business requirements through to the IT solution.

[pic]

The Requirement Traceability Matrix (RTM)

| | | | | |
|Requirement Hierarchy Example | | | | |
|Hierarchy ID |Business Requirement ID|User Requirement ID |System Requirement ID |Source |
|H-1 |BR-1 |UR-1.1 |SR-1.1.1 |Project Brief |
|H-2 | | |SR-1.1.2 |Process Model A |
|H-3 | | |SR-1.1.3 |Data Model X |
|H-4 | |UR-1.2 |SR-1.2.1 |Business Owner |
|H-5 | | |SR-1.2.2 |Process Model B |
|H-6 | |UR-1.3 |SR-1.3.1 |Policy Manual |
|H-7 |BR-2 |UR-2.1 |SR-2.1.1 |Goal Model |
|etc… | | | | |
| | | | | |
|Trace Document Example | | | | |
|Traceability ID |System Requirement ID |Use Case ID |Test Cast ID |Solution |
|T-1 |SR-1.1.1 |UC-1.1 |TC-1.1.1 |Oblix |
|T-2 | | |TC-1.1.2 |Oblix |
|T-3 | |UC-1.2 |TC-1.2.1 |Oblix |
|T-4 | | |TC-1.2.2 |Oblix |
|T-5 | | |TC-1.2.3 |Oblix |
|T-6 |SR-1.1.2 |UC-2.1 |TC-2.1.1 |Oracle |
|T-7 | | |TC-2.1.2 |Oracle |
|Etc… | | | | |

-----------------------

Requirement Specifications

RTM Tracing

Req-2

Req-1

Design Item

Test Case

Design Item

Test Case