1. Use Cases

2. Use-Cases: an Example

3. Using use cases to describe requirements
Use cases can show the sets of possible interactions between the system and the people who use it
Use cases can also show interactions between computer systems
Use cases can also be used at the subsystem level (to show interactions between subsystems)
Example use case diagram
Student
Administrator
Instructor
My system
register
create new
course
delete
offering
actors
use cases
The “use case diagram” is a standard notation for showing the high level system view. Each use case represents a block of system functionality. The stick figures in this picture represent the different kinds of users (called actors) that can interact with the system. The ellipses represent the system-level use cases.
The mapping between “features” and “use cases” is normally not one-to-one -- each use case is defined by a series of scenarios that show the steps that are needed to achieve the overall goal of that use case.
Use cases can’t show all of the requirements: they can be used to show many of the “functional” requirements, but non-functional requirements such as (security, performance, availability, or capacity) should be described in other documents.

4. What is Requirements Engineering About?
Effectively generating High Quality Requirements:
correct
consistent
complete
modifiable
traceable
verifiable
non-ambiguous
understandable
annotated
Requirements Engineering
Requirements Development
Requirements Management
Elicitation
Analysis
Modeling & Specification
Verification & Validation
Change Control
Version Control
Tracing & Impact Analysis
Status Tracking
Best Practices, Methods,Tools and Processes for Requirements Engineering

5. Use Cases & Early Testing Paradigm
Requirements Validation
Quality Assurance
Faster Time to Market
Requirements
System Test
System Design
Integration Test
Detailed Design
Module Test
Implementation
Build

6. Software Production Cycle
Design
Specifications & Models
Code
Creation
Documentation
Design Specification
(Design Model
Generation)
Design
Tools
Build
Code
SDE, SCM Tools
Documentation
Requirements
Specifications & Models
(Use Cases)
Change
Request
Change
Requests
Build-triggered Installation
Requirements
Tools
Capture with
Customers
Shipped Product
Requirements “validation”
Testable version
Test
Plans, Scenarios, Cases
Test Execution
Test
Creation
Test
Tools
Traceability, Change Management, Impact Analysis

7. What is a Use Case?
A Use Case captures a contract between the stakeholders of a system about its behavior. Use cases describes the system’s behavior under various conditions as the system responds to requests from its users (actors) specifying how the actors’ goals get delivered or fail.
A use case is:
a set of scenarios that describe the behavior of the system and its users
at a high level of detail
with “sunny-day” and “rainy-day” scenarios being defined
A use case gathers the scenarios related to the (primary) actor’s goal
Actors are the people and/or computer systems that are outside the system under development (SuD)and interact with it:
Primary actor – a stakeholder who requests that the system deliver a goal
Supporting/secondary actor – an external system against which the SuD has a goal
Scenarios are dialogs between actors and the system
Use Cases are a way to document requirements. It isn’t possible to put every requirement into use case form – but most of the functional requirements fit well into a use case model.
Developers and testers sometimes create use cases – even in situations where the requirements writers or systems engineers have written requirements documentation in a more traditional manner. The developers create use cases to understand the context for all of the individual detailed requirements statements, and to help guide the development of the system’s architecture.
Use cases may also be used to do “reverse engineering” of an existing system – to create a requirements model that reflects the legacy system’s behavior that needs to be preserved in the new system.

8. What is a Use Case? A Use Case is
a set of scenarios that describe the behavior (or desired behavior) of a system and its users
at a superficial level of detail
with “sunny-day” and “rainy-day” scenarios
with some generalization of the roles and activities
A Use Case is the set of scenarios that provides positive value to one or more external actors
actors are the people and/or computer systems that are outside the system under development
scenarios are dialogs between actors and the system
no information about the internal design
Use Cases are a way to document requirements. It isn’t possible to put every requirement into use case form – but most of the functional requirements fit well into a use case model.
Developers and testers sometimes create use cases – even in situations where the requirements writers or systems engineers have written requirements documentation in a more traditional manner. The developers create use cases to understand the context for all of the individual detailed requirements statements, and to help guide the development of the system’s architecture.
Use cases may also be used to do “reverse engineering” of an existing system – to create a requirements model that reflects the legacy system’s behavior that needs to be preserved in the new system.

9. Use-Case (Cont.) WHAT is the system supposed to do A use-case is
a set of activities within a system
presented from the point of view of the associated actors
leading to an externally visible result
a (simplified) part of a business process model
WHAT is the system supposed to do
not for functional decomposition
simplified and limited graphical notation
other diagrams and text templates used to support it
combined with prototypes

10. Actors An actor is an entity that is outside of the system
Actors will interact with the system:
an actor will often request the system to perform some actions on behalf of the actor
an actor may also receive responses from the system
An actor plays a “role” in the use of the system
the name given to an actor is usually the “role name”: for example, an actor who is a Person will usually be called a User, Operator, Administrator, or something like that
each role might be treated as a different actor in the use cases
It is important to give clear descriptions of the actors of the system – there should either be a separate document that lists the actors or a list of actor definitions at the beginning of a use case document.
Some of the people who write about use cases also refer to the system itself as an actor. With this definition, a use case is just a set of interactions among a bunch of actors (and one of them is the “system”).

11. More on Actors Actor, entity, control, boundary, source/sink, ...
An actor is
a class that forms a system boundary,
participates in a use-case,
but is not within our responsibility as systems analyst/designer
Examples are
end-user (roles)
external systems
time related events
external, passive objects (entities)
Actor types
Primary – a stakeholder that calls on the system to deliver one of its services
Secondary or supporting actors – ia an external actor that provides service to the system under design

