Iterative Enhancement Model

Useable product is released at the end of the each cycle,

with each release providing additional functionality.

• Customers and developers specify as many requirements

as
possible and prepare a SRS document.

• Developers and customers then prioritize these

requirements

• Developers implement the specified requirements in one

or
more cycles of design, implementation and test based on
the
defined priorities.
Incremental Process Models
T hey are e f fe c ti v e i n the si tuati ons whe re
requirements are def ined precisely and there is no
confusion about the
functionality of the final product.

After every cycle a useable product is given to the

customer.

Popular particularly when we have to quickly deliver a

limited functionality system.
Incremental approach
• does not require going back and changing things that are
already delivered;
• the focus is only the requirements that have not yet been
implemented.
Evolutionary Process Models

• Evolutionary process model resembles iterative

enhancement model.

• The same phases as def ined for the waterfall model

occur here in a cyclical fashion.

• This model differs from iterative enhancement

model in the sense that this does not require a
useable product at the end of each cycle.
Evolutionary Process Models

• In evolutionary development, requirements are

implemented by category rather than by priority.

• T hi s m o d e l i s use f ul f o r p ro j e c ts usi ng ne w
technology that is not well understood.

• This is also used for complex projects where all

functionality must be delivered at one time, but the
requirements are unstable or not well understood at
the beginning.
Evolutionary Models: Prototyping

Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

15
 Evolutionary Model : Spiral Model

One phase is split roughly into four sectors of major

activities.

1. Planning : Determination of objectives,

alternatives & constraints.

2. Risk Analysis : Analyze alternatives and attempts

to identify and resolve the risks involved.

3. Development : Product development and testing

product.

4. Assessment : Customer evaluation

 Spiral Model

• The radial dimension of the model represents the

cumulative costs.

• Each path around the spiral is indicative of

increased costs.

• The angular dimension represents the progress

made in completing each cycle.

• Each loop of the spiral from X-axis clockwise

through 360 degree represents one phase.
Rapid Application Development (RAD) Model

• Not an appropriate model in the absence of user

participation.

• Reusable components are required to reduce

development time.

• Highly specialized & skilled developers are

required and such developers are not easily
available.
Selection of a Life Cycle Model

Selection of a model is based on:

a) Requirements
b) Development team
c) Users
d) Project type and associated risk
 External entities

Processing steps

Data stores or sources

Data flows

26
The enrolment process works as follows:

1. Students send in an application form containing their

personal details, and their desired course.

2. The university checks that the course is available and that

the student has necessary academic qualifications.

3. If the course is available the student is enrolled in the

course, and the university confirms the enrolment by
sending a confirmation letter to the student.
OR
4. If the course is unavailable the student is sent a rejection
letter.
Steps for DFD
1. people/organisations/things that supply
information to or use information from the
system external entities (EE)

2. Actions/doing words/verbs => Processes (P)

3. Movement/exchange of information/data
between external entities to processes, and
processes to processes => data flows (DF)

4. store/record information/data => data

stores(DS)
In Example
1. A student (EE) sends in an application form (DF)
containing their personal details, and their desired
course.

2. The university checks (P) that the course is available.

3. If the course is available the student is enrolled (P) in

the course, and the university confirms (P) the
enrolment by sending a confirmation letter (DF) that
they are registered for the course to the student.
OR
4. If the course is unavailable the student is sent a rejection
letter (DF).
Context Diagram or 0 Level
DFD
 1 Level DFD

External entity – Student

Processes - Check available, Enrol student, Confirm

Registration

Data Flows - Application Form, Course Details, Course

Enrolment Details, Student Details, Confirmation/Rejection
Letter

Data Stores - Courses, Students.

 Example: University Admissions

Application Rejection
Completed
form Receive application
application Evaluate
Applican
t Offer

33
 Example: University Admissions

Assemble Application Stage

Acknowledgmen Acknowledgme
t nt
Application Completed AND Evaluation
form application Initiate request
Receive
evaluation
Applican AND
t
Supporting
information

Pending Applicant
database database
34
 Example: University Admissions

Process Completed Application
Stage

Rejection

Evaluation
request Acceptance
Evaluation Financial Offer
aid

Special
request

Applicant
database
35
 A Telephone Call DFD

voice

