Chapter 2

Modeling with UML

UML

• What is UML?
• A more detailed view on
 Use case diagrams
 Class diagrams
 Sequence diagrams
 Activity/Statecharts diagrams

2
UML Basic Notation
 UML provides a wide variety of notations for
modeling many aspects of software systems
 UML diagrams cover the three fundamental
models for software design:
• Functional model: Use case diagrams
• Object model: Class diagrams
• Dynamic model: Sequence diagrams, statechart diagram

3
UML
• Use case diagrams
• Describe the functional behavior of the system as seen
by the user
• Class diagrams
• Describe the static structure of the system: Objects,
attributes, associations
• Sequence diagrams
• Describe the dynamic behavior between objects of the
system
• Statechart diagrams
• Describe the dynamic behavior of an individual object
• Activity diagrams
• Describe the dynamic behavior of a system, in
particular the workflow.
4
UML Use Case
Diagram

5
UML :Use case diagrams
Classifier
Use
Case

Actor
.

System
boundary

Use case diagrams represent the functionality of the

6
system from user’s point of view
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
UML Use Case Diagrams
Used during requirements elicitation
and analysis to represent external
behavior (“visible from the outside of
the system”)
An Actor represents a role, that is,
a type of user of the system
Passenger
A use case represents a class of
functionality provided by the system

Use case model:

The set of all use cases that
PurchaseTicket completely describe the
functionality of the
system.

7
Actors
 An actor is a model for an
external entity which interacts
(communicates) with the system:
• User
• External system (Another system)
• Physical environment (e.g. Weather)

Passenger • An actor has a unique name and an

optional description Optional
• Examples: Description
• Passenger: A person in the train
• GPS satellite: An external system that
Name
provides the system with GPS
coordinates.

8
 Use
 A use case represents a class of
Case
functionality provided by the
system
 Use cases can be described
textually, with a focus on the
event flow between actor and
system
PurchaseTicket  The textual use case description
consists of 6 parts:
1. Unique name
2. Participating actors
3. Entry conditions
4. Exit conditions
5. Flow of events
6. Special requirements.
9
Textual Use Case
Description PurchaseTicket
Example Passenger

1. Name: Purchase 5. Flow of events:

ticket 1.Passenger selects the
2. Participating actor: number of zones to be
Passenger traveled
2.Ticket Distributor displays
3. Entry condition:
the amount due
 (GOOD) Passenger 3.Passenger inserts
selects an option from the money, at least the
display amount due
 (WRONG) Passenger 4.Ticket Distributor returns
stands in front of ticket change
distributor 5.Ticket Distributor issues
 (Very WRONG) ticket
Passenger has sufficient 6. Special requirements:
money to purchase ticket None.
4. Exit condition:
• Passenger
Bernd Bruegge & Allen H. Dutoit has ticket
Object-Oriented Soft 10

• (Better): System
delivered ticket
Use Cases can be related

• Extends Relationship
• To represent seldom invoked use cases or exceptional
functionality
• Includes Relationship
• To represent functional behavior common to more than
one use case.

11
 The <<extends>>
• <<extends>>
Relationship model exceptional or seldom
relationships
invoked cases
• The exceptional event flows
Passenger are factored out of the main
event flow for clarity
• The direction of an
<<extends>> relationship is
PurchaseTicket to the extended use case
• Use cases representing
<<extends>> exceptional flows can extend
more than one use case.
<<extends>>
<<extends>>
OutOfOrder <<extends>> TimeOut

Cancel NoChange
12
 The <<includes>> Relationship
 <<includes>>
relationship represents
common functionality
needed in more than one
Passenger use case
• <<includes>> behavior is
PurchaseMultiCard factored out for reuse, not
because it is an exception
PurchaseSingleTicket • The direction of a
<<includes>> <<includes>> relationship
<<includes>> is to the using use case
(unlike the direction of the
<<extends>> relationship).
CollectMoney
<<extends>> <<extends>>
<<extends>>

NoChange Cancel TimeOut

13
Use Case Models can be packaged
Classifier
Use
Case

Actor
.

System
boundary

14
Historical Remark: UML 1 used
packages
Package
Course

GiveLecture
Instructor

HoldExercise
Student

Teaching DoHomework
Assistent

15
UML Class
Diagram

16
 UML: Class diagrams

Associatio
n Clas
s
Multiplici
Simple
ty Watch
2 1 1 1 1 1 2 1
PushButton Display Battery Time

Class diagrams represent the structure of the

system
17
UML : Class diagrams
Class diagrams represent the structure of the
system
Association
Class
Multiplicity Watch
1 1 1
2
1 1 2 1
PushButton
state LCDDisplay Battery Time
push() blinkIdx Load Now
release() blinkSeconds()
blinkMinutes()
blinkHours()
stopBlinking()
Operations
Attribut referesh()
e
18
Class Diagrams

 Class diagrams represent the structure of

the system
• Used
• during requirements analysis to model application
domain concepts
• during system design to model subsystems
• during object design to specify the detailed behavior
and attributes of classes.

TarifSchedule
Trip
Table zone2price
zone:Zone
* Price: Price
Enumeration
getZones()
Price getPrice(Zone) 19
*
Classe Typ
s e TarifSchedule Table
zone2price
Enumeration getZones()
Name Price getPrice(Zone)
TarifSchedule
zone2price Attribute Signature
getZones() s
getPrice()
Operation TarifSchedule
s
• A class represents a concept
• A class encapsulates state (attributes) and behavior
(operations)
Each attribute has a type
Each operation has a signature

The class name is the only mandatory information

20
Actor vs Class vs Object

• Actor
• An entity outside the system to be modeled,
interacting with the system (“Passenger”)
• Class
• An abstraction modeling an entity in the application or
solution domain
• The class is part of the system model (“User”, “Ticket
distributor”, “Server”)
• Object
• A specific instance of a class (“Joe, the passenger who
is purchasing a ticket from the ticket distributor”).

21
Instances

tarif2006:TarifSchedule :TarifSchedule
zone2price = { zone2price = {
{‘1’, 0.20}, {‘1’, 0.20},
{‘2’, 0.40}, {‘2’, 0.40},
{‘3’, 0.60}} {‘3’, 0.60}}

• An instance represents a phenomenon

• The attributes are represented with their values
• The name of an instance is underlined
• The name can contain only the class name of the
instance (anonymous instance)

22
Associations

TarifSchedule

TripLeg

Price
Zone
*
Enumeration
getZones() *
Associations denote relationships
Price getPrice(Zone) between classes

The multiplicity of an association end denotes how many

objects the instance of a class can legitimately reference.

23
1-to-1 and 1-to-many Associations

Countr City
y 1

name:St 1 name:St
ring ring

1-to-1 association

Point
Polygo
n *
x:

draw() Integer
y:
Integer
1-to-many association
24
 Many-to-many Associations

StockExchange * Company

*
Lists

tickerSymbol

• A stock exchange lists many companies.

• Each company is identified by a ticker symbol

25
From Problem Statement To Object
Model
Problem Statement: A stock exchange lists many companies.
Each company is uniquely identified by a ticker symbol.

Class Diagram:

* * Company
StockExchange
Lists

tickerSymbol

26
From Problem Statement to Code
Problem Statement : A stock exchange lists many
companies. Each company is identified by a ticker symbol

Class Diagram:
StockExchange * * Company
Lists tickerSymbol

Java Code
public class StockExchange
{
private Vector m_Company = new Vector();
Associations
};
are mapped to
public class Company
{ Attributes!
private int m_tickerSymbol;
private Vector m_StockExchange = new Vector();
};
27
 Qualifiers

Without qualification
File
Directory 1
*
With qualification filename

1 0..1
Directory filename File

 Qualifiers can be used to reduce the

multiplicity of an association

28
Qualification: Another Example

Company
StockExchange * Lists
*
tickerSymbol
Company
StockExchang * Lists
e
* tickerSymbo
l
StockExchange
*
tickerSymbol
Lists 1
* Company