12. Communication between actors and the system
In each use case, a “primary actor” starts things off: that actor initiates an interaction with the system
The system will then respond to messages and might send messages of its own to other actors
In a use case, the primary actor is trying to achieve a specific goal:
the use case consists of all the possible interactions that take place in the attempt to reach the goal
there may be many scenarios in a use case - each scenario shows an alternative “course” that is based on the success or failure of some of the intermediate steps
the goal might not be reached (because of some of the failures)
The use case (and the scenarios that make up the use case) will break the goal down into a series of subgoals. It is possible that one or more of the subgoals might match the goal of another use case.
A use case might “call” another use case (so the author of a use case can avoid repeating a sequence of interactions that appear in many scenarios).

13. Goals A goal is a result that one of the actors wants to achieve
Example goals:
An administrator wants to add a new user to the system
A pilot wants to land a plane
A customer wants to file a claim on an insurance policy
A service person wants to file a trouble report
A goal usually indicates the “final state” that the system should be in when the use case is complete.

14. Scenarios A scenario is a little story
it is an outline of some expected sequence of events
A scenario is used to convey the fundamentals of “how things work”
It usually includes at least one actor
Each actor can make requests of the system or respond to system activity
I would like a book of stamps, please.
OK. Will that be all?
Yes.
That will be $7.40.
Here is $10.
Thanks. Here are your stamps and your change.
Writing scenarios is a simple game of “what happens next”. Some scenarios are easy: there is only one logical sequence of operations from the initial action. Other scenarios are more complicated, with multiple exception cases (when something goes wrong) or different options in the interaction path.
A good clerk (or a good computer) gives very predictable responses to the standard stimuli. Some of the responses will be request for more information from one of the actors:
Customer: “I would like a burger and a diet cola.”
Server: “Would you like fries with that?”
Some scenarios are master-slave interactions, but in most of them, there is some back-and-forth passing of control. The post office example above could be made simpler by omitting the “Will that be all?” question, but the scenario as-is is a much more realistic model of a real postal clerk.
By the way, scenarios are a very old software modeling technique. Although they have been adopted by people doing “object oriented design”, there is nothing inherently “object-oriented” about them.

15. Different styles of use cases
Text formats:
informal paragraph summary – the paragraph will describe who starts the scenario, the key actions by the actors and the system, and how to handle failures
numbered list of steps – in this format, the main scenario is a list of sentences describing the sequence of actions by each actor and/or the system; failure scenarios can be written as branch scenarios at the end
Graphical formats:
UML Sequence Diagrams (also known as message sequence charts)

16. Identifying actors
An Automated Teller Machine (ATM) permits customers to withdraw money from their accounts, make deposits, and check their account balances. The ATM machine communicates with a computer system in the bank’s central office to validate passwords and account information. The ATM is serviced on a regular basis by bank employees, to collect deposit envelopes and to load in more cash and receipt paper.
Question: who are the actors in this system?

17. Creating a simple scenario
Draw a sequence diagram for one of the scenarios in the ATM system. One prominent use case in this system is “customer performs an ATM transaction,” and one scenario in that use case is “customer withdraws money”. Assume we are in the sunny-day scenario.
Customer
ATM
1. Customer inserts card
???
Did you think about which order the ATM will ask its questions?
Did you think about what happens if the customer mistypes the PIN number? (You don’t need to -- this is a sunny-day scenario!)

18. Scenario - Example A scenario is a little story
It describes one possible course of events:
Customer puts ATM card into machine and types password
System validates the card and password
System prompts the customer for a transaction type and amount
Customer selects “withdraw $100 from checking”
System checks with the central bank make sure customer has sufficient funds
System dispenses the cash, returns card, and prints receipt
System asks customer if he/she would like another transaction

19. Representing Use cases
Text templates:
Informal text
informal paragraph summary – the paragraph will describe who starts the scenario, the key actions by the actors and the system, and how to handle failures
numbered list of steps – in this format, the main scenario is a list of sentences describing the sequence of actions by each actor and/or the system; failure scenarios can be written as branch scenarios at the end
Tables – informal text
Structured templates – one popular example (A. Cockburn)
Structured (“semi-formal”) DOORS template
Graphical formats:
UML Use Case diagrams capturing the system boundary, use cases(names), actors, channels and use case relationships
UML Sequence Diagrams (also known as message sequence charts, MSC) to represent scenarios

20. Showing a scenario in text format …
A scenario can be written as a series of sentences:
each sentence shows one step of the scenario
each step needs to explain
who does the operation
what operation is performed
when the operation is performed
are there any side conditions?
one important thing that is not included in the description of each step of a scenario: how the operation is performed (this is left for the design phase)
Important style points:
each step in the scenario must have a subject (either the system or an actor is performing the step)
no passive or impersonal voice allowed (e.g., “the results are displayed”)
In text format use cases, the sentences always have a subject (who performs the operation) and a verb (what operation is performed). If the sentence has nothing else in it, it is assumed that the operation will take place immediately after the operation in the previous step is complete.
The sentence might contain either “time delay” or “time limit” information – the start of an operation might be delayed (“the ATM machine will prompt for the PIN number 15 seconds after the Customer inserts the card”) or the operation may need to be successfully completed within a certain time interval in order for the operation to be successful (“the Customer needs to enter the PIN number within 2 minutes”).

