CHAPTER Seven

Ensuring Your Requirements Are correct:

Requirement validation Techniques
 Testing Early and Often
 Use-Case Scenario Testing 

08/05/2022 DaDu System and Design 1

 What is a Use case Scenario? 

 Use case Scenarios are one means to describe a specific path

through a use case. A scenario list specific step toward that
goal. It describes a sequence of events or list of steps to
accomplish. Each step is a simple declarative statement with
no branching. A scenario may describe:
• Actors and their intentions
• System responsibilities and actions

08/05/2022 DaDu System and Design 2

• All steps should be visible to or easily surmised by the actor. We
typical state a statement by naming who is performing the step.
Our goal is to convey how the system and actor will work together
to achieve a goal. Even though a Scenario can show more detail,
resist putting in too much detail. Much of that detail can be placed
in the preamble or Supplementary parts of the use case template.
It should be clear where a scenario starts. Describe the steps in
achieving the actor’s goal. End there.

08/05/2022 DaDu System and Design 3

• Use-case scenario testing is a task process pattern in which users
are actively involved with ensuring that user requirements are
accurate. The basic idea is that a group of business domain
experts (BDEs), with the aid of a facilitator, step through a series
of defined use cases to verify that CRC model accurately reflects
their requirements. The facilitator distributes the cards to the
BDEs, trying to ensure that two cards that collaborate are given to
two different people (sometimes this is easier said than done). The
facilitator then leads the group through acting out each scenario
one at a time.

08/05/2022 DaDu System and Design 4

There are six steps to acting out scenarios:

1. Call out a new scenario (Identifying all system users and

creating a profile for each one. This includes every role played by
a user who interacts with the system).
• Both the description of the scenario and the action(s) to be taken
are called out by the facilitator. Once this is complete, the group
must decide if this scenario is reasonable (remember, the system
can’t handle some scenarios) and if it is which card is initially
responsible for handling the scenario. The facilitator starts out with
the ball, and throws it to the person holding that card. When the
scenario is completely acted out the ball will be thrown back to the
facilitator.
08/05/2022 DaDu System and Design 5
2. Determine which card should handle the responsibility
(Selecting one user and defining their goal -- or what the user
hopes to accomplish by interacting with the system).
• When a scenario has been described, or when the need for
collaboration has been identified, the group should decide what
CRC card should handle the responsibility. Very often there
will already be a card that has the responsibility identified. If
this isn’t the case, update the cards. Once the update is
complete (if need be), whoever has the ball should throw it to
the person with the card that has the responsibility.

08/05/2022 DaDu System and Design 6

3. Update the cards whenever necessary (Considering every alternate
course of events and extending use cases -- or the different courses that
can be taken to reach the goal).
• If a card needs to be updated, one of two situations has arisen. The
responsibility needs to be added to an existing card, or a new card needs
to be created with that responsibility. If a responsibility needs to be added
to an existing card, then ask yourself which card should logically have it,
and then have the BDE with that card update it. If a new card needs to be
created, the facilitator should hand a blank CRC card to one of the BDEs
and ask them to fill it out. At the same time, you may also find that you
need to update your prototype drawings as well (if an interface or report
class changes, then the prototype may need to change as well).

08/05/2022 DaDu System and Design 7

4. Describe the processing logic (Describing the course taken for each user
through the system to reach that goal).
• When the ball is thrown to someone, they should describe the business logic
for the responsibility step-by-step. Think of it like this: The BDEs are
effectively describing pseudo-code (high level program code) for the
responsibility. This is often the most difficult part of use-case scenario testing,
as some of your BDEs might not be used to documenting processes step-by-
step. If this is the case with some of your BDEs, then the facilitator needs to
help them through the logic. You’ll find that after running through the first few
scenarios the BDEs will quickly get the hang of describing processing logic. As
the BDE describes the processing logic, the scribe should be writing it down
(remember, the job of the scribe is to record the business logic/rules for the
system, which is exactly what the BDE is currently describing!)
08/05/2022 DaDu System and Design 8
5. Collaborate if necessary (Identifying commonalities in journeys to
create common course use cases).
• As the BDE describes the business logic of the responsibility, they
will often describe a step where they need to collaborate with
another card to complete. That’s great -- That’s what use-case
scenario testing is all about! If this is the case, go back to Step 2.
6. Pass the ball back when done (Repeating steps two through five
for all other system users).
• Eventually the BDE will finish describing the responsibility.
When this happens, they should throw the ball back to whoever it
was that originally threw it to them. This will be another BDE
(remember, every time you need to collaborate you throw the ball
to the person holding the card that you need to collaborate with)
or to the facilitator (remember, the facilitator starts with the ball
and throws it to the person holding the card that initially handles
the scenario).
08/05/2022 DaDu System and Design 9
 • For example, we might write a scenario
