Module 5: Requirements Analysis

and Modeling
Software Engineering
School of Computing, Faculty of Engineering
Universiti Teknologi Malaysia
 Outline
• Part I: Requirements Modeling Concept
– Use Case Modeling and Specification
– Domain Modeling
– Activity Diagram
– Sequence Diagram
– State Chart/State Machine Diagram
• Part II: Requirements Document
– Software Requirements Specification (SRS)
Note: The overall contents of the slide are based on the main reference that is
Sommerville (2016) with other references specified directly in respective slides (if any)

2021 Software Engineering 2

 Use Case Modeling and Specification, Sequence Diagram, Activity
Diagram, Domain Modeling, State Chart/Machine Diagram

PART I: REQUIREMENTS MODELING

CONCEPT
Note: Main reference for Part I: Sommerville (2016), Arlow and Neustadt (2002)

2021 Software Engineering 3

 Objectives
• To define requirements using use cases and
problem domain classes
• To identify and analyze events and resulting
use cases for use case diagram
• To identify and analyze domain classes for
domain model class diagram
• To produce detail requirements using
sequence diagram, activity diagram and state
chart/state machine diagram

2021 Software Engineering 4

 System Modeling
• System modeling is the process of developing abstract
models of a system, with each model presenting a
different view or perspective of that system
• System modeling represents a system using graphical
notation, which is now almost always based on
notations in the Unified Modeling Language (UML)
• System modeling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers

2021 Software Engineering 5

 Existing and Planned System Models
• Models of the existing system are used during
requirements engineering
– They help clarify what the existing system does and can be
used as a basis for discussing its strengths and weaknesses
– These then lead to requirements for the new system
• Models of the new system are used during
requirements engineering to help explain the proposed
requirements to other system stakeholders
– Engineers use these models to discuss design proposals and
to document the system for implementation

2021 Software Engineering 6

 System Perspectives
• An external perspective: model the context or
environment of the system
• An interaction perspective: model the interactions
between a system and its environment, or between the
components of a system
• A structural perspective: model the organization of a
system or the structure of the data that is processed by
the system
• A behavioral perspective: model the dynamic behavior
of the system and how it responds to events

2021 Software Engineering 7

 Context Model
• Context models are used to illustrate the operational
context of a system - they show what lies outside the
system boundaries
• Social and organisational concerns may affect the
decision on where to position system boundaries
• Architectural models show the system and its
relationship with other systems
«system»
Patient record
system
«system»
Management
«system»
Admissions The context of
reporting
system
system
Mentcare system
«system»
Mentcare

«system» «system»
HC statistics Prescription
system system
«system»
Appointments
system

2021 Software Engineering 8

 UML Diagram Types
• Activity diagrams show the activities involved in a
process or in data processing
• Use case diagrams show the interactions between a
system and its environment
• Sequence diagrams show interactions between actors
and the system and between system components
• Class diagrams show the object classes in the system
and the associations between these classes
• State diagrams show how the system reacts to internal
and external events

2021 Software Engineering 9

 Use of Graphical Models
• As a means of facilitating discussion about an
existing or proposed system
– Incomplete and incorrect models are fine at the early
stage as their role is to support discussion
• As a way of documenting an existing system
– Models should be an accurate representation of the
system but need not be complete
• As a detailed system description that can be used
to generate a system implementation
– Models have to be both correct and complete

2021 Software Engineering 10

 Ways of Writing a System
Requirements Specification Recall

Notation Description

Natural language The requirements are written using numbered sentences in natural
language. Each sentence should express one requirement.
Structured natural The requirements are written in natural language on a standard form or
language template. Each field provides information about an aspect of the
requirement.

Design description This approach uses a language like a programming language, but with
language more abstract features to specify the requirements by defining an
operational model of the system. This approach is now rarely used
although it can be useful for interface specifications.

Graphical notations Graphical models, supplemented by text annotations, are used to define
the functional requirements for the system; UML use case and
sequence diagrams are commonly used.

