Use Case Tutorial (3 of 4)

In a previous blog we explained how the core of a use case is a textual description of the dialogue between an actor and the system.  We then covered that actors are roles in the system and that a collection of use cases indicates scope.

In this blog entry, we will cover adding additional detail to the use case dialog.  This additional detail will have the effect of:

·         Enabling the business to make sure the requirements are complete and consistent

·         Enable the developers to identify constraints that will modify the requirements before code is written

·         Enable the developers to see enough information to build good architectures

·         Enable QA to build test cases before the system is built

Extending the dialogue

The use case for Withdraw Money had the following dialogue:

1. ATM presents a list of accounts and asks user to select one
2. ATM asks user how much he wants to withdraw
3. ATM dispenses money
4. ATM dispenses receipt

Remember, all of the ATM interactions for authenticating the user, determining the transaction to execute, and asking for another transaction is all handled by Authenticate User.

Adding Interface Details

An easy way to extend lines 1, 2, and 4 would be to simply include display shots of what the interface will look like.  For example, presenting the list of accounts could look as follows:

Simple ATM select account screen

Here we have an extremely simplified example of what the select account screen might look like.  Adding screen information directly into the use case make is clear what is desired from the developers.  The business analyst/product manager can then have a productive discussion with the developers about various interface constraints before the code is generated. 

If the screen shots are produced for an entire set of use cases before development starts, then the developers can more effectively plan the architecture of the GUI.  In addition, screen shots will lead to multiple requirements being flushed out before development starts.  Once the developers get the use cases, you can expect changes to the screen shots because of constraints that the business analyst was unaware of.  This will lead to a productive discussion on what is possible and the screens can be modified before the coding begins.

Once the project is complete, actual screen shots can be put into the use case.

Adding Validation Information

In line 2, the interface may look as follows:

Simple ATM select amount screen

Here we have a data entry screen, and after the data screen we can give information about data validation and screen behavior.

Field	Type and Length	Comment
Amount	Numeric 8 digits	Digits can be entered on the keypad will be inserted from right to left
Correct	Button	Hitting the correct key will clear the display number back to $0.00
Ok	Button	Hitting the Ok button will complete the data entry process

Again, by placing the validation and behaviour information directly into the use case it not only enables the developers to plan the architecture better but also allows the QA department to verify the code once it is completed by development.

Adding report information

In step 4, the ATM dispenses a receipt.   As expected, we can show the report in the use case, or link to the report if it is too long.  In the case of the ATM we could show the following:

When this additional detail is added to the use case it will look as follows:

(use case as a MS Word document)

Effects of adding detail to use case dialogues

By adding the screen shots, data validation, and reports directly into the use case we extend the dialog with information that needs to be provided anyways for development to proceed.

By bringing all the information together this way, we can provoke discussions at the business level and ensure that the requirements are more complete and consistent before they are delivered to development.

Once a complete set of use cases are created the use case diagram can be colored to indicate which use cases are in the scope of the current project.

 

Once the developers receive the use cases they can then look through all of the information and plan a consistent architecture.  In addition, by looking through the detailed use cases they can identify where the requirements have to be altered because of technical constraints.  If there are serious constraints that prevent the requirements from being implemented the project can be put on hold until either the constraints are changed (i.e. change technology) or the requirements are consistent with the technology that you have.

The requirements can be delivered to the QA department at the same time as development.  This allows the QA department to create a test plan for the use cases and in fact they will generate one or more test cases per use case.  Complete use cases enable the QA department to be prepared when the code is finally delivered.

Summary

• A use case can be annotated by adding detail to the dialogue of the use case
• We can add screen shots, data validation, and reports
• This additional detail will help complete requirements get to development
• Modifications to the requirements can be made before development as the developers and architects see the annotated use cases
• By inserting the screen shots, data validation, and reports directly into the use case we can provoke a discussion of the requirements to make sure that they are consistent and complete at the business level
• By having this detail prior to development will allow the developers to review the use cases and identify areas where the requirements will need to be changed because of technological or time constraints.
• Detailed requirements can be delivered to development and QA simultaneously which allows QA to build test plans and cases before development is complete.

Last part (4 of 4)

·         How to add meta-information to determine how and when a use case is called

·         How to add meta-information to improve project management

Use Case Tutorial (2 of 4)

In the previous blog we explained how the core of a use case is a textual description of the dialogue between an actor and the system.

In this blog entry, we will cover:

• What is an actor?
• What is a use case diagram?
• Why a collection of use cases provides project scope

 What is an actor?

An actor in a use case represents a role in the system and not a specific user.  In the case of an ATM, let us look at the following users:

• Bob who does not work at a bank
•  Jill who works as a branch manager in the bank
•  Ted who is a bank employee that puts cash in the ATM and collects the envelopes