29
 Aggregation
• An aggregation is a special case of association
a “consists-of” hierarchy
denoting Exhaust
• The aggregate is the parent class, system
the components are the children classes

1 0..
2
Muffler Tailpipe
diameter diamet
er
A solid diamond denotes composition: A strong form of
aggregation where the life time of the component instances
is controlled by the aggregate. That is, the parts don’t exist
on their won (“the whole controls/destroys the parts”)
TicketMachine

3
ZoneButton
30
Inheritance

Button

CancelButton ZoneButton

 Inheritance is another special case of an

association denoting a “kind-of” hierarchy
 Inheritance simplifies the analysis model by
introducing a taxonomy
 The children classes inherit the attributes
and operations of the parent class.
31
Association class

32
Ternary associations

33
Packages
 Packages help you to organize UML models
to increase their readability
 We can use the UML package mechanism to
organize classes into subsystems

Account

Bank Customer

 Any complex system can be decomposed into

subsystems, where each subsystem is modeled as
a package.
34
Object Modeling in Practice

CUS
TOM
ER1
Amount
Custome
rId
Deposit()
Withdra
w()
GetBalan
ce()

Class Identification: Name of Class, Attributes and

Methods

35
Object Modeling in Practice:
Brainstorming
“Ann” Foo

Amount Amount
Customer CustomerI
Id d
Deposit() Deposit()
Withdraw( Withdraw(
) ) Accou
GetBalanc GetBalanc
e() e() nt
Amount
Custome
rId
Deposit()
Withdra
w()
GetBalan
ce()
36
Object Modeling in Practice: More
classes
Accou
nt
Custom
Amount
Bank er
Account
Customer
IdId Name
Name Deposit() Custome
Withdra rId
w()
GetBalan
ce()
1)Find New Classes
2)Review Names, Attributes and
Methods

37
Object Modeling in Practice:
Associations
Accou
nt
Custom
Bank
? * Amount
* own
er
ha Account
Customer
s IdId s Name
2
Name Deposit() Custome
Withdra rId
w()
GetBalan
ce()
1)Find New Classes
2)Review Names, Attributes and
Methods
3)Find Associations between Classes
4)Label the generic assocations
5)Determine the multiplicity of the
assocations
38

6)Review associations
Practice Object Modeling: Find
Taxonomies
Bank
Accou
Custome
nt
r
* Amount * Ha Name
Name Account
Customer s
IdId
Deposit()
Withdra Customer
w()
Withdra Id()
w()
GetBalan
ce()
Saving Checki Mortga
s ng ge
Accoun Accoun Accou
t t nt

Withdra Withdra Withdra

39
w() w() w()
Practice Object Modeling: Simplify,
Organize Account

Amount Show Taxonomies

AccountI
Customer
Id
d separately
Deposit()
Withdraw(
)
GetBalanc
e()

Saving Checki Mortga

s ng ge
Accoun Accoun Accou
t t nt

Withdra Withdra Withdra

40
w() w() w()
Practice Object Modeling: Simplify,
Organize
Bank
Accou
Custome
nt
r
* Amount * Ha Name
Name Account
Customer s
IdId
Deposit() Customer
Withdra Id()
w()
GetBalan
ce()

Use the 7+-2 heuristics

or better 5+-2!

41
UML Sequence
Diagram

42
UML first pass: Sequence diagram
Lifelin
Actor Message
e
Object :LCDDisplay :Time
pressButton1() blinkHours()
:WatchUser :Watch
pressButton1()
blinkMinutes()
pressButton2()
incrementMinutes()
refresh()

pressButton1and2()
commitNewTime()
stopBlinking()
Activatio
n
Sequence diagrams represent the behavior of a
system as messages (“interactions”) between
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43

different objects
 Sequence Focus on
Controlflow
Diagrams
• Used during analysis
TicketMachine
Passenger • To refine use case descriptions
selectZone() • to find additional objects
(“participating objects”)
• Used during system design
to r
TicketMachine efine• subsystem interfaces
insertCoins()
zone2price
• Insta n ces are
selectZone() rectan repMreessseangteesd->by
insertCoins() g les. participating
pickupChange() pickupChange() figures ActorsObObjectpyersattiiocnksy
pickUpTicket() es are on represented by
• lines
 Lifelin
Messages are represented
dashed
by arrows
pickUpTicket()
 Activations are
represented by narrow
rectangles. 44
Scenarios, use case and
sequence diagrams
 A scenario is an instance of a use case
describing a concrete set of actions (no
alternative paths are in it)
 A use case is an abstraction that describes
all possible scenarios involving the described
functionality.
 Scenarios are used as examples for
illustrating common cases;
• their focus is on understandability.
 Use cases are used to describe all possible
cases;
• their focus is on completeness.

45
How to describe scenarios

 We describe a scenario using a template with

three fields:
• The name of the scenario enables us to refer to it
unambiguously. The name of a scenario is underlined
to indicate that it is an instance.
• The participating actor instances field indicates
which actor instances are involved in this scenario.
Actor instances also have underlined names.
• The flow of events of a scenario describes the
sequence of events step by step.

46
Scenario: an example

47
Sequence Diagrams can also
model the Flow of Data

ZoneButton TarifSchedule Display

Passenger
selectZone()
lookupPrice(selection)

price
displayPrice(price)
Dataflo
w …continued on next slide...
 The source of an arrow indicates the activation which
sent the message
 Horizontal dashed arrows indicate data flow, for
example return results from a message

48
 Sequence Diagrams: Iteration &
Condition …continued from previous
slide...
ChangeProcessor CoinIdentifier Display CoinDrop
Passenger

*insertChange(coin) lookupCoin(coin)

price
Iteratio displayPrice(owedAmount)
n
[owedAmount<0] returnChange(-owedAmount)
Condition
…continued on next slide...

• Iteration is denoted by a * preceding the message name

• Condition is denoted by boolean expression in [ ]
before the message name

49
 Creation and destruction
…continued from previous
slide...
ChangeProcessor
Passenger Creation of
Ticket
createTicket(selection)

Ticket
print()

free()
Destruction of
Ticket

• Creation is denoted by a message arrow pointing to the object

• Destruction is denoted by an X mark at the end of the
destruction activation
• In garbage collection environments, destruction can be used to
denote the end of the useful life of an object.
50
Message Types

• Asynchronous
• Synchronous
• Call and Object creation
• Reply
• Lost
• Found

51
Sequence Diagram Properties

 UML sequence diagram represent behavior

in terms of interactions
• Useful to identify or find missing objects
• Time consuming to build, but worth the
investment
• Complement the class diagrams (which
represent structure).

52
Chapter 3: UML DIAGRAM

53
Interaction Diagrams

55
Interaction Diagrams
• Four types of interaction diagrams:
• Sequence diagrams
• Communication diagrams
• Interaction overview diagrams
• Timing diagrams

• The basic building block of an interaction diagram

is the interaction.
• An interaction is a unit of behavior that focuses on
the observable exchange of information between
connectable elements.
56
Example of an Interaction: Sequence
Diagram

57
UML Sequence Diagram with Alternative
Paths
This sequence diagram visually represents a decision-making process in object interactions,
where different actions are taken depending on the value of x.

58
UML Sequence Diagram with Alternative
Paths

● Alternative Interaction (alt): Used to define mutually exclusive interaction

sequences based on conditions.

● Interaction Constraint: [x>0] and else determine which sequence executes.

● Execution Specification: The rectangular bars indicate actions being

performed.

● Messages: Represent communication between objects.

59
Example of a Critical Region
Problem statement: The telephone Operator must make sure to forward a 911-call
from a Caller to the Emergency system before doing anything else. Normal calls
can be freely interleaved.

60
Key Characteristics of Critical
Regions

●Atomic Execution: All messages within the critical region are executed
sequentially without interruption.​

●Mutual Exclusivity: Ensures that no other interactions can interleave with the
critical region, preserving consistency.​

61
UML Statechart
Diagram

62
 Purpose of Statechart Diagrams
