Software Requirements

Analysis and Specification

 Today’s Topic

 How to get the customers’ requirements?

Reasons for Project Failure

Sources:
Standish Group, 1995 & 1996
Scientific American, September 1994
Project Success Factors

Sources:
Standish Group, 1995 & 1996
Scientific American, September 1994
Agenda
Questions
Requirement Engineering
 Requirement Engineering

 Identifying and specifying requirements necessarily involves

people interaction
 Cannot be automated
 Requirement (IEEE)= A condition or capability that must be
possessed by a system
 Requirement analysis phase ends with a Software Requirements
Specification (SRS) document
 SRS specifies what the proposed system should do
What Requirements are
What Requirements are not

X
 Requirement Engineering

Inputs System Outputs

Design Constraints
Functions
Non-Functional
Requirements
(E.g. Performance)

(E.g. Environments)
Definitions
 Examples from the Course
Registration System
Stakeholder Request
 Need less administrative overhead for registration.
 Professors need immediate access to student grades.

Feature
A tree browser provides a way to view student information, by semester, by
class.
Software Requirement
Functional
The use case starts when the student selects the “register for course”
command. The system displays the list of available courses…
Non-Functional
99% of 24/7 availability (3.65 days downtime per year)
Constraint
Operate on the College DEC VAX Main Frame.
Requirements Exist at Many Levels

Stakeholder Needs
What
How
Product or System Features
What
How
Software Requirements
What
How
Design Spec
Test Procedures
Documentation Plans
 Requirement Management

Problem Problem Space

Problem

Needs

Features
The system
to be built
Software
Requirements
Solution
Traceability
Space
Test Procedures User
Design
Doc
 Types of Requirements

 Customer Requirements
 Functional Requirements
 Non-functional Requirements
 Performance Requirements
 Design Requirements
 Derived Requirements
 Allocated Requirements
Complexity of Requirement
Engineering
Problems & Challenges
 Characteristics of Requirements

 Unitary (Cohesive)
 Complete
 Consistent
 Non-Conjugated (Atomic)
 Traceable
 Current
 Unambiguous
 Specify Importance
 Verifiable
 Need of Requirements Analysis

 The purpose of Requirements Analysis is to:

 Refine customer objectives and requirements
 Define initial performance objectives and refine them into
requirements;
 Identify and define constraints that limit solutions; and
 Define functional and performance requirements based on
customer provided measures of effectiveness.
Agenda
Task of Requirement Engineering
 Task of Requirement Engineering

 Problem Recognition- the goal of the analyst is recognition of the

basic problem elements as perceived by the user/customer;
 Evaluation and Synthesis- the analyst must evaluate the flow and
content of information, define and elaborate all software functions,
understand software behavior in context of the events that affect the
system, establish system interface characteristics and design
constraints;
 Modeling- the analyst should create models of the system which
serves as a foundation for system design
 Task of Requirement Engineering

 Specification- the tasks associated with analysis and specification

strive to provide a representation of software that can be reviewed
and approved by the customer;
 Review- is conducted to check the progress of the project and to
check whether all the work is performed well according to the user
requirements. A group of people read and analyze the requirements,
look for problems, meet and discuss the problems and agree on
actions to address these problems
 Role and Tasks of System Analyst

 Defining Requirement

 Prioritizing Requirements

 Gathering Facts, data and opinions of Users

 Evaluation and Analysis

 Solving Problems

 Drawing Specifications
Agenda
 Requirement Analysis Principles (1/8)

For analysis process following principle must be followed:

The information domain of a problem must be represented and
understood.
The functions that the software is to perform must be defined.
The behavior of the software (as a consequence of external events)
must be represented.
The models that depict information, function and behavior must be
partitioned in a manner that uncovers detail in a layered (or
hierarchical) fashion.
The analysis process should move from essential information
toward implementation detail.
 Requirement Analysis Principles (2/8)

The various analysis principles are

o The Information Domain

o Modeling

o Partitioning

o Essential and Implementation Views

 Requirement Analysis Principles (3/8)

The Information Domain

