UNIT-2

Software Requirement
Specifications (SRS)
Amit Sinha
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


Without well written document

-- Developers do not know what to build
-- Customers do not know what to expect
-- What to validate.

Definition

Requirement Engineering is the disciplined application of proven
principles, methods, tools and notations to describe a proposed
systems intended behavior and its associated constraints.

SRS may act as a contract between developer and customer.


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.

Problem Statement ?
Types of Requirement







Stakeholder: Anyone who should have some direct or indirect
influence on the system requirements.
--Users
-- Affected persons

Requirements



KNOWN
Requirement
UNKNOWN
Requirement
UNDREAMED
Requirement
FUNCTIONAL Non-FUNCTIONAL
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 ell the software does, what
it has to do.
User
Availability
Reliability
Usability
Flexibility

For Developers

Maintainability
Portability
Testability



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
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 projects vision statement?
What are the current estimated cost and schedule for
the project?
How big is the gap between the original cost & schedule
targets & current estimates?
Is the business model for software justified when the current
cost & schedule estimate are considered?
Have the major risks to the project been identified & can they
be surmounted?
Is the specifications complete & stable enough to support
remaining development work?
. 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?
Technical feasibility

Is it technically feasible to provide direct
communication connectivity through space from
one location of globe to another location?

Is it technically feasible to design a programming
language using Sanskrit?

Feasibility depends upon non technical Issues like:
Are the projects cost and schedule assumption
realistic?
Does the business model realistic?
Is there any market for the product?
Economic feasibility
Economic analysis is the most frequently used method for evaluating the
effectiveness of a new system.
More commonly known as cost/benefit analysis, the procedure is to
determine the benefits and savings that are expected from a candidate
system and compare them with costs.

If benefits outweigh costs, then the decision is made to design and
implement the system.

Cost-based study: It is important to identify cost and benefit factors,
which can be categorized as follows: 1. Development costs; and 2.
Operating costs. This is an analysis of the costs to be incurred in the
system and the benefits derivable out of the system.

Time-based study: This is an analysis of the time required to achieve a
return on investments. The future value of a project is also a factor.


Legal feasibility

Determines whether the proposed system conflicts with legal requirements, e.g.
a data processing system must comply with the local Data Protection Acts.

Operational feasibility

Operational feasibility is a measure of how well a proposed system solves the
problems, and takes advantage of the opportunities identified during scope
definition and how it satisfies the requirements identified in the requirements
analysis phase of system development.

Schedule feasibility

A project will fail if it takes too long to be completed before it is useful. Schedule
feasibility is a measure of how reasonable the project timetable is.
Requirement Elicitation

* RE is the most difficult, most critical, most error prone and
most communication intensive aspect of s/w development.
* The real requirement actually resides in users mind.
* RE requires the collaboration of several groups of participants
who have different background.

There are number of RE methods. Few of them are..

# Interviews
# Brainstorming sessions
# FAST (Fast Application Specification Techniques)
# Quality Function Deployment
# Use case Approach
Interviews

1. After receiving the problem statement from the customer, the
first step is to arrange a meeting (Interview) with the customer.

2. Specialized developers, often called Requirement Engineers,
interact with the customer.

Objective
To understand the customers expectations from the s/w.

Types
Open Ended
Structured
Open Ended Interviews
* No pre set agenda.
* Context free questions may be asked.
* e.g. Library Management Systems
Who is the min Librarian?
Who has requested for such a s/w?
Who will use the s/w?

Structured Interviews

* Agenda of fairly open questions is prepared.
* Proper questionnaire is designed.
* Customer may be allowed to voice his or her perceptions
about the possible solutions
Selection of StakeHolders

* It is impossible to interview every stakeholder.
* Representatives from groups must be selected based on
their technical expertise, domain knowledge, credibility
and accessibility.

The groups are..
1. Entry Level Personnel
2. Mid-Level StakeHolders
3. Managers
4. Users of S/w
Brainstorming Session

It is a group technique


Group Discussion






Prepare long list of requirements

Categorized
Prioritize
Pruned
New ideas Quickly
Creative Thinking
Advantages

# Brainstorming has become very popular and is being used by most
of the companies.

# It encourages to participate everyone and promotes creative
thinking, generates new ideas and provided platform to share views
and difficulties of implementation.

# Every idea will be documented in such a way that everyone can see it

# After the session, a detailed report will be prepared and facilitator
will review the report.

# Incomplete ideas may be listed separately and discussed to
make them complete ideas.

# A detailed report is prepared.


Groups for Brainstorming

1. Users
2. Mid Level Managers
3. Total Stakeholders
Facilitated Application Specification Techniques (FAST)

# This approach is similar to Brainstorming sessions.
# Used to bridge the expectation gap between customers and developers.
# In order to reduce the gap, a team oriented approach is developed for
requirements gathering and is called FAST.
# FAST encourages the creation of a joint team of customers and developers
who work together and propose a set of requirements.

Guidelines for FAST

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 FAST attendee is asked to make
(i) a list of services (processes or functions)
(ii) a list of constraints (cost, size)
(iii) a list of performance criteria (speed, accuracy)


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
Quality Function Deployment

Incorporate voice of the customer


Technical requirements

Documented (SRS)
Prime concern is customer satisfaction

what is important for customer ?

Three types of requirements are identified
-- Normal requirements
-- Expected requirements
-- Exciting requirements

Steps for QFD

1. Identify stakeholders
2. List out requirements
3. Degree of importance to each requirement.
5 Points : V. Important
4 Points : Important
3 Points : Not Important but nice to have
2 Points : Not important
1 Points : Unrealistic, required further exploration

4. Requirement Engineer may categorize like:
(i) It is possible to achieve
(ii) It should be deferred & Why
(iii) It is impossible and should be dropped from consideration.
The Use Case Approach

# This approach uses a combination of text a pictures in order to
improve the understanding of requirements.

# The Use case describes what of a system and not How.

# They give functional view of the system.

The Terms

Use Case often interchanged
Use Case Scenario But they are different
Use Case Diagram (UCD)
Components of Use Case approach

Actor:
# An actor or external agent, lies outside the system model, but
interacts with it in some way.
Actor : Person, machine, information System

# 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.
# 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.

So,

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

Use Case Diagrams
-- represents what happens when actor interacts with a system
-- captures functional aspect of the system.

Notes
Actors appear outside the rectangle.
Use cases within rectangle providing functionality
Relationship association is solid line between actor & use cases.


* 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