Continuing with the Dash application, let us study it from the perspective of use cases.

Dash

(1) Dash is a tool to quickly and easily transfer money to friends and to pay for things using your mobile phone. It is developed in collaboration with a collection of Swedish banks. In this description we focus on what you can do with the application once it is installed Dash on your phone and connected it with your bank account, and that you have BankID installed and configured. Your task is to design the features of the system that are described below.

(2) With Dash you can transfer money to other Dash users, receive money, and view a list of previous transactions.

(3) You transfer money by entering the mobile phone number of the recipient, the amount you want to transfer, and a message.

(4) In order to actually execute the transaction you identify yourself using your BankID. This starts a transfer of the specified amount from your account to the bank and account associated with the recipient's mobile phone number.

(5) At any point, you can abort a transaction.

(6) If there is not enough money in our account to complete the transaction, the transfer is aborted.

(7) If you want to see if you have received any money you first identify yourself yourself using your BankID. The Dash app then displays the last transaction, including the sender of the money, the amount received, and the message.

(8) You can get an overview of all transactions. You first have to identify yourself using your BankID, and then the Dash app displays an overview of previous transactions. This includes both incoming and outgoing transactions.

(9) To identify yourself using BankID, you enter a pin code. The system then connects to the BankID server to verify your identity.

(10) If you enter the wrong pin code, the current operation is aborted.

Our first step is to analyse the description (and/or whatever other sources we may have available) and identify things that a user may do together with the system. From the description we learn that we can do the following (the number of the corresponding paragraph is listed in parentheses):

Transfer Money (§2)
Receive Money (§2)
View a list of Transactions (§2)
Identify via BankID (§4)

... and that's it. Since we decided that BankID is an external application (out of scope for our system), we may not need to focus on the fourth one. However, since we use this same process in all the other three usage scenarios, I include it for now. Let's see if we can find a "lazy" way to model it as little as possible.

Each of these usage scenarios are candidates for becoming a UML Use Case. Note how each of them is also expressed as an action. It is not just the noun "Money", it is the action "Transfer Money". It is also not just the single verb "Transfer", since that would be too ambiguous. Item 4 can be generalised a bit -- let's use the commonly known term for what is going on: "Authenticate". Do note that this sort of breaks the rules.

To get an overview of this system, we can express the use cases in a use case diagram:

use case model

This is a relatively small system, so we do not learn much that is new, but we /do/ learn that:

There is only one actor against the system, User (we ignore the bank and the BankID Authorisation service for now).
There is only one sub-system, Dash, to which all use cases belong.
User is involved as an actor in all use cases.
All use cases make use of the Authenticate use case.

Prioritisation

We can start deciding which use case is the most important to implement already here. What is the "juciest bit" that the customer is most happy to get? What is the minimum viable product? Which use case has the largest architectural impact (which is another way of expressing minimum viable product)? Which use case has the most unknowns (highest risk)?

In a bigger system we would go about playing planning poker or engage in some other means for prioritising the use cases. Here, I can instead make a rational argument for a particular order. As long as you have some controlled (and explainable (and documentable)) process to prioritise, you are usually ok.

Authenticate is important, but in a first release of the system I do not need as much of it -- a simple scaffolding upon which I can later implement a full authentication service is enough.

View Transactions is the least important right now, because unless there are any transactions to view, it is pointless to look at an empty list.

Receive Money: Since this use case is not really about the actual receiving of money but rather the process by which you confirm that you have recieved money, it is less important than sending money. In a first version of the system, I can go in and check my bank account to see if any money has been received.

Transfer Money: This exercises several part of the system. Both Authentication and connection to the Bank is exercised. There are also several screens (enter information, receive confirmation that the transaction has gone through), so much of the user interface needs to be in place. I also need the database of previous transactions.

Taken together, the Transfer Money use case, along with parts of the Authenticate use case comprises a good candidate for a minimum viable product.

This order of implementation is not set in stone in any way. For example, I just realised that "Receive Money" is just a special case of "View Transactions", and so I will reverse the order of these two so that I do "View Transactions" before "Receive Money".

High-Level Use Cases

Use Case: Transfer Money
Actors: User
Description: A user initiates a transaction, and enters the phone number of the recipient, the amount to transfer, and a brief message. The user then authenticates themselves to actually send the transaction.

Use Case: Authenticate
Actor: User, Authentication Service
Description: A User authenticates themselves against the authentication service.

Use Case: View Transactions
Actor: User
Description: User views a list of previous transactions (after first authenticating themselves). User selects an individual transaction to view more details about that particular transaction.

Use Case: Receive Transaction
Actor: User
Description: User authenticate themselves to view a transaction that just came in. Details about the transaction are presented.

Detailed Use Cases

Starting with the high level use cases above, we add a positive usage scenario. We describe how a user interacts with the system in a dream scenario, where everything works as expected. Things that may go wrong are expressed (possibly in a later development iteration) as an alternative flow of events.

Use Case: Transfer Money
Actors: User
Description: A user initiates a transaction, and enters the phone number of the recipient, the amount to transfer, and a brief message. The user then authenticates themselves to actually send the transaction.

Main Course of Events:

Actor	System
1. The User initiates a transaction	2. The system responds by asking for a phone number, an amount, and a message.
3. The User enters a phone number	4. The system verifies that it is a correct phone number.
5. The User enters an amount	6. The system verifies that the amount is positive and not too large.
7. The User enters a message
8. The User selects "Send"	9. The system initiates the use case Authenticate
	10. The system confirms that the transaction has been processed.

Alternative Flow of Events:

1--7: The user aborts the transaction
9: Authentication fails. The use case is aborted and a fail message is displayed.
10: There are problems with the transaction (e.g. not enough money on the account). The use case is aborted and a fail message is displayed.

List System Events

The detailed use case describes how the actors interact with the system. The use case can be used for discussing with other people (e.g. the customer). However, when an actor interacts with the system, they are eventually going to need to do that in a way that a computer system understands. The way to deal with this is to "look beyond" the user interface (we pretend it does not exist), and instead see what methods will be called inside the system, by the actor, to execute the use case. These system events will in turn call plenty of other methods on objects inside the system, and we will look closer at this later. But for now, the system events that the actors generate on the system in the use case above are:

initiateTransaction()
enterPhoneNumber()
enterAmount()
enterMessage()
sendTransaction()

Somewhere behind the user interface, there is going to be a class which is at least responsible for all the interaction that happens in this use case, and this class is going to contain the methods listed above, corresponding to the system events that actors can generate as part of this use case.

10 GOTO 10

Now, all we need to do is the same for the remaining three use cases. I leave that as an exercise to the reader 👹.