UoL CS Notes

Functional Requirements and Use Case Analysis

COMP201 Lectures 2021-09-27

This lecture is targeted at coursework 1.1.

Requirements

Requirements can be functional:

What the system should do.
Provide a login facility that uses a username and password.

They can also be non-functional:

Constrains on how the functions are provided.
Username must be longer than six characters.

Non-functional requirements don’t concern the user and relate to system services.

Use Cases

These show how external actors interact with the system.

A use-case is a task which the actor needs to perform with the help of the system.

Actors can be a user or another system.

A set of use-cases describe all possible interaction with the system.

Actors

Actors are anything external to the system which the system interacts with.

These include:

Human actors.
Other systems.
External sensors.

Use Case Description Example

The details of each use case should also be documented by a use case description:

Print receipt – A customer has paid for an item via a valid payment method. The till should print a receipt indicating the current date and time, the price, the payment type and the member of staff who dealt with the sale.
- Alternate Case – No print paper available – Print out “Please enter new till paper” to the cashier’s terminal. Try to print again after 10 seconds.

Use Case Diagram Example

left to right direction
rectangle {
    actor as Actor
    Actor <--> (Article Printing)
}
note right of (Article Printing)
    Use Case
endnote

ATM Use Case Example

Actors
- Customers
- Bank staff
- ATM service engineer
Use cases
- Withdraw cash
- Check balance
- Add cash to machine
- Check security video recording

ATM Case Diagram

Actor "Bank Customer" as c
Actor "Bank Staff" as s
Actor "Service Engineer" as e
package "ATM System" {
usecase "View Balance" as vb
usecase "Withdraw Cash" as wc
usecase "Print Statement" as ps
usecase "Check Cash Stock" as ccs
usecase "Download Video Recording" as dvr
usecase "Topup Cash" as tc
}
c --- vb
c --- wc
c --- ps
s --- ccs
s --- dvr
e --- tc

The boundary of the system is defined by the box.

Advanced Use Case Diagrams

Boundaries - A labelled box can be drawn around a set of use cases to denote the system boundary.
Inheritance - Can be used between actors to show that all use cases of one actor are available to the other:
```
  left to right direction
  :Bank Staff: --|> :Customer:
```

Include Relations - If several use cases include another use case:

  left to right direction
  :Bank customer: as bc
  package "ATM System" {
      (View Balance) as vb 
      (Withdraw Cash) as wc
      (Print Statement) as ps
      (Authenticate Customer) as ac
  }
  bc --- vb
  bc --- wc
  bc --- ps
  vb --> ac:includes
  wc --> ac:includes
  ps --> ac:includes

Extend Relations - If a use case has two or more significantly different outcomes, we can show this by extending the use case to a main use case:

  left to right direction
  :Bank customer: as bc
  package "ATM System" {
      (View Balance) as vb 
      (Withdraw Cash) as wc
      (Print Statement) as ps
      (Authenticate Customer) as ac
      (Re-enter PIN) as pin
      (Reject Transaction) as rt
  }
  bc --- vb
  bc --- wc
  bc --- ps
  vb --> ac:includes
  wc --> ac:includes
  ps --> ac:includes	
  pin -up-> ac:extends
  rt -up-> ac:extends

Includes is for mandatory behaviour and extends is for optional/conditional behaviour.

Use Case Template

This template should be used for coursework 1.1:

Attribute of Use Case	Description
ID	Short ID, usefull for diagrams and reference.
Name	Full name
Description	Full Description
Pre-condition	What muse be true before the use case can proceed.
Event flow	Flow of behaviour that makes up this use case.
Post-condition	What should be true if the use case successfully completes.
Includes	What other use cases are used.
Exensions	Optional behaviour.
Triggers	What makes the use case happen.

Use cases don’t describe internal behaviour and must describe behaviour with external actors.

Example Template

These are some of the use cases for an ATM:

ID	UC1
Name	Withdraw Cash
Description	Bank customer withdraws cash from the machine
Pre-condition	ATM in service
Pre-condition	ATM has sufficient cash
Includes	UC2 (Authenticate Customer)
Event flow	Choose quick cash or enter exact amount, choose receipt option, take cash.
Extensions	UC4 (Balance too Low)
Triggers	Withdraw cash request entered.
Post-condition	Balance updated.

ID	UC2
Name	Authenticate Customer
Description	Bank customer proves their identity to the ATM.
Pre-condition	ATM in service
Event flow	If user is already authenticated exit from use case, user enters card PIN number, user re-enters PIN if PIN is incorrect.
Extensions	UC5 (Card Stolen), UC6 (Pin Entry Failure)
Triggers	Authenticated service requested and user not authenticated.
Post-condition	User is authenticated if credential are correct.

ID	UC3
Name	Check Balance
Description	Bank customer retrieves a balance for their account.
Pre-condition	ATM in service
Includes	UC2 (Authenticate Customer)
Event flow	Choose onscreen or paper balance.
Triggers	Check balance is requested.

ID	UC4
Name	Balance too Low
Description	Bank customer cannot make cash withdrawal due to low balance.
Event flow	Customer chooses smaller amount or cancels the transaction.
Triggers	Cash chosen is grater than available balance.