MAHARANA PRATAP GROUP OF INSTITUTIONS

KOTHI MANDHANA, KANPUR

(Approved by AICTE, New Delhi and Affiliated to Dr. AKTU, Lucknow)

Digital Notes
[Department of Computer Applications]
Subject Name : Software Engineering
Subject Code : KCA-203
Course : MCA
Branch : MCA
Semester : III
Prepared by : Mr. Yogendra Singh

Reference No./MCA/Yogendra Singh/KCA-302/3/2

Page 1 of 19
 UNIT-II: Software Requirement Specifications (SRS)

The software requirements are description and functionalities of the target system requirement
convey the expectations of users from the software.

Requirement Engineering:-
The process to gather the software requirement from client analyze and document them is known
as requirement engineering

Requirement Engineering Process:-

It is four step processes which includes-
1. Feasibility study
2. Requirements Elicitation/Gathering
3. Software Requirement specification
4. Software requirements validation

Let us see the process briefly-

Figure: Requirement Engineering Process

Page 2 of 19
1. Feasibility Study:
The aim of this is to determine whether developing the product is financially and technically
feasible.

Three types of feasibility studies are:

1. Economic Feasibility.
2. Technical feasibility.
3. Operational Feasibility

1. Economic feasibility: - Economic feasibility related to the budget for a project and many
will be spent.

2. Technical feasibility: - it is concerned with specifying equipment and software that with
successfully support the task required.
3. Operational feasibility: it is related to human organization or political aspect.
Operational feasibility related to weather the participants will be able to handle the new
system.

2. Requirement Gathering:
 If the feasibility report is positive, 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.

3. Software Requirement Specification (SRS):

 SRS is a document created by system analyst after the requirements are collected from
various stakeholders.
 SRS 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.
 The requirements received from client are written in natural language. It is the
responsibility of system analyst to document the requirements in technical language so
that they can be comprehended and useful by the software development team.
 A Software Requirement Specification (SRS) is a documents use to describe the
behaviors of the software system.

Page 3 of 19
This document is important because it is used in all the successive stages of SDLC. Any error
introduced here will result in to incomplete and bad quality product.
4. Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in this document are
validated.

Requirements can be checked against following conditions -

 If they can be practically implemented
 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the following diagram:

 Requirements 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. Requirements may then be prioritized and reasonably compromised.

The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.

 Documentation - All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing.

Page 4 of 19
Requirement Elicitation Methods:-
There are no. of requirements elicitation methods.
1. Interviews
2. Questionnaires
3. Brainstorming session
4. FAST (Facilitated Application Specification Technique).

1. Interviews:
 After receiving the problem statement from the customer come the first steps to arrange a
meeting with the customer.
 Specialized developer interact with customer
 The objective is to understand the customer expectation from the software.

2. Questionnaires:
A document with pre-defined set of objectives &respective options is handed over to all
stockholders to answer, which are collected and compiled

3. Brainstorming:

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

4. FAST (Facilitated Application Specification Technique):-This approach increases the

creation of a joint team of customers & developers who works together.

FAST Goal:-

 Identify the problem

 Solution requirement
 Process element of solution
 Negative different approach

Page 5 of 19
Data Flow Diagram (DFD):

Data flow diagram is a graphical representation of data flow in an information system. It is

capable of depicting incoming data flow, outgoing data flow and stored data. The DFD are only
concerned with data.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD does
not contain any control or branch elements.

Symbols Used in DFD: -The symbols that are used in data flow diagrams are.

Entities - Entities are source and destination of information data. Entities are represented by
rectangles with their respective names.

Fig: Entity

Process - Activities and action taken on the data are represented by Circle or Round-edged
rectangles.

Fig: process

Data Storage - There are two variants of data storage - it can either be represented as a rectangle
with absence of both smaller sides or as an open-sided rectangle with only one side missing.

Or

Fig: Data Storage

Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the
base of arrow as its source towards head of the arrow as destination.

Fig: Data Flow

Page 6 of 19
DFD rules and tips:
 Each process should have at least one input and an output.

 Each data store should have at least one data flow in and one data flow out.

 Data stored in a system must go through a process.

 All processes in a DFD go to another process or a data store.

Levels of Data Flow Diagrams (DFD):

 Level- 0/(context level) DFD
 Level -1 DFD
 Level -2 DFD

Level-0 DFD:
It is also knows as context diagram. It’s a basic overview of the whole system. It use only one
process to represent the function of the entire system
Example 01:

Figure 01: DFD Level 0

Page 7 of 19
Example 02:

Context Diagram:

 DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole system.

