Writing Cases of

Effective Use

by Jacques Robert Heckmann

from Alistair Cockburn

Scenario Body
¢ A scenario
¢ sequence of actions of the various actors for
achieve a goal

1
Body of Scenario
¢ Any of the steps falls into one of the
following categories:
¢ an interaction between actor and system
¢ client enters with address
¢ a validation step to protect a
interest of a stakeholder
¢ system validates the password
¢ an internal change to satisfy a
interest of a stakeholder
¢ system deducts amount from the balance

Body of Scenario
Typical example of main scenario: Register a loss.

1. The agent enters the policy number or the name and date of the incident.
2. the system fills in available policy information and indicates that the claim
corresponds to the policy.
3. attendant enters basic information about loss.
4. system confirms that there are no competing claims and assigns a number of
claim.
5. the attendant continues to enter specific loss information for the line of
claim.
6. the attendant has a system extracting other coverage information from other systems
computational.
7. attendant selects and assigns an organizer.
8. attendant confirms that he has finished.
9. the system saves and sends confirmation to be sent to the agent.

Legend:
¢ Interactions
¢ Validations
¢ Internal changes

2
Body of Scene
¢ Each step is written to show a
simple and active action.
¢ This can be compared to the description of a
volleyball match.
¢ Any scenario can be described
using these 3 types of steps
¢ Interactions
¢ Validations
¢ Internal changes

12 Guidelines

Guidelines for writing good action steps

3
Guideline 1
¢ Use simple grammar: the structure of
the sentence should be absurdly
simple!
¢ Subject... verb... direct object... sentence
prepositional.
¢ Example:
¢ The system... deducts... the amount... from the balance of
account.
¢ Common error:
¢ forgetting the subject (who has the ball).

Guideline 2
¢ Clearly show 'who is with the'
ball!
¢ A scenario has the same structure as a
game.
¢ At each step, a player has the ball.
¢ Ask yourself "at the end of the sentence,
Who has the ball?

4
Guideline 3
¢ Escreva com uma visão geral!
¢ Do not write the scenarios as if the system
was talking to himself.
¢ Instead of
¢ take the ATM card and the password.
Deduct amount from the account balance.
¢ Write with an overview
¢ The customer inserts the card into the ATM and
enter the password
¢ The system deducts the amount from the account balance

Directive 4
¢ Show the process advancing!
¢ Do not describe the steps in very processes
small.
¢ If a scenario has 13 or more steps, it is quite
it is likely that the sentences are not progressing
very much the objective.

¢ It is rare to find well-written use cases with

more than 9 steps in the scenario.
¢ Try to raise the level of the objective by asking several
times
¢ "Why is the actor doing this?"

5
Guideline 4 (continuation)
¢ Example:
¢ the user presses the Tab key
¢ But why is he pressing this key?
¢ Because he has to reach the address field.
¢ But why is he trying to reach the field?

address?
° Because he has to enter his name and address
before the system does anything.
¢ So, the action sentence that moves the process forward is:
¢ The user enters the name and address

Guideline 5
¢ Show the actors' intention, not theirs
movements!
¢ Do not mention the operation of the interface.

6
Guideline 5 (continuation)
¢ Defective example:
1. The system asks for the name

The user enters their name

3. system requests address
4. The user enters the address
The user clicks OK
6. the system displays the user's profile
¢ Correct example:
The user enters the name and the address
The system presents the user's profile.

Guideline 5 (continuation)
¢ If there are more than 3 fields, a variant is ...
1.user enters name, address, phone, information
secret, emergency contact phone number;
¢ Another variant would be ...
1.the user enters with

¢ name
¢ address
¢ telephone
¢ secret information
¢ emergency contact phone

7
Guideline 6
¢ Include a reasonable set of actions!
¢ Can you write each piece with a
separate action step or combine them
pieces in various ways
¢ put everyone in a single step of action!
¢ It will depend:
¢ how complicated each step is
¢ where natural pauses occur in
processing
¢ Next: Five versions. None wrong!