Mathematical specifications These notations are based on mathematical concepts such as finite-
state machines or sets. Although these unambiguous specifications can
reduce the ambiguity in a requirements document, most customers don’t
understand a formal specification. They cannot check that it represents
what they want and are reluctant to accept it as a system contract.

2021 Software Engineering 11

 Use Case Diagram

INTERACTION MODEL

2021 Software Engineering 12

 Interaction Model
• Modeling user interaction is important as it helps to
identify user requirements
• Modeling system-to-system interaction highlights the
communication problems that may arise
• Modeling component interaction helps us understand
if a proposed system structure is likely to deliver the
required system performance and dependability
• Use case diagrams and sequence diagrams may be
used for interaction modeling
• For the scope of this course, sequence diagrams will be
discussed later under behavioural model

2021 Software Engineering 13

 Use Case Modeling
• Use cases were developed originally to support
requirements elicitation and now incorporated
into the UML
• Each use case represents a discrete task that
involves external interaction with a system
• Actors in a use case may be people or other
systems
• Represented diagrammatically to provide an
overview of the use case and in a more detailed
textual form

2021 Software Engineering 14

 Stereotypes in UML
• Stereotypes allow us to introduce new modeling
elements based on existing elements
• Can do this by appending the stereotype name in
guillemots («…») to the new element
• Each model element can have at most one
stereotype
• Examples:
1. <<include>>, <<extend>> in use case relationship
2. <<entity>>, <<controller>>, <<boundary>> in class
diagram as class stereotypes
3. <<package>>, <<subsystem>> in package diagram

2021 Software Engineering 15

 Use Case Diagram: Notation

2021 Software Engineering 16

 Example: Use Case Diagram for
Mentcare System
Mentcare System
Register
patient

Unregister
patient

View patient
info.
Medical
receptionist
Transfer data

Contact
patient

Note: Use cases in the Mentcare system involving the role ‘Medical Receptionist’

2021 Software Engineering 17

 Use Case Description

2021 Software Engineering 18

 Branching within a Flow and
Alternative Flow

2021 Software Engineering 19

Repitition within a Flow: For/While

2021 Software Engineering 20

 <<include>> Relationship

2021 Software Engineering 21

 <<extend>> Relationship

2021 Software Engineering 22

 Example: Use Case Diagram for
e-Commerce System

2021 Software Engineering 23

 Example: Use Case Description for
GoToCheckout

Note: Extension points for <<extend>> relationship can be stated before preconditions in
the use case description and in the flow of events where the extension occurs

2021 Software Engineering 24

 Use Case Description for
AcceptPaymentByCard and DisplayBasket

2021 Software Engineering 25

 Class Diagram

STRUCTURAL MODEL

2021 Software Engineering 26

 Structural Models
• Structural models of software display the
organization of a system in terms of the
components that make up that system and their
relationships
• Structural models may be static models, which
show the structure of the system design, or
dynamic models, which show the organization of
the system when it is executing
• Create structural models of a system when
discussing and designing the system architecture

2021 Software Engineering 27

 Class Diagrams
• Class diagrams are used when developing an object-
oriented system model to show the classes in a system
and the associations between these classes
• An object class can be thought of as a general
definition of one kind of system object
• An association is a link between classes that indicates
that there is some relationship between these classes
• When developing models during the early stages of the
software engineering process, objects represent
something in the real world, such as a patient, a
prescription, doctor, etc.

2021 Software Engineering 28

Domain Model Class Diagram Notation
• Class diagram key:
– General class symbol: rectangle with three sections
– Sections convey name, attributes, and behaviors
– Methods (behaviors) not shown in domain model
class diagram
– Lines connecting rectangles show associations
– Multiplicity reflected above connecting lines
• Domain class objects reflect business concern,
policies, and constraints
• When moving to design, methods and details of
methods are included (design class diagram)

2021 Software Engineering 29

 Class and Object Instantiation

2021 Software Engineering 30

 Class as a Template of Objects

Note: Do not include operation part in analysis stage – only in design stage

