Requirements Document Template

Please see attachment.

Thank You

Software Requirements

Specification
Project Name

Prepared By:

1. SUMMARY 4 ………………………………………………………………………………………………………………………………

1.1. VISION 4 …………………………………………………………………………………………………………………………….
1.2. GOALS (BUSINESS REQUIREMENTS) 4 …………………………………………………………………………………….
1.3. ASSUMPTIONS 4 …………………………………………………………………………………………………………………..
1.4. DEPENDENCIES AND CONSTRAINTS 4 ……………………………………………………………………………………..
1.5. INTENDED AUDIENCE 4 …………………………………………………………………………………………………………

2. OVERALL DESCRIPTION 4 ……………………………………………………………………………………………………..

3. SOFTWARE REQUIREMENTS 4 ………………………………………………………………………………………………

3.1. REQUIREMENTS 4 …………………………………………………………………………………………………………………
3.1.1. 101 5 ………………………………………………………………………………………………………………………………
3.1.2. 102 5 ………………………………………………………………………………………………………………………………
3.1.3. 103 5 ………………………………………………………………………………………………………………………………

3.2. REQUIREMENT CONSTRAINTS 6 ……………………………………………………………………………………………..
3.2.1. Hardware Limitations 6 …………………………………………………………………………………………………….
3.2.2. Architecture Limitations 6 …………………………………………………………………………………………………
3.2.3. Tool Limitations 6 …………………………………………………………………………………………………………….
3.2.4. Security Limitations 6 ……………………………………………………………………………………………………….
3.2.5. Globalization/Localization Limitations 6 …………………………………………………………………………….
3.2.6. Time Limitations 6 ……………………………………………………………………………………………………………

3.3. SOFTWARE SYSTEM ATTRIBUTES 6 …………………………………………………………………………………………
3.3.1. Reliability 6 …………………………………………………………………………………………………………………….
3.3.2. Availability 7 …………………………………………………………………………………………………………………..
3.3.3. Security 7 ………………………………………………………………………………………………………………………..
3.3.4. Maintainability 7 ……………………………………………………………………………………………………………..
3.3.5. Portability 7 …………………………………………………………………………………………………………………….
3.3.6. Usability 7 ………………………………………………………………………………………………………………………

4. HIGH LEVEL TEST PLAN 7 ………………………………………………………………………………………………………

5. REQUIREMENTS REVIEW 7 ……………………………………………………………………………………………………

6. UI/SUBSYSTEM PROTOTYPE (OPTIONAL) 7 …………………………………………………………………………

7. REFERENCES 7 …………………………………………………………………………………………………………………………

8. DEFINITIONS AND ACRONYMS 8 ……………………………………………………………………………………………

9. APPENDICES 8………………………………………………………………………………………………………………………….

1. SUMMARY
1.1. VISION
Update vision statement from Initiation Phase – make sure you identify all users and stakeholders

1.2. GOALS (BUSINESS REQUIREMENTS)
Update goals statement from Initiation Phase

1.3. ASSUMPTIONS
Update assumptions from Initiation Phase

1.4. DEPENDENCIES AND CONSTRAINTS
Update dependencies and constraints from Initiation Phase

1.5. INTENDED AUDIENCE
Who is this document written for (project team, sponsoring organization, etc.)

2. OVERALL DESCRIPTION
Provide more detail regarding what exactly is being done in this project. Give an overview of the product,
its functions, user characteristics, etc. (Include any known limitations.)

Include major Use Cases and Scenarios here (The aim of a good scenario is to get the reader to say, “Aha, I
can see why it’s important to provide this feature for this customer.” If you’re having trouble specifying
your scenario, think about the goal that the user is trying to accomplish, which will help you put yourself
into his or her shoes.) Optionally include Use Case Diagrams.

3. SOFTWARE REQUIREMENTS
3.1. REQUIREMENTS
These requirements relate to project xxx (Committed vs. Targeted requirements plus no-commit items)

You may want to separate these into the following categories:

• Functional requirements – how a software product must map program inputs to program outputs
(e.g. The traffic light control module must switch a green lamp on a traffic light face to an amber
lamp on that face, never to a red lamp.)

• Data requirements – how data must be input to, output from, or stored by a product (e.g. The
system must accept product descriptions consisting of arbitrarily formatted ASCII text up to 1,024
characters in length.)

• Non-functional requirements – states that the software product must have certain properties (e.g.
The payroll system must process the payroll for all 32,000 XYZ Corp. employees in six hours or
less.)

