INFO2000A

System Requirements Modelling

Pakiso Khomokhoana (PhD)
Room CLM131
[email protected]
 Recap [1]
• Requirements Modelling (e.g.,The “How” of fact finding)
• Some information about modelling (Contextual diagrams,
Domain model diagrams!)
• IS Project
✓No names for Groups 2, 12, and 23
✓Dateline for self-enrolment into groups was – [03 March, 2025].
✓Recordings for “MS0” – Submission link – [07 March, 2025].
✓Any questions on the project?
 Lecture Materials Acknowledgement
• These lecture materials are largely based on:
• Satzinger, J., Jackson, R. & Burd, S. (2016). Introduction to Systems Analysis and
Design: An Agile, Iterative Approach. (7th Ed.). Course Technology, Cengage Learning.
• Tilley, S. (2025). Systems Analysis and Design. 13th Edition. Cengage Learning. ISBN:
979-8-214-40591-9.
• Lano, K. (2009). Model-Driven Software Development with UML and Java. Course
Technology, Cengage Learning.
• Larman, C. (2005). Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development. (3rd Ed.). Pearson.
• Marakas, G. (2006). Systems Analysis & Design: An Active Approach. (2nd Ed.),
Boston: McGraw-Hill.
• Lecture slides from past instructors and other internet resources have also
been utilised.
System Requirements Modelling
 Learning Outcomes [1]
On completion of INFO2000A, you should be able to:
• Demonstrate an awareness of information systems as a career
path, including potential roles and required knowledge, skills and
attributes.
• Demonstrate an emerging ability to engage critically with, and
propose solutions to, complex “real world” problems.
• Perform the tasks of the planning, requirements gathering and
analysis phases of the systems development lifecycle (SDLC)
through both written assessment and team-based project work.
• Develop a professional-level requirements specification.
 Learning Outcomes [2]
• Demonstrate an understanding of the complexity of information
systems project management through experiential learning and
reflection.
• Demonstrate competence in using professional modelling
tools to represent requirements and logical models.
• Demonstrate software development skills using a prescribed
development environment.
• Develop and demonstrate professional competence in business
and technical writing, and persuasive presentations.
Where we are

Source: Satzinger et al.

 What do we do with the functional
requirements we gather?
• Functional requirements are documented using a variety of
models.
• A model is a representation of an artefact (either existing or to
be developed), used to analyse or design the artefact, i.e. they
are the blueprints that guide the construction process.
✓Expressed in precise graphical or textual notation, using a specific
language of symbols.
✓In systems development, we are concerned with the Unified Modelling
Language (UML).
• Virtually all contemporary approaches to systems development
begin requirements modelling with the concept of a use case.
 Defining Use Cases [1]
• A use case shows an activity that the system performs, usually
in response to a request by a user (Satzinger et al., 2016).
• A use case shows a service provided by the system and with
which users/agents/actors this service interacts (Lano, 2009).
• Use cases provide an excellent picture of the system context,
showing the boundary of the system, what lies outside of it and
how it gets used (Larman, 2005).
• Use cases are grouped sequences of identified requirements
that work together to perform (a)n activity/process/service.
• Use cases focus primarily on FUNCTIONAL REQUIREMENTS.
 Defining Use Cases [2]
• Use cases manipulate the “things” normally identified in the
domain model class diagram (see next slide!).
• What do we mean by “manipulate”?
✓Think in data terms.
✓Put something in, look at something, change something, remove
something.
✓Capture/create something, view/read something, update/modify
something, delete something.
Domain Model
 Use Cases [3]
• ... emphasise user goals and perspective, i.e. are highly user-
centric.
• ... represent the analyst’s understanding of a particular business
process.
• … are used as a high-level communication tool between the
analyst and users, stakeholders, management, team members
etc.
• Has the analyst understood the process and modelled it correctly?
• Why do you think this is often done diagrammatically?
• Cliché alert: “A picture tells a thousand words”.
 Use Cases [4]
• … are designed to be simple so that users and other stakeholders
can actively contribute to their development.
• … provide a “black box” view of the functionality of the system, i.e.
they omit the detail of how the functionality is actually carried out.
✓Why do you think this is so?
o Because systems analysis is concerned with the “what” and not the “how”.
• This is particularly important to bear in mind for those that usually
code first and ask questions later ☺
 Use Case Terminology and Notation
