Part IV: On Use Cases

Chapter 9: Use Cases and Scenarios and Stories, Oh My!

Chapter 10: Actors and Users

Chapter 11: When Use Cases Aren’t Enough

Using the use case technique for exploring user requirements

Presented By:Amy Skarzenski

Abdulaziz AttaallahJimmy Williams

Chapter 9: Use Cases and Scenarios and Stories, Oh My!

In This chapter:

1. Use Cases2. Scenarios3. User Stories

These are terms that are often used when describing a system’s user requirements, but can be confusing. This chapter more clearly defines these terms and concepts.

A use case is a description of a sequence of interactions between the system and one or more external actors that results in an outcome that provides value to at least one actor.

The name given to a use case should indicate the value the use case will deliver to an actor. The use case name always starts with a verb and also contains an object.

Examples:

Use Case

o Reserve Rental Car

o Print Invoice

o Check Flight Status

When talking to users you should listen for the phrase “I need to” to indicate that the user has a specific objective for the system.

While discussing a proposed car rental kiosk for an airport, we may get a response like…

“I would use it when I need to reserve a car.”

The use case derived would be “Reserve Rental Car.”

Identifying Use Cases

Suggested Template for Documenting Use Cases

Scenarios

o We can simplify the requirements problem by combining related use cases into one general use case, which then introduces scenarios.

o Scenarios represent specializations of the general user goal stated in the use case name, or alternative pathways by which the user could reach the goal.

o A scenario is a specific path through a use case.

o A use case can contain many scenarios.

o Use cases describe requirements at a high level of abstraction and group a set of related user tasks. Those related user tasks constitute separate scenarios or variations on a common theme. Scenarios are less abstract than use cases.

Use Cases and Scenarios on the Abstraction Scale

More Abstract

Less Abstract

Prepare a mailing label [use case]

Prepare a mailing label to send a package by second-day air by carrier X [scenario]

© Karl E. Wiegers

Some scenarios result in success. The most typical or default scenario that results in success is called the normal flow of the use case. The alternative flow is another scenario that results in success.

To identify the normal flow and alternative flow when discussing the system with a user, listen for the phrases “the default should be” and “but the user should also have the option.”

“the default should be” – Normal Flow“but the user should also have the option” – Alternative Flow

Success Scenarios

Use cases typically identify conditions under which they might fail to complete successfully. These are called exceptions, exception flows, or exception paths. Some do not distinguish exceptions from alternative flows, but it is useful to separate them. An exception is another path the use case may take resulting in another scenario.

Failure Scenarios

Executing a particular scenario involves traversing a specific combination of flows. A use case can be very complex, you can identify each scenario by evaluating a single path through the use case.

Scenario Analysis

Normal Flow – straight line to success

Alternative Flow – branch off but result in success

Exception Flow – branch off and result in failure

Scenario analysis is also valuable when identifying test cases based on requirements.

© Karl E. Wiegers

User Stories

To keep with the user centric approach we define user stories as the specific, concrete instance of a user’s interaction with a system to achieve a goal.

User stories are written by the stakeholders.

User stories usually follow a pattern like, "As a [role], I want [goal].”

For example:As an advancement officer I want to be able to enter a response from many donors at once.

Although similar to use cases and scenarios, user stories lie on the low end of the abstraction scale.

More Abstract

Less Abstract

Prepare a mailing label [use case]

Prepare a mailing label to send a package by second-day air by carrier X [scenario]

Chris wants to send a 2.5 pound package by second-day air from Clackamas, Oregon, to Elba, New York. She wants it insured for $75 and she wants a return receipt. The package is marked fragile. [story]

© Karl E. Wiegers

User Stories on the Abstraction Scale

Use cases, scenarios, and stories all provide powerful ways to hear and understand the voice of the customer. Unless you focus on the user’s goals and vision, your team can easily implement a stunning set of functionality that simply doesn’t let users get their jobs done in a way they find appealing.

Chapter 10: Actors and UsersIn This chapter:

1. What a user and an actor are2. What user types and classes are3. The Relationship between actors and user classes: one-to-many and

many-to-one

Software products are created for users, so who are the users?

A user is a stakeholder who will interact with a completed system either directly (hands on) or indirectly (for example, using reports from the system but not generating those reports personally).

An actor is an entity outside the system boundary that interacts with the system for the purpose of completing a transaction.

So what is the difference?

Definitions

An actor is an abstraction,

role

A userwho interact