∙ Used to model the dynamic nature of a system. They define different
states of an object during its lifetime and these states are changed by
events.

∙ Statechart diagrams are useful to model the reactive systems.

Reactive systems can be defined as a system that responds to
external or internal events.

∙ States are defined as a condition in which an object exists and it

changes when some event is triggered.

∙ The most important purpose of Statechart diagram is to model

lifetime of an object from creation to termination.
Before drawing a Statechart diagram we
should identify the following points:

∙ 1) Identify the important objects to be

analyzed.
∙ 2) Identify the states.
∙ 3) Identify the events.
 State diagrams and
states
∙ State diagrams are used to give an abstract
description of the behaviour of a system.
∙ This behaviour is analysed and represented as a
series of events that can occur in one or more
possible states.
∙ A state represents a step in the behaviour pattern
of an object
• It is a configuration of the set of state-attributes of the
behaving object
∙ Transition from one state to another is triggered by 65

events
• An event may be either internal or external to the object
UML first pass: Statechart Wrong
state, It’s an
diagrams
Event Initial state action!!

button2Pressed
button1&2Presse Blink Increment
Hour displayRefreshe Hours
d s
d
Transition button1Pressed

button1&2Presse button2Pressed
Blink Increment
d Minutes Minutes
State displayRefreshe
d
button1Pressed

Stop Blink button2Presse Increment

Blinking Second Seconds
s d displayRefreshe
Final state d

Represent behavior of a single object with

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 66

interesting dynamic behavior.

68
Statechart for the Incident class

69
State machine diagram for
watch

70
 State machine diagram for
watch
States:
SetTime: The device is in the time-setting mode.
MeasureTime: The device is in the time-measuring mode.
DeadBattery: The device stops functioning due to an empty battery.

Transitions:
pressBothButtons: Transitions between SetTime and MeasureTime.
after 2 min.: Automatically switches from SetTime to MeasureTime after 2 minutes.
pressBothButtons/beep: A button press triggers a beep and moves the device to
DeadBattery.
batteryEmpty: If the battery is empty, the system moves to the DeadBattery state.

71
Internal transitions in Watch
statechart

72
Review: UML Statechart Diagram
Notation
Event with parameters Action Name
ofState
attr
State1 Event State2
do/Activity Event(attr) [condition]/action
entry /action
Guard
exit/action
condition

Actions and Activities in State

• Note:
• Events are italics
• Conditions are enclosed with brackets:
[]
• Actions are prefixed with a slash / 73
 Example of Concurrency within an
Object Nested states
Splitting Synchronization
control
Emitting
Do/Dispense
Cash Cash
taken

Setting Up Ready to
Read reset
y do/Eject
Card
Card
taken

Nested diagrams: a portion of behavior is specified by a

statechart within an higher level state 74
State diagram

Exit??
?

75
UML Activity Diagram

76
UML Activity Diagrams
An activity diagram consists of nodes and edges
• Nodes describe activities and objects
• Control nodes
• Executable nodes
• Most prominent: Action
• Object nodes
• E.g. a document
• Edge is a directed connection between nodes
• There are two types of edges
• Control flow edges
• Object flow edges

77
 Activity
∙
diagrams
In activity diagrams transitions from node to node happen
automatically upon completion of activities
• Transitions do not depend upon the arrival of events as it
happens in statecharts
∙ Activity diagrams represent the UML notation for the well
known flowchart
∙ Each node in a flowchart represents an action to be
executed.
• So it is not a state, but when applied to the program's state, it
results in a transition to another state.
78
 State vs Activity diagram

action1

test=1 test=0
E2[test=0]/
E2[test=1]/action2 action4 action2 action4

s
4
action3

Statechart Activity diagram

(flowchart)
79
 Activity Diagrams: Grouping of
∙Activities
Activities may be grouped into
swimlanes to denote the object or subsystem
that implements the activities.
Allocate Dispatcher
Resources

Open Coordinate Archive

Incident Resources Incident

Field Officer
Document
Incident

80
Activity Diagrams
 State Chart Diagrams vs Activity
∙Diagrams
An activity diagram that contains only
activities can be seen as a special case of a
state chart diagram
∙ Such an activity diagram is useful to describe
the overall workflow of a system

82
Statechart Diagram vs Activity
Diagram
Statechart Diagram for Incident
Focus on the set of attributes of a single abstraction (object,
system) Event causes
state transition
Active Inactive
Closed Archived
Incident- Incident- Incident-
Handled Documented Archived

Activity Diagram for Incident

(Focus on actions performed and dataflow in a system)

Triggerless
Completion of activity
transition
causes state transition 83
 Object Diagram
● Derived from class diagrams.

● Represents a snapshot of a system at a

particular moment.

● Differs from class diagrams (which represent

abstract models of classes and relationships).
Class Diagram
Object Diagram
 Object Diagram

The purpose of the object diagram are:

●Object relationships of a system

●Static view of an interaction.

●Understand object behaviour and their relationship

from practical perspective
UML Summary
∙ UML provides a wide variety of notations for
representing many aspects of software
development
• Powerful, but complex

• Notations:
• Functional model: Use case diagram
• Object model: Class diagram
• Dynamic model: Sequence diagrams, Statechart and
Activity diagrams.

89
 Exercises

1. Design the Activity Diagram for an Online Shopping System.

2. Design the Activity Diagram for an Train Ticket System.

3. Design the Object Diagram for N Online Shopping System.

Online Shopping -Activity Diagram
Train Ticket System
- Activity Diagram
Chapter 4: Introduction to
Project Management
Introduction to Project Management

● Definition: Planning and controlling system development

● Importance of managing time, cost, and functionality
● Role of a project manager
● Challenges in project management

94
 What is Project Management?
A project is an interrelated set of activities
that has a definite starting and ending point
and that results in a unique product.
(service)
■ Management is typically viewed as
focused on the planning,
organization, and control of
continuous processes or activities.

Apr 1, 2025
 Process vs. Project Work

Process Project
• Ongoing, day-to-day ⚫ Take place outside the
activities to produce normal, process-oriented
goods and services world
• Use existing systems, ⚫ Unique and separate
properties, and from routine, process-
capabilities driven work
• Typically repetitive ⚫ Continually evolving
 Characteristics of Project

• A one-time focus
• A specific purpose and a desired result
• A start and a finish
• A time frame for completion
• A limited set of resources
• A logical sequence of interdependent activities
• A clear user(customer, client) of the result

Apr 1, 2025
 Elements of Project Planning
● Define project objective(s)
● Identify activities
● Establish precedence relationships
● Make time estimates
● Determine project completion time
● Compare project schedule objectives
● Determine resource requirements to meet
objective

Apr 1, 2025
 Project Success Rates

• Software & hardware projects fail at a 65% rate,

• Only 30% of technology-based projects and
programs are a success.
• Only 2.5% of global businesses achieve 100%
project success and over 50% of global business
projects fail,
• Average success of business-critical application
development projects is 32%.
“Trade Off” Triangle”

PROJE
CT
RISK
Feasibility Analysis Overview

● Purpose: Evaluate project viability

● Types: Technical, Economic, Organizational
● Impact on project selection
● Decision-making process

101
Technical Feasibility

● Assessing technical capabilities

● Evaluating existing infrastructure
● Understanding development risks
● Compatibility with current systems

102
Economic Feasibility

● Cost-benefit analysis
● Return on Investment (ROI)
● Net Present Value (NPV)
● Break-even analysis

103
Organizational Feasibility

● Alignment with business strategy

● Stakeholder support
● Organizational structure impact
● Change management considerations

104
 The Project Team

■ Project team typically consists of a group of individuals from

various areas in an organization and often includes outside
consultants.
■ Members of engineering staff often assigned to project work.
■ Project team may include workers.
■ Most important member of project team is the project
manager.
■ Project manager is often under great pressure because of
uncertainty inherent in project activities and possibility of
failure. Potential rewards, however, can be substantial.
■ Project manager must be able to coordinate various skills of
team members into a single focused effort.
Apr 1, 2025
 Project Manager Responsibilities

