TE2104

Software Requirements
Engineering

Topic 8:
Requirements Analysis II
 Contents
• Use Case Modelling

• Sequence Modelling

• Class Diagram

• Entity-Relationship
 RECAP
Requirements Engineering Process
R equirements
Feasibility
elicitation and
study
analysis
R equirements
specification

Feasibility R equirements
r eport validation

System
models

User and system

requirements

R equirements
document
 What is a Scenario?
….A scenario is a short story about people, their activities and the
contexts in which those activities take place that are relevant to
the technology in question…
[Alexander & Maiden, 2004]

•It describes a concrete example of satisfying or failing to satisfy a

goal (or sets of goals).
•Typically defines a sequence of interaction steps executed to
satisfy a goal, represented as:
– Use Cases
– Sequence Diagrams
What is a Use Case Modelling?
A use case is a specific way of using the system by performing
some part of the functionality.

Each use case constitutes a complete course of events initiated

by an actor and it specifies the interaction that takes place
between an actor and the system.

A use case is a special sequence of related transactions

performed by an actor and the system in dialogue. The collected
use cases specify all the existing ways of using the system.

[Jacobson et al., 1992]

What is a Use Case Modelling?
• Use case is a story of users using a system to achieve goals.
• Used during requirement analysis to identify and record
functional/behavioural requirements of a system.
• Use case modelling typically involves:
1. Find the system boundary.
2. Find the actors.
3. Find the use cases:
• Specify the use case.
• Identify key alternate flows.
4. Iterate until use cases, actors and system boundary are stable.
• The output of the above activities is the use case model/diagram and
use case specification(s).
When we do use case modeling, what we need to do..

1. Draw a Use Case Diagram

7
2. Write Use Case Specification(s)

8
 What is a Use Case Diagram?
• Use case diagrams are used to specify the system
from a user’s perspective in a way that is clear and
easy to read.
– Illustrate the system behaviour particularly the
functional requirements.

• The diagrams illustrate:

– the functions of the system to be developed;
– the interrelations between these functions;
– the relations of the system functions and their
environment (i.e. primary actors and secondary actors).
What is a Use Case Modelling?
• Use case diagrams contains 4 components:
– System boundary
• edge or boundary of the system.
– Actors
• roles played by people or things that use the system.
– Use cases
• things that the actors can do with the system.
– Relationships/Associations
• connections between actors and use cases.
 Find System Boundary
• Define what is part of the system (inside the system boundary)
and what is external to the system (outside the system
boundary).
• Defined by who or what uses the system (i.e. actors) and what
specific benefits the system offers to those actors (i.e. use
cases).
• Drawn as a box, labelled with the name of the system, with the
actors drawn outside the boundary and the use cases inside.
Mail Order System
 Find Actors
• An actor specifies a role that some external entity adopts
when interacting with the system directly.
– Actors are always external and thus they are outside the system
control.
– Who or what uses the system? What roles do they play in the
interaction?

• It represents a user role, or a role played by another system

or hardware that touches the boundary of the system.
– Actors represent roles that people or things play in relation to the
system, not specific people or specific things.

• They are written as noun.

 Find Actors
• Drawn as a rectangle with stereotype <<actor>> or a stick man.
Normally, stick man is used to represent people whereas
rectangle for other systems/entities.

<<actor>>
Customer

Customer
• If the actors are system, stereotype <<system>> is usually used.

<<system>>
InventorySystem

• Can use ‘Time’ actor if the event occurs in the system at a

<<system>>
InventorySystem
specific point of time without being triggered by a ‘real’ actor.

Time
 Find Use Cases
• A use case is a specification of sequences of actions
(including variants and errors) that a system can perform by
interacting with outside actors.
• It is something an actor wants the system to do (user goal) .
– How does each actor use the system? What does the system do for
each actor?

• It is a ‘case of use’ of the system by a specific actor:

– Use cases are always started by an actor.
– Use cases are always written from the point of view of the actors.
• Drawn as a ‘bubble’ with a name that is a verb phrase.

PlaceOrder GetStatusOnOrder
 The Use Case Diagram
System name
System boundary

Mail Order System

Communication
relationship

PlaceOrder

ShippingCompany

ShipProduct
CancelOrder

Customer
CheckOrderStatus Use case

Actor
Dispatcher
 The Use Case Diagram

e.g., secondary actor

e.g., primary actor

CPRE-FL © Mathias Lampe

(Writing) Use Case Specification