Figure 02: DFD Level 0

DFD Level 1:
 DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram. You
will highlight the main functions carried out by the system, as you break down the high-level
process of the Context Diagram into its sub processes.

Figure: DFD Level 1

DFD Level 2 then goes one step deeper into parts of Level 1. It may require more text to reach
the necessary level of detail about the system’s functioning.

Page 8 of 19
Entity Relationship Diagrams

An entity-relationship diagram is a type of flowchart that illustrates how “entity” such as people
or objects relate to each other within a system. ER Model creates a set of entities with their
attributes, a set of constraints and relation among them. ER Model is best used for the conceptual
design of database. ER Model can be represented as follows:

Entity - An entity in ER Model is a real world being, which has some properties called attributes.
Every attribute is defined by its corresponding set of values, called domain.
For example, consider a school database. Here, a student is an entity. Student has various
attributes like name, id, age and class etc.

Relationship - The logical association among entities is called relationship. Relationships are
mapped with entities in various ways. Mapping cardinalities define the number of associations
between two entities.

Decision table:
A decision table is used to represent the complex processing logic in a tabular or a matrix form.
The upper rows of the table specify the variables or conditions to be evaluated. The lower rows
of the table specify the actions to be taken when the corresponding conditions are satisfied. A
column in a table is called a rule. A rule implies that if a condition is true, then the corresponding
action is to be executed.

Page 9 of 19
What is Software requirement Specification (SRS)? Why is it important? List
the characteristic of a good quality SRS?

Ans: Software Requirement Specification (SRS):

 Software Requirement Specification (SRS) is a description of a software system to be
developed.
 It contains all the functions and non functional requirements.
 It may include a set of use cases that describe user interactions that the software must
provide to the user for perfect interaction.
 SRS minimize the time effort required by developed to achieve the desired goal and as a
minimize the developed cost.
 SRS document is known as black-box specification

Why is it important?
This document is important because it is used in all the successive stages of SDLC. Any error
introduced here will result in to incomplete and bad quality product.

Software Requirements Characteristics:

The characteristics of a good quality SRS are:
i. Correctness
ii. Completeness
iii. Consistency
iv. Unambiguousness
v. Modifiable
vi. Verifiable
1. Correct: An SRS is correct iff every requirement stated therein is one that the software shall
meet.
2. Unambiguous: An SRS is unambiguous iff every requirement stated therein has only one
interpretation. Each sentence in SRS should have the unique interpretation.
3. Complete: An SRS is complete iff it includes all significant requirements full labels and
references to all figures and diagram and definition of all terms and units of measures

Page 10 of 19
Parts of a SRS document
The important parts of SRS document are:
 Functional requirements of the system
 Non-functional requirements of the system
 Goals of implementation

Functional Requirements:
The functional requirements part discusses the functionalities required from the system.
or
The functional requirements of the system should clearly describe each of the functions that the
system needs to perform along with the corresponding input and output dataset.

Non-functional requirements:
Nonfunctional requirements are the characteristics of the system which cannot be expressed as
functions - such as the maintainability of the system, portability of the system, usability of the
system, etc.
Non-functional requirements include -
1. Security
2. Logging
3. Storage
4. Configuration
5. Performance
6. Interoperability
7. Flexibility, etc
8. Disaster recovery
9. Accessibility
Non-functional requirement-issues may include:

 reliability issues,
 performance issues,
 human - computer interface issues,
 interface with other external systems,
 security and maintainability of the system, etc.

Page 11 of 19
3. Goals of implementation:

The goals of implementation part documents some general suggestions regarding development.
These suggestions guide trade-off among design goals. The goals of implementation section
might document issues such as revisions to the system functionalities that may be required in the
future, new devices to be supported in the
future, reusability issues, etc. These are the items which the developers might keep in their mind
during development so that the developed system may meet some aspects that are not required
immediately.

Difference between Functional Requirements and Non Functional Requirements:

Functional Requirements Non Functional Requirements

A functional requirement describes what the Non-functional requirement place constraints
system should do? on how the system will do it

Ex: when a customer register on our website Ex: Email must be send within 2 sec after
send an email registration

Related to the individual system features Related to the system as a whole

Easy to test Difficult to test

Page 12 of 19
IEEE Standard for SRS:-
 IEEE documents are developed within IEEE.
 The Institute of Electrical and Electronics Engineers has published guidelines and
standard to organize or SRS document (IEEE standard 830-1998).

IEEE 830-1998 Standard for SRS:

• Title
• Table of Contents
1. Introduction

1.1 Purposes
1.2 Scopes
1.3 Definition, acronyms & abbreviation
1.4 References
1.5 Overview