with a product at a specific time

Performed by

To exemplify

The Difference

Actor: Tester

Actor: Programmer

Actor: Analyst

Error Tracking System

User : Developer

Example

Figure 10-1 A member of one user class could take on multiple actor roles

Figure 10-2 Members of multiple user classes could all perform as the same actor

ATM Chemical Tracking System

Relationship Between Actors and User Classes: one-to-many and many-to-one

o Humans beings

o Pieces of hardware

o Other software systems

It is not enough to know what the types of users can be, but also it is important to know that these users can be grouped into user classes

User Types

User classes represent groups of people who have similar characteristics and similar.

So why we need user classes?

To identify which class you need to talk with about requirements.

Additionally, we need to identify

User Classes

“Satisfying the needs of a favored user class is more important from a business perspective than meeting the needs of other groups of users.”(Gause and Lawrence 1999).

Why?

o Making priority decision

o Resolving requirements conflicts

Favored User Classes

Chapter 11: When use Cases Aren’t Enough

In This chapter:

1. Power of Use Cases2. Project Type Limitations3. Event-Response Tables 4. Use Cases Don’t Replace Functional Requirements5. Use Cases Reveal Functional Requirements

Use cases are an excellent way to structure the dialogue with users about the goals they need to accomplish with the help of the system. Users can relate to and review use cases because the analyst writes them from the user’s perspective, describing aspects of the user’s business.

Use cases give the developer an overall understanding of the systems behavior that fragments of individual functionality cannot.

Power of Use Cases

Writing requirements specifications so that users can read and understand them while at the same time providing the level of detail developers need is an important goal. However, in many cases, one requirements representation will not meet both of these objectives.

Readability vs. Detail

For many projects, the deep complexity does not lie within the user-system interactions, but resides behind the scenes in

Project Type Limitations

Examples: Projects that involve…

o intricate business rules used to make decisions or perform calculations,o Computationally intense functionality,o And other internally complex system behavior.

o Batch processeso Data warehouses o Embedded systemso Computationally intensive programs

When we explore the interactions between actors and systems of these types, we only scratch the surface of the system’s principal behaviors.

Use cases are not useless; however, more information must be provided in order for an analyst to define the functionality of the system.

Why are use cases sometimes insufficient?

Therefore, the combination of employing use cases to represent user requirements and a software requirements specification to contain functional and nonfunctional requirements is ideal for a complete description of system behavior.

+

When are use cases sometimes insufficient?Example: Complex Traffic Intersection (real-time system)

Possible Use Cases

Do these use cases really define the functionality of the system?

o A driver wants to go through the intersection.o A driver wants to turn left when coming from a particular direction.o A pedestrian wants to cross one of the streets.

An event-response table is a convenient way of collecting information that describes the external events a system must detect. Furthermore, it illustrates the particular response the system produces, depending upon the state of the system at the time a given event is detected.

Event-Response Tables

Event-Response Table

There are three main issues with adhering to the “use case-only” philosophy:

Use Cases Don’t Replace Functional Requirements

1. Use cases must contain all the functional detail analysts need.

2. Packages functional requirements into contrived use cases.

3. Use case documentation is organized in such a way that makes it difficult for the developer to understand.

Use Cases Don’t Replace Functional Requirements

Use cases can become a tool rather than being an end unto themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The analyst can study each use case and derive the functional requirements the developer must implement to realize the use case in software.

Use Cases Reveal Functional Requirements

Use case descriptions rarely state what the system should do if a precondition is not satisfied. The analyst needs to determine how best to handle these situations.

What events should take place if a precondition is not met?

Use Cases Reveal Functional Requirements

Preconditions:

The analyst needs to determine how the system could detect each exception and what it should do in each case.

How will the system handle the particulars of each exception?

Use Cases Reveal Functional Requirements

Exceptions:

Many use cases are influenced by business rules. The use case description should indicate which business rules pertain. It’s up to the analyst to determine exactly what functionality the developer must implement to comply with each rule or to enforce it.

What functionality must be implemented for the system to comply with business rules?

Use Cases Reveal Functional Requirements

Business Rules:

There’s always more functionality hinted at in the use case than is obvious from simply reading it. Someone needs to discern this latent functionality.

What other functionality is needed in order for a use case to be realized?

Use Cases Reveal Functional Requirements

Special Requirements and Assumptions:

Overall

It’s up to you. Who do you want deriving the functional requirements an when?

The EndQuestion?