Software Requirements Specification (SRS) for <app name, modified>

Baseline version 1.0

Issued on : <submission date>

Issued by : <your group’s made-up company name>

Issued for : <modified name of your app’s provider>

Software Requirement Specification for <Project> Page 1

Change History
Version Date Author Changes
0.1 August 27, 2012 ABlablaName initial version
Constantly update this
changelog whenever
there are major
changes

Software Requirement Specification for <Project> Page 2

Table of Contents
CHAPTER 1 INTRODUCTION ................................................................................................. 5
1.1 Purpose ............................................................................................................................. 5
1.2 Scope ................................................................................................................................ 5
1.3 Definitions, Acronyms, and Abbreviations ...................................................................... 5
1.4 Overview .......................................................................................................................... 6
CHAPTER 2 GENERAL DESCRIPTION ................................................................................ 7
2.1 Product Perspective .......................................................................................................... 7
2.2 Product Functions ............................................................................................................. 7
2.3 User Characteristics.......................................................................................................... 7
2.4 General Constraints .......................................................................................................... 7
2.5 Assumptions and Dependencies ....................................................................................... 7
CHAPTER 3 INTERNAL STRUCTURE .....................................Error! Bookmark not defined.
3.1 Enumerated Functional Requirements ............................Error! Bookmark not defined.
3.2 Enumerated Non-Functional Requirements ....................Error! Bookmark not defined.
3.3 On-Screen Enumerated Requirements ............................Error! Bookmark not defined.
3.4 Classes/Objects................................................................Error! Bookmark not defined.
CHAPTER 4 FUNCTIONAL REQUIREMENTS SPECIFICATION ................................... 9
4.1 Stakeholders ................................................................................................................... 11
4.2 Actors and Goals ............................................................................................................ 11
4.3 Use Case ......................................................................................................................... 11
4.4 Traceability Matrix ......................................................................................................... 11
4.5 Activity Diagram ............................................................................................................ 11
4.6 Sequence Diagram.......................................................................................................... 11
4.7 Use Case Test Plans ....................................................................................................... 11
CHAPTER 5 PROJECT MANAGEMENT PLAN ................................................................. 11
5.1 Use Case Weight ............................................................................................................ 12
5.1.1 Unadjusted Use Case Weight.................................................................................. 12
5.1.2 Unadjusted Actor Weight ....................................................................................... 12
5.1.3 Technical Complexity Factor .................................................................................. 12

Software Requirement Specification for <Project> Page 3

 5.1.4 Environmental Complexity Factor .......................................................................... 12
5.1.5 Use Case Point Calculation ..................................................................................... 12
5.2 COCOMO ...................................................................................................................... 12
5.2.1 Unadjusted Function Points .................................................................................... 12
5.2.2 COCOMO ............................................................................................................... 12
5.3 Activity Table ................................................................................................................. 12
5.4 Gantt Chart ..................................................................................................................... 12
5.5 Critical PathAppendices ................................................................................................. 12

Software Requirement Specification for <Project> Page 4

 CHAPTER 1
INTRODUCTION

1.1 Purpose
The purpose of this document is to present a detailed description of the Audio Streaming
System. It will explain the purpose and features of the system, the interfaces of the system,
what the system will do, the constraints under which it must operate and how the system will
react to external stimuli. This document is intended for both the stakeholders and the
developers of the system and will be proposed to the Regional Historical Society for its
approval.

1.2 Scope
This part should:

(1) Identify the software product by name; for example ProjectBlabla

(2) Explain what the software product will (and will not do) upon completion

(3) Describe the application of the software being specified. As a portion of this, it should :

(a) Describe all relevant benefits, objectives, and goals as precisely as possible. For
example, to say that one goal is to provide effective reporting capabilities is not as
good as saying parameter-driven, user-definable reports with an on-line entry of user
parameters.

(b) Be consistent with similar statements in higher-level specifications (if they exist).
What is the scope of this software product? Does it include the hardware parts?

This software system will be a Web Publishing System for a local editor of a regional
historical society. This system is designed to allow an editor to manage and communicate
with a group of reviewers and authors to publish articles to a public website. The software
will facilitate communication between authors, reviewers, and the editor via E-Mail.
Preformatted reply forms are used in every stage of the articles’ progress through the system
to provide a uniform review process; the location of these forms is configurable via the
application’s maintenance options. The system also contains a relational database containing
a list of Authors, Reviewers, and Articles.

1.3 Definitions, Acronyms, and Abbreviations

You can use this section to list all phrases, terms, and acronyms that are required to properly
understand this SRS. This information may refer to other documents that belong to your
documentation.

Term/Acronym Definition Description

Software Requirement Specification for <Project> Page 5

 SRS Software Requirement Specification This document

1.4 Overview
This part is used to describe how your SRS will be organized. You can also list what other
chapters will explain.

This document will provide a general overview of the system being made. It covers none
other than the system’s functions and constraints, non-functional requirements, functional
requirement, use cases, test plans, and project plan.

Software Requirement Specification for <Project> Page 6

 CHAPTER 2