• Use case specification provides detailed descriptions for the

use cases defined in a UML use case diagram.

• Use case specification is written in three format:

1. Brief – Short one-paragraph summary. Usually of the
common (or main success) scenario.
2. Casual - Multiple paragraphs that cover various scenarios.
3. Fully-dressed – All scenarios (common/main success and
uncommon/alternative) are written in details, usually
using a template.

17
 The Use Case Specification
• Brief - Terse/short one-paragraph summary. Usually illustrate the main
success scenario. E.g.:
Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the Point-of-Sale
system to record each purchased item. The system presents a running total and line-item details. The cashier
enters payment information, which the system validates and records. The system updates inventory. The
system produces a receipt. The customer receives the receipt from the cashier and then leaves with the items.

• Casual - Informal paragraph format. Multiple paragraphs that cover

various scenarios. E.g.:
Main Success Scenario:

A customer arrives at a checkout with items to return. The cashier uses the Point-of-Sale system to record each returned
item …

Alternate Scenarios:
– If the credit authorization is rejected, inform the customer and ask for an alternate payment method.

– If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier
code.
 The Use Case Specification
• The comprehensive use case description is called fully
dressed use case.

– written in details, usually using a template.

 The Use Case Specification
• Template: Use case name Use Case: ManageBasket

Use case identifier ID: 1

Brief description
Brief description:
The Customer changes the quantity of an item in the basket.
Primary actors:
Actors involved Customer
Secondary actors:
None
System state before the Preconditions:
use case can begin 1. The shopping basket contents are visible.
Main flow:
1.The use case starts when the Customer selects an item in the basket.
Actual steps of the
2.If the Customer selects “Delete”
use case 2.1 The system removes the item from the basket.
3.If the Customer types in a new quantity
3.1 The system updates the quantity of the item in the basket.
System state when the Postconditions:
use case has finished None
Alternative flows Alternative flows:
to the main flow None
Exception flows to Exception flows:
the main flow None
 The Use Case Specification
• Use case name
– Normally the words are run together and each word starts with an
uppercase letter.
– Should always be a verb, as the use case describes system behaviour.
– Choose a name that is short yet descriptive and unique.
• Use case ID
– Unique identifier in a form of numbers. May use hierarchical
numbering system (e.g. 3.1, 3.2)
• Brief description
– A single paragraph that summarises the goal of the use case (i.e. the
business benefit that it delivers to its actors).
 The Use Case Specification
• Actors
– Primary actors => these actors actually trigger the use case.
– Secondary actors => these actors interact with the use case after it has
been triggered.
– Each use case is always triggered by a single actor. However, the same
use case may be triggered by different actors at different points in time.
• Preconditions and Postconditions
– Preconditions constrain the state of the system before the use case can
start (i.e. what must be true before).
– Postconditions constrain the state of the system after the use case has
executed (i.e. what will be true after).
– Boolean conditions (i.e True or False).
 The Use Case Specification
• Main Flow
– Describes ‘perfect world’ steps in a use case, where everything goes as
expected and desired and there are no errors, deviations, interrupts or
branches.
– Sometimes known as the ‘primary scenario’.
– Always begins by the primary actor doing something to trigger the use case.
A good way to start is: The use case starts when an <actor> <function>.
– Consists of a sequence of short steps that are declarative, numbered and
time ordered. Each step should be: <number> The <something> <some
action>.
– Active sentences. E.g.
1. The use case starts when the customer selects ‘Place Order’.
2. The customer enters his or her name and address into the form.
 The Use Case Specification
Use Case: xxx
• Main Flow ID: X
Brief description:
– May use ‘If’ to indicate xxx
branches (has Primary actors:
alternatives). xxx
Secondary actors:
xxx
Preconditions:
xxx
Main flow:
1.The use case starts when the Customer selects an item in the
basket.
2.If the Customer selects “Delete”
2.1 The system removes the item from the basket.
3.If the Customer types in a new quantity
3.1 The system updates the quantity of the item in the basket.
Postconditions:
xxx
Alternative flows:
xxx
 The Use Case Specification
Use Case: xxx
ID: X
• Main Flow Brief description:
xxx
– May use ‘For’ to
Primary actors:
indicate repetition. xxx

– The statement is Secondary actors:

