Requirements Document Template

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.