•Information content and relationships (the data model) : This
includes the individual data and control objects that comprise some
larger collection of information that is transformed by the software.
•Information flow: This refers to the manner which data and control
objects (state information) is ``transformed'' as it moves (or ``flows'')
through the software system to be developed - and, how it is
manipulated by system functions.
•Information structure: This refers to the internal organization of
data and control objects.
 Requirement Analysis Principles (4/8)

Modeling

•Functional models: It focuses on the functions - transformations of

data - that the software must include.

•Behavioral models: A behavioral model creates a representation of

the states of the software and the events that cause software to change

state.
Requirement Analysis Principles (5/8)
 Requirement Analysis Principles (6/8)

Modeling
Models created during requirements analysis serve a number of
important roles:
• Aids the analyst in understanding the information, function, and
behavior of a system and make analysis easier
• Key to a determination of completeness, consistency, and
accuracy of the specifications.
• Foundation for design
 Requirement Analysis Principles (7/8)

Partitioning
Partitioning decomposes a problem into its constituent parts.
Conceptually, we establish a hierarchical representation of function or
information and then partition the uppermost element by
a. Exposing increasing detail by moving vertically in the hierarchy
b. Functionally decomposing the problem by moving horizontally in
the hierarchy.
 Requirement Analysis Principles (8/8)

Essential and Implementation Views (Logical and Physical Views)

An essential view of software requirements presents the functions to be

accomplished and information to be processed without regard to
implementation details.
The implementation view of software requirements presents the real
world representation of processing functions and information
structures.
Agenda
Software Requirement
Specification
 Need for SRS

 SRS establishes basis of agreement between the user and the

supplier.
 SRS is the medium to bridge the communication gap

 Helps user in understand his needs.

 SRS provides a reference for validation of the final product

 High quality SRS essential for high Quality S/W

 Need for SRS

 Good SRS reduces the development cost

 SRS errors are expensive to fix later
 Req. changes can cost a lot (up to 40%)
 Good SRS can minimize changes and errors
 Substantial savings; extra effort spent during req. saves multiple
times that effort
 Standard for SRS
RE
A O N
TW AT I
F
O IF IC
S
F EC
E O P
T S
PLA ENT
M M
TE IRE
Q U
RE

Example 1: SRS for Global Personal Marketplace

Example 2: SRS for Personal Investment Management Systems
Example 3: SRS for Network Simulator
Review of SRS
 Requirements Review…Checklist

 Some good checklist will depends on the projects

 Are all H/W resources defined?
 Have the response times of functions been specified?
 Have all the H/W external S/W and data interface been defined?
 Have all the functions required by the client been specified?
 Is the initial state of the system defined?
 Are the responses to exceptional conditions specified?
 Are possible future modifications specified?
 Characteristics of SRS

Looking for these Characteristics

 Correct
 Complete
 Unambiguous
 Consistent
 Verifiable
 Traceable
 Modifiable
 Ranked for importance and/or stability
 Characteristics of SRS

 Correctness
 Each requirement accurately represents some desired feature
in the final system
 Completeness
 All desired features/characteristics specified
 Hardest to satisfy
 Completeness and correctness strongly related
 Unambiguous
 Each requirement has exactly one meaning
 Without this errors will creep in
 Important as natural languages often used
 Characteristics of SRS

 Verifiability
 There must exist a cost effective way of checking if sw

satisfies requirements
 Consistent
 two requirements don’t contradict each other

 Traceable
 The origin of the req, and how the req relates to software

elements can be determined

 Ranked for importance/stability
 Needed for prioritizing in construction

 To reduce risks due to changing requirements

 Example…
Example:- Consider the case of the library system
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
 Req. 1:

 R.1.1:
 Input: “search” option,
 Output: user prompted to enter the key words.
 R1.2:
 Input: key words
 Output: Details of all books whose title or author name
matches any of the key words.
 Details include: Title, Author Name, Publisher name, Year of
Publication, ISBN Number, Catalogue Number, Location in the
Library.
 Processing: Search the book list for the keywords
 Req. 2:

 R2.1:
 Input: “renew” option selected,
 Output: user prompted to enter his membership number and
