1. Object-Oriented Software Engineering
Use Case Fundamentals
Paul J Krause

2. Outline Brief description of Use Cases and Actors
Use Case terminology and methodology
Detailed description of Use Case template
Validating Use Cases

3. What are Actors and Use Cases?
Actors - users of the system
external entities (people or other systems) who interact with the system to achieve a desired goal.
Use Cases - what happens when Actors interact with the system
by recording all the ways the system is used (“cases of use”) we accumulate all the goals or requirements of the system.

4. Therefore:
The Use Case is a collection of sequences of actions or events relating to a particular goal.
The Collection of Use Cases (the Requirements Specification) should define all system behaviour relevant to the actors to assure them that all their goals are carried out properly.
Any system behaviour that is irrelevant to the actors should not be included in the Use Case.

5. Actors: Primary and Secondary
Primary Actor:
a role name for the Actor that initiates the Use Case.
Secondary Actor:
other systems needed to accomplish Use Case.

6. Identifying Actors Who uses the system? Who installs the system?
Who starts up the system?
Who maintains the system?
Who shuts down the system?
What other systems use the system?
Who gets information from this system?
Who provides information to the system?
Does anything automatically happen at preset times?

7. Examples of Actors
Clerk
Supplier
Customer
Shipping
Company

8. Use Case Diagram Customer Supplier Place Order Supply Product
Get Order
Status
Clerk
Shipping
Company
Deliver
Package
Calculate
Postage

9. Use Cases:
Hold Functional Requirements in a easy to read, easy to track text format.
Represents the goal of an interaction between an actor and the system. The goal represents a meaningful and measurable objective for the actor.
Records a set of paths (scenarios) that traverse an actor from a trigger event (start of the use case) to the goal (success scenarios).
Records a set of scenarios that traverse an actor from a trigger event toward a goal but fall short of the goal (failure scenarios or exceptional events).
Are multi-level, one use case can use/extend the functionality of another.

10. Use Cases Do Not ... Specify User Interface Design
They specify the intent, not the action detail.
Specify implementation detail
unless it is of critical importance for the Actor in order to be assured their goal has been met.

11. Use Cases Do ... Capture the Requirements for the system;
Act as a springboard for software design;
Act as a reference to validate the design against;
Act as a foundation for Software Test and Quality Assurance;
Act as an initial framework for the User Manual (if necessary).

12. Outline Brief description of Use Cases and Actors
Use Case terminology and methodology
Detailed description of Use Case template
Validating Use Cases

13. Use Case Definitions Primary Actors: Secondary Actors:
The Actor(s) using the system to achieve a goal.
Secondary Actors:
Actors that the system needs assistance from to achieve the Primary Actor’s goal.

14. A Use Case ...
Is a collection of possible scenarios between the system under discussion and external Actors;
Is characterised by the goal the Actor has;
Shows how the Primary Actor’s goal might be delivered or might fail.

15. What’s a Use Case made of?
Use Cases are goals made up of scenarios.
Scenarios consist of a sequence of steps to achieve the goal:
each step in a scenario is a “mini” goal of the use case which may be:
another Use Case;
an autonomous action or event.
This last point means that Use Cases can have a hierarchical relationship.

16. Levels: Summary Level Use Case: User Level Use Case:
Represent collections of User Level Goals.
User Level Use Case:
Represents a User Task - the level of greatest interest.
Sub-function level Use Case:
A sub-goal or step below the main level of interest to the User.

17. Outline Brief description of Use Cases and Actors
Use Case terminology and methodology
Detailed description of Use Case template
Validating Use Cases

18. Reference: The following template is based on that used in:
Alistair Cockburn, Writing Effective Use Cases, Addison Wesley.
Other templates are available

19. Use Case Template
Use Case: <the name should be the goal as a short active verb phrase>
Exercise: Let’s have some names please!

20. CHARACTERISTIC INFORMATION
Description: <a longer statement of the goal>
Level: <Summary, Primary task, or Subfunction>
Preconditions: <what we expect of the world>
Postconditions: <the state of the world upon successful completion >
Primary Actor: <a role name for the actor that initiates the Use Case>
Secondary Actors: <Other actors needed to accomplish Use Case>

21. FLOW OF EVENTS
Trigger: <the action upon the system that starts the use case; may be a time event>
<put here the actions that take place from trigger to goal delivery, and any cleanup after>
<step #> <action description> ….

22. EXCEPTIONAL EVENTS
<put here the sub-variations that will cause eventual bifurcation in the flow of events>
<step or variation # > <list of sub-variations> ….

23. RELATED INFORMATION
(optional, applies to indicate the <<uses>>, <<extends>> relations)
Superordinate Use Case: <optional, name of use case that includes this one>
Subordinate Use Cases: <optional, depending on tools, links to sub.use cases>

24. Use Case: Place Order
Customer
Place
Order

25. Use Case: Place Order
Description: This Use Case describes how a customer selects an item to purchase and then places an order for that item.
Level: Primary task
Preconditions: The Customer is logged into the system
Postconditions: A product has been ordered
Primary Actor: Customer
Secondary Actors: Credit Company

26. Place Order: Flow of Events
Trigger: The Customer selects a Product category
The Customer browses the chosen Product category page
The Customer selects a specific Product to purchase
The Customer adds the Product to their Shopping Cart
The Customer may repeat events 1, 2 and 3 to add additional items to their Shopping Cart
When ready, the Customer requests that the Order be commited to
The Credit Company is notified to authorise the Customer’s credit rating
If the credit rating is positive, the Order will be placed

27. Nouns as Candidate Classes
Trigger: The Customer selects a Product category
The Customer browses the chosen Product category page
The Customer selects a specific Product to purchase
The Customer adds the Product to their Shopping Cart
The Customer may repeat events 1, 2 and 3 to add additional items to their Shopping Cart
When ready, the Customer requests that the Order be commited to
The Credit Company is notified to authorise the Customer’s credit rating
If the credit rating is positive, the Order will be placed

28. Place Order: Exceptional Events
The Customer may terminate the transaction at any point before Step 7 and the Order will not be placed
2a If the Product is out of stock, the customer will be notified and asked to confirm of they wish to continue with the selection
6a If the Customer’s credit rating is not satisfactory, the transaction will be politely terminated at this point

29. Outline Brief description of Use Cases and Actors
Use Case terminology and methodology
Detailed description of Use Case template
Validating Use Cases

30. Remember, Use Cases …. Capture the Requirements for the system;
Act as a springboard for software design;
Act as a reference to validate the design against;
Act as a foundation for Software Test and Quality Assurance;
Act as an initial framework for the User Manual (if necessary).

31. Validating Use Cases? Ask the following questions:
Is the Use Case complete? Are there any details that need to be added?
Do I feel confident that the Actor’s goal is going to be properly met?
Can I simplify the process depicted in the Use Case?
Are there any additional Goals of the Actors that are not addressed?
Are there any additional Actors that are not represented (directly of indirectly)?

32. Summary
We have:
Introduced Use Cases as Sequences of Actions, aimed at achieving a Goal of an Actor.
Covered some basic definitions and methodology.
Introduced the Use Case template.
Emphasised the importance of Validating Use Cases.