SRS

SRS
• The production of the requirements stage of the software development process is
Software Requirements Specifications (SRS) (also called a requirements document).
• SRS is a formal report, which acts as a representation of software that enables the
customers to review whether it (SRS) is according to their requirements.
• Also, it comprises user requirements for a system as well as detailed specifications of
the system requirements.
• The SRS is a specification for a specific software product, program, or set of
applications that perform particular functions in a specific environment.
• It serves several goals depending on who is writing it.
• First, the SRS could be written by the client of a system.
• Second, the SRS could be written by a developer of the system.
• The two methods create entirely various situations and establish different
purposes for the document altogether.
• The first case, SRS, is used to define the needs and expectation of the users. The
second case, SRS, is written for various purposes and serves as a contract
document between customer and developer.
Uses of SRS document
• Development team require it for developing product according to the need.

• Test plans are generated by testing group based on the describe external behavior.

• Maintenance and support staff need it to understand what the software product is

supposed to do.

• Project manager base their plans and estimates of schedule, effort and resources on it.

• customer rely on it to know that product they can expect.

• As a contract between developer and customer.

• in documentation purpose.
Properties of a good SRS document
• Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and
complete.
• Structured: It should be well-structured. A well-structured document is simple to understand
and modify. Often, user requirements evolve over a period of time. Therefore, to make the
modifications to the SRS document easy, it is vital to make the report well-structured.
• Black-box view: It should only define what the system should do and refrain from stating how
to do these. This means that the SRS document should define the external behavior of the
system and not discuss the implementation issues. The SRS report should view the system to
be developed as a black box and should define the externally visible behavior of the system. For
this reason, the SRS report is also known as the black-box specification of a system.
• Conceptual integrity: It should show conceptual integrity so that the reader can merely
understand it.
• Verifiable: All requirements of the system, as documented in the SRS document, should be
correct. This means that it should be possible to decide whether or not requirements have been
met in an implementation.
 Functional Requirements Non Functional Requirements

A functional requirement defines a system or its A non-functional requirement defines the quality
component. attribute of a software system.

It places constraints on “How should the software

It specifies “What should the software system do?”
system fulfill the functional requirements?”

Non-functional requirement is specified by technical

Functional requirement is specified by User. peoples e.g. Architect, Technical leaders and software
developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the software. Helps you to verify the performance of the software.
Functional Testing like System, Integration, End to End, Non-Functional Testing like Performance, Stress,
API testing, etc are done. Usability, Security testing, etc are done.
 Functional Requirements Non Functional Requirements

Usually easy to define. Usually more difficult to define.

Example1) Emails should be sent with a latency of no

Example1) Authentication of user whenever he/she
greater than 12 hours from such an activity.
logs into the system.
2) The processing of each request should be done
2) System shutdown in case of a cyber attack.
within 10 seconds
3) A Verification email is sent to user whenever he/she
3) The site should load in 3 seconds when the number
registers for the first time on some software system.
of simultaneous users are > 10000
User Requirements

• Easy and user friendly

• Quick Response

• Effectively Handling Operational Errors

• Customer Support
User Requirement Specification
• The URS should include:
• Introduction – including the scope of the system, key objectives for the project, and
the applicable regulatory concerns
• Program Requirements – the functions and workflow that the system must be able to
perform
• Data Requirements – the type of information that a system must be able to process
• Life Cycle Requirements – including how the system will be maintain and users
trained
System Requirement
• System Requirements Document is also known as System Requirements
Specifications.
• System requirements document is a set of documentation that describes the
behavior and features of a software or system.
• The system requirements document (SRD) describes the system-level
performance and functional requirements for a system.
• System Requirements Document or System Requirements Specification is
defined as a document which defines what the software will do and how it will
be required to perform, and it also defines the functionality the software
needs to satisfy all stakeholders (users, business) requirements.
Interface

• A point where two systems, subjects, organizations etc. meet and interact.

• A device or program enabling a user to communicate with a computer.

• A interface is a interaction between system and environment.

• Interface = system / environment

Interface Specification
Types of Interface Specification
There are four types of interface specifications:
Procedural Interface
Data Structures
Message Passing Interface
Representation of Data
Requirements Engineering Process

• Requirements engineering is the process of identifying, eliciting, analyzing,

specifying, validating, and managing the needs and expectations of stakeholders for a
software system.

• The requirements engineering process is an iterative process that involves several

steps:
• Requirements Elicitation
• Requirements Analysis
• Requirements Specification
• Requirements Validation
• Requirements Management
Tools involved in requirement engineering
• Observation report

• Questionnaire ( survey , poll )

• Use cases

• User stories

• Requirement workshop

• Mind mapping

• Role playing

• Prototyping
Main Activities of Requirements Engineering Process

• Requirements elicitation

• Requirements specification

• Requirements verification and validation

• Requirements management
Requirements Elicitation