toward the user’s goal of “Register a
Customer.” This specific scenario explains a
variation of this task called “Register
Customer with Auto-Activation.”

08/05/2022 DaDu System and Design 10

 Example Scenario: Register Customer with Auto-Activation

1. User enters registration information:

• Required information: user name, email address,
desired login ID and password, and confirmation password
• One of: account number and challenge data, or ATM # and
PIN
• Optional: language choice and company
2. System checks that password matches confirmation
password.
3. System validates required fields and verifies uniqueness of
login ID
4. System verifies customer activation information.
5. System creates and activates customer on-line account.
6. System displays registration
08/05/2022
notification.
DaDu System and Design 11
 Writing Scenarios

©The purpose of a scenario is to describe the flow of

events in the use case. These events can be initiated by
the user or performed by the system, but should
express the steps of the process as the user understands
it.
1. For each use case, determine the “happy path” to the
actor’s goal.
GUIDELINE: Ignore other possible paths through the
use case at first. Write these “secondary” scenarios later.
GUIDELINE: Refer to the specific use case that the
scenario elaborates, if the use case has been written.

08/05/2022 DaDu System and Design 12

2. Write a scenario as a sequence of steps, ordered by time.
GUIDELINE: Every step in a scenario should be visible to or easily
surmised by the user.
GUIDELINE: Write each step as a simple, explanatory statement.
GUIDELINE: Keep information and actions concrete.
GUIDELINE: Focus on ordering and definition of steps.
GUIDELINE: Factor lower-level details into new descriptions.
GUIDELINE: Keep steps roughly the same level of abstraction.
In following example, several steps have been compressed to keep
actions at the same level.
3. Number the steps.
GUIDELINE: Don’t get carried away. Keep the numbering one
level deep. Remember, the goal is clarity.

08/05/2022 DaDu System and Design 13

4. Look for steps that might repeat within the scenario.
GUIDELINE: To show repetition, use repeat or while statements.
GUIDELINE: Avoid the tendency to write pseudo code unless your audience
are programmers who only understand code.
5. Look for steps that depend on a condition.
Mixed level of detail:
• Check for required fields
• Capture user ID and password
• Ask security component for validation
• Issue SQL statements to security database for logon
• authorization…
• Open connection to bank server
• Read account summaries…
Fixed:
• Check for required fields
• Login user to domain
• Display
08/05/2022
account summaries and bulletin
DaDu System and Design 14
• GUIDELINE: To show that a step depends on a condition, use an
if statement.
• GUIDELINE: When the logic for expressing a conditional
statement becomes too complex, write another, alternative
scenario.
• GUIDELINE: Distinguish between variations and exceptions.
Describe recovery from exceptions in a supplementary note or
another scenario if the recovery is complex. Document variations
in either a
• supplementary note, or another scenario if the actions are
interesting.
6. Look for sequences of steps that repeat across scenarios.
• GUIDELINE: Don’t do this early in your project. Later, factor
out portions of a scenario that repeat in other supporting
scenarios, give them a name, and refer to them within the core use
case with a reference to the
08/05/2022
supporting use case’ name.
DaDu System and Design 15
 7. Look for optional steps.
• GUIDELINE: Preface optional steps or actions with
“Optionally,..”. Indent optional steps for clarity.
8. Show the range of values of data that is used in the
scenario.
• GUIDELINE: If the user changes the information,
specify the possible states that the information might go
through.

08/05/2022 DaDu System and Design 16