SCSJ 2253

REQUIREMENTS ENGINEERING
AND SOFTWARE MODELING

TOPIC 4:
MODEL-BASED REQUIREMENTS
DOCUMENTATION

1
Noraini Ibrahim, May 2021
 TOPIC 4 OVERVIEW
Definition of models, benefits of using models

Development of system vision model (Goal diagram)

Development of business process model (Swimlane diagram)

3 perspectives of requirements modelling – Functional, Data, Behaviour

Functional perspective:
• Use Case (diagram and specifications)
• Activity diagram

Data perspective:
• Domain class diagram

Behaviour perspective:
• State diagram
 PART 2
1. 3 Perspectives of Requirements Models
2. Functional Perspective
a. Use Case Diagram (UCD)
b. Use Case Specifications
1. THREE PERSPECTIVES OF REQUIREMENTS
MODELS
 UML use case diagrams

e.g. UML state diagrams

The three perspectives of requirements models
 Recap to Topic 1 (Intro)
The three perspectives of requirements Building a software vs. building a house
analogy

• Architect & engineer ~ use AutoCAD

software to model 2D & 3D objects i.e.
building
a. walls, doors, windows, rooms, kitchen,
toilet, stairs [building structures/static ~
data]
b. electrical wirings, piping [how objects
manipulated ~ functional]
c. Simulation for piping/waste
management in kitchen area [testing
environment to observe faults ~
behavioral]
2. MODELS OF THE FUNCTIONAL
PERSPECTIVE
 Use Case Documentation Objectives

• Identify the Use case

Diagram
components of use case
diagram
Use Case
Documentation

• Knows how to write use Use Case

Specification
case specification
 Use-Case Documentation

• Use cases help to examine and documents a planned

or existing systems from user's perspective.
• The use case approach is based on two
complementary documentation techniques:
i. Use Case Diagrams (Conceptual model)
ii. Use Case Specifications (Natural language)
System boundary; actor; use case; communication association

A) USE CASE DIAGRAM (UCD)

 Use Case Diagram

• Shows a set of external Actors and their Use Cases connected

with communication associations
• Documents the interrelations of the functions of a system and
the relations between these functions and the systems
context.
• The communication associations between the Actors and
their Use Cases define the boundary between the system and
its external environment.

14
Use case diagram syntax/semantics – elements (ebook, page 65)
K. Pohl and C. Rupp, Requirements Engineering Fundamentals,
1st edition. CA, USA: Rocky Nook, 2011.
 Example #1 – Use case diagram

Generalization
for Actors

Usage of rectangle
notation with
<actor> stereotype
for external
systems
 Example 2– Use case diagram

Usage of
<include>relations
from base use
case(UC003) to target
use cases (UC004 till
UC008) – mandatory
interaction
sequences

* observe the
arrowheads

Usage of <extend>
relation from target
use case (UC010) to
base use case
(UC009) – optional
sequences

* observe the
arrowhead
TOPIC 4 PART 2 ACTIVITY
• Identify errors in Use Case diagram
 What is wrong with the Use Case Model

Item Update Item

Librarian Librarian

Fig. 1 vs. Fig. 2

 What is wrong with the Use Case Model

«includes» Enter
Category «includes»
Browse Browse Browse
Catalog
«includes»
Catalog Result
Member Member

Browse «extends»
«extends»
Result

«includes»

View item
«extends» details Add to item
View item Add to item list
details list

Fig. 3 vs. Fig. 4

 What is wrong with the Use Case Model

Manage Manage
Steering Clutch
Drive Car

Manage
Gears
Manage Car Driver
Brakes

Car Driver
Manage Air
Conditioner
Adjust Seat

Fig. 5 vs. Fig. 6

 Activity 4.2a
System

Scenario:
Add to Waiting
List Provide

A popular restaurant decides to modernize its

Alternative Date
Manage

{ condition: full booking }

Booking
booking process from phone call to the online

g}
kin
oo
system. The following Figure 1 models the

ll b
: fu
View

ion
Restaurant
documented use case diagram for the planned

>

dit
ds
<extends>
Booking

on
n
xte

{c
restaurant online booking system by the

<e
Restaurant
Manager
developer team after their first-round
workshop and brainstorming activity.
Make
Booking Check Dietary
Requirements
Customer

Question: Update
<i
nc
lu
de
Head Chef

> Cook Booking

The use case diagram is not complying with
Booking
Order

the syntactic rules of Unified Modeling

Language (UML). View
Booking
<<actor>>
Make Payment
Payment Gateway
Describe FOUR (4) potential errors in Figure 1

Figure 1 : Use case diagram for online restaurant

booking system
Use case scenario – Normal, Alternative and Exceptional Flow; Use case
specification for <<extend>> <<include>>

B) USE CASE SPECIFICATION

 Recommended Use Case Specification template

Use Case ID
Use Case Name
Description
Actor(s)
Pre-condition(s)
Normal Flow(s) // Synonym : Main/Primary Scenario
Alternative Flow(s) // Synonym : Alternative Scenario
Exception Flow(s) // Synonym : Error handling Scenario
Post-condition(s)

Refer ebook – page 68-69 (main reference):

K. Pohl and C. Rupp, Requirements Engineering Fundamentals,
1st edition. CA, USA: Rocky Nook, 2011.
Example 1 – Use case specification
Example 2 – Use case specification
 Example 3 – Use case specification

UCS for <include>

 Activity 4.2b
From Activity 4.2a:
System

Provide the details descriptions for Make Add to Waiting

Booking and Make Payment Use Case List Provide

Alternative Date
Manage

{ condition: full booking }

Specifications based on the template given: Booking

g}
kin
oo
lb
ful
View

n:
Restaurant

io
>

dit
ds
<extends>
Booking

on
n
xte

{c
Use Case ID

<e
Restaurant
Manager
Use Case Name
Description
Make
Check Dietary
Actor(s) Booking
Requirements
Customer

Pre-condition(s) <i n
clu
Head Chef
Update de
Booking > Cook Booking
Normal Flow(s) // Synonym : Main/Primary Scenario Order

Alternative Flow(s) // Synonym : Alternative Scenario

View
Exception Flow(s) // Synonym : Error handling Scenario Booking
<<actor>>
Make
Payment
Payment
Post-condition(s) Gateway

Figure 1 : Use case diagram for online restaurant

Note: booking system
The use case diagram is not complying with the
syntactic rules of Unified Modeling Language (UML).
The improvement of the UC diagram from the Activity
4.2a should be considered.
 Topic 4 – Part 2 Summary
1. 3 perspectives of requirements modelling – Functional, Data, Behaviour
2. Functional perspective - Use Case (diagram and specifications)
3. Use Case Diagram (UCD) elements – system boundary, actors, use cases

UCD elements (ebook, page 65)

 Topic 4 – Part 2 Summary
4. Use Case Specifications (UCS) – ID, name, description, pre-conditions,
normal flows, alternative flows, exception flows, post-conditions

Use Case ID

Use Case Name

Description

Actor(s)

Pre-condition(s)

Normal Flow(s) // Synonym : Main/Primary Scenario

Alternative Flow(s) // Synonym : Alternative Scenario
Exception Flow(s) // Synonym : Error handling Scenario
Post-condition(s)

UCS recommended template

 Topic 4 – Part 2 Summary

Functional
3 Perspectives of
Data
Requirements Models
Behavioral

Use Case Diagram (UCD)

Functional Perspective Use Case Specifications
(UCS)
update: August 2019 (sharinhh)

68