2021 Software Engineering 31

 Class Stereotype Syntax

2021 Software Engineering 32

 Types of Class Stereotype
• Boundary class: interacts with
actors outside the system and other
objects in the system
• Entity class: a passive class i.e. does
not initiate interactions on its own,
store and manage information,
normally persistent data
• Control class: coordinate boundary
and entity object(s) – collect inform
from boundary and dispatch to
entity, usually has behavior specific
for one use case
Source: [Link]

2021 Software Engineering 33

 Good Analysis Class
What makes a good analysis class:
• its name reflects its intent
• it is a crisp abstraction that models one specific
element of the problem domain
• it maps on to a clearly identifiable feature of the
problem domain
• it has a small, well-defined set of responsibilities
• it has high cohesion
• it has low coupling
Note: Our SE course focuses on domain models. Thus, the concepts of high cohesion and low
coupling will be elaborated in design stage where we include operations in class diagram.

2021 Software Engineering 34

 Association
Note: The arrow head in navigability
can be ignored in analysis stage

OR

2021 Software Engineering 35

 Multiplicity

2021 Software Engineering 36

 Reflexive Association

2021 Software Engineering 37

 Association Class

2021 Software Engineering 38

 Generalization…
• Generalization is an everyday technique that can be
used to manage complexity
• Rather than learning the detailed characteristics of
every entity, place these entities in more general
classes (animals, cars, houses, etc.) and learn the
characteristics of these classes
• This allows us to infer that different members of
these classes have some common characteristics e.g.
square, circle and triangle are shape

2021 Software Engineering 39

 Generalization
• In modeling systems, it is often useful to examine the
classes in a system to see if there is scope for generalization
• Do not have to look at all classes in the system to see if
they are affected by the change in future
• In a generalization, the attributes and operations
associated with higher-level classes are also associated with
the lower-level classes
• The lower-level classes are subclasses inherit the attributes
and operations from their superclasses
• These lower-level classes then add more specific attributes
and operations

2021 Software Engineering 40

 Class Generalization

2021 Software Engineering 41

 Example: Generalization Hierarchy

Doctor
Doctor
Name
General
Hospital
doctor practitioner
Phone #
Email

register ( )
Consultant Team doctor
de-register ( )

Trainee Qualified
doctor doctor

Hospital doctor General practitioner

Staff # Practice
Pager # Address

2021 Software Engineering 42

 Aggregation and Composition

Note: The arrow head in navigability

can be ignored in the analysis stage

Part can exist without whole Part cannot exist without whole

2021 Software Engineering 43

 Example: Classes and Associations in
MHC-PMS
Consultant
1
referred-to
1..*
1..* 1..* 1..* 1
Condition Patient General
referred-by practitioner
diagnosed-
with 1..*
attends
1..*
prescribes
Consultation Medication
Patient record 1..* 1..*
1..*
1 1 runs prescribes
1..4 Treatment
1 1..* 1..*
Patient Consultation Hospital
Doctor

2021 Software Engineering 44

 Example: Domain Model for Online
Shopping

Note: Stating the type for the

attribute is optional in analysis stage

source: [Link]

2021 Software Engineering 45

 Activity Diagram, Sequence Diagram, State Diagram (State Chart/Machine)

BEHAVIORAL MODEL

2021 Software Engineering 46

 Behavioral Model
• Behavioral models are models of the dynamic
behavior of a system as it is executing, show what
happens or what is supposed to happen when a
system responds to a stimulus from its
environment
• Think of these stimuli as being of two types:
– Data: Some data arrives that has to be processed by
the system (activity diagram, sequence diagram)
– Events: Some event happens that triggers system
processing and may have associated data, although
this is not always the case (state diagram)

2021 Software Engineering 47

 Data-Driven Modeling
• Many business systems are data-processing
systems that are primarily driven by data,
controlled by the data input to the system, with
relatively little external event processing
• Data-driven models show the sequence of actions
involved in processing input data and generating
an associated output
• They are particularly useful during the analysis of
requirements as they can be used to show end-
to-end processing in a system