• Interface requirements – These can be functional, data or non-functional but should be listed
separately for clarity

o User Interfaces –
o Hardware Interfaces –
o Software interfaces –

• Use of standards – list any requirements to use specific standards (e.g. for interfaces include
those requirements in the interface section)

Several categories of requirements are listed below in sections 4.2 and 4.3 to help trigger you thinking.

The following rules are from the IEEE Standards Style Manual:
• The word shall is used to indicate mandatory requirements strictly to be followed in order to

conform to the standard and from which no deviation is permitted (shall equals is required to). The

use of the word must is deprecated and shall not be used when stating mandatory requirements;
must is used only to describe unavoidable situations. The use of the word will is deprecated and
shall not be used when stating mandatory requirements; will is only used in statements of fact.

• The word should is used to indicate that among several possibilities one is recommended as
particularly suitable, without mentioning or excluding others; or that a certain course of action is
preferred but not necessarily required; or that (in the negative form) a certain course of action is
deprecated but not prohibited (should equals is recommended that).

• The word may is used to indicate a course of action permissible within the limits of the standard
(may equals is permitted to).

• The word can is used for statements of possibility and capability, whether material, physical, or
causal (can equals is able to).

All requirements shall map to a SOW high level requirement. After the Requirements Document has been
approved, any changes to the requirements shall be indicated in the Version field as appropriate.

3.1.1. 101
Details of requirement 101 (possible additional Use Case or Scenario)

3.1.2. 102
Details of requirement 102

3.1.3. 103
Details of requirement 103

Req. ID Version Description

SOW
High
Level
Req.

C T
N
C

101 (Changed)
1.2

Shall implement abc 100
X

102 (New) 1.0 Shall implement bcd. 100 X

103 (New) 1.1 Should implement cde 100 X

201 (Removed)
1.2

Should implement def 200
X

202 (New) 1.2 Shall implement efg 200 X

301 (Changed)
1.1

May implement xyz 300
X

401 (New) 1.1 Shall implement wxy 400 X

402 (New) 1.2 Shall implement ijk 400 X

3.2. REQUIREMENT CONSTRAINTS

3.2.1. HARDWARE LIMITATIONS

3.2.2. ARCHITECTURE LIMITATIONS

3.2.3. TOOL LIMITATIONS

3.2.4. SECURITY LIMITATIONS

3.2.5. GLOBALIZATION/LOCALIZATION LIMITATIONS

3.2.6. TIME LIMITATIONS

3.3. SOFTWARE SYSTEM ATTRIBUTES
Define any special requirements due to reliability/availability/etc.

3.3.1. RELIABILITY

Req. ID Description

Req. ID Description

Req. ID Description
Req. ID Description
Req. ID Description
Req. ID Description
Req. ID Description

3.3.2. AVAILABILITY

3.3.3. SECURITY

3.3.4. MAINTAINABILITY

3.3.5. PORTABILITY

3.3.6. USABILITY

4. HIGH LEVEL TEST PLAN
Define high level functional tests for this project

5. REQUIREMENTS REVIEW
Review and Sign-off

6. UI/SUBSYSTEM PROTOTYPE (OPTIONAL)
Goals to be accomplished with prototype
Results of prototype when done

7. REFERENCES
1. Note any special information used to help define the project requirements
2.

Req. ID Description
Req. ID Description
Req. ID Description
Req. ID Description
Req. ID Description

Approver Title

Approver Title

8. DEFINITIONS AND ACRONYMS
Define any special terms/acronyms used in the document

9. APPENDICES
Any special information needed to understand the requirements

Term Definition.

Status Key
DR : Draft
IR: In
Review
AP:
Approved
RW: Rework

Revision History Of This Document
When this document requires update, document the revision details below and notify affected parties.

Date Author/ 
Updater Status Item Changed Short Description of Change

Created initial document.

• Summary

Vision
Goals (Business Requirements)
Assumptions
Dependencies and Constraints
Intended Audience

• Overall Description

Software Requirements
Requirements
101
102
103
Requirement Constraints
Hardware Limitations
Architecture Limitations
Tool Limitations
Security Limitations
Globalization/Localization Limitations
Time Limitations
Software System Attributes
Reliability
Availability
Security
Maintainability
Portability
Usability

• High Level Test Plan
• Requirements Review
• UI/Subsystem Prototype (Optional)
• References
• Definitions and Acronyms
• Appendices