System Definition Requirements Modelling Scenario Analysis

1
System Definition - Requirements Modelling
(Scenario Analysis)

• Week 2

2
Lecture Outline

• Requirements Modelling in UniMENTOR
• Scenario Analysis
• Use Cases
• Use Case Diagrams
• Requirement Modelling activities in UniMENTOR

3
Requirements Modelling in Uni-SEP

• In Uni-SEP, requirements are documented using
  scenarios
• A scenario is a textual description of an
  interaction within a system
• We have two types of scenarios
• Business Scenarios - focused on the problem that
  the business is trying to solve
• System Scenarios - focused on the solution
  provided by a particular system for a business
  scenario
• In general, we aim to have all scenarios
  understandable by all members of the project
  team, including user representatives

4
Scenarios in Uni-SEP
Described using use cases in UML
Described using interaction diagrams in UML
5
Requirement Modelling Activities in Uni-SEP

• Scenario Analysis (Use Cases)
• produce requirements overview
• identify actors
• identify initial business scenarios
• develop graphical scenario diagrams
• identify subject areas
• document business scenarios
• develop domain scenarios
• develop domain dictionary
• re-factor business scenarios
• re-factor the actors

6
Requirement Modelling Activities in Uni-SEP

• Business Domain Modelling
• modelling of the business objects in the domain
• we will look at this next week in Lecture 3
• Operational Analysis
• determining enabling technologies (Rational ROSE,
  JBuilder and Monash University computer labs in
  our case)
• determining standards employed (UniMENTOR
  documentation and relevant coding standards)
• determining the operational parameters (defined
  in the assignment specification)
• As this is a student assignment, there will not
  be any significant concentration in this area,
  though of key importance in the real world

7
Use Cases

• A Use Case is a narrative document that describes
  the sequence of events of an actor using a system
  to complete a process
• Properties of a Use Case
• it captures some user-visible function
• a use case is a relatively large end-to-end
  process
• it achieves some discrete goal for the user
• You need some understanding of the requirements
  before starting to develop your use cases
• Use cases are used to describe business scenarios

8
High-Level Use Case Example
Use Case Buy items Actors Customer,
Cashier Importance Primary Description
A Customer arrives at a checkout with items to
purchase. The Cashier records the purchase
items and collects payment. On completion, the
Customer leaves with the items
9
Components of a Use Case

• NAME - start with a verb to emphasise that it is
  a process
• ACTOR - is a role that a user plays in respect
  to the system. Actors are generally shown when
  they are the ones who need the use case.
• Also need to indicate which actor initiates
  (starts) the use case
• DESCRIPTION - short and abstract
• CROSS-REFERENCES indicate other use cases
  connected to this use case by ltltincludesgtgt,
  ltltextendsgtgt or inheritance

10
Importance

• Primary
• System needs it, no point building the system
  without it
• These have to be done to achieve the business
  goals
• Represent major common processes
• Secondary
• System should have it, but can work without it
• These have a measurable impact on the system's
  business goals
• Represent minor or rare processes
• Optional
• System doesnt require it, but it would be nice
• These would make the user happy, but without
  explicit justification
• processes that may not be implemented in the
  system depending upon resources
• This is determined by the CLIENT!

11
Use Case Type
Abstract

• High-level - terse description of the activities
  without going into details of how activities are
  performed
• Expanded - shows more detail than a high-level
  one, details the sequence of events in the
  process
• generally done in a conversational style
• show alternative courses
• shows the initiator of the use case
• Real - details concretely the process in terms of
  its real current design, input and output
  technologies

Concrete
12
Pre-conditions

• Things that must be true for the use case to
  commence
• Similar to pre-conditions (assertions) in Eiffel
  but more general
• A very common pre-condition is that a user is
  logged in to the system
• Often used to indicate business process
  relationships between use cases, where the output
  of one use case is a necessary requirements for
  another use case to proceed

13
Expanded Use Case Example
Use Case Buy Items with Cash Actors Customer
(initiator), Cashier Purpose Capture a sale and
its cash payment Overview A Customer arrives
at a checkout with items to purchase. The
Cashier records the purchase items and
collects a cash payment. On completion, the
Customer leaves with the items. Type Expand
ed Importance Primary Cross references R1.1,
R1.2, R1.7 Pre-conditions Cashier logged
in Store open
14
Expanded Use Case (2)
TYPICAL COURSE OF EVENTS
ACTOR ACTION
SYSTEM RESPONSE

• 1. This use case begins when a Customer arrives
  at the register with items to purchase.
• 2. The cashier records the identifier from each
  item. If more than one of the same item, the
  Cashier can enter the quantity as well.
• 4. Cashier indicates completion of item entry.
• 6. Cashier tells the Customer the total.

3. Determines the item price and adds the item
information to the running sales transaction.
The description and price of the item are
presented.
5. Calculates and presents the sale total.
15
Expanded Use Case (3)
ACTOR ACTION
SYSTEM RESPONSE

• 7. The Customer gives a cash payment - possibly
  greater than the sale total.
• 8. The Cashier records the cash received amount.
• 10. The Cashier deposits the cash received and
  extracts the balance owing. Cashier gives balance
  and receipt to Customer.
• 12. Customer leaves with items purchased.

9. Show the balance due back to the
Customer. Generates a receipt.
11. Logs the completed sale.
16
Expanded Use Case (4)

• Alternative Courses
• Line 2 Invalid identifier entered. Indicate
  error
• Line 7 Customer didnt have enough cash. Cancel
  sales transaction

17
Alternative Courses

• If a Typical Course of Events has multiple
  equally likely courses of action