xxx
repeated for a
Preconditions:
number of xxx
iterations specified Main flow:
in the iteration 1.The use case starts when the Customer select “Find Product”.
2.The Customer enters the requested criteria.
expression. 3.If the system finds some matching products then
3.1 For each product found
3.1.1. The system displays the product details
3.1.2 The system displays the product price.
Postconditions:
xxx
Alternative flows:
3a. Else if product is not found.
3a1. The system tells the Customer that no matching products could be
found.
 The Use Case Specification
Use Case: xxx
• Main Flow ID: X

– May use ‘While’ to Brief description:

xxx
indicate a sequence of Primary actors:
actions is performed xxx
while some Boolean Secondary actors:
condition is true. xxx
Preconditions:
xxx
Main flow:
1.The use case starts when the Customer selects “Show Company
Details”.
2.The system displays a web page showing the company details.
3.While the Customer is browsing the company details
3.1 The system plays some background music.
3.2 The system displays special offers in a banner ad.

Postconditions:
xxx
Alternative flows:
xxx
 The Use Case Specification
• Use cases can integrate related scenarios:
– Main scenario
– Alternative scenarios (optional)
– Exception scenarios (unintended)
 The Use Case Specification
• Alternative Flow

– Each use case has one main flow and may have many alternative
flows.

– Sometimes known as the ‘secondary scenario’.

– These are alternative paths through the use case that capture errors,
complex branches and interrupts to the main flow.

– They frequently do not return to the main flow, as they often deal
with errors and exceptions and tend to have different postconditions.

– Can document alternative flows separately (but not too many) or

append them to the end of the use case.
 The Use Case Specification
• Alternative Flow
– If the alternative flow returns to the main flow, its postconditions must be
added to those of the main flow. In the last step, state: The alternative flow
returns to step X of the main flow.
– An alternative flow should not have alternative flows. Otherwise, things get
far too complex.
– May be triggered in 3 different ways:
1. Instead of the main flow
2. After a particular step in the main flow
3. At any time during the main flow
– If case (1), it effectively replaces the use case entirely.
– If case (2), should state: The alternative flow begins after step X of the main
flow.
– If case (3), should state: The alternative flow begins at any time.
 The Use Case Specification
• Alternative Flow (separate for case 2)
Use Case: CreateNewCustomerAccount
Use Case:
ID: 5 CreateNewCustomerAccount:InvalidEmailAddress
Brief description: ID: 5.1
xxx
Brief description:
Primary actors: xxx
xxx
Primary actors:
Secondary actors: xxx
xxx
Secondary actors:
Preconditions: xxx
xxx
Preconditions:
Main flow: xxx
1.xxx
Alternative flow:
2.While the Customer details are invalid
1.The alternative flow begins after step 2.2 of the main flow.
2.1 The system asks ....
2.The system ...
2.2 The system validates the Customer details
3.xxx
3. xxx
Postconditions:
Postconditions:
xxx
xxx
Alternative flows:
InvalidEmailAddress
Cancel
 The Use Case Specification
• Alternative Flow (separate for case 3)
Use Case: CreateNewCustomerAccount
ID: 5 Use Case: CreateNewCustomerAccount:Cancel
Brief description: ID: 5.2
xxx
Brief description:
Primary actors: xxx
xxx
Primary actors:
Secondary actors: xxx
xxx
Secondary actors:
Preconditions: xxx
xxx
Preconditions:
Main flow: xxx
1.xxx
Alternative flow:
2.While the Customer details are invalid
1.The alternative flow begins at any time.
2.1 The system asks ....
2.The Customer cancels account creation.
2.2 The system validates the Customer details
3. xxx Postconditions:
xxx
Postconditions:
xxx
Alternative flows:
InvalidEmailAddress
Cancel
 The Use Case Specification
• Alternative Flow
– Can identify alternative flows by looking for:
• Possible alternatives to the main flow.
• Errors that might be raised to the main flow.
• Interrupts that might occur at a particular point in the main flow.
• Interrupts that might occur at any point in the main flow.

– Should try to limit the number of alternative flows. The strategies:

• Pick the most important ones.
• When there are groups of alternative flows that are very similar,
document one example and add notes to explain how the others differ
from it.
 The Use Case Specification
• Sometimes, a two-column format use case is also used.

Actor Actions System Responses Actor Actions System Responses

1. Specify the
desired chemical. 1. Specify the 2. Verify that the
2. Verify that the chemical desired chemical
requested is valid chemical. requested is valid.
4. If desired, ask 3. Displays a list of
3. Displays a list of to view the containers of the
containers of the desired history of any desired chemical.
chemical. container.
4. If desired, ask to view 5. Specify a
the history of any specific
container. container.
5. Specify a specific
container.
Example: Fully-dressed (two-column format)