■ Selecting a team
■ Developing project objectives and a plan for
execution
■ Performing risk management activities
■ Cost estimating and budgeting
■ Scheduling
■ Managing resources
 Steps in Managing a Project
Steps in Managing a Project

Define the problem

Develop solution options

Plan the Project : what must be done ?, who will do it?, How will it be done ?
How much will it cost? ,what do we need to do?

Execute the plan

Monitor & Control Progress

Close Project
What was done well?
What should be improved?

Apr 1, 2025
 Project Life Cycles
Man Hours

Conceptualization Planning Execution Termination

Project Life Cycle Stages

 Project Life Cycle

Apr 1, 2025
 Project Life Cycle

Apr 1, 2025
Project Life Cycles and Their
Effects

Project Life Cycles and Their Effects

Elements of Project Management
Work Breakdown Structure (WBS)
■ WBS breaks down project into major components (modules).

■ Modules are further broken down into subcomponents,

components, activities, and finally, into individual tasks.

■ Identifies activities, tasks, resource requirements and

relationships between modules and activities.

■ Helps avoid duplication of effort.

■ Basis for project development, management , schedule

resources and modifications.

■ Approaches for WBS development:

1. Top down process 2. Brainstorm entire project
Apr 1, 2025
 Work Breakdown Structure

Apr 1, 2025 Dr.Bokkasam Sasidhar

Elements of Project Management
Work Breakdown Structure

WBS for computerized order-processing system project

Elements of Project Management
Project Scheduling
■ Project schedule evolves from planning documents, with focus
on timely completion.

■ Critical element in project management – source of most

conflicts and problems.

■ Schedule development steps:

1. Define activities, 2. Sequence activities,
3. Estimate activity times, 4. Develop schedule.

■ Gantt chart and CPM/PERT techniques can be useful.

■ Computer software packages available, e.g. Microsoft Project.

Apr 1, 2025
Elements of Project
Management
Gantt
■ Chart
Popular, traditional technique, also known as a bar chart -
developed by Henry Gantt (1914).

■ Direct precursor of CPM/PERT for monitoring work progress.

■ A visual display of project schedule showing activity start

and finish times and where extra time is available.

■ Suitable for projects with few activities and precedence

relationships.

■ Drawback: precedence relationships are not always

discernible which limits chart’s use for smaller projects
Apr 1, 2025
 Gantt Chart

• Visual scheduling tool

• Graphical representation of information
• Show dependencies between tasks,
personnel, and other resources
allocations
• Track progress towards completion

Apr 1, 2025
 Building a Gantt Chart
• List all tasks and milestones from the
project along the vertical axis
• List time frame along the horizontal axis
Activity 1
Activity 2
Milestone

Time Frame: day 1 day 2 day3

Apr 1, 2025
 Building a Gantt Chart
• Activities: Create box the length of each activity time
duration
– E.g., activity one is scheduled from day1-day3

Activity 1
Activity 2

Time Frame: day 1 day 2 day3

Apr 1, 2025
 Building a Gantt Chart
• Dependencies: Show dependencies between
activities with arrows
– E.g., activity 2 cannot start until activity 1 is complete

Activity 1
Activity 2

Time Frame: day 1 day 2 day3…

Apr 1, 2025
 Gantt Charts
✔ Establish a time-phased network
✔ Can be used as a tracking tool

Benefits of Gantt charts

1. Easy to create and comprehend
2. Identify the schedule baseline network
3. Allow for updating and control
4. Identify resource needs
Gantt Charts

122
Gantt Charts
Database Subsystem

123
Network Diagram
• Also known as PERT chart or PERT/CPM chart
• Illustrates task relationships
• Used to determine the critical path
• Software such as Microsoft Project can be used to
create a network diagram.
Network Diagram
Network Diagram: Activity on
Arrow
• Alternative method
• More difficult to read and understand
• May require the creation of dummy activities when a
task has multiple predecessors and multiple dependent
tasks
• More “mathematical” in its illustration of activities and
events.
Network Diagram compared to
Gantt
• Network diagram is more technical, helps determine
the critical path
• Network diagram is not to a scaled timeline
• Gantt is easy to read and explain to non-technical
people
• Gantt has a good method for graphically illustrating
task progress and whether things are ahead of
schedule or behind
Project constraints
• Cost
• Scope
• Quality
• Risk
• Resources
• Time
Interpersonal Skills in Project
Management
• Understanding the project environment
• Business goals and user needs, Market & Industry
Trends, Competitor Landscape, Economic & Social
Factors

• Interpersonal skills
• Communication,
• Leadership,
• Motivation ,
• Negotiation ,
• Problem solving.
 Computer-Aided Software Engineering

CASE tools – Analysis &

Design
Design tools
Information repository tools
Program development tools
Software Engineers
Custom Programs

Courtesy of Federal
Express Corporation.
All rights reserved.
 CASE Tool Kit Contains
Design tools
User interface
Screen generator
Layout
Report generator
Information repository tools
Cross-referencing system (database)
Packages system documentation
Program development tools
Application Generator
Generation of text data
 Exercise
1. Compare and contrast the Gantt chart
with the net-work diagram.

2. What are the components and disadvantages for

WBS?

3. Create a Gantt Chart for the project of building a

simple web application.
List the tasks for Gantt Chart:

A. Planning & Analysis

Task 1: Requirements gathering (2 days)

Task 2: System design (3 days)

Task 3: Define project architecture (2 days)

B. System Design

Task 4: Create UI design (3 days)

Sub-task 4.1: Create wireframes (1 day)

Sub-task 4.2: Design UI components (2 days)

Task 5: Develop GUI pages (7 days)

Sub-task 5.1: Create login page (2 days)

Sub-task 5.2: Create dashboard page (3 days)

Sub-task 5.3: Create admin panel page (2 days)

 List the tasks for Gantt Chart:

C. Backend Development

Task 6: Set up server and database (4 days)

Task 7: Develop API endpoints (5 days)

Sub-task 7.1: Create user authentication endpoints (2 days)

Sub-task 7.2: Create data handling endpoints (3 days)

D. Testing
Task 8: Unit testing (4 days)

Task 9: Integration testing (3 days)

Task 10: User acceptance testing (2 days)

E. Delivery of the web application

Task 11: Final Testing & Bug Fixes (3 days)

Task 12: Launch the web application in the live environment with proper setup and configuration.
(3 days)
 Exercise
U3. Create a Gantt Chart for the project of building a simple web application.
Design the Class Diagram for the Train Ticket
Reservation System
Assignment: Design the Activity and Statechart
Diagram for the Train Ticket Reservation System
Object-Oriented Software Engineering
Using UML, Patterns, and Java
Dynamic Modeling
Chapter 5, Analysis:
Outline of the Lecture

• Dynamic modeling
• Interaction Diagrams
• Sequence diagrams
• Communication diagrams
• State diagrams
• Requirements analysis model validation
• Analysis Example

139
Overview of Analysis
Dynamic Modeling

• Definition of a dynamic model:

• Describes the components of the system that have
interesting dynamic behavior
• The dynamic model is described with
• State diagrams: One state diagram for each class with
interesting dynamic behavior
• Classes without interesting dynamic behavior are
not modeled with state diagrams
• Sequence and communication diagrams: For the
interaction between classes
• Purpose:
• Identify new classes in the object model and supply
operations for the classes.
141
UML Interaction Diagrams

• Two types of interaction diagrams:

• Communication Diagram:
• Shows the temporal relationship among objects
• Position of objects is identical to the position of the
classes in the corresponding UML class diagram
• Good for identifying the protocol between objects
• Does not show time
• Sequence Diagram:
• Describes the dynamic behavior between several
objects over time
• Good for real-time specifications.

142
Example of a Communication
Diagram
1) We start with the Class Diagram for 2Bwatch

2) Then we look at the sequence of events when Joe sets the time
on 2Bwatch