21. Example of a text format scenario
Customer buys a single item:
1. Customer asks for an item
2. Postal clerk acknowledges customer request, checks if the requested item is available
3. Postal clerk asks the Customer if there will be anything else in this transaction
4. Customer indicates that they don’t want anything else
5. Postal clerk determines the price of the requested items and tells the customer
6. Customer pays
7. Postal clerk gives the Customer the items and change
Note: this is not yet a use case, just a single scenario.
In this example, the scenario is slightly more general than the example shown earlier. In this example, the customer asks for an “item” (rather than just “a book of stamps”). The different types of items can be enumerated in a separate section of the scenario document – this will be discussed later when the concept of “variations” is introduced.

22. Showing a scenario in graphical form
Scenarios can be shown in a standard graphical notation – this notation has many different names
Sequence diagram, Event trace diagram, Interaction diagram, Fence post diagram
Postal clerk
Customer
Ask for item
Acknowledge request
Anything else? No
Respond with price
Give money
There is a set of standard object oriented analysis and design notation called the Unified Modeling Language (UML), which has been defined by Object Management Group (OMG), an industry consortium. In UML, these drawings are called “Sequence diagrams.” (In the telecom world, some folks use the ITU term – Message sequence chart – to describe this kind of diagram.)
For more information on UML, see the documents posted on the Rational Software Corp. Web site: A brief summary of UML can be found at
Give item and change

23. Writing a use case
Step 1: Pick one of the potential goals of one of the actors
Step 2: Write down the preconditions for that goal
Step 3: Write the “sunny-day” scenario for the interaction between actors and system
Step 4: Identify the possible failures at each step - think about the alternative scenarios that might result
Step 5: For the main failure situations, either create entire scenarios or create extensions of the main scenario
optional step: Find common chunks that occur in several scenarios that can be factored out to make the scenarios simpler
A “sunny-day” scenario is a scenario where everything goes right – there are no failures in any of the intermediate process steps. It is useful to write the sunny-day scenario first, but also to think about some of the failure paths.
A more complete description of a simple iterative use case development process can be found at:

24. Example use case Use case name: Ticket Buyer buys a lottery ticket
Primary actor: Ticket Buyer
Precondition: Ticket Buyer has $1
Main scenario:
1. Ticket Buyer tells the system (person or machine) that he/she wants to buy a ticket
2. System asks the Ticket Buyer for his/her choice of lucky number
3. Ticket Buyer chooses a number
4. System asks for $1
5. Ticket Buyer supplies $1
6. System prints a lottery ticket and gives it to the Ticket Buyer
Variations:
2. Ticket Buyer chooses a number:
2a. using keypad
2b. fills in circles on card
2c. asks for a “quick pick”

25. Example use case - scenario
Ticket
buyer
machine
Sell me a ticket
Prompt for lucky number
Number choice
Prompt for $1
Insert $1
Dispense ticket
Alternative format for a scenario: UML Sequence Diagram (also known as Message sequence chart)
Note: the scenario explains “what” happens but not “how” it happens (that will be in the design)

26. Example use case (continued)
The use case isn’t finished…
still need to handle failures
go through the steps, list the various ways that they could fail:
Ticket Buyer can’t decide on a number, changes his/her mind
Ticket Buyer fills in too many circles on the card
System can’t print a ticket because it is out of ticket paper
from some failures, the system can recover
from other failures, the use case will “fail”

27. Making scenarios more elaborate
There are three ways to create more elaborate scenarios:
Variations
Extensions
Chunks (subfunctions)
These three techniques are techniques for the use case writer. They help manage the complexity of use cases.
we don’t have to write each individual “course” as a separate scenario
we can identify places where future changes might be likely
we can handle the failure of individual subgoals in a neat way

28. Variations A variation is a way to avoid “scenario explosion”
A variation is a list of alternatives that is tied to a specific line of a scenario
Each variation could turn into a lower-level scenario
An example variation (for the post office scenario):
1. Item is
a. stamps
b. postage on an item that the customer is mailing
c. postage due on an item that the customer is receiving
d. post office box rental
e. mugs, t-shirts, and other Postal Service merchandise
6. Payment is
a. ______________
b. ______________
c. ______________
Main scenario:
1. Customer asks for an item
2. Postal clerk acknowledges customer request, checks if the requested item is available
3. Postal clerk asks the Customer if there will be anything else in this transaction
4. Customer indicates that they don’t want anything else
5. Postal clerk determines the price of the requested items and tells the customer
6. Customer pays
7. Postal clerk gives the Customer the items and change
Some people call these varations the “Technology Variations” – because they are often used to specify the technology options for the communication between the system and the actor.
Most people list the variations in a separate section of a use case document - separate from the main scenario.
When a use case contains a variation, this is a “tip” that the developers ought to profit from in structuring their design. The designers should try to keep the system’s implementation flexible in the area where a variation is present, because this is a part of the system where new variations may arise in the future.
A variation is the absolutely simplest kind of “branch” in a straight-line use case scenario. The next page (“extensions”) will show branches that can be more complicated than a single step.