34
 Use Case Constructs
• A use case may have generalization.
– Two or more use cases that have commonalities in behavior,
structure and purpose.

• Use case generalization:

– Specialises a more general use case into one or multiple specialized
(more specific use cases).
– Specialized use cases may have additional properties and
associations.
 Use Case Constructs
Use Case Generalization
 Use Case Constructs
Example:
 Use Case Constructs
• Actor generalization:
– Relationship which can exist between two actors and which shows
that one actor (descendant) inherits the role and properties of
another actor (ancestor).

Actor Generalization
 Representing inheritance relationship between actors in use
case diagram
Library System
Example:

Search Book
Don’t need this association to indicate
X VIP Member can Search Book

Reserve Book

Record
Book Loan

Record
Book Return

Record
Fine
Payment 39
 Use Case Constructs
• A use case may have two dependencies: Include and Extend
• Include dependency between use cases (i.e. common
behaviour).
– Indicates the base use case will include/call the inclusion use case.
Base use case is dependent on the included use case(s); without
it/them the base use case is incomplete.
– E.g. Activities of project manager, resource managers and system
administrators are logged when they use project management
system.
 Use Case Constructs
• Extend dependency between use cases (i.e. optional
behaviour).
– Indicates the extension use case will extend/be inserted into the
base use case. Extending use case is dependent on the base use case;
base use case is a fully functional on its own.
– E.g., Project manager may manage projects by maintaining the
project itself, its activities, or its tasks.
 Use Case Constructs
Extend Relationships

Include Relationships
 Use Case Constructs
Example:
 Benefits of Use Case
• It is task-centric and user-centric perspective.

• Leads to functional requirements that allow the users to

perform certain known tasks – avoid ‘orphan functionality’
that seem to be good but no one uses.
 Use Case Traps to Avoid
• Use cases that are not about user goal (i.e. should be from
user perspective, not system)

• Describing specific user interface elements or actions

• Failing to consider alternative flows and exceptions

• Excessive use of includes and extends relationships

• Too many use cases

• Highly complex use cases (i.e. too detailed and lengthy)

Use Case Traps to Avoid

CPRE-FL © Mathias Lampe

 Sequence Diagram
• An interaction diagram that shows how objects operate with
one another and in what order.
– Used to specify a single scenario.

– Define interaction-based system behavior.

– Shows object interactions arranged in time sequence.

– Specify interactions between objects:

• Between actors

• Between actor and system

• Between system instances

 Sequence Diagram
Example: UML sequence diagram (View patient info)
 Sequence Diagram
Example: UML sequence diagram (Transfer Data)
Sequence Diagram
Sequence Diagram
Various notations of an instance:

: Car : An unnamed instance of the Car class

car : : A named instance of an unnamed class

car : Car : A named instance of the Car class

52
Sequence Diagram

[invalid destination]
Sequence Diagram
UML Notation: ref
• "ref" fragment refers to parts specified in another sequence
diagram.
• To avoid duplication.

Note: Earlier messages not shown in the example

Reference to another SD

55
 Class Diagram
• Used when developing an object-oriented system model to
show the classes in a system and the relationships between
these classes.

• An object class can be thought of as a general definition of

one kind of system objects.

• Objects represent something in the real world (e.g. a patient,

a prescription, doctor etc.)
 Class Diagram
Example: UML class diagram – A class

Attributes

Methods/
operations/
behaviours
Object-Oriented Class Relationships

•There are FOUR types of relationship between classes in OO

approach:

1. Association
2. Aggregation
3. Composition
4. Inheritance
Association in Concept

•Association is a relationship between two objects.

– The objects have an independent lifecycle, and there is no
ownership between the objects.
– Example: Book - Author

Many Books can be written by one Author, and one Book

can be written by many Authors (no ownership), but both
have their own lifecycles (both can be created and deleted
independently)  so when a Book is destroyed, its
Author(s) does not die, and when an Author dies, their
Book(s) does not just disappear.
Many Books can be written by one Author, and one Book can be
written by many Authors.
Aggregation

•Aggregation is a special form of association. Aggregation refers

to a has-a relationship between two objects (whole/part).
– The objects have an independent lifecycle, but there is an
ownership between the objects where the whole object
contains (or has) the part objects, but the part objects can
survive or exist without the enclosing (or whole) object.
– Example: Library - Book