Guideline 6 (continued)
¢ Version 1:
1. The customer enters the order number.
the system detects that he corresponds to the number
monthly award, registers the user and the
order number like this month's winner,
send an email to the sales manager,
greet the customer and give instructions to him
how to receive the prize.
¢ very complicated to read!

8
Guideline 6 (continuation)
¢ Version 2:
1. The customer enters the order number.
The system detects that it corresponds to the
winning number of the month, registers the user and
the order number like this winner of
month, send an email to the manager of
sales, greets the customer and gives instructions
to him about how to receive the prize.

¢ simple pieces, however, a bit long

too much to work.

Guideline 6 (continuation)
¢ Version 3:
1. The customer enters the order number.
2. The system detects that it matches the winning number of
month.
3. The system records the user and the order number as this
winner of the month, send an email to the sales manager
greet the customer and give him instructions on how to receive it
prize.
¢ Version 4:
1. The customer enters the order number.
2. The system detects that it matches the winning number of
month.
3. The system registers the user and the order number as this
monthly winner, send an email to the sales manager.
4. The system greets the customer and gives them instructions on how to
receive the award.
¢ They are good, but they don't work if the purpose is testing.

9
Guideline 6 (continuation)
¢ Version 5:
1. The customer enters the order number.
The system detects that he corresponds to the number
monthly award winner.
3. The system registers the user and the order number as
this winner of the month.
4.Send an email to the sales manager.
5. The system greets the customer and gives instructions to them.

how to receive the prize.

¢ very small steps
¢ great for testing
¢ suitable for a more formal development!

Guideline 7
¢ Guideline 7: "Validate," not "Check if"!
¢ One of the three types of action steps is the
verification of the system of some business rule
is satisfied.

¢ verify a condition:
¢ Don't take the process further!
¢ It is not really the objective of the UC!
¢ Leave open what the result of the verification is.

¢ Why is the system checking something?

¢ He is determining, or validating, or ensuring
something.

10
Guideline 7 (continued)
¢ Instead of ...
2. The system checks if the password is correct.
3. If so, the system presents the available actions for the
user
¢ Use ...
2. The system validates that the password is correct.
3. The system presents the actions available to the user.
¢ Note that the second case considers that the scenario has
success.
¢ It leads to the natural question: 'But if in 2 the password is not
correct?
¢ What leads to the search for a scenario for this situation.
¢ Keep the use case with a consistent review rhythm and
reading.

Guideline 8
¢ Mention the time, optionally!
¢ Generally, the weather is obvious: it doesn't need to be.
mentioned.
¢ Normally, one step follows the previous one.
¢ Just like that...
¢ ... occasionally, you will have to say something like
¢ At any time between steps 3 and 5, the user will
¢ you
¢ As soon as the user has..., the system will ...