Joe:2BwatchOwner
1:pressButtons1And2()
2:pressButton1()
3:pressButton2() 1.1:blinkHours()
4:pressButtons1And2() 2.1:blinkMinutes()
4.2:stopBlinking()
:2BwatchInput :2BwatchDisplay

3.1:incrementMinutes()
4.1:commitNewTime()

3.2:refresh()
:2BwatchTime

143
Identify Classes and Operations
∙ We have already established several
sources for class identification:
• Application domain analysis: We find classes by talking
to the client and identify abstractions by observing the
end user
• General world knowledge and intuition
• Textual analysis of event flow in use cases (Abbot)
∙ Two additional heuristics for identifying
classes from dynamic models:
• Actions in state chart diagrams are candidates for public
operations in classes
• Activity lines in sequence diagrams are candidates for
objects.

144
How do we detect Operations?

∙ We look for objects, who are interacting

and extract their “protocol”
∙ We look for objects, who have interesting
behavior on their own
∙ Good starting point: Flow of events in a
use case description
• From the flow of events we proceed to the
sequence diagram to find the participating
objects.

145
How do we detect Operations?

∙ We look for objects, who are interacting

and extract their “protocol”
∙ We look for objects, who have interesting
behavior on their own
∙ Good starting point: Flow of events in a
use case description
• From the flow of events we proceed to the
sequence diagram to find the participating
objects.

146
 Event and participating objects

• Something that happens at a point in time

• An event sends information from one object to
another
• Events can have associations with each other:
• Causally related:
• An event happens always before another event
• An event happens always after another event
• Causally unrelated:
• Events that happen concurrently
Heuristic for finding participating objects:
• A event always has a sender and a receiver
• Find the sender and receiver for each event => These are the
objects participating in the use case.

147
An Example

• Flow of events in “Get SeatPosition” use case :

1. Establish connection between smart card

and onboard computer

2. Establish connection between onboard

computer and sensor for seat

3. Get current seat position and store on smart card

• Where are the objects?

148
 Sequence Diagram for “Get SeatPosition”
Smart Card Onboard Computer Seat

1. Establish
connection Establish Connection
between smart card Establish Connection
and onboard
computer

2. Establish
connection Accept Connection
between onboard
computer and seat
(actually seat Accept Connection
sensor)

3. Get current seat Get SeatPosition

position and store
on smart card. “500,575,300”
time
149
 Heuristics for Sequence Diagrams
∙ Layout:
1st column: Should be the actor of the use case
2nd column: Should be a boundary object
3rd column: Should be the control object that
manages the rest of the use case
∙ Creation of objects:
∙ Create control objects at beginning of event flow
∙ The control objects create the boundary objects
∙ Access of objects:
∙ Entity objects can be accessed by control and
boundary objects
∙ Entity objects should not access boundary or control
objects. 150
 Heuristics for Sequence Diagrams
● Entity objects represent the persistent information
tracked by the system.
● Boundary objects represent the interactions
between the actors and the system.
● Control objects are in charge of realizing use cases.

● In the 2Bwatch example, Year, Month, and Day are

entity objects;
● Button and LCDDisplay are boundary objects;

● ChangeDateControl is a control
151
Is this a good Sequence Diagram?
Smart Card Onboard Computer Seat
The first
column is Establish Connection
not an actor
Establish Connection
It is not
clear where
the
boundary Accept Connection
object is

It is not Accept Connection

clear where
the control
object is Get SeatPosition
“500,575,300
”
152
 Analysis Activities: From Use Cases to Objects

The activities that transform the use cases and scenarios produced
during requirements elicitation into an analysis model.

Analysis activities include:

• Identifying Entity Objects

• Identifying Boundary Objects
• Identifying Control Objects
• Mapping Use Cases to Objects with Sequence Diagrams
 Analysis Activities: From Use Cases to Objects

Analysis activities include:

• Modeling Interactions among Objects with CRC Cards

Identifying Associations
• Identifying Aggregates
• Identifying Attributes
• Modeling State-Dependent Behavior of Individual Objects
Another Example: Finding Objects from a
Sequence Diagram
∙ Let’s assume ARENA’s object model contains -
at this modeling stage – the following six objects
• League Owner, League, Tournament, Match and Player

League
Owner 1 League
*
Attributes Attributes

Operations Operations

Tournament

Attributes
Operations

Player * Match

Attributes * Attributes

155
Operations Operations
ARENA Sequence Diagram: Create
Tournament
:Tournament :Arena :League
Boundary
League
Owner

newTournament
(league)
:Announce
«new» Tournament
Control
checkMax
Tournament()
setName(name)

setMaxPlayers
(maxp)

commit() create
createTournament Tournament
(name, maxp) «new»
(name, maxp) :Tournament

156
Impact on Arena’s Object Model
League
Owner League
1 *
Attributes Attributes

Operations Operations
Arena Tournament_
Boundary
Attributes
Attributes
Operations
Operations Tournament

Announce_ Attributes
Tournament_ Operations
Control

Attributes
Operations

Player Match
*
*
Attributes Attributes

Operations Operations
157
 Impact on ARENA’s Object Model (2)

∙ The sequence diagram also supplies us with

many new events
• newTournament(league)
• setName(name)
• setMaxPlayers(max)
• commit
• checkMaxTournament()
• createTournament

∙ Question:
• Who owns these events?
∙ Answer:
• For each object that receives an event there is a public operation
in its associated class
• The name of the operation is usually the name of the
event. 158
Example from the Sequence Diagram

:Tournament :Arena :League

Boundary
League
Owner

newTournament
(league)

:Announce
«new» Tournament
Control
checkMax
Tournament()
setName(name)

setMaxPlayers
(maxp)

commit() create
createTournament Tournament
(name, maxp) «new»
(name, maxp) :Tournament

159
 League 1 * League
Owner
Attributes Attributes

Operations Operations
Tournament_
Boundary
Arena Attributes
Operations
Attributes
Tournament
Operations
Announce_
Tournament_ Attributes
Control Operations
Attributes
createTournamen
t (name, maxp)

Player *
* Match

Attributes Attributes

Operations Operations 160

 What else can we get out of
Sequence Diagrams?
• Sequence diagrams are derived from use cases
• The structure of the sequence diagram helps
us to determine how decentralized the system is
• We distinguish two structures for sequence
diagrams (Fork & Stair Diagram)

161
 Fork Diagram
• The dynamic behavior is placed in a single object,
usually a control object
It knows all the other objects and often uses them for direct
questions and commands

Control
Object

Object-Orinted Software Engineering: Using UML, Patterns, and Java 32

e
Stair Diagram

∙ The dynamic behavior is distributed. Each

object delegates responsibility to other objects
• Each object knows only a few of the other objects and
knows which objects can help with a specific behavior

163
Fork or Stair?

∙ Object-oriented supporters claim that the stair

structure is better
• Modeling Advice:
• Choose the stair - a decentralized control structure - if
• The operations have a strong connection
• The operations will always be performed in the
same order
• Choose the fork - a centralized control structure - if
• The operations can change order
• New operations are expected to be added as a
result of new requirements.

164
Review: UML Statechart Diagram
Notation
Name of
Action
Event with parameters attr State

State1 Event
(attr) [condition]/action State2
do/Activity
entry /action Guard
exit/action condition

• Note: Actions and Activities in State

• Events are italics
• Conditions are enclosed with brackets: []
• Actions are prefixed with a slash /
• UML statecharts are based on work by Harel
• Added are a few object-oriented modifications.

165
Example of a StateChart Diagram

coins_in(amount) / set balance

Collect Money
Idle
cancel / refund coins
coins_in(amount) / add to balance

[item empty] [select(item)] [change<0]

do/Test item and compute change

[change=0] [change>0]

do/Dispense item do/Make change

166
Dynamic Modeling of User Interfaces

∙ Statechart diagrams can be used for the

design of user interfaces
• States: Name of screens
• Actions are shown as bullets under the
screen name

167
Navigation Path Example
Screen name

