Software Engineering

B.Tech IT/II Sem-II

Term: 2008-2009
Unit-3 PPT SLIDES
Text Books:1.Software Engineering, A practitioners approach
Roger s. Pressman 6th edition McGraw-Hill
2.Software Engineering Somerville 7th edition
No. of Slides:43
1

UNIT 3 SYLLABUS
Requirements engineering process :
Feasibility studies, Requirements elicitation and
analysis, Requirements validation,
Requirements management.
System models : Context Models, Behavioral
models, Data models, Object models, structured
methods.

S.No

Topic

INDEX
Unit-3 PPTS
Lecture No

PPTSlides

Requirement Engineering
Process -Feasibility Studies
Requirements Elicitation &
analysis

L1

Requirement Validation

L2

20

Requirements Management

L3

22

System Models-Context Model

L4

29

Behavioral Models

L5

32

Data Models

L6

36

Object Models & structured

Models

L7

39

REQUIREMENTS ENGINEERING PROCESS

To create and maintain a system requirement document
The overall process includes four high level requirements
engineering sub-processes:
1.Feasibility study
--Concerned with assessing whether the system is
useful to the business
2.Elicitation and analysis
--Discovering requirements
3.Specifications
--Converting the requirements into a standard form
4.Validation
-- Checking that the requirements actually define the
system that the customer wants
4

The requirements engineering process

Feasibility
study

Requirements
elicitation and
analysis

Requirements
specification
Requirements
validation

Feasibility
report
System
models
User and system
requirements

Requirements
document

SPIRAL REPRESENTATION OF REQUIREMENTS

ENGINEERING PROCESS

Process represented as three stage activity

Activities are organized as an iterative process around a
spiral.
Early in the process, most effort will be spent on
understanding high-level business and the user
requirement.
Later in the outer rings, more effort will be devoted to
system requirements engineering and system modeling
Three level process consists of:
1.Requirements elicitation
2. Requirements specification
3. Requirements validation
6

Requirements engineering

FEASIBILITY STUDIES
Starting point of the requirements engineering process
Input: Set of preliminary business requirements, an
outine description of the system and how the system is
intended to support business processes
Output: Feasibility report that recommends whether or
not it is worth carrying out further
Feasibility report answers a number of questions:
1.Does the system contribute to the overall objective
2.Can the system be implemented using the current
technology and within given cost and schedule
2.Can the system be integrated with other system which
are already in place.
8

REQUIREMENTS ELICITATION
ANALYSIS
Involves a number of people in an organization
Stakeholder definition
-- Refers to any person or group who will be affected by
the system
directly or indirectly i.e. End
users,Engineers,business managers, domain experts.
Reasons why eliciting is difficult
1.Stakeholder often dont know wht they want from the
computer system.
2.Stakeholder expression of requirements in natural
language is sometimes difficult to understand.
3.Different stakeholders express requirements differently
4.Influences of political factors
Change in requirements due to dynamic environments.
9

REQUIREMENTS ELICITATION
PROCESS
Proces activities
1.Requirement Discovery

-- Interaction with stakeholder to collect their requirements

including domain and documentation
2.Requirements classification and organisation

-- Coherent clusteing of requirements from unstructured

collection of requirements
3. Requirements prioritization and negotiation

-- Assigning priority to requirements

--Resolves conflicting requirements through negotiation

Requiremnts documentation
-- Requirements be documented and placed in the next
round of spiral
10

The spiral representation of

Requirements Engineering

11

REQUIEMENTS DICOVERY
TECHNIQUES

1. View points
--Based on the viewpoints expressed by the stake holder
--Recognizes multiple perspectives and provides a framework for
discovering conflicts in the requirements proposed by different
stakeholders
Three Generic types of viewpoints
1.Interactor viewpoint
--Represents people or other system that interact directly with the
system
2.Indirect viewpoint
--Stakeholders who influence the requirements, but dont use the
system
3.Domain viewpoint
--Requirements domain characteristics and constraints that influence
the requirements.
12

REQUIREMENTS DISCOVERY TECHNIQUES

2. Interviewing
--Puts questions to stakeholders about the system
that they use and the system to be developed.
--Requirements are derived from the answers
Two types of interview
Closed interviews where the stakeholders answer a
pre-defined set of questions.
Open interviews discuss a range of issues with the
stakeholders for better understanding their needs.
Effective interviewers
a) Open-minded: no pre-conceived ideas
b) Prompter: prompt the interviewee to start
discussion with a question or a proposal

13

REQUIREMENTS DISCOVERY TECHNIQUES

3. Scenarios

--Easier to relate to real life examples

than to
abstract description

--Starts with an outline of the interaction and during

elicitation, details are
added to create a
complete description
of that interaction

--Scenario includes:

1. Description at the start of the scenario

2. Description of normal flow of the event

3. Description of what can go wrong and how this is

handled

