1. Part IV: On Use Cases
Using the use case technique for exploring user requirements
Chapter 9: Use Cases and Scenarios and Stories, Oh My!
Chapter 10: Actors and Users
Chapter 11: When Use Cases Aren’t Enough
Research shows that this is a good technique
Why?
It focuses what the user wants to do rather than what the user wants the system to do
discussions that focus on users yield the best results and greatly increases the chance of building the right system
Why is this true? most users find it more natural to talk about their business tasks and usage goals than to try to identify functionality
Presented By:
Amy Skarzenski
Abdulaziz Attaallah
Jimmy Williams

2. Chapter 9: Use Cases and Scenarios and Stories, Oh My!
In This chapter:
Use Cases
Scenarios
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.
We are now going to discuss user cases, scenarios, and stories
These are terms that are often used when describing a system’s user requirements
They can be confused with one another
I am going to clarify these terms.

3. Use Case
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:
Reserve Rental Car
Print Invoice
Check Flight Status
A use case is a description of a sequence of steps between actors and a system.
In other words, a use case describes a series of events in which an actor, Alice the applicant, interacts with a system, such as the Common Application system, to achieve a result of value to Alice, such as submitting an application for college.
???An example of a use case for the Error Tracking system is “Submit Error Report.”
So, now how do we identify use cases during discussions with stakeholders?

4. Identifying Use Cases
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.”
For example, when we were conducting the interview with the stakeholders for the Error Tracking System, we asked a question like “Other than entering errors, what other functions do you see a programmer performing?” They answered, “We would need the ability for a programmer to propose a solution.” This response tells us that “Propose Solution” would be a possible use case.
Now that we know how to identify use cases, let’s talk about documenting them.

5. Suggested Template for Documenting Use Cases
There is no standard template for documenting use cases, but this is a suggested one.
The simplest use case specification consists of:
unique identifier
use case name
actors involved
a brief description
event that triggers the execution
Basic or Normal flow of events
That is enough information for prioritizing the use cases.
Most use cases will benefit from additional information.
Actors: The users or users who will perform the action in the use case
Description: The purpose of the use case
Trigger: Event that triggers the execution of the use case
Preconditions: the state of the system after a use case has run its course
Postconditions: conditions that must be present in order for the use case to start
Normal Flow: description of the interaction between the actor and the system
Alternative Flow: optional situations in the use case
Exceptions: what happens when things go wrong can be describe in this section instead of the alternative flows section
Includes: a relationship between two use cases – For example, with an ATM withdrawal of money, there is a use case for validating the user information.
Priority: How critical is this functionality to the organization
Frequency of Use: How often is it expected to happen?
Business Rules: rules or policies that determine how an organization conducts its business with regard to a use case
Special Requirements: A place for non-functional requirements (doesn’t define the behavior in the system) (security, testability, availability, efficiency)
Assumptions: Conditions that must be true for the duration of the use case (i.e., user must be logged in)
Notes and Issues: Things that might not fit under a specific heading
We have learned:
what use cases are
how to identify them
how to document them
Now let’s break things down even further

6. Scenarios
We can simplify the requirements problem by combining related use cases into one general use case, which then introduces scenarios.
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.
A scenario is a specific path through a use case.
A use case can contain many scenarios.
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.
If you find that your list of use cases has grown into hundreds and you are only building a small or moderate system, you can combine related use cases into one. Avoiding the duplication of functionality.
This is where scenarios come into play. A specific path through a use case.
1. Submit code error
2. Submit database error
Combined: Submit error
A use case can contain many scenarios.
Use cases are very abstract. Scenarios are more specific and provide more detail than a use case.

7. Use Cases and Scenarios on the Abstraction Scale
Prepare a mailing label [use case]
© Karl E. Wiegers
More Abstract
Prepare a mailing label to send a package by second-day air by carrier X [scenario]
Less Abstract
priority mail example
???Use Case: from the Error Tracking System: Submit Error Report
Scenario: Submit an error report to be recorded to the error tracking database and available for review by the project leader.
As you can imagine, scenarios can yield different results.
For example, if the package makes it to the intended destination, then this is a success scenario.

8. Success Scenarios
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
A success scenario is any path through a use case that has an expected outcome or is successful.
There are two types of success scenarios.
Normal Flow – default path through the use case that results in success
Alternative Flow – is another path through the use case that results in success
Normal – using the previous example, the normal flow would be “The mailing label is prepared to ship the package second day by Fed Ex.”
Alternative – and the alternative might be “The mailing label is prepared to ship the package second day by UPS.”
Occasionally the scenarios will not result in an expected outcome. This is a failure scenario.

9. Failure 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.
A failure scenario is any path through a use case that doesn’t result in a desired outcome or fails.
Also called exceptions
Example: The printer with mailing labels jams.
Given that use cases may have several scenarios, is it best to diagram the possible outcomes and analyze the scenarios.

10. Scenario Analysis
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.
Normal Flow – straight line to success
Alternative Flow – branch off but result in success
Exception Flow – branch off and result in failure
writing the normal flow down, don’t worry about any branching options or anything that could go wrong.
Most of the alternative flows in this case return to the main flow.
After fully analyzing the scenario, we can move down the abstraction scale to provide more detail of the user’s interaction with a system.
Scenario analysis is also valuable when identifying test cases based on requirements.
© Karl E. Wiegers

11. 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.
User stories are a user’s specific interaction with a system to achieve a goal.
User stories are even less abstract than scenarios.