Action
Diagnostics Menu
∙User moves cursor to Control Panel or
Graph
Control panel Graph
∙User selects functionality of ∙User selects data group
sensors
and type of
Define
graph
∙User defines a sensor event
Selection
from a list of
∙User selects data group
events Enable Disable
∙Field site
∙User can enable ∙User can disable a
∙Car
a sensor event sensor event from
from a list of ∙Sensor group
a list of sensor events
sensor events ∙Time range

168
Model Validation and Verification

∙ Verification is an equivalence check

between the transformation of two models
∙ Validation is the comparison of the model
with reality
• Validation is a critical step in the development
process Requirements should be validated with
the client and the user.
• Techniques: Formal and informal reviews
(Meetings, requirements review)
∙ Requirements validation involves several
checks
• Correctness, Completeness, Ambiguity, Realism

169
Checklist for a Requirements Review

• Is the model correct?

• A model is correct if it represents the client’s view of
the system
• Is the model complete?
• Every scenario is described
• Is the model consistent?
• The model does not have components that
contradict each other
• Is the model unambiguous?
• The model describes one system, not many
• Is the model realistic?
• The model can be implemented

170
 Verification vs Validation of models

System Object Implemen- Design

Analysis
Design tation
R M M M M
Impl
Analysis System Object
fR f f f f
MA MS MD Impl
R M M M M
Impl
Analysis System Object
Validation Verificati Verificati
Verification on on

M M
fM
I I
R R
fR
171
Checklist for a Requirements
Review (2)

• Syntactical check of the models

• Check for consistent naming of classes,
attributes, methods in different subsystems
• Identify dangling associations (“pointing to
nowhere”)
• Identify double- defined classes
• Identify missing classes (mentioned in one
model but not defined anywhere)
• Check for classes with the same name but
different meanings

172
Requirements Analysis Document
Template
1. Introduction
2. Current system
3. Proposed system
1. Overview
2. Functional requirements
3. Nonfunctional requirements
4. Constraints (“Pseudo requirements”)
5. System models
1. Scenarios
2. Use case model
3. Object model
1. Data dictionary
2. Class diagrams
4. Dynamic models
5. User interfae
4. Glossary

173
System Models

Scenarios
- As-is scenarios, visionary scenario
Use case model
-Actors and use cases
Object model
- Data dictionary
- Class diagrams (classes, associations, attributes and
operations)
Dynamic model
- State diagrams for classes with significant dynamic
behavior
- Sequence diagrams for collaborating objects (protocol)
User Interface
- Navigational Paths, Screen mockups
174
 Requirements Analysis
Questions
1. What are the transformations? Functional Modeling
Create scenarios and use case diagrams
- Talk to client, observe, get historical records
2. What is the structure of the Object Modeling
system? Create class diagrams
- Identify objects.
- What are the associations between them?
- What is their multiplicity?
- What are the attributes of the objects?
- What operations are defined on the
objects?
3. What is its behavior?
Dynamic Modeling
Create sequence diagrams
- Identify senders and
- Show sequence of events exchanged between
receivers
objects.
- Identify event dependencies and event concurrency.
Create state diagrams
- Only for the dynamically interesting objects. 175
Let’s Do Analysis: A Driving Car
Example
• Analyze the problem statement
• Identify functional requirements
• Identify nonfunctional requirements
• Identify constraints (pseudo requirements)
• Build the functional model:
• Develop use cases to illustrate functional requirements
• Build the dynamic model:
• Develop sequence diagrams to illustrate the
interaction between objects
• Develop state diagrams for objects with interesting
behavior
• Build the object model:
• Develop class diagrams for the structure of the system
176
Problem Statement:
Direction Control for a Driving Car

• Power is turned on • Power is turned off

• Car moves forward and car • Car stops and
headlight shines headlight goes out
• Power is turned off • Power is turned on
• Headlight shines
• Car stops and headlight
goes out.
• Power is turned off
• Headlight goes out
• Power is turned on
• Power is turned on
• Headlight shines
• Power is turned off • Car runs forward with
its headlight shining
• Headlight goes out
• Power is turned on
• Car runs backward with its
headlight shining

177
Find the Functional Model: Use Cases
• Use case 1: System Initialization
• Entry condition: Power is off, car is not moving
• Flow of events:
1. Driver turns power on
• Exit condition: Car moves forward, headlight is on

• Use case 2: Turn headlight off

• Entry condition: Car moves forward with headlights on
• Flow of events:
1. Driver turns power off, car stops and headlight goes out.
2. Driver turns power on, headlight shines and cardoes not
move.
3. Driver turns power off, headlight goes out
• Exit condition: Car does not move, headlight is out

178
Use Cases continued

• Use case 3: Move car backward

• Entry condition:Car is stationary, headlights off
• Flow of events:
1. Driver turns power on
• Exit condition: Car moves backward, headlight on

• Use case 4: Stop backward moving car

• Entry condition: Car moves backward, headlights on
• Flow of events:
1. Driver turns power off, car stops, headlight goes
out.
2. Power is turned on, headlight shines and car does
not move.
3. Power is turned off, headlight goes out.
• Exit condition: Car does not move, headlight is out

179
Use Cases Continued

• Use case 5: Move car forward

• Entry condition:Car does not move, headlight is out
• Flow of events
1. Driver turns power on
• Exit condition:
• Car runs forward with its headlight shining

180
Dynamic Modeling:
Create the Sequence Diagram
• Name: Drive Car
• Sequence of events:
• Billy turns power on
• Headlight goes on
• Wheels starts moving forward
• Wheels keeps moving forward
• Billy turns power off
• Headlight goes off
• Wheels stops moving
• ...

181
Driving Car: Dynamic Model
Wheel
Headlight
Forward
Off power
power off
on
power power
off on

Stationary Stationary
On

power power
on
off

Backward

182
Toy Car: Object Model

Car

Power Headlight Wheel

Status: (On, Off) Status: (On, Off) Motion: (Forward,

Backward
TurnOn() Switch_On() ,
TurnOff() Switch_Off()
Stationary
)
Start_Moving()
Stop_Moving()

183
 Project Deliverables
❑ Define Problem Statements and Objectives
❑ Requirements Elicitation ( Requirements Analysis Document)
❑ Feasibility Analysis
❑ Gantt Chart
❑ Analysis Model( Use- case, Class and Object Diagram, Dynamic
Modelling)
❑ Design the model (Hardware & Software specification,
Software Architecture)
❑ Implementation (Coding in (Java, Python) Database
development)
❑ Testing (Unit, Integrated and Final)
❑ Release the product (Application, Manual & training)
Object-Oriented Software Engineering
Using UML, Patterns, and Java

Elicitation
Requirements
Chapter 6
Outline

• Software Lifecycle
• Requirements elicitation
challenges
• Problem statement
• Requirements specification
• Types of requirements
• Validating requirements

1
8
6
Software Lifecycle Definition
• Software lifecycle
• Models for the development of software
• Set of activities and their dependency
relationships to each other to support
the development of a software system
• Examples:
• Analysis, design, implementation,
testing
• Design depends on analysis, testing
can be done before implementation

1
8
7
Software Lifecycle Activities

Requireme Analysis System Detaile Impleme Testin

nts Design d n- g
Elicitatio Design tation
n

Use
Case
Model
1
8
8
 ...and their
Software Lifecycle Activities
models

Requireme Analysis System Detaile Impleme Testin

nts Design d n- g
Elicitatio Design tation
n

Expressed in
terms of

Applicati
Use
on
Case Domain
Model Objects
1
8
9
Software Lifecycle Activities

Requireme Analysis System Detaile Impleme Testin

nts Design d n- g
Elicitatio Design tation
n

Expressed in Structured
terms of by

Use Applicati
on Sub
Case
Mod Domai
-
syste
el n
ms
Objec 1
9
ts 0
Software Lifecycle Activities

Requireme Analysis System Detaile Impleme Testin

nts Design d n- g
Elicitatio Design tation
n

Expressed in Structured Realized by

terms of by