29. Extensions
An extension is a short scenario that “branches off” from another scenario
Extensions are used to describe recovery actions when something goes wrong
extensions might rejoin the main scenario
or extensions might just terminate because the goal can’t be achieved
An example extension (for the post office scenario):
2a. Item is not available:
2a1. Postal clerk looks for an equivalent item
2a2. If an equivalent item is found, the Postal clerk asks customer if the equivalent item is OK
Main scenario:
1. Customer asks for an item
2. Postal clerk acknowledges customer request, checks if the requested item is available
3. Postal clerk asks the Customer if there will be anything else in this transaction
4. …
In this example, the extension labeled “2a” is triggered if there is a failure of step 2. “Item not available” is called the extension condition. The extension condition must be some condition that the system can detect.
The steps listed under “2a” are the recovery actions. These are the steps that are taken to try to satisfy the original goal of the primary actor, even though one of the intermediate steps in the use case didn’t work.
There may be may be more than one extension condition. If so, they are each labelled with a different letter – for example, 2a, 2b, 2c, and so on.
Extensions are also listed in a separate section of a use case document from the main scenario.

30. Chunks
A chunk is a “sub-scenario” - a sequence of messages that appears in several scenarios for one or more use cases.
A chunk is a scenario that addresses a specific subgoal
for example: logging in, searching for a specific product, etc.
They are the “subroutines” of the use case family
They may express some common “user interface” sub-scenarios
Alistair Cockburn calls them “subfunctions” (but we don’t want to think of them as associated with low-level code)
A chunk is created to save typing: to list a set of steps that appear in multiple scenarios within a use case (or even in multiple use cases).
If a chunk is actually accomplishing a goal for some actor in the system, you might consider promoting it to an actual use case.

31. The UML Use Case Diagram
In UML (Unified Modeling Language), it is possible to show a picture of the system as a group of use cases:
each stick figure is an actor
each ellipse represents a use case
The diagram is deceptively simple
behind each ellipse, there might be a whole bunch of scenarios – sunny-day, alternatives, failures
the diagram is only a “summary”
withdraw cash
Customer
check balance
Bank Employee
service ATM