Caller Receiver
* Telephone Call

Keyed phone
number

Level 01 DFD
voice A Telephone Call DFD(cont’d)
T1
Vibration to
signal Electronic signal

Switching
system Electronic
signal T2
Signal
To
Frequencies soun
Keypad vibration
& d
Electronics

Keyed phone number

Level 02 DFD
SOFTWARE REQUIREMENTS SPECIFICATION

38
Understand and specifying
requirements
 A problem of scale
 For small scale: understand and specifying
requirements is easy
 For large scale: very hard; probably the hardest,
most problematic and error prone

The requirements task:

 Input: User needs in minds of people (hopefully)
 Output: precise statement of what the future
system will do

45
Challenges

 Identifying and specifying requirements

 Necessarily involves people interaction
 Cannot be automated

46
Background..

 What is a Requirement?
 A condition or capability that must be
possessed by a system (IEEE)
 What is the work product of the Req. phase ?
 A software requirements specification (SRS)
document
 What is an SRS ?
 A complete specification of what the proposed
system should do!

47
Background..

 Requirements understanding is hard

 Visualizing a future system is difficult
 Capability of the future system not clear, hence
needs not clear
 Requirements change with time
 …
 Essential to do a proper analysis and
specification of requirements

48
Purpose of SRS document?

 SRS establishes basis of agreement

between the user and the supplier.
 Users needs have to be satisfied, but user may
not understand software
 Developers will develop the system, but may
not know about problem domain

 SRS is
 the medium to bridge the communications gap,
and
 specifies user needs in a manner both can
understand
49
Need for SRS…
 Helps user understand his needs.
 users do not always know their needs
 must analyze and understand the potential
 The requirement process helps clarify needs

 SRS provides a reference for validation of the

final product
 Clear understanding about what is expected.
 Validation - “ SW satisfies the SRS “

50
Need for SRS…

 High quality SRS essential for high Quality SW

 Requirement errors get manifested in final sw
 To satisfy the quality objective, must begin with
high quality SRS

 Requirements defects cause later problems

25% of all defects in one study; 54% of all defects
found after user testing
defects often found in previously approved SRS.

51
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

 An Example
 Cost of fixing errors in req. , design , coding ,
acceptance testing and operation are 2 , 5 , 15 ,
50 , 150 person-months
52
 Organization of SRS

1.
Introduction Purpose
1.1 Scope
1.2 Definition, Acronyms and
1.3 abbreviations
1.4 References
1.5 Overview
2. The Overall Description
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions for dependencies
2.6 Apportioning of requirements
3. Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design Constraints
3.6 Software System attributes
3.7 Organization of specific requirements
3.8 Additional Comments.

4. Others
Requirements/Information
INTRODUCTION
The Software Requirement Specification(SRS)
document provides an overview of the entire
SRS.
 Purpose:
Identify the purpose of SRS and its intended
audience.
 Scope:
I d e n t i f y t h e s o f t w a re p ro d u c t s t o b e
produced by name.
Explain what the software products will, and,
if necessary, will not do.
Describe the application of the software
being specif ied, including relevant benef its,
objective and goals
Be consistent with similar statement in
higher level specification if the exist.
INTRODUCTION CONTD……………….
Definition, Acronyms, and Abbreviations:
 Provide def inition of all terms, acronyms, and
abbreviations required to properly interpret the
SRS.
 This information may be provided by reference to
an appendix.
References:
Prov id e c o mplete list o f all d o c uments
referenced elsewhere in the SRS.
Identif ied each document by title, report number,
date, and publishing organization.
Specify the sources from which the reference can
be obtained.
INTRODUCTION CONTD……………….

Overview:
o Describe what the rest of the SRS contains.
o Explain how the SRS is organised.
THE OVERALL DESCRIPTION
Describe the general factors that affects the
product and its requirements.
Product Perspective:
 Put the product into perspective with other
related products.
 If the product is independent and totally self-
contained, it should be so stated here.
 If the SRS def ines a product that is a component
of a larger system, as frequently occurs, then it
relates the requirements of the larger system to
functionality of the software and identif ie s
interfaces between that system and the software.
THE OVERALL DESCRIPTION CONTD……
The following subsection describe how the software
operates inside various constraints:
System Interface:
 List each system interface and identify the