12. User Stories on the Abstraction Scale
Prepare a mailing label [use case]
© Karl E. Wiegers
More Abstract
Prepare a mailing label to send a package by second-day air by carrier X [scenario]
Less Abstract
More detailed and more specific
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]

13. 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.
In the end, focusing on user goals will enable you to build the right system. And isn’t that the goal in the end?

14. Chapter 10: Actors and Users
In This chapter:
What a user and an actor are
What user types and classes are
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?

15. Definitions
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?
An actor is an abstraction, in other words, it is a role performed by a member of a specific user class he/she interacts whit a product at a specific time.
Meanwhile, when we speak with a user class representative he/she identify those roles that each one in that user class can perform from time to time.
We can imagine a member in a user class as having a stack of hats, and each hat is labeled with an actor name.

16. The Difference A user An actor is an abstraction,
role
A user
who interact with a product at a specific time
Performed by
An actor is an abstraction, in other words, it is a role performed by a member of a specific user class he/she interacts whit a product at a specific time.
Meanwhile, when we speak with a user class representative he/she identify those roles that each one in that user class can perform from time to time.
We can imagine a member in a user class as having a stack of hats, and each hat is labeled with an actor name.
To exemplify 

17. Example Error Tracking System User : Developer Actor: Programmer
Actor: Analyst
Actor: Tester

18. Relationship Between Actors and User Classes: one-to-many and many-to-one
ATM
Chemical Tracking System
Figure 10-1 A member of one user class could take on multiple actor roles
Figure Members of multiple user classes could all perform as the same actor

19. User Types Humans beings Pieces of hardware 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

20. User Classes
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 

21. Favored 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?
Making priority decision
Resolving requirements conflicts

22. Chapter 11: When use Cases Aren’t Enough
In This chapter:
Power of Use Cases
Project Type Limitations
Event-Response Tables
Use Cases Don’t Replace Functional Requirements
Use Cases Reveal Functional Requirements

23. Power of Use Cases
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.
Way to elicit requirements from users.
Helps users understand what’s being proposed.
Gives an overall outline of what the system’s behavior.

24. Readability vs. Detail
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.
Developers often require more detail than use cases can offer.

25. Project Type Limitations
For many projects, the deep complexity does not lie within the user-system interactions, but resides behind the scenes in
intricate business rules used to make decisions or perform calculations,
Computationally intense functionality,
And other internally complex system behavior.
Examples: Projects that involve…
Insurance Company example:
A lot of business rules, how data is going to be analyzed.
Insurance Agent -> uses case. What’s going on under the hood?
Error Tracking System example:
How will the statistical reports\ risk analysis be generated? What business rules?
Mill Software example:
Will the way files are loaded be specified in use cases?
Batch processes
Data warehouses
Embedded systems
Computationally intensive programs

26. Why are use cases sometimes insufficient?
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.

27. 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. +

28. When are use cases sometimes insufficient?
Example: Complex Traffic Intersection (real-time system)
Possible Use Cases
A driver wants to go through the intersection.
A driver wants to turn left when coming from a particular direction.
A pedestrian wants to cross one of the streets.
Do these use cases really define the functionality of the system?
systems that are subject to a "real-time constraint"—i.e., operational deadlines from event to system response.
Interaction between sensors, lights, and timers.

29. Event-Response Tables
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.

30. Event-Response Table

31. Use Cases Don’t Replace Functional Requirements
There are three main issues with adhering to the “use case-only” philosophy:
Use cases must contain all the functional detail analysts need.
Packages functional requirements into contrived use cases.
Use case documentation is organized in such a way that makes it difficult for the developer to understand.

32. Use Cases Don’t Replace Functional Requirements

33. Use Cases Reveal 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.

34. Use Cases Reveal Functional Requirements
Preconditions:
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?

35. Use Cases Reveal Functional Requirements
Exceptions:
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?
As a rule.. if you put an exception in the use case, then you can confirm that it is handled when you trace your use cases to what is implemented. If you don't you are likely to miss implementing the exception. So it is important to capture all exception paths but you want to do so at as high a level as possible. Say you have a use case in which the user enters an address and submits it to the system. Do you want to make an exception path for every specific occurrence you can think of i.e. "invalid zip code", "invalid character in the name", "invalid state" etc? Probably not. You'll be writing exceptions for the next year. But since it is appropriate for the system to respond if invalid data is entered you need to capture this exception path. Capture it, but be generic... "If validation of user input fails, highlight the errors and allow the user to re-enter values". Notice that you are not specifying "how" to validate the input, only that you need to. If the database is down and the update cannot be accomplished, the user is definitely going to want to know it. Handle the exception but do it generically i.e. "If the update fails, inform the user an error occurred and the update failed". Notice that this is "what" needs to be done. That said, there is nothing to keep you from having an exception path to specifically handle the database down error (although a "database" is more a "how" you are implementing your security). If it is a condition you want to ensure is handled when you trace your use cases to implementation then include it as it's own exception path. This is a good practice if the user specifically requests certain functionality. Going back to the address example, say the user asks you to *make sure* the zip code matches the state. Create an exception path for "zip code doesn't match state". Then, when you trace your use case to the implementation, you can ensure the user's requested functionality is implemented.

36. Use Cases Reveal Functional Requirements
Business Rules:
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?

37. Use Cases Reveal Functional Requirements
Special Requirements and Assumptions:
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?

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

39. The End
Question?