<PROJECT NAME>

REQUIREMENTS DEFINITION
Version Number: 1.0
Version Date: <mm/dd/yyyy>

[Insert appropriate disclaimer(s)]

 <Project Name>

Notes to the Author

[This document is a template of a Requirements Definition document for a project. The template includes
instructions to the author, boilerplate text, and fields that should be replaced with the values specific to
the project.
 Blue italicized text enclosed in square brackets ([text]) provides instructions to the document
author, or describes the intent, assumptions and context for content included in this document.
 Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced
with information specific to a particular project.
 Text and tables in black are provided as boilerplate examples of wording and formats that may be
used or modified as appropriate to a specific project. These are offered only as suggestions to
assist in developing project documents; they are not mandatory formats.

When using this template, the following steps are recommended:

1. Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field
document values. These angle brackets appear in both the body of the document and in headers
and footers. To customize fields in Microsoft Word (which display a gray background when
selected) select File->Properties->Summary and fill in the appropriate fields within the Summary
and Custom tabs.
After clicking OK to close the dialog box, update all fields throughout the document selecting
Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking
on it and pressing F9.
These actions must be done separately for any fields contained with the document’s Header and
Footer.
2. Modify boilerplate text as appropriate for the specific project.
3. To add any new sections to the document, ensure that the appropriate header and body text
styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and
Heading 3. Style used for boilerplate text is Body Text.
4. To update the Table of Contents, right-click on it and select “Update field” and choose the option
- “Update entire table”.
5. Before submission of the first draft of this document, delete this instruction section “Notes to the
Author” and all instructions to the author throughout the entire document.

Requirements Definition (v1.0) Page 2 of 9

[Insert appropriate disclaimer(s)]
 <Project Name>

VERSION HISTORY
[Provide information on how the development and distribution of the Requirements
Definition will be controlled and tracked. Use the table below to provide the version
number, the author implementing the version, the date of the version, the name of the
person approving the version, the date that particular version was approved, and a brief
description of the reason for creating the revised version.]
Version Implemented Revision Approved Approval Description of
Number By Date By Date Change
1.0 <Author name> <mm/dd/yy> <name> <mm/dd/yy> <description of change>

Requirements Definition (v1.0) Page 3 of 9

[Insert appropriate disclaimer(s)]
 <Project Name>

TABLE OF CONTENTS
1 INTRODUCTION...........................................................................................................3
1.1 Purpose of the Requirements Definition Document......................................3
2 BUSINESS REQUIREMENTS OVERVIEW.................................................................3
2.1 Assumptions / Constraints.............................................................................3
2.2 System Scope................................................................................................3
3 FUNCTIONAL REQUIREMENTS.................................................................................3
3.1 <Functional Requirements Group 1>.............................................................3
3.2 <Functional Requirements Group 2>.............................................................3
4 NON-FUNCTIONAL REQUIREMENTS........................................................................3
4.1 Design Constraints.........................................................................................3
4.2 Hardware Requirements................................................................................3
4.3 Software Requirements..................................................................................3
4.4 Performance Requirements...........................................................................3
4.5 Reliability Requirements................................................................................3
4.6 Supportability Requirements..........................................................................3
4.7 User Documentation Requirements...............................................................3
4.8 Interface Requirements..................................................................................3
4.9 Security and Privacy Requirements...............................................................3
4.10 Compliance and Standards Requirements....................................................3
5 BUSINESS PROCESS MODEL...................................................................................3
6 LOGICAL DATA MODEL.............................................................................................3
7 REQUIREMENTS TRACEABILITY MATRIX...............................................................3
APPENDIX A: REQUIREMENTS DEFINITION APPROVAL...........................................3
APPENDIX B: REFERENCES..........................................................................................3
APPENDIX C: BUSINESS PROCESS MODEL...............................................................3
APPENDIX D: LOGICAL DATA MODEL.........................................................................3
APPENDIX E: REQUIREMENTS TRACEABILITY MATRIX...........................................3

Requirements Definition (v1.0) Page 4 of 9

[Insert appropriate disclaimer(s)]
 <Project Name>

1 INTRODUCTION
1.1 PURPOSE OF THE REQUIREMENTS DEFINITION DOCUMENT
[Provide the purpose of the Functional Requirements Definition Document. This
document should be tailored to fit a particular project’s needs.]
The Requirements Definition defines the functional, non-functional, and technical
requirements. The Requirements Definition document is created during the
Requirements Analysis Phase of the project. Its intended audience is the project
manager, project team, project sponsor, client/user, and any stakeholder whose
input/approval into the requirements definitions process is needed.

2 BUSINESS REQUIREMENTS OVERVIEW

[Describe here the business requirements that the project work will fulfill and how
and/or where the completed project product will fit into any existing systems.
Business requirements can often be described as ‘features.’ Assign a unique ID
number to each requirement.]
2.1 ASSUMPTIONS / CONSTRAINTS
[Describe any overall assumptions / constraints related to project requirements]
2.2 SYSTEM SCOPE
[Describe the features, users, and interfaced systems. Include a context diagram if
appropriate. Assign a unique ID number to each requirement.]

3 FUNCTIONAL REQUIREMENTS
[Functional requirements capture and specify intended behavior of the system
being developed. They define things such as system calculations, data
manipulation and processing, user interface and interaction with the application,
and other specific functionality that show how user requirements are satisfied.
Assign a unique ID number to each requirement.
The functional requirements are grouped according to the project’s needs, and
maybe influenced by the requirements tools and techniques used. ]
3.1 <FUNCTIONAL REQUIREMENTS GROUP 1>
3.1.1 <Functional Requirements 1>
3.2 <FUNCTIONAL REQUIREMENTS GROUP 2>

4 NON-FUNCTIONAL REQUIREMENTS
[Describe the existing non-functional (also referred to as Quality of Service by the
International Institute of Business Analysts, Business Analysis Body of
Knowledge), technical environment, systems, functions, and processes. Include
an overview of the non-functional requirements necessary to achieve the project’s
objectives.]

Requirements Definition (v1.0) Page 5 of 9

[Insert appropriate disclaimer(s)]
 <Project Name>
4.1 DESIGN CONSTRAINTS
[Describe hardware/software requirements that will limit the design or COTS
options. These may include laws, regulations, hardware limitations, interfaces,
development environment, operational environment, criticality, safety, and/or
security. Assign a unique ID number to each requirement.]
4.2 HARDWARE REQUIREMENTS
[Describe hardware requirements and any related processes. Include a detailed
description of specific hardware requirements and associate them to specific
project functionality/deliverables. Include information such as type of hardware,
brand name, specifications, size, security, etc. Assign a unique ID number to each
requirement.]
4.3 SOFTWARE REQUIREMENTS
[Describe software requirements and any related processes. Include a detailed
description of specific software requirements and associate them to specific
project functionality/deliverables. Include information such as in-house
development or purchasing, security, coding language, version numbering,
functionality, data, interface requirements, brand name, specifications, etc. Assign
a unique ID number to each requirement.]
4.4 PERFORMANCE REQUIREMENTS
[Describe performance requirements and any related processes. Include a
detailed description of specific performance requirements and associate them to
specific project functionality/deliverables. Include information such as system
capacity, cycle time, speed per transaction, test requirements, minimum bug
counts, speed, reliability, utilization etc. Assign a unique ID number to each
requirement.]
4.5 RELIABILITY REQUIREMENTS
[Describe all of the technical requirements that affect availability such as hours of
operation, level of availability required, down-time impact, support availability,
accuracy, etc. Assign a unique ID number to each requirement.]
4.6 SUPPORTABILITY REQUIREMENTS
[Describe all of the technical requirements that affect supportability and
maintainability such as coding standards, naming CONVENTIONS; maintenance
access, required utilities, etc. Assign a unique ID number to each requirement.]
4.7 USER DOCUMENTATION REQUIREMENTS
[Describe the requirements, for any special or on-line user documentation or help
systems, etc. Assign a unique ID number to each requirement.]
4.8 INTERFACE REQUIREMENTS
[Describe all of the user interface (such as user navigation, presentation of
application and associated functionality, screen location of interface elements,
data display and manipulation, etc), system interface, and technical (hardware and

Requirements Definition (v1.0) Page 6 of 9

[Insert appropriate disclaimer(s)]
 <Project Name>
software) requirements that affect interfaces such as look-and-feel, protocol
management, scheduling, directory services, broadcasts, message types, error
and buffer management, security, etc. Assign a unique ID number to each
requirement.]
4.9 SECURITY AND PRIVACY REQUIREMENTS
[Summarize and make reference to Privacy Impact Assessment produced during
Planning phase and its impact on security requirements. Provide justifications for
why a specific privacy item is needed. Provide Security Categorization if available.
Describe all of the technical requirements that affect security such as security
audits, cryptography, user data, system identification/authentication, resource
utilization, facility access times, etc. Assign a unique ID number to each
requirement. ]
4.10 COMPLIANCE AND STANDARDS REQUIREMENTS
[Describe the existing compliance environment as it affects project requirements,
and the standards the system development must follow. Include an overview of
the compliance or standards requirements necessary to achieve the project’s
objectives. List all that are applicable to the project. Assign a unique ID number to
each requirement.]

5 BUSINESS PROCESS MODEL

[Include the Business Process Model as an appendix.]
See Appendix D - <Project Name> Business Process Model.

6 LOGICAL DATA MODEL

[Include the Logical Data Model as an appendix.]
See Appendix E - <Project Name> Logical Data Model.

7 REQUIREMENTS TRACEABILITY MATRIX

[Include the Traceability Matrix as an appendix. In the Requirements Analysis
phase, the matrix is populated with requirements identified in the Requirements
Definition. It is a living document that should be populated with information
throughout design, construction, and test phases, etc.]
See Appendix F - <Project Name> Requirements Traceability Matrix.

Requirements Definition (v1.0) Page 7 of 9

[Insert appropriate disclaimer(s)]
 <Project Name>

Appendix A: Requirements Definition Approval

The undersigned acknowledge that they have reviewed the <Project Name>
Requirements Definition and agree with the information presented within this
document. Changes to this Requirements Definition will be coordinated with, and
approved by, the undersigned, or their designated representatives.
[List the individuals whose signatures are desired. Examples of such individuals
are Business Owner, Project Manager (if identified), and any appropriate
stakeholders. Add additional lines for signature as necessary.]

Signature: Date:
Print Name:
Title:
Role:

Signature: Date:
Print Name:
Title:
Role:

Signature: Date:
Print Name:
Title:
Role:

Requirements Definition (v1.0) Page 8 of 9

[Insert appropriate disclaimer(s)]
 <Project Name>

APPENDIX B: REFERENCES
[Insert the name, version number, description, and physical location of any
documents referenced in this document. Add rows to the table as necessary.]
The following table summarizes the documents referenced in this document.
Document Name Description Location
<Document Name and <Document description> <URL or Network path where document
Version Number> is located>

APPENDIX C: Business Process Model

The Business Process Model is attached as a separate document.

APPENDIX D: Logical Data Model

The Logical Data Model is attached as a separate document.

APPENDIX E: Requirements Traceability Matrix

The Requirements Traceability Matrix is attached as a separate document.

Requirements Definition (v1.0) Page 9 of 9

[Insert appropriate disclaimer(s)]