2021 Software Engineering 48

 Activity Diagram
• Activity diagrams are “OO flowcharts” that allow us to model
a process as a collection of activities and transitions
between those activities
• Activity diagrams are really just special cases of statecharts
where every state has an entry action that specifies some
process or function that occurs when the state is entered
• An activity diagram can be attached to any modeling
element for the purpose of modeling the behavior of that
element at different abstraction levels
• Activity diagrams are typically attached to: use cases, classes,
interfaces, components, nodes, collaborations, operations
and methods
2021 Software Engineering 49
 Activity Diagram: Transition and
Decision

2021 Software Engineering 50

 Activity Diagram: Fork and Join

2021 Software Engineering 51

 Activity Diagram: Swimlanes

2021 Software Engineering 52

 Sequence Diagram
• Sequence diagrams are part of the UML and are used
to model the interactions between the actors and
the objects showing their behavior within a system
• A sequence diagram shows the sequence of
interactions that take place during a particular use
case or use case instance (scenario)
• The objects and actors involved are listed along the
top of the diagram, with a dotted line drawn
vertically from these
• Interactions between objects are indicated by
annotated arrows
2021 Software Engineering 53
 Sequence Diagram Syntax

Note: Related Use

Case Description

2021 Software Engineering 54

 Syntax/Notation Details
• Lifeline represents an individual participant (or object)
in the interaction
• Focus of control (activation) specifies a behavior or
interaction within the lifeline also known as execution
specification
• Message defines a particular communication between
lifelines of an interaction
• Examples of communication: raising a signal, invoking
an operation, creating or destroying an instance

2021 Software Engineering 55

 Types of Message