4.Information about other activities parallel to the

scenario

5.Description of the system state when the scenario

finishes
14

LIBSYS scenario
Initial assumption: The user has logged on to the LIBSYS system
and has located the journal containing the copy of the article.
Normal: The user selects the article to be copied. He or she is then
prompted by the system to either provide subscriber information for
the journal or to indicate how they will pay for the article. Alternative
payment methods are by credit card or by quoting an organisational
account number.
The user is then asked to fill in a copyright form that maintains details
of the transaction and they then submit this to the LIBSYS system.
The copyright form is checked and, if OK, the PDF version of the
article is downloaded to the LIBSYS working area on the users
computer and the user is informed that it is available. The user is
asked to select a printer and a copy of the article is printed

15

LIBSYS scenario

What can go wrong: The user may fail to fill in the copyright form
correctly. In this case, the form should be re-presented to the user
for correction. If the resubmitted form is still incorrect then the users
request for the article is rejected.
The payment may be rejected by the system. The users request for
the article is rejected.
The article download may fail. Retry until successful or the user
terminates the session..
Other activities: Simultaneous downloads of other articles.
System state on completion: User is logged on. The downloaded
article has been deleted from LIBSYS workspace if it has been
flagged as print-only.

16

REQUIREMENTS DISCOVERY TECHNIQUES

4. Use cases
-- scenario based technique for requirement
elicitation
-- A fundamental feature of UML, notation for
describing object-oriented system models
-- Identifies a type of interaction and the actors
involved
-- Sequence diagrams are used to add
information to a Use case
17

Article printing use-case

Article printing

18

LIBSYS use cases

Article search

Library
User

Article printing

User administration

Supplier

Library
Staf

Catalogue services

19

REQUIREMENTS VALIDATION
Concerned with showing that the requirements define the system that the
customer wants.
Important because errors in requirements can lead to extensive rework cost
Validation checks
1.Validity checks

--Verification that the system performs the intended function by the user
2.Consistency check

--Requirements should not conflict

3. Completeness checks

--Includes requirements which define all functions and

constraints
intended by the system user
4. Realism checks

--Ensures that the requirements can be actually implemented

5. Verifiability

-- Testable to avoid disputes between customer and developer.

20

VALIDATION TECHNIQUES
1.REQUIREMENTS REVIEWS
--Reviewers check the following:

(a) Verifiability: Testable

(b) Comprehensibility

(c) Traceability

(d) Adaptability
2.PROTOTYPING
3.TEST-CASE GENERATION
21

Requirements management
Requirements are likely to change for large software
systems and as such requirements management process
is required to handle changes.
Reasons for requirements changes
(a) Diverse Users community where users have different
requirements and priorities
(b) System customers and end users are different
(c) Change in the business and technical environment
after installation
Two classes of requirements
(a) Enduring requirements: Relatively stable requirements
(b) Volatile requirements: Likely to change during system
development process or during operation
22

Requirements evolution
Initial
understanding
of problem

Initial
requirements

Changed
understanding
of problem

Changed
requirements
Time
23

Requirements management planning

An essential first stage in requirement management process

Planning process consists of the following
1.Requirements identification
-- Each requirement must have unique
tag for cross
reference and traceability
2.Change management process
-- Set of activities that assess the impact and cost of changes
3.Traceability policy
-- A matrix showing links between requirements and other
elements of software development
4.CASE tool support
--Automatic tool to improve efficiency of change management
process. Automated tools are required for requirements storage,
change management and traceability management

24

Traceability

Maintains three types of traceability

information.
1.Source traceability
--Links the requirements to the stakeholders
2. Requirements traceability
--Links dependent requirements within the requirements
document
3. Design traceability
-- Links from the requirements to the design module

25

A traceability matrix

26

Requirements change management

Consists of three principal stages:
1. Problem analysis and change specification
-- Process starts with a specific change
proposal
and analysed to verify that it
is valid
2.Change analysis and costing
--Impact analysis in terms of cost, time and
risks
3. Change implementation
--Carrying out the changes in requirements
document, system design and its implementation

27

Change management
Identified
problem Problem analysis and
change specification

Change analysis
and costing

Change
implementation

Revised
requirements

28

SYSTEM MODELS
Used in analysis process to develop understanding of
the existing system or new system.
Exclude details
An abstraction of the system
Types of system models
1.Context models
2. Behavioural models
3.Data models
4.Object models
5.Structured models
29

CONTEXT MODELS

A type of architectural model

Consists of sub-systems that make up an entire system
First step: To identify the subsystem
Represent the high level architectural model as simple
block diagram
Depict each sub system a named rectangle
Lines between rectangles indicate associations between
subsystems
Disadvantages
--Concerned with system environment only, doesn't take
into account other systems, which may take data or give
data to the model
30

The context of an ATM system

Security
system
Branch
accounting
system

Account
database
Auto-teller
system

Branch
counter
system

