The cold hard facts about software development, i.e. propositions are backed up from facts from over 15,000 projects. Many truths are counter-intuitive to the current beliefs. This blog is oriented towards beginner and intermediate developers and product managers. (dsm@dalipmahal.com)

Pages

Tuesday, 13 March 2012

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.

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.