• Synchronous:
– If a caller sends a synchronous message (in sequence), it must
wait until the message is done before it proceeds with its
business
• Asynchronous:
– If a caller sends an asynchronous message, it can continue
processing and does not have to wait for a response
– Usually used in multithreaded applications and in message-
oriented middleware
• Return message:
– Return messages are an optional part of a sequence diagram
– The use of return messages depends on the level of
detail/abstraction that is being modeled
– Return messages are useful if finer detail is required; otherwise,
the invocation message is sufficient
(Source: [Link]

2021 Software Engineering 56

 Message in Sequence Diagram
• To show an object (lifeline) sending a message to another
object, draw a line to the receiving object with a solid
arrowhead (if a synchronous call operation) or with a
stick arrowhead (if an asynchronous signal).
• Besides message calls, there are return messages. These
return messages are optional; a return message is drawn
as a dotted line with an open arrowhead back to the
originating lifeline, and above this dotted line you place
the return value from the operation.
Source: [Link]

Source: Arlow and Neustadt (2002)

2021 Software Engineering 57

 Iteration in Sequence Diagram

guard

2021 Software Engineering 58

 Branching and Self-Delegation

2021 Software Engineering 59

 Concurrency: Active Objects

asynchronous flow

2021 Software Engineering 60

 Example: Sequence Diagram for View
Patient Info in MHC-PMS

alt: Alternative flow

2021 Software Engineering 61

 Example: Sequence Diagram for
Process Order

argument

Note: Sequence diagram also shows the interaction (interaction model) besides behaviour –
in the analysis stage, the argument can be included (optional)

2021 Software Engineering 62

 Example: Sequence Diagram Using
Class Stereotypes
sd Interaction

Weather Operator
Weather Station Weather Weather Data Instrument
Controller
retrieve()
getData()
collect()
get()

sendData()

ok()

ok()

displayData()

Note: Sequence diagram with return messages (optional) using class stereotypes (optional)

2021 Software Engineering 63

 Sequence Diagram: Scope for Analysis
• Each use case must have at least
one sequence diagram that
comprises normal flow and
alternative flows – split only if it is
cluttered to combine all
• Refer to use case description when
creating a sequence diagram
• Focus on object interaction in
domain model (class diagram for
analysis) for a particular use case
• Not necessary to include boundary,
controller and data layer that could
be added in design stage

2021 Software Engineering 64

 Event-Driven Modeling
• Some systems mainly real-time systems are often
event-driven, with minimal data processing
• Examples: (Source: [Link]
– A robot has reached its destination (real-time warehouse
management)
– An illegal trade pattern has been detected (fraud
detection)
– A loan application has been accepted/rejected
(commercial business)
• Event-driven modeling shows how a system responds
to external and internal events; is based on the
assumption that a system has a finite number of states
and the events (stimuli) may cause a transition from
one state to another
2021 Software Engineering 65
 State Chart or State Machine Diagram
• In OO approaches, state chart is drawn for a single
class to show the lifetime behavior of a single object
• State chart is also known as state machine diagram
• State: a condition during the life of an object when it
satisfies some conditions, performs some actions, or
waits for an event
– It is found by examining the attributes and links
defined for the object
– represented as a rectangle with rounded corners
• Transition: represents a change of the internal
condition/state of an object

2021 Software Engineering 66

 Event and State

2021 Software Engineering 67

 State Syntax

2021 Software Engineering 68

 State
• State: a semantically significant condition of an object
• Object state is determined by object attribute values,
relationships to other objects, activities the object is performing
• State syntax:
– entry action: performed immediately on entry to the state
– exit action: performed immediately on exit from the state
– internal transitions: these are caused by events that are not
significant enough to warrant a transition to a new state, the
event is processed by an internal transition within the state
– internal activity: a piece of work that takes a finite amount of
time and which may be interrupted

2021 Software Engineering 69

 Identifying the Object Behavior
• In brief, a state in a state chart similar to
status condition:
– Spans many business events
– Developed for complex problem domain classes
• State chart/state machine diagram
– Composed of ovals representing status of object
– Arrows represent transitions

2021 Software Engineering 70

 Identify States
• Guidelines to help identify states:
– Check naming convention for status conditions
– Simple states reflect simple conditions such as “On”
– Complex states labeled with gerunds or verb phrases
• Example: “Being shipped”
– Active states usually not labeled with nouns
– Describe only states of being of the object itself
– Status conditions reported to management/customers
• Example: “Shipped”

2021 Software Engineering 71

 Transition

• Transitions have a simple syntax that may be used

for external transitions (shown by an arrow) or
internal transitions (nested within a state).
• Every transition has three optional elements:
– an event – this is an external or internal occurrence
that triggers the transition
– a guard condition – this is a Boolean expression that
must evaluate to true before the transition can occur
– an action – this is a piece of work associated with the
transition, and occurs when the transition fires
2021 Software Engineering 72
 Event
• UML defines an event as, “the specification of
a noteworthy occurrence that has location in
time and space.”
• Events trigger transitions in state machines
• Events may be shown externally on transitions
• There are four types of event, each of which
has different semantics:
1. call event
2. signal event
3. change event
4. time event

2021 Software Engineering 73

 Example: Call Event State Chart

2021 Software Engineering 74

 Example: Signal Event State Chart
Note: A state chart relates to the class that provides the
signal e.g. OverdrawnAccount that triggers respective
event and action

2021 Software Engineering 75

Example: Change Event State Chart

2021 Software Engineering 76

 Example: Time Event State Chart

2021 Software Engineering 77

 Example: State Diagram of a
Microwave Oven
Full
power Full power
do: set power
= 600

Timer
Waiting
Number
do: display Operation
Full Set time
time
power do: get number do: operate
exit: set time oven
Half
Half power
Door
power Cancel
Timer closed
Start
Door
open Door
Half power Enabled Waiting
open
do: set power Door do: display do: display
= 300 closed 'Ready' time

Disabled
do: display
'Waiting'

2021 Software Engineering 78

 Example: Microwave Oven Operation
Operation
Time
Checking
OK Cook
do: check do: run
status generator

Turntable Emitter Timeout

fault fault

Done
Alarm
do: buzzer on
do: display
for 5 secs.
event

Door open Cancel

Disabled Waiting

2021 Software Engineering 79

 Rules for Developing State Charts

1. Select the classes that will require state charts

2. List all the status conditions for each group
3. Specify transitions that cause object to leave the
identified state
4. Sequence state-transition combinations in correct
order
5. Identify concurrent paths (if any)
6. Look for additional transitions
7. Expand each transition as appropriate
8. Review and test each state chart

2021 Software Engineering 80

 Key Points…
• A model is an abstract view of a system that ignores system
details. Complementary system models can be developed to
show the system’s context, interactions, structure and behavior.
• Context models show how a system that is being modeled is
positioned in an environment with other systems and
processes.
• Use case diagrams and sequence diagrams are used to describe
the interactions between users and systems in the system being
designed. Use cases describe interactions between a system
and external actors; sequence diagrams add more information
to these by showing interactions between system objects.

2021 Software Engineering 81

 Key Points
• Structural models show the organization and architecture of a
system. Class diagrams are used to define the static structure
of classes in a system and their associations.
• Behavioral models are used to describe the dynamic behavior
of an executing system. This behavior can be modeled from
the perspective of the data processed by the system, or by the
events that stimulate responses from a system.
• Activity diagrams may be used to model the processing of
data, where each activity represents one process step.
• State diagrams are used to model a system’s behavior in
response to internal or external events.

2021 Software Engineering 82

 Software Requirements Specification (SRS)

PART II: REQUIREMENTS

DOCUMENT

2021 Software Engineering 83

 Objective
• To understand how requirements may be
organized in a software requirements
document
• To adopt a standard in producing a
requirements document
• To focus on specific requirements that include
the analysis models

2021 Software Engineering 84

 Software Requirements Document
• Software requirements document is an official
statement of what is required for the reference of
software developers
• Should include both definitions of user requirements
and specifications of the system requirements
• It is NOT a design document
• As far as possible, it should set WHAT the system
should do rather than HOW it should do it

2021 Software Engineering 85

 User and System Requirements
Recall

2021 Software Engineering 86

Users of a Requirements Document

2021 Software Engineering 87

 Requirements Document
Variability
• Information in requirements document depends
on type of system and the approach used in its
development
• Systems developed incrementally will, typically,
have less detail in the requirements document
• Requirements documents standards have been
designed e.g. IEEE standard
• These are mostly applicable to the requirements
for large software projects

2021 Software Engineering 88

 IEEE Std 830-1998

2021 Software Engineering 89

 SRS Outline of IEEE Std 830-1998

See page 11 of IEEE Std 830-1998

2021 Software Engineering 90
Example of Template for the Front Part
of SRS Document

2021 Software Engineering 91

 Section 1: Introduction

2021 Software Engineering 92

 Section 2: Overall Description,
Sub-Section 2.1

2021 Software Engineering 93

 Sub-sections 2.1.1 to 2.1.3

2021 Software Engineering 94

 Sub-sections 2.2 & 2.3

2021 Software Engineering 95

 Sub-sections 2.4 to 2.6

2021 Software Engineering 96

 Section 3: Specific Requirements

Note: Focus on “Specific Requirements” for the scope of this course – see the given
System Documentation template that combines the required details for analysis
(Section 2), design (Section 3 to 6) and testing (Section 7 and 8) to meet the minimum
requirements of this course

2021 Software Engineering 97

 Appendix A.5 Template of SRS Section 3:
Organized by Feature (IEEE Std 830-1998)
• Sections 3.1.1 to 3.1.4 provide
the details of what described
in Sections 2.1.2 to 2.1.5
• For each functional
requirement, include the use
case diagram and its details
using use case description
• Include sequence diagram and
activity diagram for each use
case i.e. functional
requirement
• Include state diagram for
classes with states under
respective use cases
2021 Software Engineering 98
 Key Points
• The software requirements document is an agreed
statement of the system requirements
• It should be organized so that both system customers
or users and software developers can use it
• Documentation standard can be referred and
customized based on stakeholders’ needs

2021 Software Engineering 99