2. Overall Description

1.1 Product Perspective

1.2 Product function
1.3 User characteristics
1.4 General Constraints
1.5 Assumptions & dependencies

3. Specific Requirements

3.1 External interfaces

3.2 Functional requirements
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design constraints
3.6 Software System Quality Attributes
3.7 Object Oriented Models

4. Appendices
5. Index

Page 13 of 19
What is Software Quality Assurance?

 Software Quality Assurance (SQA) is a process which ensures that developed software
meets & compiles with defined or standardized quality specifications.
Example: ISO 9000, SEI-CMM etc.

 Software quality assurance is a process which works parallel to development of software.

 SQA incorporates all software development processes starting from defining

requirements to coding until release. Its prime goal is to ensure quality.

Page 14 of 19
Difference between Verification & Validation
These two terms are very confusing for people, who use them interchangeably. Let’s discuss
about them briefly.

Verification Validation

Are you building it right? Are you building the right thing?

Ensure that the software system meets all the Ensure that functionalities meet the
functionality. intended behavior.

Verification takes place first and includes the Validation occurs after verification and
checking for documentation, code etc. mainly involves the checking of the
overall product.

Done by developers. Done by Testers.

Have static activities as it includes the reviews, Have dynamic activities as it includes
walkthroughs, and inspections to verify that executing the software against the
software is correct or not. requirements.

Page 15 of 19
ISO 9000 Models:

 International standards organisation (ISO) is a consortium of 63 countries established to

formulate and foster standardisation. ISO published its 9000 series of standards in 1987.
 It is an independent, nongovernmental international organization for developing
standards.
 These standards are developed for ensuring quality, safety and efficiency of products,
services and system.

Types of ISO 9000 Quality Standards:

ISO 9000 is a series of three standards—ISO 9001, ISO 9002, and ISO 9003.

1. ISO 9001: This standard applies to the organisations involved in design, development,
production, and servicing of goods.
2. ISO 9002: This standard applies to those organisations which do not design products but are
only involved in production.
Examples of this category of industries include steel and car manufacturing industries who buy
the product and plant designs from external sources and are involved in only manufacturing
those products. Therefore, ISO 9002 is not applicable to software development organisations.

3. ISO 9003: This standard applies to organisations involved only in installation and testing of
products.

Page 16 of 19
SEI Capability Maturity Model:

SEI Capability Maturity Model (SEI CMM) helped organizations to improve the quality of the
software they develop and therefore adoption of SEI CMM model has significant business
benefits.
CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University
in 1987.
 It is not a software process model. It is a framework which is used to analyse the
approach and techniques followed by any organization to develop a software product.
 It also provides guidelines to further enhance the maturity of those software products.
 This model describes a strategy that should be followed by moving through 5 different
levels.
 Each level of maturity shows a process capability level. All the levels except level-1 are
further described by Key Process Areas (KPA’s).

The CMM five maturity levels:

The 5 levels of CMM are as follows:
1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimizing

Figure: The Capability Maturity Model (CMM).

Page 17 of 19
The 5 levels of CMM are as follows:

Level-1: Initial –
 No KPA’s defined.
 Processes followed are ad-hoc and immature and are not well defined.
 Unstable environment for software development.
 No basis for predicting product quality, time for completion, etc.

Level-2: Repeatable –
 Focuses on establishing basic project management policies.
 Experience with earlier projects is used for managing new similar natured projects.

Level-3: Defined –
 At this level, documentation of the standard guidelines and procedures takes place.
 It is a well defined integrated set of project specific software engineering and
management processes.

Level-4: Managed –
 At this stage, quantitative quality goals are set for the organization for software products
as well as software processes.
 The measurements made help the organization to predict the product and process quality
within some limits defined quantitatively.

Level-5: Optimizing –
 This is the highest level of process maturity in CMM and focuses on continuous process
improvement in the organization using quantitative feedback.
 Use of new tools, techniques and evaluation of software processes is done to prevent
recurrence of known defects.
 Key features are:
1. Process change management.
2. Using latest technology
3. Using latest approach

Page 18 of 19
Difference between ISO 9000 & SCI-CMM

ISO 9000 SCI-CMM

It is a standards developed by International It is model developed by Software Engineering
Standards Organization Institute(SCI)
Applicable for any types of industry Applicable for software industry
It verify the quality of product then provide It verify the quality of software, according to
certificate to organization quality they provide level based certificate.
It has no any levels It has five levels
ISO gives either pass or fail certificate CMM provides maturity of levels

Page 19 of 19