• Labelled ovals represent use cases:
✓Use cases are labelled using descriptive verb-noun phrase notation.
✓Use cases always depict a SINGLE occurrence of a SINGLE process/event.
• Labelled stick figures represent actors/users/agents:
✓An actor is something with behaviour.
✓Actor names are always SINGULAR.
✓Represents a role (e.g. customer, administrator, etc.) and not a specific
person.
✓Specific people could play several roles, each of which will require a separate
use case.
✓Actors can also be other systems.
• Connecting lines join use cases to their actors.
• Labelled rectangles represent the automation (or system) boundary,
i.e. defines the scope of the system being represented:
✓The actor’s communication with the use case crosses the boundary.
Generic Use Case Diagram for a System [1]
use case 1

use case 2

use case 3
Actor 1

use case 4

use case 5

use case 6

Actor 2
System name
Generic Use Case Diagram for a System [2]
Primary
Actor use case 1 Labelled use case and connecting line

use case 2

use case 3
Actor 1

use case 4
Supporting
Actor
use case 5

use case 6

Actor 2
System name Labelled boundary

16
 A Simple Use Case Example
• For a banking system:
• There are two (2) users/clients/actors, namely:
✓A Customer, who can view his/her account(s), transfer money,
withdraw money and view statements.
✓A Bank Clerk (or Bank Employee), who can add or remove customers
and add or remove accounts.
• Required:
✓Identify and name each unique process (i.e. UC), and then draw a UC
diagram.
 view account

transfer money

withdraw money
Customer

view statement

add customer

remove customer

add account Bank

Clerk
remove account

Banking System

Use Case Diagram: Banking System

 Lecture Exercise 1
• Construct a use case diagram for the following restaurant
scenario:
✓A customer can order a meal from a waiter, eat the meal, and pay for the
meal through the waiter.
✓A waiter takes the order, serves the meal, and handles the payment for the
meal.
✓A chef cooks the meal based on the order.
Use Case Diagram: Restaurant
serve meal

pay for meal

order meal
Waiter

cook meal

eat meal

Customer Chef
Restaurant System

Use Case Diagram: Restaurant System

 Lecture Exercise 2
• Construct a use case diagram for a simple cash only point of sale
(POS) system:
✓Sales are captured by a Cashier. They are also recorded by an external
Accounting System. Cashiers also capture returns, which must first be
approved by a Manager and, once approved, are also recorded in the
Accounting System. During peak trading hours, managers may also
capture sales and returns as if they were cashiers.
Use Case Diagram: Point of Sale (POS) System [1]

create sale

create return
Cashier Accounting
System

Point of Sale (POS) System

Manager

Use Case Diagram: Point of Sale (POS) System

Use Case Diagram: Point of Sale (POS) System [2]

create sale

create return
Cashier Accounting
System

Point of Sale (POS) System

Manager

Use Case Diagram: Point of Sale (POS) System

Primary actor(s) typically Supporting actor(s) typically

shown on the left shown on the right 23
 Adding More Detail
• Sometimes a use case might need to use (or invoke) the
functionality of another use case in order to perform its function,
i.e. it is required, not optional.
✓This is referred to as an includes relationship.
✓Guillemet (or angle quote) notation is used, together with a dashed
arrow, i.e.
<<includes>>
• Sometimes a use case might have optional or supplementary
functionality that is not necessarily used (or invoked) every time.
✓This referred to as an extends relationship (note the reversed arrow)
<<extends>>
 Lecture Exercise 3
• In the restaurant scenario, a customer may order a drink from a
waiter, which will also have to be served by the waiter and be paid
for with the meal.
✓Extend your solution to Lecture Exercise 1 to include these new
business rules.
 Use Case Diagram : Restaurant
serve meal <<extends>> serve drink

pay for meal <<extends>> pay for drink

order meal <<extends>> order drink

Waiter

cook meal

eat meal <<extends>> drink drink

Chef
Customer Use Case Diagram: Restaurant
 Validating and Refining Use Cases
• CRUD technique:
✓Create a new instance of a thing,
✓Read/Report on a thing.
✓Update data relating to a thing.
✓Delete an instance of a thing (usually ARCHIVE, not actually delete…
why?).
• Based on what we might need to do with “things” in our
environment.
• Very focused on data and database design.
• Often used as a cross-check to ensure that use cases are not
missed, i.e. is the scope we communicate to the client complete?
 Simplified CRUD Steps
1. Use the domain model class diagram to identify all entities
or “things” or domain classes in the system.

2. For each entity or “thing”, verify that a use case exists to

create an instance, view/read instance(s), update instance(s)
and delete (archive) instance(s), i.e. each “thing” gets four (4)
use cases by default.

3. If a required use case has been overlooked, create it.

Simple CRUD Example for an Airtime System
Entity/Domain Class CRUD Verified Use Case

Customer Create Create customer

Read/Report Read customer or

View customer or
Search customer

Update Update customer

(Note: This could mean updating airtime balance
OR updating demographic data)

Delete Delete customer or

Archive customer
 Our Rule in INFO2000A & INFO2001A
•Let us stick to:
✓Order meal
•Not
• Ordering meal
• order meal
• Order_meal
• Order Meal
• ORDER MEAL
• etc.
 CRUD Verification [1]
• All use case names begin with a verb followed by a “thing” in the
business environment.
• CRUD verification often involves translating from “business speak”
into “analysis speak”.
✓“register customer” or “add customer” would equate to “create customer”
✓“display customer” or “show customer” would equate to “read customer”
✓“modify customer” or “change customer” would equate to “update customer”
• Name the use case similarly to the business task being performed by
the user, e.g.
✓Goal: recording a sale, UC: create sale
✓Goal: changing a customer’s details, UC: update customer
• Sometimes “business speak” can mislead us as to what type of UC
the process actually involves (see next slide!).
 view account read account

transfer money create transfer

withdraw money create withdrawal

Customer Customer

view statement read account

add customer create customer

remove customer delete customer

add account Bank create account Bank

Clerk Clerk
remove account delete account

Banking System Banking System

Use Case Diagram: Banking System Use Case Diagram: Banking System
32
 The Deliverable: A Use Case Set
• All identified use cases are compiled into a use case set.
• Essentially a structured list.
• Related use cases are grouped together under appropriate
headings.
• Key functionality is thereby made obvious, therefore…
• A comprehensive use case set gives us…
• … the PROJECT SCOPE
• This can be communicated to and negotiated with the client with
either the structured list OR be used to generate a project
scope statement in paragraph form.
 Use Case Set Example [1]
• Customer-related use cases:
✓Create customer
✓Read/view customer
✓Update customer
• Sale-related use cases
✓Create sale
✓Read/view sale
✓Update sale
• Return-related use cases:
✓Create return
✓Read/view return
✓Update return
• Reporting-related use cases:
✓Generate report
 Simple Use Case Set Example [2]
• Customer-related use cases:
• Create customer
• Read/view customer
• Update customer
• Sale-related use cases
• Create sale These relate to identified “things”
• Read/view sale
• Update sale
• Return-related use cases:
• Create return
• Read/view return
• Update return
• Reporting-related use cases: This remains generic at this point
and is included by default. Indicates
• Generate report a use case that provides access to
our reporting functionality.

35
 Use Case Sets can be tabular and include
more details
Class UC Name Related UCs

Customer Create customer

Read customer

Update customer Read customer (includes)

Sale Create sale

Read sale

Update sale Read sale (includes)

N/A Generate report

 Testing a Use Case Set
• There are tests to check whether identified use cases are valid or
not.
✓The Boss Test
o?
✓The Elementary Business Process (EBP) Test
o?
✓The Size Test
o?
 The Boss Test (for Use Cases)
• A simple guideline used in use case modeling to determine
whether a use case is meaningful from a business perspective.
• A valid use case should describe a business-relevant process
that, if completed, would make sense when reported to a boss or
stakeholder.
• Applying the Test:
✓Imagine telling your boss: “I just completed [use case name]”.
✓If your boss finds it meaningful, the use case passes the test.
✓If your boss asks for clarification (e.g., “So what?” or “What does that
mean?”), the use case fails the test (see examples in the next slide!).
The Boss Test (for Use Cases) ─ Examples
 Elementary Business Process (EBP) Test
• A guideline used in software and business process modelling to
determine whether a process is well-defined and manageable.
• An Elementary Business Process (EBP) is a small, self-contained unit
of work that:
✓Adds measurable business value to the organisation.
✓Is meaningful from a business perspective (i.e., an independent, complete
transaction).
✓Occurs in a short period (typically seconds to minutes).
✓Is performed by a single person or system in response to a business event.
• Example of an EBP in an Online Store:
✓Valid EBP: “A customer places an order”. (It is a self-contained action that adds
business value).
✓Invalid EBP: “A system updates the database with an order number”. (This is
too technical and not meaningful from a business standpoint).
 The Size Test (for Use Cases)
• A guideline used in use case modeling to ensure that a use case
is appropriately scoped—neither too broad nor too detailed.
• A valid use case should be small enough to be completed in a
single business interaction but large enough to provide
meaningful business value (see next slide!).
Applying The Size Test (for Use Cases)
 Lecture Exercise 4
• Which of these is a valid use case? If not, which test(s) is/are
failed?
✓Negotiate a supplier contract.
✓Create a sale.
✓Log in.
✓Calculate VAT.
✓Update customer details.

• Some are valid use cases, but can they be named better?
 We can also try a Process/Event driven
Approach (UC Identification)
• Use cases are identified by determining the business events to
which the system must respond.
• This is called event decomposition (or event analysis).
• An event is something that occurs at a specific time and place, can
be precisely identified and must be remembered by the system.
• It is usually something that produces, uses or modifies data within
the system, i.e. affects the underlying database in some way.
• Often a group of events can belong to the same use case, e.g. enter
item, enter payment amount, calculate change all belong to Create
sale.
 Types of Events
• External events occur outside the system and are usually initiated by
an external actor, usually “the user”.
✓e.g. A customer places an online order; A student submits a course
registration form; A user logs into their account.
• Temporal events occur as a result of reaching a certain point in time.
✓e.g. A bank automatically deducts a loan payment on the due date; A
system generates a monthly sales report at midnight; A reminder email is
sent one day before an appointment.
• State events occur when something happens inside the system that
triggers some process.
✓e.g. A membership status changes from “active” to “expired” when the
subscription period ends; An inventory system automatically reorders
stock when the quantity falls below a certain level; A loan application
moves to the next approval stage once all required documents are
uploaded.
Separating events from things that happen
before (triggers) and after (responses)
 The True Power of Use Cases
• Diagramming is the easy part .
• Many regard use case diagrams as secondary in use case
work.
• Use cases are text documents, which means doing use case
work means to write text.
• These text documents (or text models) are known as use case
descriptions.
• Use case descriptions have three varying levels of detail, i.e.
• Brief, intermediate, detailed.
• Sometimes called brief, casual and fully dressed ☺.
 Use Case Formats
• Brief
• Terse/concise/succinct, one paragraph summary.
• Covers a single, usually well-understood success scenario.
• Done during early requirements analysis for a quick sense of scope and
requirements, i.e. only a first step.
• Intermediate/Casual
• Multiple paragraph format containing more detail, also covering potential
variations/exceptions.
• Still used as above, i.e. early in the process.
• Detailed/Fully dressed
• All steps (including potential variations/exceptions) written in detail for fuller
understanding.
• Include supporting sections such as pre- and post-conditions, exceptions etc.
• Only a few significant and high-value use cases are written in detail
(sometimes only around 10%) before design and programming starts,
especially in “newer”, more agile approaches to systems development.
Detailed/fully Dressed Use Case Template
Use case name: Verb-noun phrase format
Scope: Name of the system or sub-system of which this use case is a
part
Triggering event: What sets the use case in motion?
Brief description: One paragraph summary (i.e. the brief use case description)
Actor(s): Primary and supporting actors (classified)
Related use cases: Use cases that will/may be invoked
Stakeholders and interests: Who cares about this use case and why?
Pre-conditions: What must be true for the use case to begin?
Post-conditions: What must be true after successful execution?
Flow of activities: List the process in numbered sequence, assuming a successful
(sometimes called outcome and using the perfect technology assumption
Main success scenario: or Note: Sometimes called the “happy path” ☺
Basic flow:)
Extensions: List alternative scenarios of success or failure
(sometimes called Note: Alternative/branching/exception statements are often
Alternative flows:) deferred to this section
50
 Flow of Activities Section
Expressed in a two-column, numbered, sequential format that
shows actor and system responsibilities, e.g.
Flow of Actor System
activities: 1. A new customer requests 1.1 Prompts customer to
to create an account enter demographic data

2. Customer enters 2.1 Records demographic

demographic data data
2.2 Prompts customer to
enter credit card details
3. Customer enters credit
card details 3.1 Records credit card
details
3.2 Verifies credit card details
with external credit bureau
3.3 Creates a new customer
account using captured
customer data
3.4 Confirms new account
creation 51
 Lecture Exercise 5
• … for a CASH ONLY point of sale (POS) system

• Write a fully dressed use case description for the Create sale use case based on the
following process description:
✓ A Customer arrives at a checkout point with one or more items to purchase. The Cashier requests to
create a new sale. As each item is added to the sale, the system displays a description of that item
and a running total. Items and descriptions are held in an external Inventory System. After all items
have been added, the Cashier indicates the end of the sale and the system displays the total cost.
The Cashier captures the Customer’s payment on the system and the system then requests the
Inventory System to update the stock level(s) based on the new sale. The system generates and
prints a receipt which the Cashier hands over to the Customer. The Customer then leaves with the
items.
Use case name: Create sale
Scope: Point of sale (POS) system
Triggering event: Cashier requests to create a sale
Brief description: Summary of the process (see previous slide, but remember the shirt
example!)
Actor(s): Cashier (Primary)
Inventory System (Supporting)
Related use cases: N/A
Stakeholders & interests: Cashier: Wants quick and accurate capture of sales
Customer: Wants to purchase items quickly and receive proof of
purchase
Inventory System: Wants update requests in correct format/structure
Retail organisation: Wants quick and accurate transaction
processing, clean data for reporting purposes and customer
satisfaction
Pre-conditions: N/A
Post-conditions: Sale is recorded in the system
Inventory update request has been sent to the Inventory System
Receipt is generated
Flow of activities: 1. Cashier requests to create sale 1.1 Prompts for item

2. Cashier enters item 2.1 Requests price from Inventory

System
Steps 1.1, 2 and 2.1 to 2.7 are 2.2 Requests description from
repeated for each item in the sale Inventory System
2.3 Calculates VAT on price
2.4 Adds price plus VAT to
running total
2.5 Displays item description
2.6 Displays running total
2.7 Adds item to sale

3. Cashier indicates end of sale 3.1 Displays total cost

4. Cashier enters amount 4.1 Calculates change due

tendered by Customer 4.2 Displays change due
4.3 Records payment
4.4 Requests update of inventory
in Inventory System
4.5 Generates receipt
 Remember
• You do not have to construct your UC description in the same order it is
presented to the client.

• Doing the top half before the bottom half is like compiling the highlights
package before you have watched the football match.

• Do the flow of activities first!

• Critical elements like triggering event, related UCs and post-conditions

then become much simpler, as does writing the brief UC description.
 Use Case Diagram: create sale
Note:
• How little detail appears in
the use case diagram
compared to the fully
create sale Inventory System dressed use case
description
Cashier
Create sale • AND the value of
constructing the text model
Authorisation System
BEFORE the diagram,
which then becomes very
simple to draw
 Reminders about Use Cases
• Text models should ALWAYS come BEFORE diagrams… why?
• Diagrams are exercises in translation from a text model, NOT
creation from scratch.
• Extensions normally comprise the majority of the text… why?
✓Capturing the true complexity of a “real world” business process in a
“real world” client environment.
• Note: Some stakeholder interests are best handled as non-
functional requirements… what would be examples?
 A note on Related Use Cases
• ONLY recorded in the Related UCs section of the UC description
AND shown on the UC diagram when the flow of activities
EXPLICITLY invokes the functionality of another UC, e.g.
Flow of activities: 1. Administrator requests to update 1.1 Prompts for customer ID number
customer

2. Administrator enters ID number 2.1 Uses ID number to invoke Search

customer use case
2.2 Prompts for new customer data
… …

update customer <<includes>> search customer

Administrator

Update Customer
58
Use Case Diagram: Update customer
 Practice Exercise
• Consider the following scenario:
• Students may have their demographic data and/or status, e.g. “YOS1” for
first year, “YOS2” for second year etc., updated by administrators at the
Faculty Office. The administrator requests to begin the update process.
He/she then enters the student’s student number when prompted. The
system uses the student number to retrieve and display the student’s
demographic data and current status as confirmation and prompts for a
choice of update (demographic data or status change). The administrator
makes his/her selection and then enters the update according to
appropriate prompts from the system. The system then captures the
update. Both the administrator and the student receive e-mail
confirmation when the update is successful.
✓Construct a PARTIAL fully-dressed use case description including: use case
name, triggering event, actor(s), related use cases, pre-conditions, post-
conditions, flow of activities and extensions (if necessary).
✓Draw a use case diagram for the use case. 59
Any Questions?
Thank You!