0% found this document useful (0 votes)
14 views13 pages

SRS Template

Uploaded by

Ibrahim Wael
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views13 pages

SRS Template

Uploaded by

Ibrahim Wael
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

My Program name

Software Requirements Specification


Document approval

Second Name Date Sign

Prepared

Verified

Quality control

Approved

Access list

Company Second name Position For approval/


Information

Change history

Version Date Author Description Section

FUN

Document information

Date of creation

File name

Location

Number of pages
Introduction

Goals
This document aims to provide a complete description of the system software requirements. It
fully describes the external behavior of the application or the subsystems described. It also
describes non-functional requirements, design constraints, and other factors necessary to
provide a complete and comprehensive description of software requirements.

An application or product is described whose functionality will be described in the SRS.


For example:
This document describes the functionality of a centralized program for monitoring remote
devices. The customer needs to provide general centralized control of all monitored areas, as
well as provide multi-level remote access for control and monitoring.

Links
The submitted document refers to the following documents.

Reductions

Document structure
The first section describes functional and non-functional requirements. The second section
comprehensively describes the use cases in terms of how the model is structured into groups
and what are the use cases for the participants in the model.
Section 1: Requirements

Overview

Introduction
This section describes the various requirements (functional and non-functional)

Content
This section contains the following topics

Topic See page

Requirements type

Functional requirement list

Non-Functional requirement list


Requirements type

Definitions
Requirement is defined as "a state or opportunity that a system must conform to."

Functional requirement define the actions that the system should be able to perform without
taking physical constraints into account. They are often best described in the use-case model
and use cases. The functional requirements thus determine the input and output behavior of the
system.

Requirements that are not functional are sometimes referred to as non-functional


requirements. Many requirements are not functional and only describe system attributes or
features of the system's environment.

FURPS+
There are many different kinds of requirements. One way to categorize them is described as
FURPS+ model, using an acronym to describe the main categories and subcategories of
requirements, as shown below.
● Functionality,
● Usability,
● Reliability,
● Performance,
● Supportability.

"+" also helps you remember to include requirements such as

● design constraints,
● requirements for interfaces,
● physical requirements.

Functionality (FUN)
Functional requirements may include:
 sets of functions,
 possibilities,
 security.

Usability (USA)
Usability requirements can include subcategories such as:
 human factor,
 aesthetics,
 consistency of the user interface,
 online and context-sensitive help,
 masters and agents,
 user documentation,
 educational materials.

Reliability (REL)
Reliability requirements to be considered:
 availability (percentage of available time, operating hours, maintenance
access, ...)
 frequency / degree of failure rate,
 recover-ability,
 predictability,
 accuracy,
 mean time between failures (MTBF).

Performance (PER)
Performance requirements impose conditions on functional requirements. For example,
for a specified action, they can specify performance parameters for:
 throughput (for example, transactions per second),
 response time,
 recovery time,
 use of resources (memory, disk, processor, ...).

Supportability (SUP)
Maintainability requirements may include:
 testability,
 extensibility,
 adaptability,
 maintainability,
 compatibility,
 configure-ability,
 ease of maintenance,
 install-ability,
 localization (internationalization).

Design requirements (DES)


Design requirements, often referred to as design constraints, indicate or constrain the
design of a system.
This section should indicate any design constraints in the system under construction.
Design constraints are design considerations that are introduced and must be followed.
Examples include programming languages, software development process
requirements, prescribed use of development tools, architectural and design constraints,
purchased components, class libraries, and more.

Interface requirements (INT)


This section defines the interfaces that the application must support. It should contain
adequate specifications, protocols, ports and logical addresses, etc., such that the
program can be designed and tested to meet the interface requirements.
Interface requirements can be divided into:
 User interface (user interfaces to be implemented with software)
 Hardware interface (hardware interfaces that must be supported by the software,
including logical structure, physical addresses and expected behavior, etc.)
 Programming interface (programmatic interfaces for other system components.
They can be purchased, components reused from another application,
components developed for a subsystem that is outside the scope of this project,
but with which this application must interact).

Hardware requirements (HAR)


Hardware requirements define the physical characteristics that a system must have; for
example:
 material,
 the form,
 the size,
 the weight.
This type of requirement can be used to represent hardware requirements such as the
required physical network configuration.

Applied standards (STD)


This section describes any applicable standards and specific clauses of such standards
that apply to the described system. For example legal, regulatory, industry standards,
quality standards, compatibility, localization, compliance with operating systems, etc.
Functional requirements list

Introduction
Functional requirements define the actions that the system must be able to perform
without taking physical constraints into account. They are often best described in the use-
case model and use cases. The functional requirements thus determine the input and
output behavior of the system.

List of functional requirements


Each defined functional requirement is assigned a unique key "FUN-nn", where nn is a
sequential number that identifies the functional requirement.
The table below lists all functional requirements:

Functional
requirement identifier Description

Supports up to 16 video input streams from H.264 / MJPEG HD IP


FUN-01
video cameras.

Output of video images and audio signals with the possibility of local
FUN-02
recording to the archive.

FUN-03

FUN-04

FUN-05

FUN-06

FUN-07

FUN-08

FUN-09

Non-functional requirements list

Introduction
Non-functional requirements describe only the attributes of the system or features of the
environment of the system.
Each specific non-functional requirement is assigned a unique key "XXX-nn", where XXX
is the abbreviation of the requirement type, nn is a sequence number that identifies the
non-functional requirement.

Usability requirements (USA)

The table below lists all of the usability requirements:

Usability
requirement Description
identifier

USA-01 Split screen into 1, 4, 8, 16 cameras.

USA-02 Grab - move the position of the camera windows.

USA-03

USA-04

USA-05

Reliability (REL)

The table below lists all the reliability requirements:

Reliability
requirement Description
identifier

REL-01

REL-02

REL-03

Performance (PER)

The table below lists all the performance requirements:


Performance
requirement Description
identifier

PER-01

Supportability (SUP)

The table below lists all of the supportability requirements:

Supportability
requirement Description
identifier

SUP-01

SUP-02

SUP-03

SUP-04

SUP-05

SUP-06

SUP-07

Design requirements (DES)

The table below lists all design requirements:

Design requirement
identifier Description

DES-01
DES-02

DES-03

DES-04

Interface requirements (INT)

The table below lists all the interface requirements:

Interface
requirements Description
identifier

INT-01

INT-02

INT-03

INT-04

INT-05

INT-06

INT-07

INT-08

Hardware requirements (HAR)

The table below lists all hardware requirements:

Hardware
requirements Description
identifier

HAR-01

HAR-02

HAR-03

HAR-04
Compatibility (COM)

The table below lists all compatibility requirements:

Compatibility
requirements Description
identifier

COM-01

COM-02

COM-03

COM-04

Security (SEC)

The table below lists all the security requirements:

Security
requirements Description
identifier

SEC-01 Differentiation of user access rights.

SEC-02

SEC-03

SEC-04

Applied standards (STD)

The table below lists all applicable standards:

Standards
requirement Description
identifier

STD-01

STD-02

STD-03

STD-04
Use cases

For example: The program can be used both by students in the learning process and by
professional security organizations to provide centralized control of remote devices.

You might also like