April 5th, 2022 
—Detailed Use Case Diagram
‹#›
1
Detailed (expanded) Use Case
Identify who will be involved and what they want from the system (Overall use case).
How each ‘want’ i.e., requirement will be performed – Check the detail (detailed or expanded use case).
How do you know EXACTLY what is going to happen?
How do you tell the programmer exactly what should happen?
How can you be sure you have covered everything that needs to happen?
Describes the dialogue between the actor (active) and the system (software/app).
The dialogue should be call-and-response style, i.e. the actor does something, and the system immediately responds.
‹#›
‹#›
2
Detailed (expanded) Use Case: example
Three sections
‹#›
‹#›
Disclaimer: this slide is to show the three sections; texts might not be clear.
3
First section
Within the first section, there are several compartments:
The first and second compartments are used to identify the use cases and scenarios within use cases, if needed, that are being documented.
The third compartment identifies the triggering event that initiates the use case from the event table.
The fourth compartment is a brief description of the use case or scenario.
Analysts may just duplicate the brief description they constructed earlier here.
The fifth compartment identifies the actor or actors.
The sixth compartment identifies other use cases and the way they are related to this use case. These cross references to other use cases help document all aspects of the users’ requirements.
The seventh (stakeholders) compartment identifies interested parties other than specific actors. They might be users who do not actually invoke the use case but who have an interest in results produced from the use case.
Preconditions state what conditions must be true before a use case begins.
A postcondition identifies what must be true upon completion of the use case.
‹#›
‹#›
4
Second section – the actual Actor-System dialogue
| Actor Action | System Response |
| 1. Actor action 1 | 2. System response to actor action 1 |
| 3. Actor action 2, after system response (in #2) | 4. System response to actor action 2 |
| … | … |
NOTE: For each actor action, there is an immediate system response!!!
‹#›
‹#›
5
Third section – Alternative Courses/Exceptions
Some of the Actor actions or System Responses might have exceptions, as things don’t always function as per plan when you are interacting with software.
This is “stormy day” scenario (than a ‘sunny day’).
For example, sometimes you try to send a SMS, but the software does not send your SMS, saying “Message not sent: Please re-try send”, or “you do not have sufficient credit to send this text”.
‹#›
‹#›
6
Use case: Purchase productPreconditions: The products(s) is/are already in cartThe customer is already signed-in
| Actor action | System response |
| Customer hits ‘checkout’ | |
| 2. The website loads “payment” page | |
| 3. Customer enters card number4. Enters CCV number5. Enters expiry date6. Hits “next” button | |
| 7. Takes to the “review order page” | |
| 8. Hit “place order” | |
| 9. Order is placed10. Customer taken to the homepage |
Alternative courses:
Line 3. Wrong card number, display “Ooops! Please enter a correct card number”
4. Wrong CCV number, display “ooops! please enter a correct CCV number”
5. Wrong expiry date, display “ooops! please enter a correct expiry date”
8. If “cancel order” button is clicked, display “Are you sure to cancel the order”. If hits “yes” take to the homepage”; if “no” button is clicked, refresh the page.
‹#›
‹#›
Some fields on first section are not mentioned (to save space), but the students should not do the same!
7
Name: Input production figures into systemActors and Initiator: EmployeePurpose: To record production figures in systemType: ConcreteImportance: High/SecondaryTechnical Difficulty: LowPre-conditions: User logged inAssumptions: Cross References: Login to systemAlternative courses:Line 11: User enters non-numeric data; System displays “Please enter a numeric value”; Return to line 11.Line 13: User selects Cancel; Return to line 1.
1. User opens the “input” tab on the Inventory app
‹#›
‹#›
Every use case should be initiated by an actor (that is why the new text is added).
Ignore the numbering inconsistency.
Some fields (e.g., related use case, preconditions, post-conditions) cell can be empty; however, it does not mean the students will delete the entire row. Please explain the difference (null is a value).
8
Class exercise
Assume you have developed the overall UCD of Uber taxi booking system. Let, “Book trip” is a use case, which is initiated by a passenger.
Who are the actors?
Passenger
Driver
GPS
…
Now, develop the expanded use case of it.
‹#›
‹#›
It is often found that the students bring an expanded use case (out of the blue!), which is not found in the Overall UCD!!
9
(Kind of) solution
| Actor action | System response |
| 1. Passenger clicks “Ride” | 2a. System activates GPS and find the current location.2b. Loads the page to select pick up (default is GPS-located) and destination locations. |
| 3. Passenger enters details | 4. System loads different types of cars (Uberx, Comfort, UberXL) with estimated fare. |
| 5a. Passenger selects vehicle type.5b. Hits “confirm” | 6a. System searches nearest vehicles of the type requested through the GPS 6b. System receives coordinates of nearest vehicles and presents to the customer 6c. System matches Pick-up address with nearest vehicle 6d. System presents nearest vehicle and driver information |
| 7. Customer confirms ride | 8. System assigns the job to one driver. |
| 9. Driver accepts the job. | 10. System notifies customer of selected driver’s location, rego and name. |
…
Precondition: Already signed up.
The app is running online on the passenger’s device.
‹#›
‹#›
10
Alternative courses/Exceptions
Line 2a: If GPS is off, System notifies Customer to turn on GPS.
Line 3. Address not found, show “please enter a valid address”.
Line 4: if no car is vicinity, show “no ride available”, and go to line 2b.
Line 7: Customer cancels the booking, System asks “Are you sure to cancel the ride”; if presses “Yes”, terminate the app; if presses “No”, reload the page.
Line 9: if job rejected, go to line 6a.
‹#›
‹#›
We understand that the ride can be cancelled after placing the order; this will be handled by “Cancel ride” use case. Similarly, “Pay for ride” will be a separate use case (which is an <<includes>> relationship).
11
Remember
One system (e.g., Canvas) will have one Overall UCD.
Each of the Use Case from Overall UCD will become an Expanded Use Case.
Therefore, each and every Expanded Use Case MUST come from the Overall UCD. Each of the steps in Expanded Use Case should be performed through the System.
For example, “Customer enters pin number of credit card” is done through the system, but “customer looks for the wallet” is not a step because customers cannot search his wallet via the online shopping system. This mistake is continuously made by more than 60% in every semester!!!
‹#›
‹#›
It is often found that the students bring an expanded use case (out of the blue!), which is not found in the Overall UCD!!
12
Exceptions: the last compartment
Finally, the last compartment (“exception conditions” or alternative course”) attracts least attention by the students but is extremely important.
Here, we “catch” exceptions as well as “throw” it. The throw can be done in two ways: either display something, or go to a defined line.
For example: line 2. If CCV number is invalid (catch), display “please enter a correct CCV number” (throw); or go line 10 (which is “close application”)
‹#›
‹#›
It is often found that the students bring an expanded use case (out of the blue!), which is not found in the Overall UCD!!
13
Why UCD?
Overall UCD: To understand (and eventually add/include) the expectations of the users.
Detailed UCD: To explain the developer how the expectation is to address.
For example, students of RMIT want to arrange housing through Canvas. In that case, BA needs to understand the feasibility of such use case.
If the BA understands that such use case is possible (through investigating the associated activities and resources e.g., coordination with housing facility wing, payment), then the BA needs to design how exactly the use case (“arrange housing”) can be performed and thus develop the overall/expanded UCD so that the developer can write codes.
‹#›
‹#›
14
Posted in 