Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 10

REQUIREMENTS COLLECTION

TEMPLATE
A GUIDE FOR REQUIREMENTS GATHERING AND TRACE-ABILITY
MATRIX DEVELOPMENT

REVISION: 1.0

Department of Information Technology Requirements Collection Template

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

Department of Information Technology Requirements Collection Template

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.

Department of Information Technology Requirements Collection Template

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 =
o

B1a

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

o Note: Business requirement number should always be a whole number


value.)

User Requirement

U1.1a

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


User req. number, a=first revision)
o Note: User requirement number should always follow a business
requirement number, and always be in the second position.)

System Requirement

S1.1.1a

o (S=System, 1=bus. req. num., .1=User req. number (detailed by this


system requirement), 1 =System req. number, a=first revision)
o 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

Department of Information Technology Requirements Collection Template


- 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.).
o

Note: It is not necessary to capture all requirement relationships in this


section. It is only required to capture critical dependencies.

Department of Information Technology Requirements Collection Template

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?

Department of Information Technology Requirements Collection Template

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

<Unique id #>

Status

Ne
w

Parent
Requirement #

<Enter the unique id #(s) for each requirement that this requirement supports

Description

<Enter concise description of requirement>

Rationale

<Provide a brief rationale, and or business value for the requirement.>

Source

<Name of Requirement.
Provider>

Acceptance/Fit
Criteria

<Provide a target that makes it possible to test if requirement was satisfied>

Dependencies

<List other requirement. Id#s that this requirement is dependent on>

Priority

Essential

Change History

<List history of changes to this requirement>

<x>

Requirement
Type
Agreedto

<x>

<See List Below>


Baseline
d

<x>

Use Case #
Rejected

<Unique id #>

<x>

(This field will be empty for high level requirements e.g., business requirements)>

<x>

Conditional

Source Document

<x>

Optional

<filename>

<x>

Department of Information Technology Requirements Collection Template

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.

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

Department of Information Technology Requirements Collection Template

The Requirement Traceability Matrix (RTM)

RTM Tracing

Req-1

Design Item

Test Case

Req-2

Requirement
Specifications

Design Item

Test Case

Requirement Hierarchy Example


9

Department of Information Technology Requirements Collection Template


Hierarchy ID

Business
Requirement ID

H-1
H-2

BR-1

H-3
H-4

User
Requirement
ID
UR-1.1

Trace Document Example


Traceability ID
T-1
T-2
T-3
T-4
T-5
T-6
T-7
Etc

10

Source

SR-1.1.1
SR-1.1.2

UR-1.3
UR-2.1

SR-1.3.1
SR-2.1.1

Project Brief
Process Model
A
Data Model X
Business
Owner
Process Model
B
Policy Manual
Goal Model

Use Case ID

Test Cast ID

Solution

UC-1.1

TC-1.1.1
TC-1.1.2
TC-1.2.1
TC-1.2.2
TC-1.2.3
TC-2.1.1
TC-2.1.2

Oblix
Oblix
Oblix
Oblix
Oblix
Oracle
Oracle

UR-1.2

H-5
H-6
H-7
etc

System
Requirement ID

SR-1.1.3
SR-1.2.1
SR-1.2.2

BR-2

System
Requirement ID
SR-1.1.1

UC-1.2

SR-1.1.2

UC-2.1

You might also like