11
Guideline 9
¢ User has System A calls System
B!"
¢ Instead of using
1. the user signals the system to retrieve data from the system
B.
2. the system retrieves secondary data from system B.
¢ It is acceptable, however, they are redundant.
¢ Use:
1. the user has the system retrieving secondary data from
system B.
¢ Note:
¢ the user continues to control the time;
¢ it is said that the ball goes from system A to B;
¢ the details of how the user initiates the action are not
specified (and they really shouldn't!)

Guideline 10
¢ Expression "take steps x-y until condition"!
¢ Just write the step(s) using simple prose.
will repeat.
¢ Please write the repetition after the steps to be repeated.
It facilitates reading.
¢ Example:

1. Customer provides account identifier or name and address.

2. System brings the customer's preferred information.
3. Customer selects an item to buy, marks the item to
acquisition.
4. The system adds the item to the customer's shopping cart.
The client repeats steps 3-4 until indicating that they have finished.*
5. Customer purchases the items in the "shopping cart."

¢ The sentence of repetition was not numbered!

12
Guideline 11
¢ the condition of an alternative scenario or of
the exception should say 'what' was detected!
¢ Describe what the system detects, not just what.
it happened.
¢ Do not write:
¢ customer forgot the password
¢ The system cannot detect this. But it can.
detect user inactivity.
¢ "password entry time limit expired"

Guideline 11 (continuation)
¢ The condition must be a short phrase.
example:
¢ Invalid password
¢ Inoperative network
¢ The client does not respond
¢ “Dinheiro não foi ejetado corretamente”.

¢ Link the new scenario to the original scenario:

¢ In step number X, of scenario tal, if the
the password is invalid, ...

13
Guideline 12
¢ Align the treatment of the condition!
¢ Condition 1: Insufficient balance:
¢ System notifies customer, asks for a new one
amount
¢ 1b. Client enters with a new amount.
¢ Not considered.
¢ It gets complicated when you need
renumber these conditions.

Beyond the 12 Guidelines:

When do we finish?
1.Named all the primary actors and all
os objetivos de usuário?
2. It captured all the conditions of
system activation?
3.Wrote all the use cases for the objective
user, in addition to the summary use cases
the necessary subfunction to support
the?
4. The responsible parties agree that the set
Does the use case cover everything they want?

14
In addition to the 12 Guidelines:
a) When do we finish? (continuation)

5. Each UC is written clearly.

sufficient? Such that:
1. The responsible parties agree that they will be
able to say if he is really committed
or not?
2.Users agree that this is what they
they want (or can accept as the
system behavior)?
3. The developers agree that they
they can really develop that
functionality?

In addition to the 12 Guidelines:

b) How to deal with many UCs?
¢ Say less about each one (adopt
low precision representation
¢ define well what a use case does with its
¢ nome e resumo.
¢ Group the UCs:
¢ for actor;
¢ summary of use case;
¢ by development team and version;
¢ by subject area.

15
Beyond the 12 Guidelines:
c) UCs CRUD
¢ There is no consensus on how to organize all those
small UCs of the type
¢ Ccreate a <Anything>
¢ Rrecover a <Anything>
¢ Uupdate <Any>
¢ Ddelete <Anything>
¢ Question:
¢ everyone is part of a larger single UC (Manage
<Any>) or are separated (Create, Retrieve,
Update, Delete)?
¢ Suggestion from Alistair Cockburn:
¢ start with just one UC Manage, to have a
minor disorder;
¢ break into other separate UCs, in case a section
become very complex.

Beyond the 12 Guidelines:

d) Parameterized UCs
¢ And if we have a pile of UCs that
are they almost the same?
¢ Write half a dozen similar UCs
it's not a problem.
¢ However, write 6 use cases
entirely similar is unpleasant.
¢ It won't be long before the authors want one
shortcut.

16
Beyond the 12 Guidelines:
d) Parameterized UCs (continuation)

¢ Example:
1.User specifies <Any> to be found;
2. system searches, brings the list of possible equivalents;
3. user selects, maybe reorganizes the list, maybe changes
the research;
4. system finds one or more <Any>

¢ What differs from use to use?

1. The name of <Any> to be found;
2. The searchable qualities of <Any>
(research fields);
3. What to display about the <Anything>
(display fields, in sequence)
4. How to classify the options
(classification criteria)

Beyond the 12 Guidelines:

d) Parameterized UCs (continuation)

¢ So, we could have a UC.

what Select
¢ User identifies the qualities <Any>
searchable of <Any>;
¢ The system finds all the
equivalents and displays their values
for display in a list;
¢ The system can reclassify them from Select
agreement with some criteria; Client
¢ The user selects that of
interest.
¢ And from this, to make Select
generalizations for UCs that Supplier
they specify the items that
they differ between UCs.

17
Writing Use Cases
Effective
¢ References:
¢ COCKBURN, Alistair. Writing cases
effective use: a practical guide for
software developers. Porto Alegre :
Bookman, 2005. viii, 254 p, il.

¢ Film.

18