32. A simple format for a use case
Use case 1: Employee opens door
Goal: An Employee wants to unlock a door to pass from one room to another.
Preconditions: The Employee has valid identification to open the door.
Success end condition: Employee has successfully opened the door.
Failed end condition: Door remains closed and the Security Guard on duty is notified.
Actors: Employee, Security Guard
Main scenario:
1. Employee’s identification and door identification is sent to system
2. Door is unlocked
3. Employee opens door, passes through the door, and recloses door, SUCCESS
Extensions:
2a. Employee’s identification is not valid
2a1. System notifies Security Guard, FAIL
open
door
reset
alarm
test
Employee
Security
Guard
Repair
Person
Office Security
System
This shows a very simple use case for an office security system. In this system, there are doors that need to be opened electronically by the security system. The Employee provides some kind of identification: the Employee might type an identification number on a keypad or pass a keycard over a machine that reads the code on the card.
This use case could include some supplementary information:
performance: there could be a concluding paragraph that notes the average or maximum amount of time taken to perform each of the steps (for example: the door should be unlocked within 20 seconds after the Employee enters the identification information)
cross-references to other use cases: some actions in this use case might trigger other use cases (for example:
when the Employee recloses the door, the “lock door after closing” use case will be performed
if the Employee fails to close the door within 1 minute of opening the door, the “door left open” use case will be performed to alert the Security Guard

33. More Notations and Examples

34. Use-Case diagrams - actors
cellular network
Textual stereotype (class)
Visual stereotypes (classes)
actor
persons & roles
boundary/interface
control
entity
passive objects
data stores

35. Use- Case diagramms - use-cases
Representing use cases - more details
Use- Case diagramms - use-cases
Use-Case Number (ID) & Name
Actors
Pre- & postconditions
Non-functional requirements
Behavior - main scenario
sequence diagram(s)
decomposition in smaller UC diagrams
Error-handling & exceptions
Other
examples, prototypes, etc.
open questions & contacts
other diagrams
place
phone call
UC description

36. More on Use-Case diagrams
Show use-cases & actors
connected by „associations“
refined by inheritance stereotypes
“uses”
re-use of a set of activities (use-case)
partitioning of activities
points to the re-used use-case
“extends”
variation of a use-case
points to the standard use-case
elicit customer
needs
“extends “
make an
interview
“uses “
produce a
SRS

37. Use-Case diagrams: Example
customer
traveler
anybody
clerk
search for
a flight
check
travel options
“uses”
flight db
“actor“
flight res-sys
book
pay
with cc
credit-card sys
Pay a
bill
“extends”
prepare-travel

38. On Use Case Levels It is possible to write
“business-level” use cases –
organizational goals (marketing, finance, systems engineering, installation)
or “system-level” use cases
goals of specific users
or “subsystem-level” use cases
goals of the other subsystems

39. Levels of scope (A. Cockburn)
Summary-level goals
“cloud-level”
Upgrade all
customers
User goals
“sea-level”
usually 2 to 20 minutes
Add new
service
Sub-functions
“under water”
not a real “user goal”: these scenarios describe common sub-operations
Find list of
services
The concept of “Goal Level” is described in detail in Alistair Cockburn’s book Writing Effective Use Cases.
When using use cases to document system requirements, it is best to keep most of the use cases at the “user goal” level, although it is also a good idea to document some of the “summary-level goals”. You can waste a lot of time creating detailed subfunction-level scenarios that might be completely ignored during software design.
If it is really necessary to include “underwater behavior” in the requirements documentation, don’t write the behavior as use cases – choose a different formalism. For many telecom applications, state machines work well for modeling the internal behavior of the system.

40. Goals & Sub-goals
Each use case represents a “goal” of one of the actors
the use case is “the set of all scenarios that might happen” in trying to reach that goal – success or failure scenarios
each scenario is a series of smaller sub-goals
if you can succeed in each step, you will reach the goal
if a step fails, then there might be an alternative series of steps that get to the goal
the substeps might be lower-level use cases, or they might just be “things implemented in the design”

41. Use Case diagram decomposition
Use- Case diagrams: Hiearachies
diagram name: anything
uc-1
Use Case diagram decomposition
uc-2
uc-3
uc-4
Diagram name: anything-level2-for-uc4
uc-4.1
uc-4.2

42. Use Case Process Step 1: Create a list of Actors
Customer
Repair person
Administrator
Step 2: Create a list of Goals
Web-based music distribution system:
UC1: Customer downloads a song
UC2: Customer searches music directory
UC3: Administrator adds a new user
UC4: Administrator updates directory
UC5: Support hotline person investigates a Customer problem
UC6: Support hotline person authorizes Customer refund
UC7: Repair person runs diagnostics
Step 3: Write simple use cases with only sunny-day scenarios
Precondition: Song file is on a server
Main scenario:
1. Customer chooses song
2. System checks availability and price; prompts Customer for payment
3. Customer enters credit card info
4. System sends credit card transaction to Bank
5. Bank returns transaction number
6. System transmits the song to Customer’s computer
Support
hotline person
Step 4: Review the use cases with customer (or customer surrogate)
In Step 1: The goal is to produce a list of all of “external users” of the system – both human and machine. Each actor should have a short, clear definition (usually three sentences). The “stick-figure” is the UML notation for an actor.
In Step 2: The goal is to produce a list of the most important operations in the system, where “important” means “one of the actors really cares that the operation is performed”.
The most difficult part of creating the “goal list” is writing the goal the correct level. Most use cases are written at user-goal level:
one actor can perform the activity in one sitting (between 2 and 20 minutes), and it is something that the actor might get paid for
this definition knocks out complete end-to-end business processes (summary goals) that include multi-day shipping; it also eliminates microscopic goals such as “administrator logins in” (would you pay someone for 100 logins per day?)
In Step 3: We focus on the “sunny-day” scenario for three reasons:
if we can’t agree on the sunny-day behavior, it is useless to go forward
it is important to understand the complexity of the sunny-day scenario when doing performance analysis
the main scenario is the best place to start when doing failure analysis
In Step 4: The goals of the review:
to weed out errors in the initial use cases
to find missing actors and missing high-priority use cases – you should ask the customer “If we deliver a system that has the specified behavior, will you be happy?”

43. Use Case Process (Cont.)
Step 5: Identify failure conditions
2a. Song is not available
3a. Customer quits without entering credit card info
4a. Link to Bank is down
5a. Credit card is rejected by Bank
6a. Server fails during transmission
6b. Customer cancels during transmission
Step 6: Write a selected set of failure scenarios and alternatives
Step 7: Internal review
review the scenarios and failure branches with testers, developers, project managers
Ongoing: make links to other requirements, update use case model as needed
define the business rules and non-functional requirements (in text documents, with links to the use case model)
add new use cases and new scenarios for new actors and goals; new variations for existing use cases
5a. Credit card is rejected by Bank:
5a1. System reports failure to the Customer, prompts Customer for a different credit card
5a2. Customer enters card info
5a3. go to step 4
In Step 5: Each failure condition is a “detectable condition” that the software must be able to support.
In Step 6: The branch scenario can either complete (with success or failure), or the branch scenario can rejoin the main scenario.
In Step 7: Each kind of reviewer looks for different problems.
Testers want to be able to derive a fairly complete set of functional tests for the system from the use cases – so they want good “feature coverage” and good descriptions of the most important failure cases. Testers will complain when the preconditions for each use case are vague and when there are key failure scenarios missing from the use case model.
Developers want scenarios they can use to evaluate their architecture and designs. Designers will complain when the scenarios are too detailed (for example, they prescribe specific user interface details) and when there are gaps in the scenarios (some steps of the scenario don’t logically follow from the preconditions or the preceding scenario steps).
Project managers want to be able to divide the work into logical groupings based on the scenarios, so they can track what functionality is being delivered at each software release. They prefer having high-priority and low-priority functionality in separate scenarios.
Ongoing: In order to be able to work in an environment where the requirements will be changing over time, you need to make sure there are links between the use cases and other models:
Requirements-to-requirements links: links from individual scenario steps or whole scenarios to the “associated business rules” that give more details about the requirements.
Requirements-to-design links: links from each use case to the principal entities (architecture scenarios, design-level classes, state machines, etc.) that implement the use case.
Requirements-to-test links: links from each use case to the test cases that validate that the system really supports the required behavior.

44. Use Case Tips When you do “use case brainstorming”:
try to create a list of actors: write down a definition of the actor that everyone can agree on
actors are “roles”, not job titles
in the scenarios, start each step with the name of an actor or the system
not “the lucky number is entered”
better: “the Ticket Buyer enters the lucky number”
use strong, active verbs in the steps of the scenarios
not: Make, Report, Organize, Record, Retrieve, Search
better: Create, View, Calculate, Register, Find, Browse

45. How many use cases is enough?
It depends…
make sure you cover the major goals of each actor
don’t forget OA&M – administrative use cases usually include initialization, running backups, diagnosing problems, and reporting current status to another system
some systems might need use cases, but most only have 20-40
do some “abstraction” to reduce the number of scenarios

46. Use Cases contribute to agility
It is important to be “agile”
Requirements
get direct customer involvement in documenting the requirements – using scenarios and use cases
Architecture
make better architectural decisions – use the high-runner, high-priority scenarios to assess “candidate architectures”
Project management
use cases can help to plan an iterative development process
Test
update the tests as the requirements change

47. Agile development
Some important goals in today’s software development:
focus on the customers’ needs
adapt to changing requirements; support iterative development
document the core requirements faster
The “agile development” approach:
everyone collects requirements using scenarios or stories
project managers assign priorities (with the help of the customer)
everyone plans to add “variations” of the scenarios – but don’t implement every variation in the first release
developers use scenarios in their designs; testers build tests from scenarios

48. Scenarios and use cases in design, coding, and test
The use cases are a very useful form of requirements
they attempt to describe the externally visible behavior of the system
they are concise enough for everyone to read (customers, developers, testers)
Use cases can be kept under change control
Design-level and code-level comments ought to refer to individual use cases, so that individual design decisions can be revisited when the use cases are changed
System-level tests will use the information from use cases
It is important to give “names” or “numbers” to each use case, so designers and developers can refer to them unambiguously in their models and code. A design document or source code file might contain a comment such as “this module helps to implement the ‘Employee opens door’ use case” or “this class implements the user interface section of Use Case #6”. This sort of cross-reference will make it easier to find the parts of the design that have to be revisited if there is a requirements change that affects some of the use cases.

49. Impact of Use Cases on Software Teams
Systems engineers: improve communication with development team
SEs will write the key functional requirements as use cases (typically, 20 to 200 use cases for a system)
the set of system-level use cases (a subset of the overall requirements) can be constructed and reviewed quickly
customers can validate the main scenarios
Architects: benefit from using the most important “failure scenarios” to evaluate the architecture
Development managers: “iterative and incremental development” can start with the high-priority use cases – focus on the scenarios that deliver the maximum value to customers
Developers: code inspections can narrow the focus on the most important scenarios
Testers: integration and system tests are guided by the use cases

50. Use cases and requirements
Use cases are requirements
a use case will specify the essential behavior that the system must deliver
Use cases are usually about 1/3 of the total volume of requirements
The use cases are supplemented by other kinds of requirements information
Business Rules: conditions, policies, and conventions
Operational Profiles: how many scenarios
Architectural Requirements: “-ilities” (reliability, usability, performance)
Business Rules
BR1. Each employee has a unique identification number.
BR2. Each “open-door” request is logged.
Operational Profiles
OP1. During the busy hour (8-9am), the system should be able to handle 500 “open-door” requests (UC1 sunny-day).
OP2. The “test alarm” use case will be executed every weekend.
Architectural Requirements
AR1. Maximum time to process an “open-door” request is 15 seconds.
AR2. No more than 5 minutes downtime per year.
For more information, see the paper “Building and Applying Requirements Models” by Indira Kuruganti and Dennis Mancl in Bell Labs Technical Journal, Fall 2003,
Business rules come in many different flavors:
computational rules
structural facts
action restricting rules
action triggering rules
inferences
There is more detail in the book Use Cases: Requirements in Context by Daryl Kulak and Eamonn Guiney.

51. Why use cases?
Why write use cases instead of “normal” functional requirements?
Use cases hold functional requirements in an easy-to-read, easy-to-track format
Each use case gives information on how the system will deliver a “goal” to one of the users of the system
a use case explains how a goal succeeds/fails using scenarios
the scenarios provide context – traditional requirements are often too ambiguous
“If you have a requirement that doesn’t help meet any of the users’ goals, why do you have the requirement in the system?”
also need to look at the goals of the “stakeholders”
Use cases show only the Functional requirements
the use cases are a framework to attach non-functional requirements and other project details

52. Use Cases and “Requirements”
The use cases are not all of the requirements – some requirements do not fit into scenarios, for examples:
Constraints, e.g., Business Rules (structural facts, computation rules, action restricting rules, action triggering rules)
Non-functional Requirements: security, reliability, performance, usability, flexibility (all of the “-ilities”)
Links to use cases
Constraints and Non-functional Requirements are written in text, and they are related to the use cases where they are pertinent
DOORS links provide an excellent mechanism for this

53. After the use cases are written, what next?
Jumpstart the OOAD – CRC and models
use cases describe the “externally-visible behavior” of the system
an object model describes the internal behavior
Design decisions can be linked back to a use case
Jumpstart test cases
Scenarios provide excellent start for “early testing”
Test planning – RTP and RSTP
DOORS-based traceability
Use the Use Case list to manage your project
Use cases provide excellent basis for structuring and monitoring your project iterations
It is important to be “agile”

54. Use Cases and other “Requirements”
The use cases are not all of the requirements – because some things don’t fit into scenarios
Business Rules (structural facts, computation rules, action restricting rules, action triggering rules)
Non-functional Requirements: security, reliability, performance, usability, flexibility (all of the “-ilities”)
Links to use cases
The Business Rules and the Non-functional Requirements are written in text, and they have links to the use cases where they are pertinent
Some folks store these items in a spreadsheet or a repository tool (such as Telelogic DOORS or Rational RequisitePro)

55. After the use cases are written, what next?
Object oriented modeling – using CRC cards or other informal brainstorming techniques
use cases describe the “externally-visible behavior” of the system
an object model describes the internal behavior
Design decisions can be linked back to a use case
just put comments in your code or model
search for the comments whenever the use cases are modified
Test planning
each use case needs to be converted into test scenarios and test cases
Connection
Customer
Network Elem
Report
create
archive

56. Use cases and CRC cards
Use cases are written to describe the external view of a system
Use cases may describe the high-level physical architecture of a system
but they leave out most of the details about “how” the system will perform most of its functions
CRC cards are created to describe the high-level classes of a system: they describe the first internal view of a system
CRC cards are another “informal” modeling technique that is widely used for the initial “brainstorming” process
CRC cards attempt to identify the high-level classes by describing their behavior and principal interactions
For more information on CRC cards, see Nancy Wilkinson’s book Using CRC Cards (SIGS Books, 1995)
“CRC” stands for “Class, Responsibility, and Collaborators”. Each class in the system is represented by a single index card with the name of the class, the list of functions the class is responsible for performing, and the names of the other classes it directly collaborates with while performing its responsibilities. CRC card sessions always include creating scenarios that describe the end-to-end interactions of the classes in the design. For more information, see:
The fundamental difference between use cases and CRC cards:
Use cases document functional requirements – the behavior that the system must exhibit in order to meet the users’ needs.
CRC cards document the architecture/design – the information about “how the system is structured” in terms of interacting classes.
It is often a good idea to “iterate” – to take an early draft of the use cases as input to a short CRC card session, then to use the result of the CRC card session to revise the contents of the use cases.

57. Iteration management with use cases
A use case model can be very useful in a project with rapid iteration
for each iteration, identify which use cases are “in” the iteration
that is, will some or all of the use case’s scenarios work?
track progress by counting scenarios (with priority weighting)
typical iteration scheme:
first iteration: highest priority use cases, sunny-day scenarios only
second iteration: add a few second-tier use cases, start implementing the failure scenarios that fail completely
later iterations: add a few more use cases, start filling in the “recovery” scenarios
you might choose certain use cases as “high-priority” because they help validate key parts of the architecture

58. References Books: Web sites:
Alistair Cockburn, Writing Effective Use Cases
Daryl Kulak and Eamonn Guiney, Use Cases: Requirements in Context
Steve Adolph and Paul Bramble, Patterns for Effective Use Cases
Kurt Bittner and Ian Spence, Use Case Modeling
Web sites:

59. Extra ....
Use Cases and Tools …

60. Use cases and RM Tools

61. Storing Use Cases in DOORS
A Use Case is stored in the DOORS “hierarchical object structure”:
entire DOORS module
a Use Case object in DOORS
These two snapshots show the “browser window” (the left-hand window) in the DOORS interface. It shows an expandable outline of DOORS objects. If you click on an object title, the right-hand window scrolls to the part of the database that contains the object.

62. This is a snapshot of the DOORS user interface – browser window on the left, the actual database on the right. Note that some of the information about the scenario steps (the step number and the “actor in control”) are defined in specific attributes in the DOORS model.

63. This picture shows how the previous use case can be documented in the DOORS requirements repository tool. Each use case follows a template that has a series of sections that contain the key attributes for the use case: name, level, description, primary actor, preconditions, and so on.

64. This picture shows the “Preconditions” and “Main Scenario” sections for the previous use case. In the “Main Scenario” section, the step numbers (1, 2, 3, etc.) are defined in a separate “Step Number” column of the table.

65. This picture shows the Main Scenario as a Sequence Diagram in the Rational Rose tool. To create this diagram, the use case has been exported to an XML file that has been imported into Rose (using the transfer tools from the PacketIN “artifact flowthrough” initiative). The text on each step of the main scenario is identical to the text in the main scenario in DOORS.

66. Extra ....
Modeling …

67. Why build models? To organize the work
Building software is a time-consuming and complex operation
Good quality software can have a long lifetime
To improve communication among team members
Software is very labor-intensive: many people play a part in the construction of a software product
Ordinary text documentation is inherently imprecise and ambiguous
To aid in the “thinking process”
In most software development projects, the actual form of the “thing to be built” is initially very vague
Iterative and incremental development will focus on changes to the models - it is easier to “rebuild the model” than to “rebuild the system”
Models have been used in many engineering fields: both “paper models” and actual physical scale models of buildings, bridges, automobiles, ships, airplanes, and so on. These models are used by members of the development team:
to organize the team’s work: the model makes it easier for the team members to break the problem down into multiple pieces that can be worked on by different subteams, and new team members can gain an appreciation for the overall structure of the system by referring to the model
to improve communication: a model gives team members a more concrete reference to the structure of the problem and its solution when they discuss different design alternatives, and the structure of the model often introduces a “vocabulary” of standard terms to use in design discussions
to aid in “thinking” about the problem and its possible solutions: the model may be subject to iterative modifications throughout the development process, as the team members learn about new customer requirements or they find reusable components that might apply to the problem

68. Some traditional modeling techniques
Data modeling (using Entity-Relationship Diagrams)
the system is viewed as a set of “data entities” and “relationships”
the model includes the “transactions” that are applied to the system
Data flow
the system is viewed as a group of data sources, data stores, and active processes that exchange data messages on a regular basis
the model emphasizes the frequency and data content of the messages
State machines
each element of the system has a “internal” state
there can be transitions from one state to another when certain key “events” are received by an element
Airport
served by
City
course
offering
data
vali-
dation
Student
registration
request
update DB
registration DB
student info
idle
beeping
cooking
turn on
open door
open
door
cancel
timer
In all of these modeling techniques, there are a set of standard notations for representing the parts of the model, and there may also be some computer-based tools for recording information in parts of the model.
Data models (E-R diagrams) describe the “structure of the data”
Dataflow diagrams describe the “processes” that access the data and perform computations
State machines describe the “events” that can have an effect on major entities in the system

69. System-level static data model
In the process of creating a set of use cases for a system, it is useful to think about the major data entities in the system
these data entities and their connections can be drawn using Entity-Relationship diagrams or Class diagrams
the names of the entities are often used in the descriptions of the actions in the use case scenarios
Be careful not to “over-specify” the data entities
you should only specify the key data attributes (not all of the attributes)
it is sometimes useful to describe some of the fundamental responsibilities of the data entities (using CRC cards or other OO techniques) 1
Transaction 1 1
Receipt
0..*
Item

70. Extra ...
Example …

71. Exercise
What are the main actors and use cases for an Online Banking System?
Actors:
Use cases

72. Lottery system exercise
The system to be built is a distributed computer system for a state lottery.
The system will be used by three kinds of users: ticket buyers, lottery ticket agents, and lottery staff people.
Ticket buyers use the system to buy lottery tickets. Each ticket costs $1.
Lottery ticket agents pay prizes to ticket buyers who turn in winning lottery tickets.
A lottery staff person will post the winning number of the day on the computer system, check on the day’s revenue, and disable ticket sales one minute before the drawing.
List the actors for the whole system:
Ticket buyer
List the actors for the lottery ticket machine subsystem:
We have two ways of thinking about “what is the system”:
the “system” might be the combination of all of the ticket machines and the central computer system that manages the network – all communication between ticket machines and the central system are merely internal design scenarios
or the “system” might just be the individual ticket machine – which makes anything that the ticket machine interacts with into an “external actor”

73. A lottery system use case
Use case for the “ticket buyer buys a ticket” situation (assume that we are considering the whole system and not just the lottery ticket machine subsystem):
Use case name:Ticket buyer buys a ticket
Actors: (a list of all the actors involved in this use case) ????
Authors of this use case: me
Summary:
Preconditions: (what has to be true before this use case can be initiated?)
????
Frequency: (how often will this use case happen? – once per week, once per hour, …)
Description: (in words or as one or more sequence diagrams – use more pages if needed) 1. 2.
Exceptions, Variations, Extensions, and Chunks:
This is a very simple template for a use case. Even in this bare-bones form, it contains information that is useful to architects and developers.
Some other standard templates for use cases:
PacketIN template (MS-Word):
Alistair Cockburn template (MS-Word):

74. Sample list of actors Actors for the whole system Ticket buyer
Lottery ticket agent
Lottery staff person
Actors for the ticket machine subsystem
Central computer
Machine service person

75. Sample lottery system use case
Use case name: Ticket buyer buys a ticket
Actors: Ticket buyer
Authors of this use case: me
Summary: The Ticket buyer wants to buy a $1 lottery ticket, and the ticket machine will take the money and ask the Ticket buyer to enter his/her choice of number.
Preconditions:
Ticket machine has been initialized
Ticket buyer has $1
Frequency: maximum: 5,000,000 per day for the entire lottery system; 10,000 per ticket machine per day
Description:
1. Ticket buyer inserts $1 into ticket machine
2. Ticket machine prompts the ticket buyer for a number
3. Ticket buyer chooses a number
4. Ticket machine prints the ticket
Variations:
1. Ticket buyer can insert $1 as 3. Choosing a number can be
1a. dollar bill 3a. typing a set of digits on machine’s keyboard
1b. coins 3b. hitting the machine’s “quick pick” button

76. Extra ...
Summary …

77. Better Requirements and Product Quality through Use Cases (UC)
Summary of Characteristics and Benefits
UCs capture a contract between the stakeholders of a system about its behavior
UCs specify system’s behavior under various conditions (success & failure modes) in a way that is concise and easy to understand, track, and validate
UCs are collections of scenarios; scenarios provide context – traditional requirements are often too ambiguous
UCs are a key to the creation/ generation of quality test cases and system verification
Industry data:
Use cases improved developer productivity by 40% (DaimlerChrysler)
35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases
Impact of Use Cases on Software Teams
Systems engineers: improve communication with development team
- SEs will write the key functional requirements as use cases (typically, 20 to 200 use cases for a system)
- the set of system-level use cases (a subset of the overall requirements) can be constructed and reviewed quickly
- customers can validate the main scenarios
Architects: benefit from using the most important “failure scenarios” to evaluate the architecture
Development managers: “iterative and incremental development” can start with the high-priority use cases – focus on the scenarios that deliver the maximum value to customers
Developers: code inspections can narrow the focus on the most important scenarios
Testers: integration and system tests are guided by the use cases

78. Vocabulary in this section
use case: collection of scenarios related to a goal
goal: what the actor is trying to accomplish when using the system (this might succeed or fail)
scenario: a sequence of interactions
sunny-day scenario: a scenario where everything works
failure scenario: a scenario that explains what happens when something goes wrong
variation: a set of choices for a single scenario step
extension: a branch scenario that starts with an extension condition
actor: a person or system outside of the system under development
precondition: one of the conditions that must be true when a scenario of the use case is triggered
chunk or subfunction: a set of scenario steps that are repeated in several different use cases
business rule: one of the rules that describes how the business is run
operational profile: description of which use cases will be run at the same time

79. Useful books Writing Effective Use Cases by Alistair Cockburn
Patterns for Effective Use Cases by Steve Adolph and Paul Bramble
Use Case Modeling by Kurt Bittner and Ian Spence