Note: This template is largely based on the template provided by the Unified Process for

Education (www.yoopeedoo.com) with minor modifications.

Team <Number>: <Team Name>

<Team Members’ Contact Information>

<Project Name>

Version <1.0>

[Note: The following template is provided for use with the Unified Process for EDUcation. Text enclosed
in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the
author and should be deleted before publishing the document. A paragraph entered following this style will
automatically be set to normal (style=Body Text).]

[To customize automatic fields in Microsoft Word (which display a gray background when selected), select
File>Properties and replace the Title, Subject and Company fields with the appropriate information for
this document. After closing the dialog, automatic fields may be updated throughout the document by
selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must
be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and
the field contents. See Word help for more information on working with fields.]
<Project Name> Version: <1.0>
Date: <dd/mmm/yy>
<document identifier>

Revision History
Date Version Description Author
<dd/mmm/yy> <x.x> <details> <name>

Confidential <Company Name>, 2008 Page 2

<Project Name> Version: <1.0>
Date: <dd/mmm/yy>
<document identifier>

Table of Contents
1. Document Overview 4
1.1 Purpose 4
1.2 Document Conventions 4
1.3 Team Contact information 4
1.4 References 4

2. Project Mission Statement 4

2.1 Project Introduction 4
2.2 Product Vision and Scope 4
2.3 Stakeholders 4
2.4 Assumptions and Constraints 4
2.5 Business Requirements 4

3. Requirements 5
3.1 Functionality 5
3.1.1 <Functional Requirement One> 5
3.2 Non-functional Requirements 5
3.3 Performance Requirements 5
3.4 Security Requirements 5
3.5 Software Quality Attributes 5
3.6 Supplementary Requirements 5

4. Classification of Functional Requirements 6

5. Appendixes 6

Appendix A: Project Glossary 6

Confidential <Company Name>, 2008 Page 3

<Project Name> Version: <1.0>
Date: <dd/mmm/yy>
<document identifier>

1.Document Overview
1.1Purpose

[The introduction of the Software Requirements Specification (SRS) provides an overview of the entire
SRS. It should describe the purpose of the document, what the document contains, and the organization of
your document. ]

1.2Document Conventions

[Describe standards or formatting conventions that have particular meaning. For example, bold and
italicized words are technical terms whose definition can be found in an included glossary.]

1.3Team Contact information

1.4References

[If you used any resources to define technical terms in a glossary or to do any other research related to
your project, list them here with a brief description of their use (and a proper citation!)]

2.Project Mission Statement

2.1Project Introduction

[Give background information about the target product and the motivation for its development. See the text
for details on the content of a Project Mission Statement Introduction.]

2.2Product Vision and Scope

[Description of the product’s purpose and form, and the limitations (scope) of the project.]

2.3Stakeholders

[Description of the people that are affected by the project or product.]

2.4Assumptions and Constraints

[State the assumptions and constraints for this project.

For constraints, list and discuss issues that will limit the options available to the developers. For example,
you may be required to use certain hardware, programming languages, database software, or software
modeling tools

2.5Business Requirements

[Client or organization goals should be stated here.]

Confidential <Company Name>, 2008 Page 4

<Project Name> Version: <1.0>
Date: <dd/mmm/yy>
<document identifier>

3.Requirements
[This section of the SRS contains all software requirements to a level of detail sufficient to enable
designers to design a system to satisfy those requirements, and testers to test that the system satisfies those
requirements.]

3.1Functionality

[This section describes the functional requirements of the system for those requirements that are expressed
in the natural language style. For many applications, this may constitute the bulk of the SRS package and
thought should be given to the organization of this section. This section is typically organized by feature,
but alternative organization methods may also be appropriate; for example, organization by user.

The set of requirements should be complete, and each requirement should meet the characteristics outlined
in the Requirements Inspection Checklist on pg. 141 in the text]

3.1.1<Functional Requirement One>

[A requirement statement.]

3.2Non-functional Requirements

3.3Performance Requirements

[State performance requirements here (if any). For each requirement, you should identify if it is a
requirement over the entire system or a particular product feature. If there are no performance
requirements, just write “None” in this section.]

3.4Security Requirements

[State security requirements here (if any). Indentify authentication and privacy requirements. These may be
relevant to the product because it enhances a desired product feature or legal reasons. If there are no
security requirements, just write “None” in this section.]

3.5Software Quality Attributes

[State software quality attribute requirements here. This includes characteristics such as maintainability,
availability, etc.]

3.6Supplementary Requirements

[Supplementary Specifications capture requirements that are not included in the functional and non-
functional requirements. If there are no supplementary requirements, you can either remove this section or
write “None” in this section.]

Confidential <Company Name>, 2008 Page 5

<Project Name> Version: <1.0>
Date: <dd/mmm/yy>
<document identifier>

4.Classification of Functional Requirements

[List, usually in a table, all functional requirements and order them by priority (Essential, Desirable, and
Optional) or by order of appearance in the document.]

Functional Requirement Priority

...

...

5.Appendixes
[When appendices are included, the SRS should explicitly state whether or not the appendices are to be
considered part of the requirements]

Appendix A: Project Glossary

Confidential <Company Name>, 2008 Page 6