GENERAL DESCRIPTION

This section should describe the general factors that affect the product and its requirements.
It should be made clear that this section does not state specific requirements; it only makes
those requirements easier to understand.

2.1 Product Perspective

This subsection of the SRS puts the product into perspective with other related products or
projects. Basically, compare your product with similar ones.

2.2 Product Functions

This subsection of the SRS should provide a summary of the functions that the software will
perform. Create a list.

2.3 User Characteristics

This subsection of the SRS should describe those general characteristics of the eventual users
of the product (use-case actors) that will affect the specific requirements.

The Reader is expected to be Internet literate and be able to use a search engine. The main
screen of the Online Journal Website will have the search function and a link to
“Author/Reviewer Information.”

The Author and Reviewer are expected to be Internet literate and to be able to use email with
attachments.

The Editor is expected to be Windows literate and to be able to use button, pull-down menus,
and similar tools.

2.4 General Constraints

This subsection of the SRS should describe any items or issues that will limit the options
available to the developers. These might include: corporate or regulatory policies; hardware
limitations (timing requirements, memory requirements); interfaces to other applications;
specific technologies, tools, and databases to be used; parallel operations; language
requirements; communications protocols; security considerations; design conventions or
programming standards (for example, if the customer’s organization will be responsible for
maintaining the delivered software).

2.5 Assumptions and Dependencies

This subsection of the SRS should list each of the factors that affect the requirements stated
in the SRS. These factors are not design constraints on the software but are, rather, any
changes to them that can affect the requirements in the SRS. For example, an assumption

Software Requirement Specification for <Project> Page 7

 might be that a specific operating system will be available on the hardware designated for
the software product. If, in fact, the operating system is not available, the SRS would then
have to change accordingly.

Software Requirement Specification for <Project> Page 8

 CHAPTER 3
SPECIFIC REQUIREMENT

This will be the largest and most important section of the SRS. The customer requirements will
be embodied within Chapter 2, but this section will give the requirements that are used to guide
the project’s software design, implementation, and testing.

Each requirement in this section should be:

- Correct

- Traceable (both forward and backward to prior/future artifacts)

- Unambiguous

- Verifiable (testable)

- Prioritized (with respect to importance and/or stability)

- Complete

- Consistent

- Uniquely identifiable (usually via numbering, like 3.4.5.6)

Attention should be paid to the carefully organize the requirements presented in this section so
that they may easily accessed and understood. Furthermore, this SRS is not the software design
document, therefore one should avoid the tendency to over-constrain (and therefore design) the
software project within this SRS.

3.1 Enumerated Functional Requirements

This subsection of the SRS is usually taken from system use-cases. One use-case can be
used to fulfill multiple requirements.

Identifier Description

System shall allow an unregistered User to provide personal information and

REQ-01
create an account.

3.2 Enumerated Non-Functional Requirements

This subsection of the SRS contains important requirements but not related to use-cases. The
numbering continues from previous section.

Software Requirement Specification for <Project> Page 9

3.3 On-Screen Enumerated Requirements
This subsection of the SRS contains what the user interface would look like. The
numbering continues from previous section.

3.4 Classes/Objects
This subsection of the SRS contains the class diagram.

Software Requirement Specification for <Project> Page 10

 CHAPTER 4
FUNCTIONAL REQUIREMENT SPECIFICATION
4.1 Stakeholders
4.2 Actors and Goals
This subsection of the SRS list all actors (usually the one described in use-cases) and their
goals. One actor can have multiple goals.

Actors Goals
User To register themselves into the system.

4.3 Use Case

This subsection of the SRS list all use-cases with casual description. Just use the name and
description in a numbered list.

4.4 Traceability Matrix

4.5 Activity Diagram
This subsection of the SRS contains the activity diagram for all use-case.

4.6 Sequence Diagram

This subsection of the SRS contains the sequence diagram for all use-case.

4.7 Use Case Test Plans

This subsection of the SRS contains the test plans for all use-case. One use-case can have
more than one test plan.

Test case ID TC-1

Test case name View classes
Preconditions List of classes has been made
Action Expected Results Test Data
System send GET request to
1. Select get classes menu retrieve list of classes and -
show the result on screen

Software Requirement Specification for <Project> Page 11

 CHAPTER 5
PROJECT MANAGEMENT PLAN

5.1 Use Case Weight

5.1.1 Unadjusted Use Case Weight
5.1.2 Unadjusted Actor Weight
5.1.3 Technical Complexity Factor
5.1.4 Environmental Complexity Factor
5.1.5 Use Case Point Calculation
5.2 COCOMO
5.2.1 Unadjusted Function Points
5.2.2 COCOMO
5.3 Activity Table
5.4 Gantt Chart
5.5 Critical Path

Software Requirement Specification for <Project> Page 12

 Appendices
Appendices may be used to provide additional (and hopefully helpful) information. If present, the
SRS should explicitly state whether the information contained within an appendix is to be
considered as a part of the SRS’s overall set of requirements.

A.1. Appendix 1

A.2. Appendix 2

Software Requirement Specification for <Project> Page 13