password.
 R2.2:
 Input: membership number and password
 Output:
 list of the books borrowed by user are displayed. User prompted to
enter books to be renewed or
 user informed about bad password
 Processing: Password validation, search books issued to the
user from borrower list and display.
 Req. 2:

 R2.3:
 Input: user choice for renewal of the books issued
to him through mouse clicks in the corresponding
renew box.
 Output: Confirmation of the books renewed
 Processing: Renew the books selected by the in the
borrower list.
 Example…

Example: - Withdraw Cash from ATM

R1: withdraw cash
Description: The withdraw cash function first determines the type of account that
the user has and the account number from which the user wishes to withdraw
cash. It checks the balance to determine whether the requested amount is available
in the account. If enough balance is available, it outputs the required cash,
otherwise it generates an error message.
R1.1 select withdraw amount option
Input: “withdraw amount” option
Output: user prompted to enter the account type
 Example…

Example: - Withdraw Cash from ATM

R1.2: select account type
Input: user option
Output: prompt to enter amount
R1.3: get required amount
Input: amount to be withdrawn in integer values greater than 100 and less than 10,000
in multiples of 100.
Output: The requested cash and printed transaction statement.
Processing: the amount is debited from the user’s account if sufficient balance is
available, otherwise an error message displayed.
 Data Flow Modeling

 Widely used; focuses on functions performed in the system

 Uses Data Flow Diagrams (DFDs) and functional decomposition
in modeling
 A DFD shows flow of data through the system
 Views system as transforming inputs to outputs
 Transformation done through transforms
 DFD captures how transformation occurs from input to output
as data moves through the transform
Data Flow Diagrams…
Drawing DFD… Two Notations

Yourdon and
Coad Process
Notations

1 Gane and Sarson

Process Notation
PROCESS NAME
 Main steps…Drawing DFD

 Draw a context diagram

 Draw DFD of the existing system

 Draw DFD of the proposed system and identify the man-machine

boundary
 Context Diagram

 Views the entire system as a transform and

identifies the context
 It is a DFD with one transform (system), with all
inputs, outputs, sources, sinks for the system
identified
 Example
A supermarket needs to develop the following software to encourage
regular customers. For this, the customer needs to supply his/her
residence address, telephone number, and the driving license number.
Each customer who registers for this scheme is assigned a unique
customer number (CN) by the computer. A customer can present his
CN to the check out staff when he makes any purchase. In this case,
the value of his purchase is credited against his CN. At the end of each
year, the supermarket intends to award surprise gifts to 10 customers
who make the highest total purchase over the year. Also, it intends to
award a 22 caret gold coin to every customer whose purchase
exceeded Rs.10,000. The entries against the CN are the reset on the
day of every year after the prize winners’ lists are generated.
 Context Diagram

Sales-Clerk

winner-list
sales-details

Supermarket
Software
0 CN
gen-winner
command
cus
tom
er - de
Manager
tails Customer
Level 1 Diagram
 Drawing a DFD for a system

 Identify inputs, outputs, sources, sinks for the system

 Work your way consistently from inputs to outputs, and identify
a few high-level transforms to capture full transformation
 If get stuck, reverse direction
 When high-level transforms defined, refine each transform with
more detailed transformations
 Never show control logic; if thinking in terms of loops/decisions,
stop & restart
 Label each arrows and bubbles; carefully identify inputs and
outputs of each transform
 Context Diagram
Claim with
treatment costs Insurance
Symptoms,
and type Company
Patient info,
Insurance info,
Payments Payment or
Patient rejected claim
Patient Information
System
Bills,
Medical info, Patient info
Receipt
Updated
Referring
Patient info
Doctors or
Hospitals

Patient Information System in a Hospital

DFD Example
 Leveled DFDs

 DFD of a system may be very large

 Can organize it hierarchically
 Start with a top level DFD with a few bubbles
 then draw DFD for each bubble
 Preserve I/O when “ exploding” a bubble so
