1

UNIT-2Software Requirement SpecificationPresentation By Nishu RastogiAssistant ProfessorInvertis University, Bareilly

2

Requirement• Features of system or system function used to fulfill

system purpose• Focus on customer’s needs and problem, not on

solutionsTypes of Requirements-• User requirements

Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

• System requirementsA structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

3

Requirement Engineering

• The process to gather the software requirements from client, analyze and document them is known as requirement engineering.

• The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.

4

Requirement Engineering ProcessIt is a four step process, which includes –

• Feasibility Study

• Requirement Gathering / Elicitation

• Software Requirement Specification

• Software Requirement Validation

5

Feasibility Study• When the client approaches the organization with rough

idea about what functions the software must perform• Analysts does a detailed study about whether the

desired system and its functionality are feasible to develop

• Analyzes whether the software can be practically materialized in terms of implementation, cost constraints and as per values and objectives of the organization

• Output of this phase is a feasibility study report that contain comments and recommendations for management about whether or not the project should be undertaken.

6

Requirement Elicitation

• If the feasibility report is positive towards undertaking the project then the next phase starts with gathering requirements from the user.

• Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.

• Sometimes known as Requirement gathering.

7

Requirement Elicitation Process

Requirement

Gathering

Requirement

Organization

Negotiation and

Discussions

Documentation

8

Elicitation Process• Requirement Gathering- The developers discuss with

the client and end users and know their expectations from the software.

• Organizing Requirements - The developers prioritize and arrange the requirements in order of importance, urgency and convenience.

• Negotiation & discussion - If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Unrealistic requirements are compromised reasonably.

• Documentation - All formal & informal, functional and non-functional requirements are documented

9

Requirement Elicitation Techniques

1- Interviews• Interviewers should be open-minded, willing to listen

to stakeholders.• They should prompt the interviewee with a question

or a proposal.2- Surveys3- Questionnaires4- Task analysis Team of engineers and developers

may analyze the operation for which the new system is required.

5- Brainstorming- An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis.

10

Requirement Elicitation Techniques

6- Domain Analysis- Every software falls into some domain category. The expert people in the domain can help to analyze general and specific requirements.7- Prototyping- is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. 8- Observation- Team of experts visit the client’s organization or workplace. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software.

11

Analysis of Gathered InformationWhen Analyst understands the exact customer requirement. Requirement problems are identified and eliminated.1- Anomaly - Ambiguity in requirement.Ex- If the temp is high switch off heater (Threshold must be

defined).2- Inconsistency- If requirement contradicts with each other.Ex- Multiple user may need different actions on some

particular condition.3- Incompleteness- When requirements have been

overlooked. In that case analyst suggest customer, the features which

are missing for consideration

12

Software Requirement Specification• SRS is a document created by system analyst

after the requirements are collected from various stakeholders.

• Requirements received from client are written in natural language

• Defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

• It acts as a formal (legal) document between the client and the service provider.

13

Features of SRS• User Requirements are expressed in natural

language.

• Technical requirements are expressed in structured language, which is used inside the organization.

• Design description should be written in Pseudo code.

• Format of Forms and GUI screen prints.

• Conditional and mathematical notations for DFDs etc.

14

Content of SRS

• Functional Requirement

• Non- Functional Requirement

• Goal of Implementation

15

Functional RequirementsRelated to functional aspect of software such as input/output, processing and error handling

EXAMPLES • Search option given to user to search from various

invoices.• User should be able to mail any report to

management.• Users can be divided into groups and groups can

be given separate rights.• Should comply business rules and administrative

functions.• Software is developed keeping downward

compatibility intact.

16

Example(Writing Functional Requirement)• Consider the case of the library

management system, where

F1 : Search Book function Input : An author’s name Output : Details of the author’s books and

the location of these books in the library

17

Non-Functional RequirementsImplicit or expected characteristics of software, which users make assumption of.• Security• Logging• Storage• Configuration• Performance• Cost• Interoperability• Flexibility• Accessibility

18

User Interface requirements

• Easy to operate

• Quick in response

• Effectively handling operational errors

• Providing simple yet consistent user interface

19

Organization of SRS Document1- Introduction a- Background b- Overall Description c- Environmental Characteristics

* Hardware* Peripherals* People

2- Goals of Implementation3- Functional Requirements4- Non-Functional Requirements5- Behavioral Description

a- System Statesb- Events and Actions

20

Why and Who needs SRS ?• Users, Customers and Marketing PersonnelTo ensure them the system as described in SRS will meet their needs.• Software Developers To make sure that they develop exactly what is required by the customer.• Test Engineers To ensure that the requirements are understandable from a functionality point of view, so that they can test the software and validate its working.

21

Why and Who needs SRS ? CONTD..• User Document WritersTo ensure that they understand the document well, to be able to write user manuals.

• Project ManagersTo ensure that they can estimate the cost easily as it contains all the information required to plan for the project well.

• Maintenance EngineersTo understand the functionality of the system. It enables them to determine what modifications to the system’s functionality would be needed for a specific purpose.

22

Characteristics of Good SRS• Clear (easy to understand)• Correct• Consistent (same everywhere no contradiction) • Coherent (logical)• Comprehensible (user-friendly)• Modifiable• Verifiable (justified)• Prioritized• Unambiguous (not more than one interpretation)• Traceable • Credible source (trusted based on facts)

23

Problems without a SRS document • Without developing the SRS document, the

system would not be implemented according to customer needs.

• Software developers would not know whether what they are developing is what exactly required by the customer.

• Without SRS document, it will be very much difficult for the maintenance engineers to understand the functionality of the system.

• It will be very much difficult for user document writers to write the users’ manuals properly without understanding the SRS document.

24

Software Requirement Validation• Requirement specifications are developed, the

requirements mentioned in this document are validated

• User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly

Check following-If they can be practically implementedIf they are valid and as per functionality and domain of softwareIf there are any ambiguitiesIf they are completeIf they can be demonstrated

25

Requirement vs. DesignRequirement Design

Describe what will be delivered

Describe how it will be done

Primary goal of analysis is UNDERSTANDING

Primary goal of design is OPTIMIZATION

There is more than one solution

There is only one final solution

Customer Interested Customer not interested

26

Why Requirement Analysis?• What is the problem? • Why is it important to solve the problem? • What are the possible solutions to the problem? • What exactly are the data input to the system and what exactly are the data output by the system? • What are the likely complexities that might arise while solving the problem? • If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be?

27

Software Documentation• A written text that accompanies computer

software. It either explains how it operates or how to use it, and may mean different things to people in different roles.

Types of documentation • Technical Documentation• User Documentation• Marketing Documentation

28

Thank You !!!