functionality of the software to accomplish the
system requirement.
 And the interface description to match the
system.
THE OVERALL DESCRIPTION CONTD……
Interfaces:
 It specify the logical characteristic of each
interface between the software product and its
users.
 All the aspects of optimising the interface with
the person who must use the system.
Hardware Interfaces:
 Specify the logical characteristics of each
interface between the software product and
hardware component of the system.
 This also includes configuration characteristics.
THE OVERALL DESCRIPTION CONTD……
Software interfaces:
 Specify the use of other software products and
interface with other application system.
 It includes
Name
Specification number
Version number
Source
THE OVERALL DESCRIPTION CONTD……
Communication Interfaces:
 Specify the various interfaces to
communications such as local network
protocols, etc.
Memory constraints:
 Specify any applicable characteristics and limits
on primary and secondary memory.
THE OVERALL DESCRIPTION CONTD……
Operations:
 Specify the normal and special operations
required by the users such as:
The various mode of operation in the user
organization.
Periods of interactive operations and periods
of unattended operations.
Data processing support functions
Backup and recovery operations
THE OVERALL DESCRIPTION CONTD……

Site Adaption Requirements:

 Def in e t h e req u i rem en t f or a n y d a t a or
initialization sequences that are specif ic to a
given site, mission, operational mode.
 Specify the site or mission related feature that
should be modif ied to adapt the software to a
particular installation.
PRODUCT FUNCTION
Provide a summary of the major functions that the
software will perform.
 The function should be organised in a way that
makes the list of functions understandable to the
c ust o m e r o r t o a ny o ne e l se re a d i ng t he
document for the first time.
 Textual or graphic methods can be used to show
the different function and their relationship.
USER CHARACTERISTICS
Describe those general characteristic of the
intended users of the product including educational
level, experience, and technical expertise
CONSTRAINTS
Provide a general description of any other items
that will limit the developer’s options. These can
include:
 Regulatory Policies
 Hardware Limitation
 Interface to other Application
 Parallel Operation
 Audit Function
 Control Function
 Higher Order Language Requirements
 Signal Handshake Protocols
 Reliability Requirements
 Criticality of the Application
 Safety and Security Considerations
ASSUMPTION AND DEPENDENCIES
List each of the factors that affects the
requirements stated in SRS
These factors are not designed constraints on the
software but, any change to them may that can
affect requirements in SRS.
APPORTIONING OF REQUIREMENTS
Identify requirements that may be delayed until
future version of the system.
SPECIFIC REQUIREMENTS
Specific requirements should be stated with all the
characteristics of the good SRS.
 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and stability
 Verifiable
 Modifiable
 Traceable
Specific requirement should be cross-referenced to
earlier documents that relate.
All requirements should uniquely identifiable.
Careful attention should be given to organising the
requirement to maximize readability.
EXTERNAL INTERFACE
This contains a detailed description of all the input
into and output from the software system.
It contains both content and format as follow:
 Name of item
 Description of purpose
 Source of input or destination of output
 Valid range, accuracy and tolerance
 Units of measure
 Timing
 Relationship to other Input/Outputs
 Screen formats
 Window formats
 Data formats
 Command formats
 End message
FUNCTIONS
Functional requirements def ines the fundamental
action that must take place in software in accepting
and processing the inputs and in processing and
generating the outputs. These includes:
 Validity checks on the inputs
 Exact sequence of operations
 Response to abnormal situation, including
Overflow
Communication facilities
Error handling and recovery
 Effects of parameters
 Relationship of output to inputs, including
Input/output Sequences
Formulas for input to output conversion.
PERFORMANCE REQUIREMENTS
This subsection specif ie s both the static and the
dynamic numerical requirements placed on the
software.
Static numerical requirements may include:
 The number of terminals to be supported.
 The number of simultaneous users to be supported.
 Amount and types of information to be handled.

Dynamic numerical requirements may include:

 Number of transactions and tasks and the amount of
data to be processed within certain time periods for
both normal and peak workload conditions.
LOGICAL DATABASE REQUIREMENTS
This section specifies the logical requirements for
any information that is to be placed into a database.
This may include:
 Types of information used by various functions
 Frequency of use
 Accessing capabilities
 Data entities and their relationship
 Integrity constraints
DESIGN CONSTRAINTS
Specify design constraints that can be imposed by
other standards, hardware limitations, etc.
Standard Compliance:
 Specify the requirements derived from existing
standards or regulations.
 Report format
 Data naming
 Accounting procedure
 Audit tracing
SOFTWARE SYSTEM ATTRIBUTES
There are a number of quality attribute of software
that can serve as requirements.
Reliability:
Specify the factor required to establish the
required reliability of the software system at time
of delivery.
Availability:
 Specify the factors required to guarantee a
def ined availability level for the entire system
such as check point, recovery and restart.
SOFTWARE SYSTEM ATTRIBUTES CONTD……
Security:
 Spe c ify the fac to r that wo uld pro te c t the
software form accidental or malicious access,
use, modif ication, destruction. This may include
need to:
Utilizing certain cryptographic techniques
Keep specific lo or history data sets
Assign certain functions to different modules
Restrict communication between some areas
of the program
Check data integrity for critical variable
SOFTWARE SYSTEM ATTRIBUTES CONTD……
Maintainability:
 Specify attribute of software that relate to the
ease of maintenance of software itself.
 There may be some requirement for certain
modularity, interface, complexity, etc.
Portability:
 Specify attributes of software that relates to
the ease of parting the software to other host
machine and operating systems. This may
include:
Percentage of component with host dependent
code
Percentage of code that is host dependent
Use of a proven portable language
Use of a particular compiler
Use of a particular operating system.
ORGANISING THE SPECIFIC REQUIREMENTS
System Mode:
 Some system behave quite differently depending
on the mode of operation. There are two possible
outlines.
 The choice depends on whether interfaces,
 Performance are dependent on mode.
User Class:
Some system provide different sets of functions to
different class of users.
Objects:
 Object are real world entities that have a counterpart
within the system.
 Associated with each object is a set of attributes and
functions.
 The se funct i ons a re ca l l e d se r v i ce s, m e t hods, or
processes.
ORGANISING THE SPECIFIC REQUIREMENTS CONTD…
Feature:
 A feature is an externally desired service by the
system that may require a sequence of inputs
to effect the desired result.
 Each feature is described as sequence of
stimulus-response pairs.
Stimulus:
 S om e s y s tem ca n be bes t orga n is ed by
describing their functions in terms of stimuli.
Response:
 S o m e s y s t e m c a n b e b e s t o r g a n i s e d by
describing their function in support of the
generation of the response.
CHANGE MANAGEMENT PROCESS:
 Specify the change management process to be
used to identify, log, evaluate, and update the
SRS to reflect changes in project scope and
requirement.
DOCUMENT APPROVAL
Identify the approvers of the SRS documents.
Approver’s name, signature, and date should be
used.
SUPPORTING INFORMATION

The supporting information makes the SRS easier

to use. It includes:
 Table of contents
 Index
 Appendices
SRS
 1.0 INTRODUCTION
This document specifies all the requirements
for
 1.1 Purpose

The purpose of the …is to ….

The system should assist ….
The intended audience for this document is …
This specification describes …..
 1.2 Scope

This document applies only to …...

93
SRS
1.3 Definitions, Acronyms, and Abbreviations
SRS - Software Requirements Specifications
IEEE - Institute of Electrical and Electronic Engineering
1.4 Reference

[1] IEEE 830-1993: IEEE Recommended Practice for

Software Requirements Specifications" IEEE Standards
Collection, IEEE, 1997.
1.5 Overview

In the following sections of this specification……will be

presented.
In Section 2, the general product and its functions will
be introduced.
94
SRS
In Section 3, all detailed requirements will be specified
and grouped.
In Appendix …….
2.0 GENERAL DESCRIPTION
2.1 Product Perspective
This system allows stakeholders to…..
The system will display…..
The system will help ……
The system provides information about ….
2.2 Product Functions
The system provides the following functions:
95
SRS
 2.3 User Characteristics
The users of the system are:
• Level of Users’ Computer Knowledge

• Level of Users’ Business Knowledge

• Frequency of Use

 2.4 General Constraints

The system will support ….

The system will not allow ……
 2.5 Assumption and Dependencies

This system relies on ……

The system must have a satisfactory interface and ……
96
 SRS
 SPECIFIC REQUIREMENTS

3.1 Functional Requirements

3.1.1 Unit Registration
 The unit registration requirements are concerned with functions
regarding unit registration which includes students selecting, adding,
dropping, and changing a unit.
 SRS-001 (3.1.1.1):
 The system shall allow the user to register a unit.
 SRS-002 (3.1.1.2):
 System shall allow the user to delete a unit if the user has chosen to drop that
unit.
 SRS-003 (3.1.1.3):
 System shall check if a unit has been filled by enough registered students.

97
 SRS
 SRS-004 (3.1.1.4):
 System shall allow the user to add his/her name to the unit waiting
list if the user wants to register in a unit which has been filled
already with enough registered students.
 SRS-005 (3.1.1.5):
 System shall automatically register the unit for the user who is the
first one on the waiting list if a vacancy appears for that unit.
 SRS-006 (3.1.1.6):
 System shall allow the user to change practical session(s) within
a unit.
 SRS-007 (3.1.1.7):
 System shall allow the user to change tutorial session(s) within a
unit.

98
 SRS
 3.1.2 Retrieving and Displaying Unit Information
 The retrieving and displaying requirements are concerned
with how information is retrieved and presented to the user.
 SRS-014 (3.1.2.1):
 The system shall allow users to enter the following
selection criteria to retrieve unit information: by unit code,
by unit number, by title of unit, by weight of unit (credit
points).
 OR by unit code (3.1.2.1.1) , by unit number (3.1.2.1.2) , by
title of unit (3.1.2.1.3) , by weight of unit (credit points)
(3.1.2.1.4).

99
 SRS
 3.2 Design Constraints
 SRS-031 (3.2.1):
 System shall store and retrieve persistent data.
 SRS-032 (3.2.2):
 System shall support PC and/or UNIX platforms.
 SRS-033 (3.2.3):
 System shall be developed using the JAVA
programming language

100
 SRS
 3.3 Non-Functional Requirements
 SRS-034 (3.3.1):
 System shall respond to any retrieval in less than 5
seconds.
 SRS-035 (3.3.2):
 System shall generate a report within 1 minute.
 SRS-036 (3.3.3):
 System shall allow the user to remotely connect to the
system.
 SRS-041 (3.3.8):
 The system will be accompanied by a comprehensive
user manual. 101
 3.5.3 Security
 The security requirements are concerned with security and
privacy issues.
SRS-029:
 System shall provide staff ID and password verification
protection to protect from unauthorised use of the system.
SRS-030:
 System shall allow the store manager to add, remove and

modify staff ID and passwords as required.

102
Use Cases & Use Case Diagram

Introduction
 “Invented” by Ivar Jacobson in the late 1960’s
 Introduced to the OO community in the late
1980’s
 Alistair Cockburn has extended Jacobson’s
model
 Is a way to specify functional requirements
 Is not part of the Unified Modeling Language
(UML), but is many times used in conjunction
with it

104
 Use Cases

l What is a Use Case

 A formal way of representing how a
business system interacts with its
environment
 Illustrates the activities that are
performed by the users of the system
 A sequence of actions a system performs that
yields a valuable result for a particular actor.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide105
 Use Case Analysis

l What is an Actor?
• A user or outside system that interacts
with the system being designed in order
to obtain some value from that
interaction
l Use Cases describe scenarios that describe
the interaction between users of the system
(the actor) and the system itself.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide106
 Use Cases Diagrams

l Use case diagrams describe what a system

does from the standpoint of an external
observer. The emphasis is on what a system
does rather than how.

l Use case diagrams are closely connected to

scenarios. A scenario is an example of what
happens when someone interacts with the
system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide107
108
109
 Use Cases Diagrams

Student Result Management System

110
 Student Result Management System
1. manage information about subjects offered in
various semester,
2. students enrolled in various semester,
3. elective (s) opted by various students in different
semester,
4. marks and credit points obtained by students in
different semesters.
5. The system should also have the ability the
printable mark-sheets for each student.
6. S e m e s t e r - w i s e m a r k l i s t a n d s t u d e n t
performance report also need to be generated.

111
112
113
114
115
116
 Use Case Diagram

for

Railway Reservation System

117
Use Case Diagram For Railway Reservation system

118