consistency preserved
 Makes drawing the leveled DFD a top-down refinement
process, and allows modeling of large and complex
systems
 Data Dictionary
 In a DFD arrows are labeled with data items
 Data dictionary defines data flows in a DFD
 Shows structure of data; structure becomes more visible
when exploding
 Can use regular expressions to express the structure of data
 For the timesheet DFD
Weekly_timesheet – employee_name + id + [regular_hrs +
overtime_hrs]*
Pay_rate = [hourly | daily | weekly] + dollar_amt
Employee_name = last + first + middle
Id = digit + digit + digit + digit
 DFD drawing – common errors

 Unlabeled data flows

 Missing data flows
 Extraneous data flows
 Consistency not maintained during refinement
 Missing processes
 Too detailed or too abstract
 Contains some control information
Example – context diagram
Restaurant Mgmt System
Example – DFD of existing system
Example – DFD of proposed system
 STAKEHOLDERS…SRS…NEED

 USERS, CUSTOMERS, AND MARKETING PERSONNEL

 To ensure that system defined in SRS meet their needs.
 SOFTWARE DEVELOPERS
 To ensure that they develop exactly what is required by the customer.
 TEST ENGINEERING
 To ensure that the requirements are understandable from the
functionality point of view, so that they can test the software and
validate its working.
 USER DOCUMENTATION WRITERS
 To ensure that they understand the document well enough to be able
to write the users’ manuals.
 STAKEHOLDERS…SRS…NEED

 PROJECT MANAGERS
 To ensure that they can estimate the cost easily by referencing to the
SRS document and that it contains all the information required to plan
the project well.
 MAINTENACE ENGINEERING
 Helps to maintenance engg to understand the functionality of the
system. To determine what modifications to the system’s functionality
would needed for a specific purpose.
Agenda
Summary (1/2)
Summary (2/2)
 References

1. Software Engineering by Roger S. Pressman

2. An Integrated Approach to Software Engineering by Pankaj
Jalote
3. Fundamentals of Software Engineering by Rajib Mall
4. Software Engineering by Sommerville
5. Integrating Services and Product Quality Function
Deployment by Jurassic QFD: Andrew Bolt, Glenn H. Mazur
 CASE - 1

Tom and Sue are starting a bed-and-breakfast (B & B) in a small New England town.
They will have three bedrooms for guest. They want a system to manage the
reservation and monitor expenses and profits. When a potential customer calls for
reservation, they will check the calendar, and if there is a vacancy they will enter the
customer name, address, phone number, dates, agreed upon price, credit card
number, and room numbers. Reservation must be guaranteed by one day’s payment.
Reservation will be held without guarantee for an agreed upon time. If not guaranteed
by that date, the reservation will be dropped.
Do the following:
 Requirement Analysis
 design data flow diagram
 CASE - 2
The Blood Bank Testing Unit. This is one unit within the College Street Red Cross Blood Donor
Centre. On the day following a blood donation, the Blood Bank unit tests all blood for blood type
and potential viral agents. They send the results of these tests to the Processing Office (another
unit of the Centre). For each tested blood unit, they fill out a form which lists the blood unit
number, the blood type, the date and the results of the test. If the tests indicate that the blood
may be contaminated with a viral agent, the blood unit is destroyed. This is indicated on the test
form.
Blood units have a limited shelf life. The Blood Bank receives a list every day of those units
which have exceeded their shelf life. These are discarded and the list sent back to the
Processing Office with a signed indication of the disposal of the units.
The Blood Bank also distributes blood to various hospitals requesting blood. Requests usually
come in for specific blood types. The Blood Bank prepares refrigerated containers of these units
and distributes them to the hospital vans when they arrive to pick up their supply. The Blood
Bank receives a listing for each hospital and the specific units of blood to supply to the hospital
from the Processing Office. The order is printed in triplicate. When the order is filled, the lab
technician signs the order and returns a copy to the Processing Office. A copy of it travels with
the blood to the requesting hospital. The final copy is kept in the Blood Bank records but
discarded after one year.
Do the following:
Functional requirements specification
Design data flow model