Usage
database
Maintenance
system

31

Behavioral models

Describe the overall behaviour of a system.

Two types of behavioural model
1.Data Flow models
2.State machine models
Data flow models
--Concentrate on the flow of data and functional
transformation on that data
--Show the processing of data and its flow through a
sequence of processing steps
--Help analyst understand what is going on
Advantages
-- Simple and easily understandable
-- Useful during analysis of requirements

32

Insulin pump DFD

Blood

Blood
parameters
Blood sugar
sensor

Blood sugar
analysis

Blood sugar
level
Insulin
requirement
computa
tion

Insulin

Pump contr
ol
commands
Insulin
pump

Insulin
delivery
controller

Insulin
requirement

33

State machine models

Describe how a system responds to internal or external
events
Shows system states and events that cause transition
from one state to another
Does not show the flow of data within the system
Used for modeling of real time systems
Exp:Microwave oven
Assumes that at any time, the system is in one of a
number of possible states
Stimulus triggers a transition from on state to another state
Disadvantage
-- Number of possible states increases rapidly for large
system models

34

Microwave oven model

Full
pow er

Full power
do: set power
= 600
Timer

Waiting
do: display
time

Half
power

Number
Full
power
Half
power

Set time

Operation

do: get number

exit: set time

do: operate
oven

Door
closed

Timer
Door
open
Half power
do: set power
= 300

Enabled
Door
closed

Cancel

Start

do: display
'Ready'

Door
open

Waiting
do: display
time

Disabled
do: display
'Waiting'

35

DATA MODELS
Used to describe the logical structure of data
processed by the system.
An entity-relation-attribute model sets out the
entities in the system, the relationships between
these entities and the entity attributes
Widely used in database design. Can readily be
implemented using relational databases.
No specific notation provided in the UML but
objects and associations can be used.
36

Library semantic model

Article
Article
title
title
authors
authors
pdffile
pdffile
fee
fee

1
delivers
delivers
n

n
Order
Order
ordernumber
ordernumber
totalpayment
totalpayment
date
date
taxstatus
taxstatus
n
n
places
1 places
1
Buyer
Buyer
name
name
address
address
email
email
billinginfo
billinginfo

Source
Source
title
m
title
m
n publisher
publisher
issue
feepayableto
1 date
issue
feepayableto
1 date
pages
pages
1
1
in
1
in
1
1
1
Country
Copyright
Country
Copyright 1
Agency
1
Agency
1 inin 1 copyrightform
name
copyrightform
taxrate
name
haslinks
address
taxrate
haslinks
address
publishedin
publishedin n

37

Data dictionary entries

38

OBJECT MODELS

An object oriented approach is commonly used for interactive

systems development
Expresses the systems requirements using objects and developing
the system in an object oriented PL such as c++
A object class: AN abstraction over a set of objects that identifies
common attributes
Objects are instances of object class
Many objects may be created from a single class
Analysis process
-- Identifies objects and object classes
Object class in UML
--Represented as a vertically oriented rectangle with three sections
(a) The name of the object class in the top section
(b) The class attributes in the middle section
(c) The operations associated with the object class are in lower
section.
39

OBJECT MODELS
INHERITANCE MODELS
A type of object oriented model which involves in object
classes attributes
Arranges classes into an inheritance hierarchy with the
most general object class at the top of hierarchy
Specialized objects inherit their attributes and services
UML notation
-- Inheritance is shown upward rather than downward
--Single Inheritance: Every object class inherits its
attributes and operations from a single parent class
--Multiple Inheritance: A class of several of several
parents.
40

Hierarchy of class
Library item
Catalogue number
Acquisition da
te
Cost
Type
Status
Number ofcopies
Acquir
e ()
Catalogue ()
Dispose ()
Issue ()
Return ()

Published item
Title
Publisher

Book
Author
Edition
Publication date
ISBN

Magazine
Year
Issue

Recorded item
Title
Medium

Film
Director
Date of release
Distrib
utor

Computer
program
Version
Platform

41

OBJECT MODELS
OBJECT AGGREGATION
-- Some objects are grouping of other objects
-- An aggregate of a set of other objects
-- The classes representing these objects may be
modeled using an object aggregation model
-- A diamond shape on the source of the link
represents the composition
OBJECT-BEHAVIORAL MODEL
-- Shows the operations provided by the objects
-- Sequence diagram of UML can be used for
behavioral modeling
42

Object aggregation
Study pack
Course title
Number
Year
Instructor

OHP slides

Assignment
Credits

Exercises
#Problems
Description

Slides

Lecture
notes
Text

Videota
pe
Tape ids.

Solutions
Text
Diagrams

43

OBJECT BEHAVIORAL MODEL

Ecat:
Catalog

:Library Item

Lib1:
NetServer

:Library User

Lookup
Display
Issue
Issue licence
Accept licence
Compress

Deliver

44