• indicate branches in Use case
• write a subsection for each branch indicating the
  typical course of events
• have alternatives for each subsection if necessary

18
Identifying Use Cases

• Using the actors
• Identify the actors related to a system or
  organisation
• For each actor, identify the processes they
  initiate or participate in
• Using events
• Identify the external events that a system must
  respond to
• Relate the events to actors and use cases
• Examples
• Withdraw cash from ATM
• Order a product
• Enrol for a subject
• Check the spelling of a document
• Handle a telephone call

19
Guidelines for Use Cases

• Names a single, identifiable, and reasonably
  atomic behaviour of the system
• Describes the flow of events clearly enough for
  an outsider to easily understand it

20
Use Case Diagrams

• Illustrates a set of use cases for a system, the
  actors and the relationships between actors and
  use cases.
• Each use case diagram is for a particular subject
  area

Association between a use case and an actor
Icon for a use case
Icon for an actor
21
A simple use case diagram
Buy Items
Cashier
Customer
Pay for Items
22
Actor Diagrams

• In most systems, we will see several actors
• Often these actors will have similarities
• We use an actor diagram to show these
  similarities
• Actors can have one type of relationship between
  them called generalisation
• As an example, we could decide that our
  supermarket offers home delivery to pensioners

23
A possible use case diagram
Buy Items
Get Home Delivery
Customer
Cashier
Pensioner
Pay for Items
24
A correct use case diagram
Buy Items
Cashier
Customer
Pay for Items
Get Home Delivery
Pensioner
25
The Actor Diagram
In actor diagrams, you dont have to have all the
actors connected!
Customer
Cashier
Pensioner
26
Organising Use Cases

• In many situations we find that use cases are
  very similar
• We need mechanisms to handle these similarities
• Three mechanisms in the UML
• Generalisation
• Includes
• Extends

27
Generalisation

• This means that a child use case inherits the
  behaviour and meaning of the parent use case
• The child may add or override the behaviour of
  the parent
• The child may be substituted in any place the
  parent may appear in the system
• Generalisation appears as

Parent Use Case
Child Use Case
28
Example of Generalisation in a Use Case Diagram
Check Password
Validate User
Retinal Scan
29
Includes

• Includes means that a particular use case
  explicitly incorporates the behaviour of another
  use case at a location specified in that use case
• An include use case never stands alone
• An Include relationship is used to avoid
  describing the same flow of events several times,
  by putting the common behaviour in a use case of
  its own
• Include appears as

ltltincludesgtgt
30
Example of Include in a Use Case Diagram
31
Example of Include in a Track Order Use Case
System Response
Actor Action
1. Input order number
2. Verify Order Number
Include (Validate User)
3. For each part in the order, query its
status 4. Report back to user
Note includes should also be mentioned in the
overview section of the Use Case
32
Extends

• Extends is used to separate optional behaviour
  from mandatory behaviour
• The base use case implicitly incorporates the
  behaviour of another use case at a location
  specified indirectly by the extending use case
• The base use case may stand alone, but under
  certain conditions, it may be extended by another
  use case.
• It may be extended only at certain points known
  as extension points
• Extends appears

ltltextendsgtgt
33
Example of Extends in a Use Case Diagram
ltltextendsgtgt (set priority)
Place Order Extension Points Set Priority
Place Rush Order
34
Example of Extends in a Use Case
System Response
Actor Action
1. Ask for order to be place
2. Verify customer details.
Include (Validate User)
3. Collect the users order items. (set
priority) 4. Submit order for processing
Note extends should also be mentioned in the
overview section of the Use Case
35
Subject Areas

• A subject area is a group of use cases which are
  related in some way meaningful to the user and
  the system

Orders
ltltextendsgtgt
Place order
Place rush order
ltltincludesgtgt
Check password
Track order
Validate User
ltltincludesgtgt
Retinal Scan
36
More Guidelines on Use Cases

• Factor common behaviour by pulling such behaviour
  from use cases that it includes
• Factor variant behaviour by pushing such
  behaviour into other use cases that extend it
• Show only those use cases that are important to
  understand the behaviour of the system in its
  context
• Show only those actors that relate to these use
  cases

37
More Guidelines on Use Cases

• Except for simple systems, you will have several
  use case diagrams
• Each use case diagram should focus on
  communicating one aspect of a system.
• Each aspect is known as a subject area
• Provide only the level of detail essential to
  understanding that aspect
• Try to keep them simple.

38
Use Case Diagrams are NOT Data Flow Diagrams

• Use Case Diagrams dont show the order in which
  use cases happen.
• Just because one use case has to happen before
  another use case, doesnt mean there is am
  ltltincludesgtgt or ltltextendsgtgt relationship between
  them

39
A Bad Use Case Diagram
Join Gym
Gym Staff
ltltincludegtgt
Member
Visit Gym
ltltincludegtgt
ltltincludegtgt
Swim in Pool
Use Weight Machine
40
A Good Use Case Diagram
Join Gym
Gym Staff
Member
Visit Gym
Swim in Pool
Use Weight Machine
41
Your turn

• Automated Teller Machine (ATM) at Bank
• Who are the Actors?
• Name four use cases that could be developed

42
UniMENTOR and Use Cases

• Use cases and use case diagrams are used to
  document the following activities
• identify actors
• identify initial business scenarios
• develop graphical scenario diagrams
• identify subject areas
• document business scenarios
• Re-factoring of the business scenarios and actors
  is done as we pursue these activities and
  discover commonalties between actors and scenarios

43
Summary

• Scenario Analysis is a key activity in
  requirements modelling
• Use cases and use case diagrams are the methods
  defined in the UML to document the business
  scenarios of requirements modelling