A Library can have many Books, while a Book cannot

belong to many Libraries (there is an ownership), but both
have their own lifecycles (both can be created and deleted
independently)  so when a Library shuts down, its Books
do not disappear and can be transferred to other Library.
A Library has many Books.

*open diamond points to whole object

Composition in Concept

•Composition is a special form of aggregation. Composition refers

to a part-of relationship between two objects (whole/part).
– The part object’s lifecycle is dependent on the whole
object, where the part object is created by the whole object
and is destroyed when the whole object is destroyed.
– Example: Building - Room

A Building can have many Rooms, while a Room cannot

belong to many Buildings (there is an ownership), and a
Room’s lifecycle is dependent on its Building  a Room
cannot exist without a Building and when a Building is
destroyed, its Rooms will no longer exist.
A Building has many Rooms.

*filled black diamond points to whole object

Inheritance/Generalisation in Concepts

•Inheritance refers to a is-a relationship between two objects

(parent/child).
– The child object inherits general data and behaviours from
the parent object, and has its own special data or
behaviours .
– Example: Member - VIPMember

A Member can borrow books from the library. A VIP

Member is a special kind of Member, who can borrow
books from the library and reserve a book.
A Member can borrow books from the library. A VIP Member is a
special kind of Member, who can borrow books from the library
and reserve a book.

Super class

Subclass
 Class Diagram
Example: UML class diagram (Generalization)

Superclass

Subclasses
 Class Diagram
Route Vehicle
Navigation device 1 1
* *
Travel Duration < Shows < Has Velocity interstate
Identification
Distance Velocity highway

1..*

Road segment Navigation device with Traffic information

1
congestion avoiding *
Road name Has Road
Start Congestion threshold Start
End Length
Naming Association

• Name of an association should be a verb or a verb phrase.

• Name of an association should start with capital letter.
• Default reading direction: Left to Right, or Top to Bottom.

Airline "Airline Employs Person"

Employs

Assigned-to Assigned-to
Person Flight Plane

Supervises "Plane Assigned-to Flight"

69
Association Multiplicity

• Multiplicity defines how many instances of a class A can be

associated with one instance of a class B.

Stocks
Store Item
1 *

Association multiplicity

70
71
 A Student can take up to five Courses.
 Student has to be enrolled in at least one course.
 Up to 300 students can enroll in a course.
 A class should have at least 10 students.

Student Course
10..300 takes 1..5

72
Class Diagram
 Entity-Relationship
Diagram
Identification

Distance
Navigation
Route calculates
N M device
Duration

M 1

Road N
Traffic jam queries
Average velocity highway

Start information
Length 1 Vehicle
belongs to

Cardinality
Average velocity interstate
Entity-Relationship Diagram
 THANK YOU
• Question?
• Tutorial (this week):
– Conduct analysis (group project)
• Draw a goal diagram
• Draw a context diagram
– Phase 2
• Lecture (next topic):
– Requirements Analysis III
 RECAP - Group Project (Phase 1):
Requirements Elicitation
Based on the chosen project title:
•Identify and classify your stakeholders – Who are they? Why are they selected?

•Determine the sources of requirements – From where you get the requirements?

•Select the suitable requirements elicitation techniques and justify your selection –
How do you elicit the requirements? Why do you choose that way?

•Recognise the activities involved in the elicitation process – What are the steps that
you take to accomplish the task?

•Execute the requirements elicitation process – Go to the field and run the show!

Describe and elaborate the above in the report. Submit at the end of the semester
(Phase 1 + 2 + 3).
 Group Project (Phase 2):
Requirements Analysis & Modelling
Based on the requirements that you elicited in Phase 1:
•Draw a Goal Diagram
— To illustrate the goals of stakeholders.

•Draw a Use Case Diagram and Use Case Templates

— To illustrate and elaborate the functional requirements.

•Draw Sequence Diagrams/Charts

— To illustrate the interactions between actors and system.

•Draw a Context Diagram and Data Flow Diagrams

— To illustrate system boundary and data flows between functions/processes.

Include the above in the report. Submit at the end of the semester
(Phase 1 + 2 + 3).
 Goal Diagram
(How to start) ULS – University
Example: Learning System
 Goal Diagram
Example: (How to start)
 Goal Diagram
(How to start)
Example:

L- Lecturer; S - Student
 Goal Diagram
(How to start)
Example:

To tackle conflicts, negotiate with the

respective stakeholders
 Context Diagram
(How to start)
Example: