1


Requirements is the toughest part of software development
◦ A Use-Case is a powerful tool to understand
 Who your users are (including interacting systems)
 What functions the system shall provide
 How these functions work at a high level

Spend adequate time on requirements and in the elaboration phase
2


While finding use cases, you might have to make changes to your set of actors
◦ All actor changes should be updated in the textual description of actors and use cases

Also watch for the possible use of extends and includes relationships

Naming a Use Case
◦ Should provide a general description of the use case function (verb or verb and noun [e.g.
Borrow Books])
3

System Boundary
Cashier
Adapted from Larman “Applying UML and Patterns”
POST: Point of Sale Terminal Use Case
Buy Item
Log In
Customer
Refund a Purchased Item
4

Cashier
System Administrator
POST
Buy Item
Log In
Refund a Purchased Item
Customer
Start Up
Manager
Manage Users
And a Lot More
MH
Adapted from Larman “Applying UML and Patterns”
5

Use case:
Actors:
Type:
Description:
Buy Item
Customer (initiator), Cashier
Primary
The Customer arrives at the checkout with items to purchase.
The Cashier records the purchase items and collects a payment.
On completion the Customer leaves with the items
7

Use case: Buy Item
Actors:
Type:
Customer (initiator), Cashier
Primary and essential
Description: The Customer arrives at the checkout with items to purchase. The Cashier records the purchase items and collects a payment. On completion the
Customer leaves with the items.
Use-Cases: Cashier must have completed the Log In use-case
8


Other Types of Relationships for Use Cases
◦ Generalization
◦ Include
◦ Extend
9


Generalization Relationship
◦ Represented by a line and a hollow arrow
 From child to parent
Child use case Parent use case
10

11


Include Relationship
◦ Represents the inclusion of the functionality of one use case within another
◦ Arrow is drawn from the base use case to the used use case
◦ Write << include >> above arrowhead line
12


Extend relationship
◦ Represents the extension of the use case to include optional functionality
◦ Arrow is drawn from the extension use case to the base use case
◦ Write << extend >> above arrowhead line
13

14



Pro:
◦ Reduces redundancy in use cases
◦ Reduces complexity within a use case
Con
◦ May introduce complexity to use case diagram
15





Use cases are described using the language of the customer
Use cases provide an easily-understood communication mechanism
When requirements are traced, they make it difficult for requirements to fall through the cracks
Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level
16


Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?)

Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements is not obvious
17


Activity diagrams as defined in the Unified
Modelling Language are derived from various techniques to visually illustrate workflows
18




An activity diagram can be used to model an entire business process
Similar to flow charts
◦ Contain decision points
◦ But with far less details
At the level of level 2 DFD’s
◦ But without data stores (and with logic added)




 consuming
The modeling process would be enhanced and supported by using an activity diagram
Get a basic model without spending too much time on the process
It makes you more familiar with the system and therefore

Start
End
Activity
Decision
Transition
Synchronisation Bar
ActionState1

22






Show how activities depend on one another
Can be divided into swimlanes
(what object is responsible for which activity)
A single transition comes from each activity
A transition may “branch” into two or more mutually exclusive transitions
A transition may “fork” into two or more parallel activities

Calculate payroll
[hours < =40]
Normal payroll
[hours > 40]
Overtime, get authorization
Guard expressions [ ] = transition labels


Always inlcude end point

Avoid black holes

Avoid miracles

Decision points reflect previous activity
ActionState1
ActionState1


A fork should have a corresponding join

Forks have one entry transition

Joins have one exit transition
Activity 2 Activity 1






Identify scope
◦ Document assumptions
Add start and end points
Add activities
Add transitions
Add decision points (optional)







Departments make spending
Budget is to
3 way
in the allocated budget file
If budget exceeded, request is
Approved requests are
and used purchase orders (PO’s) for suppliers
Goods received notes (GRN) are with PO’s to identify any discrepancies
When supplier invoice is received,
between PO, GRN and invoice prior to payment








Make spending request
Check budget
Reject request
Create purchase order
Match GRN with PO
◦ After receiving the goods
Match GRN and PO to invoice
◦ After receiving invoice
Pay invoice

Make spending request
Check budget
[Request > Budget]
Reject Request
[Request < Budget]
Create Purchase Order
Match GRN with PO
3 way match GRN / PO / Invoice
Invoice payment


You can keep expanding the list of activities as see fit

Those activities could be included which likely have IS (i.e. data) implications
◦ the fact that the step was completed need to be registered


Receive goods
◦ GRN match represent this step
◦ Or may be inserted on its own right before matching GRN with PO, say, if needed for warehousing

Create Purchase Order
Receive Goods
Match GRN with PO
Place goods to warehouse
Inform Owner of order


There might be activities which are not in sequential order

Either of them may happen first, their order is not relevant


Which should happen first?
◦ Receive invoice
◦ Match GRN and PO

Does not matter, they are independent
◦ Invoice may be sent with the order
◦ Or might even be sent to a different department
(warehouse vs. finance)

Make spending request
Check Budget
[Request > Budget]
Reject request
[Request < Budget]
Create Purchase Order
Match GRN with PO Receive Invoice
3 way match GRN / PO / Invoice
[No discrepancy]
[Invoice on hold]
Invoice payment