<Logo>

<Name of the project>

Software Requirement Specification

Project Code: <Code of the project>

Document Code: <Code of the document >– v<x.x>

Class Code: <Code of the class>

Group Code: <Code of the group>

<Location, issued date of the Document>

<Project code> - Software Requirement Specification v.xx

RECORD OF CHANGE

*A - Added M - Modified D - Deleted

Effective Changed Items A* Change Description New Version

Date M, D
02/12/2023 Initial a Add project overview

<Project name> 2/12

<Project code> - Software Requirement Specification v.xx

SIGNATURE PAGE

ORIGINATOR: <Name> <Date>

<Position>

REVIEWERS: <Name> <Date>

<Position>

<Name, if it’s needed> <Date>

<Position>

APPROVAL: <Name> <Date>

<Position>

<Project name> 3/12

<Project code> - Software Requirement Specification v.xx

TABLE OF CONTENTS

1 INTRODUCTION ..........................................................................................5

1.1 Purpose ................................................................................................................5

1.2 Scope ...................................................................................................................5
1.3 Definitions, Acronyms, and Abbreviations ...............................................................5
1.4 References ...........................................................................................................5
1.5 Overview ..............................................................................................................6

2 OVERALL DESCRIPTION ..............................................................................7

2.1 Product Perspective ...............................................................................................7

2.2 User classes and characteristics .............................................................................7
2.3 Design and implementation constraints ..................................................................7

3 FUNCTIONAL REQUIREMENTS ....................................................................8

3.1 Swimlane Diagrams ...............................................................................................8

3.2 Use Case Diagrams ...............................................................................................8
3.3.1. < Use Case Name 1> ............................................................................................8
3.3.2. < Use Case Name 2> ............................................................................................9
3.3 State Diagrams .....................................................................................................9
3.4 Logical Data Model ................................................................................................9
3.5 Wire Flows............................................................................................................9

4 NON-FUNCTIONAL REQUIREMENTS .........................................................10

4.1 Usability ............................................................................................................. 10

4.2 Reliability............................................................................................................ 10
4.3 Performance ....................................................................................................... 11
4.4 Supportability ..................................................................................................... 11
4.5 Licensing Requirements ....................................................................................... 11

5 SUPPORTING INFORMATION ....................................................................12

<Project name> 4/12

<Project code> - Software Requirement Specification v.xx

1 INTRODUCTION

[The introduction of the Software Requirements Specification (SRS) provides an overview of the
entire SRS. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and
overview of the SRS.]
[Note: The SRS document captures the complete software requirements for the system, or a
portion of the system. Following is a typical SRS outline for a project using only traditional,
natural-language style requirements—with no use-case modeling. It captures all requirements
in a single document, with applicable sections inserted from the Supplementary Specifications
(which would no longer be needed). For a template of an SRS using use-case modeling, which
consists of a package containing Use Cases of the use-case model and applicable Supplementary
Specifications and other supporting information, see rup_srsuc.dot.]
[Many different arrangements of an SRS are possible. Refer to [IEEE830-1998] for further
elaboration of these explanations, as well as other options for SRS organization.]

1.1 Purpose

[Specify the purpose of this SRS. The SRS fully describes the external behavior of the application
or subsystem identified. It also describes nonfunctional requirements, design constraints, and
other factors necessary to provide a complete and comprehensive description of the
requirements for the software.]

1.2 Scope

[A brief description of the software application that the SRS applies to, the feature or other
subsystem grouping, what Context it is associated with, and anything else that is affected or
influenced by this document.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to
properly interpret the SRS. This information may be provided by reference to the project’s
Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the SRS.
Identify each document by title, report number if applicable, date, and publishing organization.
Specify the sources from which the references can be obtained. This information may be
provided by reference to an appendix or to another document.]

<Project name> 5/12

<Project code> - Software Requirement Specification v.xx

1.5 Overview

[This subsection describes what the rest of the SRS contains and explains how the document is
organized.]

<Project name> 6/12

<Project code> - Software Requirement Specification v.xx

2 OVERALL DESCRIPTION

[This section of the SRS describes the general factors that affect the product and its
requirements. This section does not state specific requirements. Instead, it provides a
background for those requirements, which are defined in detail in Section 3, and makes them
easier to understand. Include such items as:

2.1 Product Perspective

[Describe the product’s context and origin. Is it the next member of a growing product line, the
next version of a mature system, a replacement for an existing application, or an entirely new
product? Provide a context diagram of the system, with explanations as applicable. The context
of a system refers to the connections and relationships between the system and its
environment.]

2.2 User classes and characteristics

[Identify the various user classes that you anticipate will use this product and describe their
pertinent characteristics.]

2.3 Design and implementation constraints

[Describe any factors that will restrict the options available to the developers and the rationale
for each constraint. Constraints are described further in Chapter 14, “Beyond functionality.”]

<Project name> 7/12

<Project code> - Software Requirement Specification v.xx

3 FUNCTIONAL REQUIREMENTS

3.1 Swimlane Diagrams

[The main Business Process flow of the system]

3.2 Use Case Diagrams

[The main Use Case Diagrams of the system]

3.2.1. < Use Case Name 1>

Manager createCatalog
(from Use Case View)
(from Use Case View)

USE CASE-n SPECIFICATION

Use-case No. <UC001> Use-case <1.0>

Version

Use-case Name <Name>

Author <Members>

Date Dd/mm/yyyy Priority <High/Normal/Low>

Actor:
<Lit all actors>
Summary:
<Briefly describe the used case >
Goal:
<Briefly describe the goal of used case >
Triggers
<What does lead in using this case?>
Preconditions:

<Project name> 8/12

<Project code> - Software Requirement Specification v.xx

<List the required pre-conditions for using this case>

Post Conditions:
<List the required post-conditions for using this case>
Main Success Scenario:
<List the main steps for using this case to reach the goal successfully >
Alternative Scenario:
<List other steps for using this case to reach the goal in some alternative conditions >
Exceptions:
<List exceptions of this use case >
Relationships:
<List the relationships that use case relates to>
Business Rules:
<Any concern about the business>

3.2.2. < Use Case Name 2>

…………………

3.3 State Diagrams

[The State Diagrams of the system]

3.4 Logical Data Model

[Provide the Logical Data Model with entities and relationship descriptions]

3.5 Wire Flows

[This part shows the system screens and the relationship among screens. You can draw the Wire
Flows for the system in the form of diagram as below. Please note that beside the normal flat
screen, we might have the oval notation for pop-up screen (Import Order) or a screen with
multiple information tab (Order Details), etc. You may also use text or background format for
different visuality purpose]

<Project name> 9/12

<Project code> - Software Requirement Specification v.xx

4 NON-FUNCTIONAL REQUIREMENTS

[This section describes the non-functional requirements of the system. Some examples are listed
as below]

4.1 Usability

[This section includes all those requirements that affect usability. For example,
specify the required training time for a normal users and a power user to become productive at
particular operations
specify measurable task times for typical tasks or base the new system’s usability requirements
on other systems that the users know and like
specify requirement to conform to common usability standards, such as IBM’s CUA standards
Microsoft’s GUI standards]

<Usability Requirement One>

[The requirement description goes here.]

4.2 Reliability

[Requirements for reliability of the system should be specified here. Some suggestions follow:
Availability—specify the percentage of time available ( xx.xx%), hours of use, maintenance
access, degraded mode operations, and so on.
Mean Time Between Failures (MTBF) — this is usually specified in hours, but it could also be
specified in terms of days, months or years.
Mean Time To Repair (MTTR)—how long is the system allowed to be out of operation after it
has failed?
Accuracy—specifies precision (resolution) and accuracy (by some known standard) that is
required in the system’s output.
Maximum Bugs or Defect Rate—usually expressed in terms of bugs per thousand lines of code
(bugs/KLOC) or bugs per function-point( bugs/function-point).
Bugs or Defect Rate—categorized in terms of minor, significant, and critical bugs: the
requirement(s) must define what is meant by a “critical” bug; for example, complete loss of data
or a complete inability to use certain parts of the system’s functionality.]

<Reliability Requirement One>

[The requirement description.]

<Project name> 10/12

<Project code> - Software Requirement Specification v.xx

4.3 Performance

[The system’s performance characteristics are outlined in this section. Include specific response
times. Where applicable, reference related Use Cases by name.
Response time for a transaction (average, maximum)
Throughput, for example, transactions per second
Capacity, for example, the number of customers or transactions the system can accommodate
Degradation modes (what is the acceptable mode of operation when the system has been
degraded in some manner)
Resource utilization, such as memory, disk, communications, and so forth.

<Performance Requirement One>

[The requirement description goes here.]

Interfaces

4.4 Supportability

[This section indicates any requirements that will enhance the supportability or maintainability
of the system being built, including coding standards, naming conventions, class libraries,
maintenance access, and maintenance utilities.]

<Supportability Requirement One>

[The requirement description goes here.]

4.5 Licensing Requirements

[Defines any licensing enforcement requirements or other usage restriction requirements that
are to be exhibited by the software.]

<Project name> 11/12

<Project code> - Software Requirement Specification v.xx

5 SUPPORTING INFORMATION

[The supporting information makes the SRS easier to use. It includes:

Table of contents
Index
Appendices
These may include use-case storyboards or user-interface prototypes. When appendices are
included, the SRS should explicitly state whether or not the appendices are to be considered part
of the requirements.]

<Project name> 12/12