All three of these individuals can be users of the ATM; however, they all have the same role as each other of a Customer when they are interacting with the ATM to withdraw money.

Users are concrete, actors are abstract; when any of the individuals above access the ATM they all have the same privileges and characteristics as far as the withdraw money use case goes.

Actors are roles.  A role is a set of actions that you can access to accomplish your goals, when people are using the ATM they all have the same role.

Now Ted may have additional use cases that he can interact with when he is in the role of someone who is provisioning the ATM with cash and collecting the envelopes.  However, that role is distinct from the role of a Customer.

What is a use case diagram?

The simplest use case diagram shows a relationship between each role in the system and the use cases that they can access.  In the previous blog, we established that a Customer can interact with two use cases: 1) Authenticate customer, and 2) Withdraw money.

Some use cases for the customer could be:

• Deposit money
• Transfer money from one account to another
• Get statement
• Change PIN
• Buy stamps

Some use cases for the ATM Maintainer could be:

• Deactivate ATM
• Activate ATM

With these additional use cases the ATM diagram would look as follows:

Note: Not all ATMs in North America provide the following use cases (but there are some that do J):

• Change PIN
• Get statement
• Buy stamps

Why a collection of use cases provides scope

By definition the core of a use case is a dialogue between an actor and the system and as such is functional and specifies the behavior of the system.  A collection of use cases is essentially the core of a functional specification.

If we were designing a new ATM, we might partition the system as follows:

We may decide that in our first project we will design the system to have only the use cases above in blue, and that the use cases in yellow will be done in a later phase of the system.  If we are executing our project and it looks as if the scope is too large, we can take an entire use case, say Transfer money from one account to another and move it into a later phase.

From a project management standpoint a project's scope is completely defined by the use cases that are to be developed.

Summary

• An actor is a role, and all users with that role will have the same interaction with a use case. 
• A use case diagram shows us which roles can access which use cases
• A project is a set of use cases which provides a complete scope definition 

Next part (3 of 4)

• What additional information should be included in the use case body?
• What additional meta-information should be included in a use case?

Use Case Tutorial (1 of 4)

In this next series of blog entries we focus on defining use cases by starting with simple examples and working our way through more sophisticated use cases.  In this blog, we identify the core part of a use case, which identifies the interaction of the user and system in a series of ordered steps.  The next blog will focus on use case diagrams and their relationship to use cases.

Use cases are concerned with the interaction between each actor and the system.  At the core of every use case is a conversation or dialog that occurs between an actor and the system.  All interactions with the system involve us providing the system with inputs and the system providing us with outputs; or we could simply say that when we input information into the system that we are ‘telling’ it something and that when the system outputs something it is ‘telling’ use something.

Let's focus on the core of the interaction between the actor and system before we investigate more complex issues in use cases.  In future blogs we will get to alternate execution paths, screen shots, or data validation.  For now assume that no mistakes will be made.

A complete dialog (not a use case) for the withdrawal from an ATM might look as follows:

Simplified Dialog

This dialog can be simplified when we recognize that when the ATM is asking for something the user needs to provide it for the withdrawal process to be successful.  Clearly there are times where users do not provide input on time (if at all), however, let’s deal with these exceptional cases later.  If we assume that every simple request by the ATM will be provided by the user, we now get the following dialog:

Steps 4, 8, and 10 are requests for simple information that can be selected from a list or entered as a single text.  This will not change the next action in the dialog and therefore these can be collapsed into a single step with the user response.

What is interesting to note is that we could not collapse steps 6/7 and steps 9/10 of the original use case into a single step.   In step 6, the ATM presents the list of transactions and asks the user to select one.  Clearly step 5. would be different if the user had selected ‘display balance’.  Just as in step 9, when the user is asked if they want to do another transaction the answer will determine if the next step is 3 or step 11.

In reality, we have two use cases here: the first one is the main loop of the ATM that authenticates the user (Authenticate User) and determines the transaction that he wants to do, and the second one is the withdraw money (Withdraw Money) use case.

Use Case: Authenticate User

The key thing to see in the Authenticate User use case is that we only diagram inputs from the user (i.e. arrow left to right) when the user is providing an input that will alter the flow of the use cases or invoke another use case.

Use Case: Withdraw Money

With most of the dialog now in the Authenticate User use case, we see that the withdraw money use case is very small.

Summary

• At its core a use case is a dialog that occurs between an actor and a system. 
• We can break a dialog into one or more use cases by identifying the places in the dialog where  user input alters the flow of a use case or invokes another one

Next part (2 of 4)

• What is an actor?
• What is a use case diagram?
• Why a collection of use cases provides project scope.