Applicati Solutio
Use
on Sub- n
Case Domain syste Domai
Model Objects n
ms
8
Object
s
Software Lifecycle Activities

Requireme Analysis System Detaile Impleme Testin

nts Design d n- g
Elicitatio Design tation
n

Implemented by
Expressed in Structured Realized by
terms of by

class...
class...
class...
Applicati Solutio
Use Sour
on Sub- n
Case Domain ce
syste Domai
Model Objects n Code
ms
1
Object 9
s 2
Software Lifecycle Activities

Requireme Analysis System Detaile Impleme Testin

nts Design d n- g
Elicitatio Design tation
n

Implemented by
Expressed in Structured Realized by
by Verified
terms of
By
class...
class... ?
class... class.?.
Applicati Solutio
Use Sour
on Sub- n ..Test
Case Domain ce Case
syste Domai
Model Objects n Code Mod
ms
Object el 1
9
s 3
Software Lifecycle Activities

Requireme Analysi System Detaile Impleme Testin

nts s Design d n- g
Elicitatio Design tation
n
Implemented
Expressed in Structured By By
Realized By
Terms Of Verified
By
class...
class...
class... ?
class....
Application ?
Use Solutio
Domai Subsyste Sour Test
Case n
n ms ce Case
Model Domai
Objec Cod Model
n 1
ts e
Object 9
4
s
First step in identifying the
Requirements: System identification
• Two questions need to be answered:
1. How can we identify the purpose of a system?
• What are the requirements, what are the constraints?
2. What is inside, what is outside the system?
• These two questions are answered during
requirements elicitation and analysis
• Requirements elicitation:
• Definition of the system in terms understood by
the customer and/or user (“Requirements specification”)
• Analysis:
• Definition of the system in terms understood by the
developer (Technical specification, “Analysis model”)
• Requirements Process: Consists of the activities
1
Requirements Elicitation and Analysis. 9
5
Techniques to elicit Requirements

∙ Bridging the gap between end user and

developer:
• Questionnaires: Asking the end user a list of pre-
selected questions
• Task Analysis: Observing end users in their
operational environment
• Scenarios: Describe the use of the system as a series
of interactions between a specific end user and the
system
• Use cases: Abstractions that describe a class of
scenarios.

1
9
6
Scenarios
• Scenario

• A synthetic description of an event or series of

actions and events
• A textual description of the usage of a system. The
description is written from an end user’s point of view
• A scenario can include text, video, pictures and story
boards. It usually also contains details about the work
place, social situations and resource constraints.

1
9
7
More Definitions

∙ Scenario: “A narrative description of

what people do and experience as they try to
make use of computer systems and
applications”
• [M. Carroll, Scenario-Based Design, Wiley, 1995]
• A concrete, focused, informal
description of a single feature of the system
used by a single actor
• Scenario become the basis of interaction for a new
design or allow better understanding of the new
design.

1
9
8
Scenario-Based
Design
Scenarios can have many different uses during the
software lifecycle
• Requirements Elicitation: As-is scenario, visionary
scenario
• Client Acceptance Test: Evaluation scenario
• System Deployment: Training scenario
Scenario-Based Design: The use of scenarios in a
software lifecycle activity
• Scenario-based design is iterative
• Each scenario should be consisered as a work
document to be augmented and rearranged (“iterated
upon”) when the requirements, the client acceptance
criteria or the deployment situation changes.

1
9
9
Scenario-based Design

∙ Focuses on concrete descriptions and

particular instances, not abstract generic ideas
• It is work driven not technology driven
• It is open-ended, it does not try to be complete
• It is informal, not formal and rigorous
• Is about envisioned outcomes, not about
specified outcomes.

2
0
0
Types of Scenarios

• As-is scenario:
• Describes a current situation. Commonly used in re-
engineering projects. The user describes the system.
• Example: Description of Letter-Chess
• Visionary scenario:
• Describes a future system
• Example: Home Computer of the Future
• Often used in greenfield engineering and interface
engineering projects
• Example: Description of an interactive internet-
based Tic Tac Toe game tournament
• Visionary scenarios are often not done by the user or
developer alone.
2
0
1
Additional Types of
Scenarios (2)
• Evaluation scenario:
• Description of a user task against which the system is
to be evaluated.
• Example: Four users (two novice, two experts) play
in a TicTac Toe tournament in ARENA.
• Training scenario:
• A description of the step by step instructions that guide
a novice user through a system
• Example: How to play Tic Tac Toe in the ARENA
Game Framework.

2
0
2
How do we find scenarios?

∙ Don’t expect the client to be verbose if

the system does not exist
• Client understands the application domain (problem
domain), not the solution domain
∙ Don’t wait for information even if the
system exists
• “What is obvious does not need to be said”
• Engage in a dialectic approach
• You help the client to formulate the requirements
• The client helps you to understand the requirements
• The requirements evolve while the scenarios are being
developed.

2
0
3
Heuristics for finding scenarios
• Ask yourself or the client the following questions:
• What are the primary tasks that the system needs to
perform?
• What data will the actor create, store, change, remove or
add in the system?
• What external changes does the system need to know
about?
• What changes or events will the actor of the system need
to be informed about?
• However, don’t rely on questions and
questionnaires alone
• Insist on task observation if the system
already exists (interface engineering or
reengineering) 2
• Ask to speak to the end user, not just to the client 0
4
•
Requirements Elicitation:
Difficulties and Challenges
∙ Accurate communication about the
domain and the system
• People with different backgrounds must collaborate to
bridge the gap between end users and developers
• Client and end users have application domain
knowledge
• Developers have solution domain knowledge
∙ Identification of an appropriate system
(Definition of the system boundary)
• Provision of an unambiguous specification
• Leaving out unintended features
=> 3 Examples.
2
0
5
 Requirements
Process :problem
statement

Requirements Requirements
elicitation Specification

:nonfunctional
requirements

:functional model

Analysis Analysis Model

:dynamic model

UML Activity :analysis object

model
Diagram
2
0
6
Requirements Specification vs
Analysis Model
Both are models focusing on the requirements
from the user’s view of the system
∙ The requirements specification uses
natural language (derived from the problem
statement)
∙ The analysis model uses a formal or semi-
formal notation
• Requirements Modeling Languages
• Natural Language
• Graphical Languages: UML, SysML, SA/SD
• Mathematical Specification Languages: VDM (Vienna
Definition Method), Z (based on Zermelo–Fraenkel
set theory), Formal methods ….
2
0
7
Types of Requirements

• Functional requirements
• Describe the interactions between the system and
its environment independent from the
implementation
“An operator must be able to define a new game“
• Nonfunctional requirements
• Aspects not directly related to functional behavior
“The response time must be less than 1 second”
• Constraints
• Imposed by the client or the environment
“The implementation language must be Java “
• Also called “Pseudo requirements”.

2
0
8
Functional vs. Nonfunctional
Requirements
Functional Requirements Nonfunctional Requirements
∙ Describe user ∙ Describe properties
tasks which the
of the system or the
system needs to
support domain
• Phrased as actions
• Phrased as
“Advertise a new
constraints or negative
league” “Schedule
tournament” “Notify an
assertions
interest group” “All user inputs should be
acknowledged within 1
second”
“A system crash should not
result in data loss”.
2
0
9
Types of Nonfunctional Requirements

• Usability • Implementation
• Reliability • Interface
• Robustness • Operation
• Safety • Packaging
• Performance • Legal
• Response time • Licensing (GPL, LGPL)
• Scalability • Certification
• Throughput • Regulation
• Availability
• Supportability
• Adaptability
• Maintainability Constraints or
Quality requirements Pseudo requirements
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, 3
Patterns, and Java
9
Types of Nonfunctional Requirements

• Usability • Implementation
• Reliability • Interface
• Robustness • Operation
• Safety • Packaging
• Performance • Legal
• Response time • Licensing (GPL, LGPL)
• Scalability • Certification
• Throughput • Regulation
• Availability
• Supportability
• Adaptability
• Maintainability Constraints or
Quality requirements Pseudo requirements
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, 4
Patterns, and Java
0
 Some Quality Requirements
