Software Requirement

Analysis and Specification

Created By: Ritin Behl ( Reference Software Engineering
(3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright
© New Age International Publishers, 2007)
Chapter Objective
 Requirement Engineering
 Types of Requirement
 Feasibility Study
 Requirement Elicitation
 Use Case Diagram
 Requirements Analysis
 Data Flow Diagram
Requirement Engineering
Requirements describe
What not How
Produces one large document written in natural language
contains a description of what the system will do without
describing how it will do it.

Crucial process steps

Quality of product Process that creates
it
Without well written
document-- Developers do not know what to build
-- Customers do not know what to
expect
-- What to validate
3
 Problem Statement

Requirements
Elicitation

Requirement
Requirement
Requirements
Engineering Analysis
Engineering
Requirements
Documentation

Requirements
Review
SRS
Crucial Process Steps of requirement engineering

4
Crucial Process Steps of
Requirement Engineering
 Requirement Elicitation: This is also known as gathering
of requirements .(information from customers and existing
system processes)
 Requirement Analysis: The requirements are analyzed in
order to identify inconsistencies , defects , omissions etc.
 Requirement Documentation : This is the end product
of requirement elicitations and analysis. The document is
known as Software Requirement Specification (SRS).
 Requirement Review: The review process is carried out
to improve the quality of the SRS. It may also be called as
Requirement Verification :
Requirement Engineering
Requirement Engineering is the disciplined application of
proven principles, methods, tools, and notations to describe a
proposed system’s intended behavior and its associated
constraints.
SRS may act as a contract between developer and customer.

State of practice
Requirements are difficult to uncover
• Requirements change
• Over reliance on CASE Tools
• Tight project Schedule
• Communication barriers
• Market driven software development
• Lack of resources

6
Requirement Engineering
Example

A University wish to develop a software system for the

student result management of its M.Tech. Programme. A
problem statement is to be prepared for the software
development company. The problem statement may give
an overview of the existing system and broad expectations
from the new software system.

7
Types of Requirements
Types of Requirements

Known Unknown Undreamed

Requirements Requirements Requirements

Stakeholder: Anyone who should have some direct or indirect

influence on the system requirements.
--- User
---
Affected persons

Requirements

Functional Non-Functional

8
Types of Requirement
 Known Requirements:- Something a stakeholder
believes to be implemented .
 Unknown Requirements : Forgotten by the
stakeholder because they are not needed right now
or needed only by another stakeholder.
 Undreamt Requirements : Stakeholder may
not be able to think of new requirements due
to limited domain knowledge.
Types of Requirements
Functional requirements describe what the software has to
do. They are often called product features.
Non Functional requirements are mostly quality
requirements. That stipulate how well the software does,
what it has to do.
Availability
Reliability For Users
Usability
Flexibility

Maintainability
Portability For Developers
Testability

10
Functional Requriements
 Any requirement which specifies what the system should do.
 A functional requirement will describe a particular behavior of function of the
system when certain conditions are met, for example: “Send email when a
new customer signs up” or “Open a new account”.

Typical functional requirements include:

 Business Rules

 Transaction corrections, adjustments and cancellations

 Administrative functions

 Authentication

 Authorization levels

 Audit Tracking

 External Interfaces

 Certification Requirements

 Reporting Requirements

 Historical Data

 Legal or Regulatory Requirements

Non-Functional Requirements
 Any requirement which specifies how the system performs a certain
function.
 Non-functional requirements generally specify the system’s quality
attributes or characteristics, for example: “Modified data in a
database should be updated for all users accessing it within 2
seconds.”
 Typical non-functional requirements include:
 Performance – for example: response time, throughput, utilization, static volumetric
 Scalability
 Capacity
 Availability
 Reliability
 Recoverability
 Maintainability
 Serviceability
 Security
 Regulatory
Types of Requirements
User and system requirements
• User requirement are written for the users and
include functional and non functional requirement.
• System requirement are derived from user requirement.
• The user system requirements are the parts of
software requirement and specification (SRS)
document.

13
Types of Requirements
Interface Specification
• Important for the
customers.

TYPES OF INTERFACES
• Procedural interfaces procedures are also
called as Application Programming Interface (APIs)
• Data structures : are used to transfer data from one
module to another module
• Representation of data: Ordering of Bits

14
Feasibility Study
Is cancellation of a project a bad news?
As per IBM report, “31% projects get cancelled before
they are completed, 53% over-run their cost estimates by
an average of 189% & for every 100 projects, there are
94 restarts.

How do we cancel a project with the least work?

CONDUCT A FEASIBILTY STUDY

15
Feasibility Study
Feasibility depends upon non technical Issues like:

• Are the project’s cost and schedule assumption

realistic?

• Does the business model realistic?

• Is there any market for the product?

16
Feasibility Study
Purpose of feasibility study

“evaluation or analysis of the potential impact of a

proposed project or program.”

Focus of feasibility studies

• Is the product concept viable?
• Will it be possible to develop a product that matches the
project’s vision statement?
• What are the current estimated cost and schedule for
the project?

17
Feasibility Study
Focus of feasibility studies

• Have users & developers been able to agree on a

detailed user interface prototype? If not, are
the requirements really stable?
• Is the software development plan complete & adequate
to support further development work?

18
Requirements Elicitation
Perhaps
•Most difficult
• Most critical
• Most error prone
•Most communication intensive
Succeed

effective customer developer partnership

Selection of any method
1. It is the only method that we know
2. It is our favorite method for all situations
3. We understand intuitively that the method is
effective in the present circumstances.
Normally we rely on first two reasons.
19
Requirements Elicitation
1. Interviews
Both parties have a common
goal
--- open Success of the
Interview
ended project
--- structured
Selection of stakeholder
1. Entry level personnel
2. Middle level stakeholder
3. Managers
4. Users of the software (Most
important)

20
Requirements Elicitation
Types of questions.
 Any problems with existing system
 Any Calculation errors
 Possible reasons for malfunctioning
 No. of Student Enrolled

21
Requirements Elicitation
2. Brainstorming Sessions
It is a group technique

group discussions

New ideas Quickly Creative Thinking

Prepare long list of requirements

Categorized
Prioritized Pruned
*Idea is to generate views ,not to vet them.

1. Users 2. Middle Level managers 3. Total Stakeholders

22
Requirements Elicitation
A Facilitator may handle group bias, conflicts
carefully.

-- Facilitator may follow a published agenda

-- Every idea will be documented in a way that everyone
can see it.
--A detailed report is prepared.

3. Facilitated Application specification Techniques (FAST)

-- Similar to brainstorming sessions.

-- Team oriented approach
-- Creation of joint team of customers and developers.

23
Requirements Elicitation
Guidelines
1. Arrange a meeting at a neutral site.
2. Establish rules for participation.
3. Informal agenda to encourage free flow of ideas.
4. Appoint a facilitator.
5. Prepare definition mechanism board, worksheets,
wall stickier.
6. Participants should not criticize or debate.

FAST session Preparations

Each attendee is asked to make a list of objects that are:

24
Requirements Elicitation
1. Part of environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
A. List of constraints
B. Functions
C. Performance criteria
Activities of FAST session
1. Every participant presents his/her list
2. Combine list for each topic
3. Discussion
4. Consensus list
5. Sub teams for mini specifications
6. Presentations of mini-specifications
7. Validation criteria
8. A sub team to draft specifications

25
Requirements Elicitation
4. Quality Function Deployment
-- Incorporate voice of the customer

Technical requirements.
Documented
Prime concern is customer satisfaction
What is important for customer?

-- Normal requirements
-- Expected requirements
-- Exciting requirements

26
Requirements Elicitation

 Steps
1. Identify stakeholders
2. List out requirements
3. Degree of importance to each
requirement.

27
Requirements Elicitation
5. The Use Case Approach

Ivar Jacobson & others introduced Use Case approach

for elicitation & modeling.
Use Case – give functional view

The terms
Use Case
Use Case Often Interchanged
Scenario Use
But they are
Case Diagram
different
Use Cases are structured outline or template for the
description of user requirements modeled in a
structured language like English.
28
Requirements Elicitation
Use case Scenarios are unstructured

descriptions of user requirements.

Use case diagrams are graphical

representations that may be decomposed

into further levels of abstraction.

Components of Use Case approach
Person, machine, information
Actor: Actor System
An actor or external agent, lies outside the
system model, but interacts with it in some way.

29
Requirements Elicitation
• Cockburn between Primary and
distinguishes secondary
actors.
• A Primary actor is one having a goal
requiring the assistance of the system.

• A Secondary actor is one from which System needs

assistance.

Use Cases
A use case is initiated by a user with a particular goal in
mind, and completes successfully when that goal is
satisfied.

30
Requirements Elicitation
* It describes the sequence of interactions between
actors and the system necessary to deliver the
services that satisfies the goal.
* Alternate sequence
* System is treated as black box.

Thus
Use Case captures who (actor) does what (interaction)
with the system, for what purpose (goal), without dealing
with system internals.

31
Requirements Elicitation
*defines all behavior required of the system,
bounding the scope of the system.
Jacobson & others proposed a template for writing
Use cases as shown below:
1. Introduction
Describe a quick background of the use case.

2.Actors
List the actors that interact and participate in the
use cases.

3.Pre Conditions
Pre conditions that need to be satisfied for the use
case to perform.

4. Post Conditions
Define the different states in which we expect the system
to be in, after the use case executes.
32
Requirements Elicitation
5. Flow of events

1. Basic Flow
List the primary events that will occur when this use case is executed.

2. Alternative Flows
Any Subsidiary events that can occur in the use case should be
separately listed. List each such event as an alternative flow.
A use case can have many alternative flows as required.
6.Special Requirements

Business rules should be listed for basic & information flows as special
requirements in the use case narration .These rules will also be used
for writing test cases. Both success and failures scenarios should be
described.
7.Use Case relationships

For Complex systems it is recommended to document the relationships

between use cases. Listing the relationships between use cases also
provides a mechanism for traceability

Use Case Template. 33

Requirements Elicitation
Use Case Guidelines
1. Identify all users
2. Create a user profile for each category of users including
all roles of the users play that are relevant to the system.
3. Create a use case for each goal, following the use case
template maintain the same level of abstraction throughout
the use case. Steps in higher level use cases may be
treated as goals for lower level (i.e. more detailed), sub-
use cases.
4. Structure the use case
5. Review and validate with users.

34
Requirements Elicitation
Use case Diagrams
-- represents what happens when actor interacts with a
system.
-- captures functional aspect of the system.

Actor Relationship between

Use Case
actors and use case
and/or between the
use cases.
-- Actors appear outside the rectangle.
--Use cases within rectangle providing functionality.
--Relationship association is a solid line between actor &
use cases. 35
Requirements Elicitation
*Use cases should not be used to capture all the details of
the system.

*Only significant aspects of the required functionality

*No design issues

*Use Cases are for “what” the system is , not “how” the
system will be designed

* Free of design characteristics

36
 Use case diagram for Result Management
System
Maintain
Student
Details

Maintain
Subject
Details
Data Entry
Operator Maintain
Result
Details
Login

Administrator/
DR Generate
Result
Reports

View Results

Student/Teacher
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age 37
International Publishers, 2007
Requirements Elicitation
1. Maintain student Details
Add/Modify/update students details like name, address.
2.Maintain subject Details
Add/Modify/Update Subject information semester wise
3.Maintain Result Details
Include entry of marks and assignment of credit points for each
paper.
4. Login
Use to Provide way to enter through user id & password.
5. Generate Result Report
Use to print various reports
6. View Result
(i) According to course code
(ii) According to Enrollment number/roll number
38
Requirements Analysis
We analyze, refine and scrutinize requirements to
make consistent & unambiguous requirements.
Steps Draw the context
Diagram

Develop prototype
(optional)

Model the
Requirements

Finalize the
Requirements
Requirements Analysis Steps
39
Requirements Analysis
Administrator Marks Entry
Subject Information Operator
Entry

Student Information Marks Entry

Entry Result Management
System

Student Information Mark sheet generated Student performance

Reports generated Reports generated

40
Requirements Analysis
Data Flow Diagrams

DFD show the flow of data through the system.

--All names should be unique
-- It is not a flow chart
-- Suppress logical decisions
-- Defer error conditions & handling until the end
of the analysis
Symbol Name Function
Data Flow Connect process

Process Perform some transformation of its

input data to yield output data.

41
Requirements Analysis
Symbol Name Function
Source or sink A source of system inputs or
sink of system outputs
Data Store A repository of data, the
arrowhead indicate net
input and net outputs
to store
Leveling
DFD represent a system or software at any level
of abstraction.

A level 0 DFD is called fundamental system model or

context model represents entire software element as a
single bubble with input and output data indicating by
incoming & outgoing arrows.
42
Data Dictionaries
DFD DD
Data Dictionaries are simply repositories to
store information about all data items defined in
DFD.

Includes :
Name of data item
Aliases (other names for items)
Description/Purpose
Related data items
Range of values
Data flows
Data structure
definition
43
Data Dictionaries
Notation Meaning

x= a+b x consists of data element a &

b
x={a/b} x consists of either a or
b
x=(a) x consists of an optional data element
a
x= y{a} x consists of y or more
occurrences
x={a}z x consists of z or fewer occurrences of
a
x=y{a}z x consists of between y & z occurrences of
a{
44
Entity-Relationship Diagrams
Entity-Relationship Diagrams

It is a detailed logical representation of data for

an organization and uses three main
constructs.
Entities Relationships Attributes

Entities
Fundamental thing about which data may be
maintained. Each entity has its own identity.

Entity Type is the description of all entities to which a

common definition and common relationships and
attributes apply.
45
Entity-Relationship Diagrams
Consider an insurance company that offers both
home and automobile insurance policies .These
policies are offered to individuals and businesses.

POLICY
CUSTOMER
home Automobile individual businesses

POLICY CUSTOMER

46
Entity-Relationship Diagrams
Relationships
A relationship is a reason for associating two entity types.
Binary relationships involve two entity types

A CUSTOMER is insured by a POLICY. A POLICY CLAIM is made

against a POLICY.

Relationships are represented by diamond notation in a ER

diagram.
Insured
CUSTOMER POLICY
by

Made
Agains
t

POLICY
Relationships added to CLAIM
ERD 47
Entity-Relationship Diagrams
A training department is interested in tracking which
training courses each of its employee has completed.

EMPLOYEE completes COURSE

Many-to Many relationship

Each employee may complete more than one course,and

each course may be completed by more than one
employee.

48
Entity-Relationship Diagrams
Degree of relationship

It is the number of entity types that participates in that relationship.

Unary Ternary

Binary

Unary relationship Is
Person Married
to

One to One Manages

Employee

One to many

49
Entity Relationship Diagram
Binary Relationship
Entity-Relationship Diagrams
Ternary relationship
Part

Vendor Ships Ware House

Cardinalities and optionality

Two entity types A,B, connected by a relationship.

The cardinality of a relationship is the number of instances of entity B that
can be associated with each instance of entity A

Is
Movie Stocked Video Tape
as

51
Entity-Relationship Diagrams
Minimum cardinality is the minimum number of instances
of entity B that may be associated with each instance of
entity A.

Minimum no. of tapes available for a movie is zero.We say

VIDEO TAPE is an optional participant in the is-stocked-
as relationship.

Is
MOVIE Stocked VIDEO TAPE
As

52
Entity-Relationship Diagrams
Attributes

Each entity type has a set of attributes associated with

it.

An attribute is a property or characteristic of an entity that

is of interest to organization.

Attribute

53
Entity-Relationship Diagrams
A candidate key is an attribute or combination of attributes
that uniquely identifies each instance of an entity type.

Student_ID Candidate Key

If there are more candidate keys, one of the key may be

chosen as the Identifier.
It is used as unique characteristic for an entity type.

Identifier

54
Entity-Relationship Diagrams
Name Address

Student_ID STUDENT Phone_No

Vendors quote prices for several parts along with quantity of parts.
Draw an E-R diagram.

Quote-
Vendor price
Parts

quantity price

55
Requirements Documentation
This is the way of representing requirements in
a consistent format

SRS serves many purpose depending upon who is

writing it.

-- written by customer
-- written by
developer
Serves as contract between customer &
developer.

56
Requirements Documentation
Nature of SRS

Basic Issues

• Functionality
• External Interfaces
• Performance
• Attributes
• Design constraints imposed on an
Implementation

57
Requirements Documentation
SRS Should
-- Correctly define all requirements
-- not describe any design details
-- not impose any additional
constraints
Characteristics of a good SRS
An SRS Should be
✓ Correct
✓ Unambiguous
✓ Complete
✓ Consistent

58
Requirements Documentation
✓ Ranked for important and/or stability
✓ Verifiable
✓ Modifiable
✓ Traceable

59
Requirements Documentation
Correct
An SRS is correct if and only if
every requirement stated therein is one that the
software shall meet.
Unambiguous
An SRS is unambiguous if every
and only if, requirement stated therein has only
one interpretation.
Complete
An SRS is complete if and
only if, it includes the following elements

(i) All significant requirements, whether

related to functionality, performance,
design constraints, attributes or
external interfaces. 60
Requirements Documentation
(ii)Responses to both valid & invalid inputs.

(iii)Full Label and references to all figures, tables and diagrams

in the SRS and definition of all terms and units of measure.

Consistent

An SRS is consistent if and only if, no subset

of individual requirements described in it conflict.

Ranked for importance and/or Stability

If an identifier is attached to every

requirement to indicate either the importance or stability
of that particular requirement.
61
Requirements Documentation
Verifiable
An SRS is verifiable, if and only if, every
requirement stated therein is verifiable.

Modifiable
An SRS is modifiable, if and only if, its structure and style
are such that any changes to the requirements can be made
easily, completely, and consistently while retaining structure and
style.

Traceable
An SRS is traceable, if the origin of each of the
requirements is clear and if it facilitates the referencing of
each requirement in future development or enhancement
documentation.
62
Requirements Documentation
Organization of the SRS

IEEE has published guidelines and standards to organize

an SRS.
First two sections are same. The specific tailoring occurs
in section-3.

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definition, Acronyms and
1.4 abbreviations References
1.5 Overview

63
Requirements Documentation
2. The Overall Description

2.1 Product
2.1.1
Perspective System Interfaces
2.1.2 Interfaces
2.1.3 Hardware
2.1.4 Interfaces
2.1.5 Software Interfaces
2.1.6 Communication
2.1.7 Interfaces Memory
2.1.8 Constraints Operations
Site Adaptation
Requirements

64
Requirements Documentation
2. Product Functions
3. User Characteristics
4. Constraints
5. Assumptions for dependencies
6. Apportioning of requirements

3. Specific Requirements
1. External Interfaces
2. Functions
3. Performance requirements
4. Logical database requirements
5. Design Constraints
6. Software System attributes
7. Organization of specific requirements
8. Additional Comments.
65
Requirements Validation
Check the document for:

✓ Completeness &
consistency
✓ Conformance to standards
✓ Requirements conflicts
✓ Technical errors
✓ Ambiguous requirements

66
Requirements Validation

SRS document
List of problems

Validatio
Organizational
n
standards
process

Organizational Approved actions

knowledge

67
 Validation Vs Verification
Validation Verification
Are we building the right system? Are we building the system right?

Validation is the process of evaluating software at Verification is the process of evaluating products
the end of the development process to determine of a development phase to find out whether they
whether software meets the customer expectations meet the specified requirements.
and requirements.

The objective of Validation is to make sure that the The objective of Verification is to make sure that
product actually meet up the user’s requirements, the product being develop is as per the
and check whether the specifications were correct requirements and design specifications.
in the first place.

Following activities are involved in Validation: Following activities are involved in Verification:
Testing like black box testing, white box testing, Reviews, Meetings and Inspections.
gray box testing etc.

Validation process describes whether the software Verification process explains whether the outputs
is accepted by the user or not. are according to inputs or not.
Cost of errors caught in Validation is more than Cost of errors caught in Verification is less than
errors found in Verification. errors found in Validation.