• Definitions
Usability
• The ease with which actors can perform a function in a system
• Usability is one of the most frequently misused terms (“The system
is easy to use”)
• Usability must be measurable, otherwise it is marketing
• Example: Specification of the number of steps – the measure! -
to perform a internet-based purchase with a web browser
• Robustness: The ability of a system to maintain a function
• even if the user enters a wrong input
• even if there are changes in the environment
• Example: The system can tolerate temperatures up to 90 C
• Availability: The ratio of the expected uptime of a
system to the aggregate of the expected up and down time
• Example: The system is down not more than 5 minutes per week.
Nonfunctional Requirements:
Examples
• “Spectators must be able to watch a
match without prior registration and without
prior knowledge of the match.”
⮚ Usability Requirement
• “The system must support 10 parallel
tournaments”
⮚ Performance Requirement
• “The operator must be able to add new
games without modifications to the existing
system.”
⮚ Supportability Requirement

2
1
3
What should not be in the
Requirements?
• System structure, implementation
technology
• Development methodology
• Development environment
• Implementation language
• Reusability
• It is desirable that none of these above
are constrained by the client.

2
1
4
Requirements Validation
Requirements validation is a quality assurance
step, usually performed after requirements
elicitation or after analysis
• Correctness:
• The requirements represent the client’s view
• Completeness:
• All possible scenarios, in which the system can be used,
are described
• Consistency:
• There are no requirements that contradict each other.

2
1
5
Requirements Validation
(2)
• Clarity:
• Requirements can only be interpreted in one way
• Realism:
• Requirements can be implemented and delivered
• Traceability:
• Each system component and behavior can be traced to
a set of functional requirements

• Problems with requirements validation:

• Requirements change quickly during requirements
elicitation
• Inconsistencies are easily added with each change
• Tool support is needed!

2
1
6
Different Types of Requirements
Elicitation
• Greenfield Engineering
• Development starts from scratch, no prior system
exists, requirements come from end users and clients
• Triggered by user needs
• Re-engineering
• Re-design and/or re-implementation of an existing
system using newer technology
• Triggered by technology enabler
• Interface Engineering
• Provision of existing services in a new environment
• Triggered by technology enabler or new market needs

2
1
7
Prioritizing Requirements

• High priority
• Addressed during analysis, design, and implementation
• A high-priority feature must be demonstrated
• Medium priority
• Addressed during analysis and design
• Usually demonstrated in the second iteration
• Low priority
• Addressed only during analysis
• Illustrates how the system is going to be used in the
future with not yet available technology.

2
1
8
Requirements Analysis Document
Template
1. Introduction
2. Current system
3. Proposed system
1. Overview
2. Functional requirements
3. Nonfunctional requirements
4. Constraints (“Pseudo requirements”)
5. System models
1. Scenarios
2. Use case model
3. Object model
1. Data dictionary
2. Class diagrams
4. Dynamic models
5. User interface
4. Glossary
2
1
9
Section 3.3 Nonfunctional
Requirements
1. User interface and human factors
2. Documentation
3. Hardware considerations
4. Performance characteristics
5. Error handling and extreme conditions
6. System interfacing
7. Quality issues
8. System modifications
9. Physical environment
10. Security issues
11. Resources and management issues

2
2
0
Nonfunctional Requirements
(Questions to overcome)
User interface and human factors
• What type of user will be using the system?
• Will more than one type of user be using the
system?
• What training will be required for each type of
user?
• Is it important that the system is easy to learn?
• Should users be protected from making errors?
• What input/output devices are available
Documentation
• What kind of documentation is required?
• What audience is to be addressed by each
document?
2
2
1
Nonfunctional
Requirements (2)
Hardware considerations
• What hardware is the proposed system to be used on?
• What are the characteristics of the target hardware,
including memory size and auxiliary storage space?
Performance characteristics
• Are there speed, throughput, response time constraints
on the system?
• Are there size or capacity constraints on the data to be
processed by the system?
Error handling and extreme conditions
• How should the system respond to input errors?
• How should the system respond to extreme conditions?

2
2
2
Nonfunctional
Requirements (3)
System interfacing
• Is input coming from systems outside the proposed
system?
• Is output going to systems outside the proposed system?
• Are there restrictions on the format or medium that must
be used for input or output?
Quality issues
• What are the requirements for reliability?
• Must the system trap faults?
• What is the time for restarting the system after a failure?
• Is there an acceptable downtime per 24-hour period?
• Is it important that the system be portable?

2
2
3
Nonfunctional
Requirements (4)
System Modifications
• What parts of the system are likely to be modified?
• What sorts of modifications are expected?
Physical Environment
• Where will the target equipment operate?
• Is the target equipment in one or several locations?
• Will the environmental conditions be ordinary?
Security Issues
• Must access to data or the system be controlled?
• Is physical security an issue?

2
2
4
Nonfunctional
Requirements (5)
Resources and Management Issues
• How often will the system be backed up?
• Who will be responsible for the back up?
• Who is responsible for system installation?
• Who will be responsible for system maintenance?

2
2
5
 Exercises
Exercise 1: Scenario and Use Case Identification
Observe a system you interact with daily (e.g., a ride-hailing app or a smart
home device). Write a detailed scenario that describes a specific interaction with
the system. Then abstract this scenario into a use case and identify the main
actor involved.

Exercise 2: Functional vs. Nonfunctional Requirements

Choose an online learning platform (e.g., Coursera, Udemy). Identify five
functional and five nonfunctional requirements for the system. Classify the
nonfunctional requirements using the FURPS+ model.
 Exercise 2: FURPS+ model.

F-Functionality
Must support multi-language interface.
U-Usability
Intuitive, User-Friendly UI with keyboard accessibility.
R – Reliability
Coursera should maintain at least 99.9% uptime to ensure global access at all times.
P-Performance
Videos should load in under 3 seconds on 4G.
S– Supportability
Multi-Device Support: The platform should function consistently across web, Android, and iOS
devices, with regular updates and support for new OS versions.
+ (Plus)
Legal/Regulatory Compliance: The system must adhere to international data protection laws
such as GDPR and CCPA.
 Exercise
Exercise 3: Consider a University Course Registration System.
Identify at least three actors and four use cases they would be
involved in.

Exercise 4: Review the following requirement and identify if it is

clear, complete, consistent, and verifiable. Rewrite it if needed.
"The system should allow fast logins and be secure."
Exercise 4
The system allow users to log in within 2 seconds under normal load
and use multi-factor authentication (MFA) and HTTPS to ensure
secure access.
 Exercise
Exercise 5: Create a checklist of at least five nonfunctional
requirements for a smart thermostat app, categorized using the
FURPS+ model.

Exercise 6: Requirements Elicitation Strategy Comparison

Compare and contrast the following elicitation strategies: interviews,
observation, Joint Application Design (JAD). For each strategy, identify
suitable use cases, potential limitations, and ideal project scenarios where
the method would be most effective​.
Exercise 6

Interviews
Advantages:
- One-on-one discussions with stakeholders or users
- Collecting in-depth insights or opinions
Limitations:
- Time-consuming
- Prone to bias

JAD
Advantages:
- Collaborative workshops for gathering consensus.
- Rapid clarification of complex requirements.
Limitations:
Needs careful planning and facilitation.
 Exercise
Exercise 5: Create a checklist of at least five nonfunctional
requirements for a smart thermostat app, categorized using the
FURPS+ model.

Exercise 6: Requirements Elicitation Strategy Comparison

Compare and contrast the following elicitation strategies: interviews,
observation, Joint Application Design (JAD). For each strategy, identify
suitable use cases, potential limitations, and ideal project scenarios where
the method would be most effective​.
 Exercise
Exercise: Relationship Mapping
Develop a set of use cases for a digital library system. Identify and
illustrate the relationships (include, extend, generalization) among these
use cases using a use case diagram. Provide justifications for the use of
each relationship.