Usecase

1. 1 Defining Requirements with Use Cases © Deloitte Inc.
Defining Requirements
with Use Cases
Consulting Technology Integration
July 15, 2005

2. 2 Defining Requirements with Use Cases © Deloitte Inc.
Table of Contents
•Introduction…………………………………………………………………………………… 2
•Overview of Use Cases…………………………………………………………………. 8
•Actors and Goals…………………………………………………………………………… 30
•Preconditions, Triggers and Guarantees……………………………………… 73
•Scenarios……………………………………………………………………………………….79
•Extensions……………………………………………………………………………………..104
•Extension Use Cases……………………………………………………………………..138
•Parameterized Use Cases……………………………………………………………..153
•Other Requirements……………………………………………………………………..160

3. 3 Defining Requirements with Use Cases © Deloitte Inc.
Introduction

4. 4 Defining Requirements with Use Cases © Deloitte Inc.
Welcome and Introductions
•Instructor and the class introduce themselves
•Please turn to someone next to you and ask them:
–How they have captured requirements for any application or system they
have worked in the past
–Their best and/or worst experience relating to capture of requirements
–Be ready to share this experience with the rest of the group

5. 5 Defining Requirements with Use Cases © Deloitte Inc.
Learning Objectives
•Upon successful completion of this course, you will be able to:
–Capture system and business requirements using Use Case Models
–Create requirement documentation that is both readable by the client, and
precise enough to support future analysis, design and implementation work
–Know when Use Case Models are useful in capturing requirements and when
they are inappropriate
–Understand the difference between functional and non-functional
requirements
–Understand the difference between a well-written and a poorly-written Use
Case
–Become familiar with industry best practices regarding requirements capture
and definition

6. 6 Defining Requirements with Use Cases © Deloitte Inc.
Workshop Agenda
•Day 1:
–Use Case Overview
–Actors and Goals
–Preconditions, Triggers and Guarantees
–Scenarios
•Day 2:
–Scenarios Continued…
–Extensions
•Day 3:
–Extension Continued…
–Extension Use Cases
–Parameterized Use Cases
–Other Requirements
–Introduce The Assignment Lab
•Day 4:
–Assignment Lab Work
•Day 5:
–Assignment Lab work

7. 7 Defining Requirements with Use Cases © Deloitte Inc.
The Case Study: ACME University Degree Management
System
•Throughout the course, we will be making reference to the ACME
University Degree Management System (ADMS)
•Group activity with every course module
•Designed for application of key lessons in course modules
•Provides practice in the principles that underlie these documents
•Sample templates are included in your course material
•Periodically, the class will be broken up into teams to define and
capture ADMS requirements

8. 8 Defining Requirements with Use Cases © Deloitte Inc.
Software Development Life Cycle (SDLC)
•A process of developing a software system in an organized, controlled,
and predictable way.
•The process starts at the conception of the project to its termination
with the company, sometime called a cradle-to-grave process.
•Typical phases include: Requirements, Analysis, Design,
Implementation and Testing.
•This course is primarily concerned with the requirements phase

9. 9 Defining Requirements with Use Cases © Deloitte Inc.
Overview of Use Cases

10. 10 Defining Requirements with Use Cases © Deloitte Inc.
Further reference
•This course has been influenced by the writings contained in the
following two books
–Patterns for Effective Use Cases
by Steve Adolph, Alistair Cockburn, Andy Pols, Paul Bramble
–Writing Effective Use Cases
by Alastair Cochran

11. 11 Defining Requirements with Use Cases © Deloitte Inc.
Module Objectives
•Upon successful completion of this module you will be able to:
•To get a high level understanding of what a use case is
•To know when Use Cases are appropriate and when they are not
•To get an understanding of all the artifact necessary to create a use
case model
•To understand the overall approach used to create use cases

12. 12 Defining Requirements with Use Cases © Deloitte Inc.
What is a Use Case (More or Less)
•Captures a contract between the stakeholders of a system about its
behavior
•Describes the system’s behavior under various conditions as the system
responds to a request from one of the stakeholders, called the primary
actor.
•The primary actor initiates an interaction with the system to accomplish
a goal
•The system responds, protecting the interests of all the stakeholders
•Scenarios can unfold depending on particular requests
•Fundamentally in text form
•When a Use Case documents an organization’s business processes, the
system under discussion (SuD) is the organization itself
•When a Use Case documents behavioral requirements for a piece of
software, the SuD is the computer program

13. 13 Defining Requirements with Use Cases © Deloitte Inc.
Requirements and Use Cases
•Use cases are requirements but not all the requirements
–Don’t detail external interfaces, data formats, business rules, and complex
formulae.
–Only a fraction of all the requirements you need to collect
•Use cases are ALL the behavioral requirements
–Business rules, glossary, performance targets, process requirements, and
many other things do not fall into the category of behavior

14. 14 Defining Requirements with Use Cases © Deloitte Inc.
A Plausible Requirements Outline
Chapter 1. Purpose and Scope
1a. What is the overall scope and goal?
1b. Stakeholders (Who cares?)
1c. What is in scope, what is out of scope?
Chapter 2. Terms Used / Glossary
Chapter 3. The Use Cases
3a. The primary actors and their general goals
3b. The business use cases (operations concepts)
3c. The system use cases
Chapter 4. The Technology Used
4a. What technology requirements are there for this
system?
4b. What systems will this system interface with,
with what requirements?
Chapter 5. Other Requirements
5a. Development process
Q1. Who are the project participants?
Q2. What values will be reflected (simple, soon,
fast, or flexible)?
Q3. What feedback or project visibility do the users
and sponsors want?
Q4. What can we buy, what must we build, what is
our competition?
Q5. What other process requirements are there
(testing, installation, etc.)?
Q6. What dependencies does the project operate
under?
5b. Business rules
5c. Performance
5d. Operations, security, documentation
5e. Use and usability
5f. Maintenance and portability
5g. Unresolved or deferred
Chapter 6. Human Backup, Legal, Political,
Organizational Issues
Q1. What is the human backup to system
operation?
Q2. What legal and what political requirements are
there?
Q3. What are the human consequences of
completing this system?
Q4. What are the training requirements?
Q5. What assumptions, dependencies are there on
the human environment?

15. 15 Defining Requirements with Use Cases © Deloitte Inc.
Definitions
•Actor: a person or a object (ie external system) with behavior
•Stakeholder: a person with a vested interest in the behavior of the
system under discussion (SuD)
•Primary actor: the stakeholder who initiates an interaction with the SuD
•Use Case: a collection of scenarios that describes how a primary actor
uses the SuD to achieve a specific goal
•Use Case Set: the model of the required behavior of the SuD
•Scope: identifies the system that we are discussing (what is it – what
does the Use Case cover)
•Preconditions and guarantees: what must be true before and after the
use case runs
•Main success scenario: the most common successful scenario in a Use
Case
•Extensions: all possible alternative scenarios and error conditions that
can happen in a specific Use Case

16. 16 Defining Requirements with Use Cases © Deloitte Inc.
Well-Written Use Cases
•Easy to read
•Sentences written in only one grammatical form – a simple action step
–Example: Sales Clerk enters customer profile
•Should not take more than a few minutes to read
•Three important concepts
–Scope
–Primary actor
–Level

17. 17 Defining Requirements with Use Cases © Deloitte Inc.
Your Use Case is not My Use Case
•Use Cases vary from project to project
•Use Cases are a form of writing that can be put to work in different
situations
•Close-knit group gathering requirements will write casual as opposed to
fully dressed use cases
•Business process people will write business use cases to describe the
operation of their business while hardware or software developers will
write system use cases

18. 18 Defining Requirements with Use Cases © Deloitte Inc.
Casual vs Fully Dressed Use Cases
Casual:
•Team of three to five people building a smaller less critical system
–Simpler template will do the job
–More variation tolerable in writing style
–Fewer and more forgiving reviews
Fully Dressed:
•Team working on software for large, mission-critical project:
–Extra ceremony worth extra cost
–Use case template needs to be longer and more detailed
–Writing styles should be similar
–Reviews should be tighter

19. 19 Defining Requirements with Use Cases © Deloitte Inc.
Use Case Examples: Casual
Use Case: Enroll in Course (Casual Version)
Student must be registered in the system before starting this use case.
The student logs onto the system and may search for courses to enroll in. The
Student searches by course name, course code, department, level and
availability. The Student then selects the course to enroll in and the system will
respond by displaying the course details. The student then confirms the
enrollment and logs out of the system or enrolls for more courses.
If the system goes down at any time, the system will display an appropriate error
message and the use case will end. If the student tries to enroll for a course that
is full, the system will inform the Student. The Student may then continue to
enroll in other courses.
The system must respond to any search request within 3 seconds. The system
must be able to perform up to 1000 concurrent searches. The System should be
able to support 500 concurrent users enrolling in classes. Class enrollment should
take no longer than 10 seconds to confirm.

20. 20 Defining Requirements with Use Cases © Deloitte Inc.
Use Case Examples: Fully Dressed
Use Case Name: Enroll in Course
Stakeholder Interests:
•Student – wants to enroll in course
•Professor, Department Head – wants a fully
enrolled course
Preconditions: Student must be registered in the
system
Main Scenario:
11.Student Logs On to the system.
Steps 2 to 6 can be repeated until the student has
reached maximum course load for the term.
13.Student searches for courses (course name, course
code, by department, by level, by availability).
14.System displays search results (course name,
course code, department, level, availability).
15.Student selects a course to enroll in.
16.System displays course details.
17.Student confirms enrolment.
18.Student Logs out.
Exceptions
EX1: System Down (applies to all steps)
a. System displays error message.
b. Use case ends
EX2: Course Already Full (applies to MS step 6)
System displays message to user.
Go to MS step 2.
Non-Functional Requirements
NF1: (Applies to MS step 2)
–System must respond to a search request within 3
seconds.
NF2: (Applies to MS step 6)
–System must respond to an enrollment request
within 10 seconds.
NF3: (Applies to step 6)
–The System should be able to support 500
concurrent users enrolling in classes.
NF4: (Applies to step 6)
–The System should be able to support 1000
concurrent searches.

21. 21 Defining Requirements with Use Cases © Deloitte Inc.
Manage Your Energy
•Problem:
–You will not make timely progress or create coherent use case sets if you
waste energy writing detailed use cases sequentially.
–Context:
•Requirements gathering is a process of discovery
•People are drawn into writing details early
•People lose energy or get bogged down in too much detail
•It is advantageous to get an overview early
•The more detail your early endeavors, the more you will have to change them as you
learn more about the system
–Solution: Breadth Before Depth
•Conserve your energy by developing an overview of your use cases first, then
progressively add detail, working across a group of related use cases.

22. 22 Defining Requirements with Use Cases © Deloitte Inc.
Steps to Writing Use Cases
Writing use cases can be divided into 5 stages of precision
2.List Actors and their goals
3.Create Use case briefs
4.Describe Main success scenario
5.List alternate and failure scenarios
6.Describe alternate and failure scenario steps

23. 23 Defining Requirements with Use Cases © Deloitte Inc.
Scope
•Scope = activity and responsibility covered by a given subject, system,
organization, etc.
•Keeping track of scope can be difficult
•In/out list - a simple and effective tool to control scope discussions for
ordinary meetings as well as project requirements
INPost and download course notes
INApproving and rejecting degree and course changes
OutTracking student grades for courses
IN
Purchasing Books Online through the AMCE University Online
Bookstore
OutInTopic

24. 24 Defining Requirements with Use Cases © Deloitte Inc.
Vision
•Establishes the purpose and objects for the SuD
•Crucial in determining scope
•Example:
–The ACME University currently manages all degrees, course scheduling, course
enrollment, asset management, and majority of other curriculum based functions
through a paper based manual process. This process has proven to be very expensive
and error prone. Furthermore, the process is not well understood by the majority of the
university faculty.
–ACME University would like to establish an online application that will offer a set of
integrated services vital to managing the university and its curriculum. These services
will consist of but are not limited to degree and curriculum management, complete
management of courses from scheduling and enrollment through to grading, tracking of
all students and professors, managing all processes from registration to hiring and
firing.
–By housing all of these integrated services into an online tool, ACME University will save
significant overhead in overseeing the various administrative functions of the university.
The online application will also increase the ability of ACME University professors to
respond to the ever changing world of academia by making it easy for them to
collaborate with each other when modifying the existing curriculum.

25. 25 Defining Requirements with Use Cases © Deloitte Inc.
Key Points
•Use cases capture goal oriented behavior of various actors in
relationship to the system under discussion (SuD)
•The SuD can be an application, a business, or any other type of system
•Use cases can be written in a casual or formally dressed
•Develop use cases in an iterative fashion, focusing on adding greater
levels of detail to the entire use case set
•Defining scope is crucial to creating the use case set.

26. 26 Defining Requirements with Use Cases © Deloitte Inc.
Patterns

27. 27 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: MultipleForms
•Problem:
–Different projects need different degrees of formality in their work, and
various people have different preferences for the template. Requiring
everyone to use the same use case template is counterproductive.
•Context:
–People and projects are different
–Different teams want different amounts of formality
–Using common form within an organization facilitates communication
•Solution:
–Select the format based on the risks associated with the project and the
preferences of the people involved

28. 28 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: BreadthBeforeDepth
•Problem:
–You will not make timely progress or create coherent use case sets if you
waste energy writing detailed use cases sequentially.
•Context:
–Requirements gathering is a process of discovery
–People are drawn into writing details early
–People lose energy or get bogged down in too much detail
–It is advantageous to get an overview early
–The more you detail your early endeavors, the more you will have to change
them as you learn more about the system
•Solution:
–Conserve your energy by developing an overview of your use cases first, then
progressively add detail, working across a group of related use cases.

29. 29 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: SharedClearVision
•Problem:
–The lack of a clear vision about a system can lead to indecision and contrary
opinions among the stakeholders and can quickly paralyze the project.
•Context:
–Time pressures can encourage people to start developing a system
prematurely, basing their work on erroneous assumptions. Getting them back
on track can be expensive
–Builders have a natural tendency to expand the scope of the system
–Stakeholders have competing visions
–People in the trenches don’t know what the goal if the project is
–People don’t communicate
•Solution:
–Prepare a statement of purpose for the system that clearly describes the
objectives of the system and supports the mission of the organization. Freely
distribute it to everyone involved with the project.

30. 30 Defining Requirements with Use Cases © Deloitte Inc.
Actors and Goals

31. 31 Defining Requirements with Use Cases © Deloitte Inc.
Module Objectives
•Upon successful completion of this module you will be able to:
–Identify Actors and describe their relationship to the Use Case Model
–Describe requirements using role based, goal-oriented language
–Describe goals in terms of both scope and levels
–Determine the different goal levels of a Use Case
–Identify higher and lower level Use Cases

32. 32 Defining Requirements with Use Cases © Deloitte Inc.
Actors
•An actor must have a behavior
–Ex: a person, a company or organization, or a computer program, hardware,
software, etc.
•Actors can be:
–Stakeholders of the system
–SuD
–Components of the system under design
–Supporting systems

33. 33 Defining Requirements with Use Cases © Deloitte Inc.
The Primary Actor
•Stakeholder participates in the contract that defines the system and has
vested interest in the behavior of the SuD
•Primary Actor is the stakeholder that interacts with the system to
achieve a specific goal
•Each use case is initiated by the primary actor of the Use Case
–Exceptions:
•Company clerk or phone operator can initiate the use case on behalf of primary actor
•Use case can be triggered by time

34. 34 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 1 (15 mins)
•List all the actors for the ACME University Degree Management System
(ADMS)

35. 35 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Actor List
•Student
•Senior Professor
•Professor
•Department Head
•ACME Online University Bookstore

36. 36 Defining Requirements with Use Cases © Deloitte Inc.
Actor-Goal List
1.List Actors and their goals
–Actor-Goal List: names all the user goals that the system supports
–Announces what the system will do, scope & purpose
–Becomes a communication device between the different stakeholders on the project
–Each goal will map directly to a specific use case
–Each goal (use case) should be named using an active verb phrase
–e.g. Purchase Book
–The first time use cases add a lot of value is when they are named as user
goals that the system will support

37. 37 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 2 (25 mins)
•Create the Actor-Goal list for the ACME University Degree Management
System (ADMS)

38. 38 Defining Requirements with Use Cases © Deloitte Inc.
Refreshment Break
•15 mins

39. 39 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Actor-Goal List
Schedule Courses
Create Course Details Professors
Review Degree and Course Overview Department Heads
Review Course Details
Assign Professor to Course
Create Course Overview for Specific Degree
Create Degree for specific departmentSenior Professors
Purchase Course Text Book
Enroll in CourseStudents
GoalActor

40. 40 Defining Requirements with Use Cases © Deloitte Inc.
When Primary Actors Are Important
•Important at the beginning of requirements gathering
–The primary actor list:
•Provides an overview
•Directs attention to the people who will use the system
•Sets up the structure for the actor-goal list
•Helps to partition a large set of use cases into packages
•Less important during detailed use case writing, analysis and design
–A particular use case can be used by many actors
–Primary actors tend to be broken down according to the roles they play
–Primary actors become increasingly generic
•Ex: Loss Taker, Order Taker, or Invoice Producer

41. 41 Defining Requirements with Use Cases © Deloitte Inc.
When Primary Actors Are Important cont’d…
•Solution 1:
–Break down the primary actors according to roles play.
–Create an actor-to-role table
–Disadvantage: Have to maintain separate list
•Solution 2:
–At the beginning of the use case section, write, “The Manager can do any use
case the Clerk can, plus more…”
–Disadvantage: People spend more time reminding each other that a Manager
can do anything a Clerk can

42. 42 Defining Requirements with Use Cases © Deloitte Inc.
Actor Profiles
•Designers need to know what skills actors have so they can design the
system behavior and the User Interface (UI) accordingly
•To gain a better view of how the software will suit the needs of actors,
create an Actor Profile Table

43. 43 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 3 (25 mins)
•Create an Actor Profile for the ACME University Degree Management
System (ADMS)

44. 44 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Actor Profile Table
Occasional user, casual computer experience
only. Impatient.
Department Head
Older user, however, typically has a lot of
experience with computers because of daily job
demands. May have difficulty with smaller fonts.
Senior Professor
Young, usually computer proficient, usually
considered a power user and has a fair amount of
experience using office applications as well as
browsing on the internet; can be impulsive and
impatient.
Student
Profile: Background and SkillsActor

45. 45 Defining Requirements with Use Cases © Deloitte Inc.
Supporting Actors
•Are external actors that provide a service to the SuD
–Ex: High-speed printer, web service, or human
•An actor could be a primary actor in one use case and a secondary
actor in another.

46. 46 Defining Requirements with Use Cases © Deloitte Inc.
Stakeholders’ Interests
•A stakeholder is someone who has a vested interest in the behavior of
the system
•Stakeholders’ Interests identify what to include and exclude in the use
case
•Use cases should capture ALL behavior that satisfy the stakeholders’
interests

47. 47 Defining Requirements with Use Cases © Deloitte Inc.
Stakeholders’ Interests cont’d
•Offstage Actors are stakeholders that are not present when the system
is running
–System must satisfy the interests of offstage actors
–Ex: Withdraw money from ATM
•system must keep log of all interactions to protect the stakeholders in case of dispute
•Stakeholder’s interests:
–List all stakeholder’s
–Name their interests with respect to the operation of the use case
–State the guarantees stakeholders want from the system
–Ex: Enroll in Course
•Stakeholder Interests:
–Student – wants to enroll in course
–Professor, Department Head – wants a fully enrolled course

48. 48 Defining Requirements with Use Cases © Deloitte Inc.
Goal Levels
•Use Case goals and interactions can be unfolded into finer and finer-
grained goals and interactions
•We witness this in everyday life:
–I want this sales contract. To do that I have to take this manager out to
lunch. To do that I have to get some cash. To do that I have to withdraw
money from this ATM. To do that I have to get it to accept my identity. To do
that I have to get it to read my ATM card. To do that I have to ding the card
slot.
–I want to find the tab key so I can get the cursor into the address field, so I
can put in my address, so I can get my personal information into this quote
software, so I can get a quote, so I can buy a car insurance policy, so I can
get my car licensed, so I can drive.

49. 49 Defining Requirements with Use Cases © Deloitte Inc.
Goal Levels
•Folding and unfolding goals might be normal for everyday life but it
causes confusion when writing a use case
•3 Goals levels:
–Summary Goals
–User Goals
–Subfunction Goals

50. 50 Defining Requirements with Use Cases © Deloitte Inc.
Graphical Scheme for Goal Levels
Increase Sales
Promote
Product
Order
Product
Invoice
Order
Set Up
Promotion
Reference
Promotion
Monitor
Promotion
Place
Promotion
Create
Invoice
Send
Invoice
Identify
Promotion
Register
User
Identify
Product
Identify
Customer
Summary Goals
(White)
User Goals
(Blue)
Subfunctions
(Indigo)
Persist
User
Details

51. 51 Defining Requirements with Use Cases © Deloitte Inc.
User Goals
•Describes user specific goals which satisfy the actor’s immediate
responsibilities
•Passes the one person, one sitting test (2-20 mins)
•Good Ex: “Register a new customer” and “ Buy a book”
– Registering 42 customers in a row has some significance to a sales agent
–A book purchase can be purchase in one sitting
•Neither “Complete an online auction purchase” nor “Log on” generally
counts as a user goal
–Online auctions take several days and so fail the single-sitting test
–Logging on 42 times in a row does not ususally satisfy the person’s job
responsibilities

52. 52 Defining Requirements with Use Cases © Deloitte Inc.
User Goal Example
Use Case Name: Create a Degree
Primary Actor: Senior Professor
Level: User
Scope: System (ADMS)
Main Scenario:
7.Senior Professor Logs On to the system.
8.Senior Professor adds a new degree.
9.Senior Professor enters degree attributes (name, description, department,
length, accredited).
Steps 4 and 5 can be repeated until the Senior Professor manages all the
courses he/she intended to add to the degree.
11.Senior Professor Creates a Course Overview for the Degree.
12.Senior Professor adds the course to the degree.
13.Senior Professor submits the degree/course overview to be approved by the
Departments Head.
14.System notifies Department Head of pending items.
15.Senior Professor Logs out.

53. 53 Defining Requirements with Use Cases © Deloitte Inc.
Summary Level
•Summary level goals involve multiple user goals
•Serve 3 purposes in describing the system
–Show the context in which the user goals operate
–Show life-cycle sequencing of related goals
–Provide a table of contents for the lower-level use cases
•They typically operate over hours, days, weeks, months, or even years
•2 levels of summary level goals
–Kites: steps are user goals
–Clouds: extremely high level “fluffy” goals; can be mapped to kites or other
clouds

54. 54 Defining Requirements with Use Cases © Deloitte Inc.
Summary Level Example (Kite)
Use Case Name: Manage Degrees
Primary Actor: ACME University
Level: Summary
Scope: System (ADMS)
Main Scenario:
7.Senior Professors Create A Degree.
8.Senior Professors Create Course Overviews for courses in the degree.
9.Department Head Reviews Degree and Course Overview.
10.Senior Professors Assign Professors to the Course.
11.Professors Create Course Details.
12.Senior Professors Review Course Details.
The following must take place before each semester.
7.Professors Schedule Courses.
8.Students Enroll in Courses.

55. 55 Defining Requirements with Use Cases © Deloitte Inc.
Summary Level Example (Cloud)
Use Case Name: Graduate with Degree
Primary Actor: Student
Level: Summary
Scope: Business (ACME University)
Main Scenario:
7.Student Applies to ACME University.
8.ACME University Accepts Student.
9.Student Accepts Offer.
Student must repeat steps 4-7 until he/she has completed all the
courses necessary to complete his degree.
11.Student Enrolls in Semester.
12.Student Takes Classes.
13.Etc.

56. 56 Defining Requirements with Use Cases © Deloitte Inc.
Subfunctions
•Required to carry out user goals
•Include to improve:
1.Readability
2.Maintenance
Ex:
•Find a product
•Find a customer
•Save as a file
•Subfunctional Use Cases should not be used to model internal system
behavior (Clam)
Ex:
•Cache Product Information
•Serialize Request Data
•Persist Account Data

57. 57 Defining Requirements with Use Cases © Deloitte Inc.
Finding the Right Goal Level
•Lower level use cases are descriptions of how higher level use case goals are
accomplished
•Higher level use cases are descriptions of why lower level use cases exist
•To find higher-level goals, ask:
–What does the primary actor really want?
–Why is this actor doing this?
•To find a lower level goal, ask:
–How is the use case’s goal accomplished?
Goal of Use Case
Goal of Steps
Why?
How
?
(White)
Goal of Use Case
Goal of Steps
(Indigo)
(Black)
(Blue = User Goal)Goal of Use Case
Goal of Steps
Why?
How
?
(White)
Goal of Use Case
Goal of Steps
(Indigo)
(Black)
(Blue = User Goal)

58. 58 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 4 (10 mins)
•Assign goal levels to the Actor-Goal List for the ACME University Degree
Management System (ADMS)

59. 59 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Assigning Goal Levels
SummaryManage DegreesACME University
UserSchedule Courses
UserCreate Course Details Professors
UserReview Degree and Course Overview Department Heads
UserReview Course Details
UserAssign Professor to Course
UserCreate Course Overview for Specific Degree
UserCreate Degree for specific departmentSenior Professors
UserPurchase Course Text Book
UserEnroll in CourseStudents
LevelGoalActor

60. 60 Defining Requirements with Use Cases © Deloitte Inc.
Scope of the System
•Design scope is the boundaries of the system
•Ex: ACME University is designing a Degree and Course Management
System which includes a Scheduling sub-system. The design scope is as
follows:
–Business (i.e. ACME University). Describes the behavior of the entire
organization or enterprise
–System (i.e. Degree Management System). Describes the behaviour of
software that is being built
–Subsystem (i.e. Scheduling system). Concerned with one piece of the main
system and how that piece works.

61. 61 Defining Requirements with Use Cases © Deloitte Inc.
Design Scope Examples
•Scenario:
–You are responsible for designing a new Degree Management System for ACME
University.
– proposed system will manage degrees and courses offered to students
–The system consists of PC’s connected to a web server
–The primary actors include: Students, Professors, Senior Professors, Department Heads,
and the ACME University Online Bookstore
•Goal:
–“Enroll in course”
•SuDs:
–ACME University
•What is the complete process for enrolling in a class?
•Scope = Business
–Degree Management System
•How does the service appear in the context of the system being created and how does
it interface with the ACME University Online Bookstore?
•Scope = System

62. 62 Defining Requirements with Use Cases © Deloitte Inc.
Finding Wider Scope Use Cases
•Helps add context to your system use cases
•Helps developers understand the business processes that interact with
the system
•How far you need to widen the scope depends on how much context
you need
•Can be the business, department, or system
•Writing a level or two of wider scope is recommended because it takes
very little time and provides excellent context for the use case set

63. 63 Defining Requirements with Use Cases © Deloitte Inc.
Wider Scope Use Case Example
•The Use Case at the design level
–“Enroll in Course”
–Actor: Student
–Scope: Course Management System (system)
–Level: User
–Main Success Scenario:
1.Student searches for courses (course name, course code, by department, by level, by availability).
2.System displays search results (course name, course code, department, level, availability).
3.Student selects a course to enroll in.
4.System displays course details.
5.Student confirms enrolment.
•Find the wider scope use case by asking why the Student is enrolling in the course
•Answer: To Enroll in Current Semester  Why?  To graduate with a degree
–Scope: ACME University (business)
–Level: Summary
–Main Success Scenario:
1.Student Applies to ACME University.
2.ACME University accepts Student.
3.Student accepts offer.
4.Student Enrolls in Semester.
5.etc.

64. 64 Defining Requirements with Use Cases © Deloitte Inc.
Key Points
•An Actor is any entity that exhibits behavior and interacts with the SuD
•Actors can be people, organizations, organizational departments, or
different software systems
•The Primary Actor of a use case is usually the actor who initiates the
use case
•Use cases may affect or interact with other actors, these actors are
known as supporting actors
•When use cases have more than one primary actor, group the actors by
specific roles
•All use cases should take into account system stakeholder interests
•The actor-goal list is created by defining the actors that interact with
the system, and the goals that they will need the system to support
–Each of these goals will map to one specific use case

65. 65 Defining Requirements with Use Cases © Deloitte Inc.
Key Points Cont’d
•Use Cases can be broken up into different levels:
–Summary
–user
–Subfunction
•Each use case has a specific scope.
–This scope depends on the SuD
–Ex: organization, department, all computer systems, current system
•Higher level use cases can be created by asking why the use case is
being performed. Lower level use cases can be created by asking how a
use case is able to perform its task
•Avoid using use cases to describe too much system detail, use cases
are NOT meant to illustrate system decomposition
–Example of a bad use case:
•Load product information
•Store product information
–These should be steps in use cases not use cases themselves

66. 66 Defining Requirements with Use Cases © Deloitte Inc.
Patterns

67. 67 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: ClearCastOfCharacters
•Problem:
–If we analyze only the users of the system, and ignore the roles they play
with respect to the system, then we can miss important system behavior or
introduce redundant behavior.
•Context:
–To be useful, a system must satisfy its users’ needs and protect the interest
of its stakeholders
–Tying services to users may make the system so rigid that services cannot be
reused
–Focusing on users may bog us down with implementation details, rather than
provide understanding of the services the user needs
–Many people find it easier to comprehend concrete concepts rather than
abstract ones
–Time pressure and expediency encourage us to analyze only the users
•Solution:
–Identify the actors the system must interact with and the role each plays with
respect to the system. Clearly describe each.

68. 68 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: CompleteSingleGoal
•Problem:
–Improper goals will leave the writers uncertain about where one use case
ends and another begins.
•Context:
•To build the correct system, we need to understand how an actor
achieves some accomplishment of value
•We want to control complexity by partitioning our use cases into pieces
that make sense to the stakeholders
–The duration of the actor goal may vary
–Excessively large use cases can busy the stakeholder in an avalanche of
details and obscure the purpose of the use case
–Large use cases can inhibit reuse
–Excessively small use cases will describe only fragments of some
accomplishment of value
•Solution:
–Write each use case to address one complete and well-defined goal. That goal
may be at any level in the EverUnfoldingStory.

69. 69 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: EverUnfoldingStory
•Problem:
–The number of steps needed to describe the behavior of the system exceeds
both the memory and the interest of the various types of readers.
•Context:
–Each use case can have many readers and many uses, all requiring different
levels of detail
–Use cases need to show how every function contributes value to the business
–It is, however, confusing to write at multiple levels
–Writers need a principle to follow for organizing the requirements
•Solution:
–Organize the use case set as a hierarchical story that can be either unfolded
to get more detail or folded up to hide detail and show more context

70. 70 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: VerbPhraseName
•Problem:
–Meaningless, generic names will not set reader expectations or provide a
convenient reference point
•Context:
–The name sets the tone and association for the audience
–The name provides a focal point for the writer
–Appropriate use case names allow you to see the big picture and work on the
whole set
•Solution:
–Name the use case with an active verb phrase that represents the goal of the
primary actor

71. 71 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: CommonSubBehavior
•Problem:
–Writing the same steps for different use cases is wasteful and makes it more
difficult to see common sub-processes within a use case model.
•Context:
–Rewriting common steps is redundant and increases the risk of
inconsistencies or inaccuracies in the model
–Partitioning individual use cases tend to scatter important behavior and
makes them harder to understand
–Misunderstanding the includes relationship leads to its misuse
•Solution:
–Express shared courses of action with lower-level included use cases.

72. 72 Defining Requirements with Use Cases © Deloitte Inc.
Refreshment Break
•1 hour

73. 73 Defining Requirements with Use Cases © Deloitte Inc.
Preconditions Triggers and
Guarantees

74. 74 Defining Requirements with Use Cases © Deloitte Inc.
Objectives
•Upon successful completion of this module you will be able to:
–Describe the necessary starting conditions for a use case
–Describe how the use case will protect the interest of all system stake holders

75. 75 Defining Requirements with Use Cases © Deloitte Inc.
Preconditions and Triggers
•Preconditions
–State what must be true before the use case may start
•Ex: User has already logged in and has been validated
•Triggers
–Specifies the event that starts the use case
–Can precede the first step of the use case scenario
–Can be the first step in the use case scenario
–Develop your own personal or project style

76. 76 Defining Requirements with Use Cases © Deloitte Inc.
Guarantees
•Minimal Guarantees
–Are the fewest promises the system makes to the stakeholders
–Are of real interest when the main goal is abandoned
–Two or more stakeholders should be addressed in the minimal guarantees
•Stakeholder ex: User, Company providing system, Government regulatory body
–Most common: “The system logged how far it got”
•Success Guarantees
–State what interests of the stakeholders are satisfied after a successful
conclusion of the use case
•Example: The file will be saved

77. 77 Defining Requirements with Use Cases © Deloitte Inc.
Preconditions Triggers and Guarantees
Examples
•Precondition:
–Place an Order  Clerk is logged on to the system
•Trigger:
–Use ATM  Customer inserts card
•Success Guarantee:
–Purchase book  the system will initiate an order for the customer, will have
received payment information and logged the request for the order
•Minimal Guarantee:
–Place Order  Order will be initiated only if payment is received

78. 78 Defining Requirements with Use Cases © Deloitte Inc.
Key Points
•Only include these sections if they add value

79. 79 Defining Requirements with Use Cases © Deloitte Inc.
Scenarios

80. 80 Defining Requirements with Use Cases © Deloitte Inc.
Objectives
•Upon completion of this module, you will be able to:
–Describe system functional behavior in detail using scenarios
–Describe main scenarios using best practices and patterns
–Recognize and avoid common errors that occur when writing Use Cases

81. 81 Defining Requirements with Use Cases © Deloitte Inc.
Scenarios
•A set of use cases is an ever-unfolding story of primary actors pursuing
goals
•Each use case has a crisscrossing story line that shows the system
delivering the goal or abandoning it
•This story line is presented as a main scenario and extensions, a set of
scenario fragments
•Each scenario or extension starts from a triggering condition that
indicates when it begins
•Each scenario or extension will run until it shows completion or
abandonment of its goal

82. 82 Defining Requirements with Use Cases © Deloitte Inc.
The Use Case Briefs
2.Writing use case briefs
–Before writing the main scenario for each use case, it is useful to write use
case briefs for the complete use case set
–Two-to-six sentence description of use case behavior
– Mention only the most significant activity and failures
–Extremely valuable in communicating system functionality to various
stakeholders
–Useful for estimating work complexity
Once students have registered in the
system, they may enroll in any course
for which they have the prerequisites.
Classes they enroll in must be part of
their degree.
Enroll in Course Student
BriefGoalActor

83. 83 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 5 (45 mins)
•Create briefs for all user goals in the ACME University Degree
Management System (ADMS)

84. 84 Defining Requirements with Use Cases © Deloitte Inc.
Solutions: Use Case Briefs
Senior Professors will review all changes made
to course details by Professors.
UserReview Course Details
Senior Professors will assign professors
responsible for teaching the course.
UserAssign Professor to Course
Senior Professors are responsible for creating
high level syllabi to courses. They also need to
specify number of credits, as well as any
prerequisites or co-requisites for the course.
These details will need to be submitted to the
department head for review.
UserCreate Course Overview for Specific
Degree
Senior Professors can create degrees for their
departments. Professors will enter degree
descriptions, prerequisites and completion
requirements, and then submit to the
department head for review.
UserCreate Degree for specific
department
Senior
Professors
While enrolling in a class students may
purchase books relating to the course. The
system will delegate purchasing functionality
to the ACME University Online Bookstore.
UserPurchase Course Text Book
Once students have registered in the system,
they may enroll in any course for which they
have the prerequisites. Classes they enroll in
must be part of their degree.
UserEnroll in CourseStudents
BriefsLevelGoalActor

85. 85 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Use Case Briefs (cont’d)
BriefsLevelGoalActor
ACME University manages a curriculum of
degrees and courses. This process involves
creating degree overviews, creating course
overviews for these degrees, reviewing degree
changes, assigning professors to the courses,
creating detailed course content, reviewing
course content, scheduling classes, and
enrolling in classes.
SummaryManage DegreesACME University
Before each semester the assigned Professor
needs to schedule a course choosing time and
classroom.
UserSchedule Courses
Professors are responsible for creating detailed
course syllabi and course notes. They can
optionally specify the supporting text book.
These details will need to be submitted for
review by Senior Professors.
UserCreate Course Details Professors
Department heads will review degree and
course overview changes made by Senior
Professors.
UserReview Degree and Course Overview Department
Heads

86. 86 Defining Requirements with Use Cases © Deloitte Inc.
The Main Success Scenario
3.Write the main success scenario for each use case
–The main success scenario
•easy-to-understand
•fairly typical
•primary actor's goal is delivered
•all stakeholders' interests are satisfied
–Most well written main scenarios have 3-8 steps
•If you have more than 10 steps you are probably describing the use case at too low a
level
–Remove user interface details
–Raise goal level by asking the “why” question
–Merge steps
–Each use case has one main scenario

87. 87 Defining Requirements with Use Cases © Deloitte Inc.
The Main Scenario (cont’d)
–Extensions - all other success scenarios as well as the handling of all failures
–Main scenario sits within a Use Case that contains:
•A condition under which the scenario runs
•A goal to achieve
•A set of action steps
•An end condition
•A possible set of extensions written as scenario fragments

88. 88 Defining Requirements with Use Cases © Deloitte Inc.
Scenario Step Guidelines
•Use simple grammar
–Subject…verb…direct object… prepositional phrase
–Ex: The customer browses a list of available books
•Keep the steps of the use case at an even level of detail
–Mixing different levels of details is distracting and makes it very difficult to
follow
•Write from a bird’s eye view
–Avoid writing use cases from the eyes of the system looking out at the world
•Don’t: Get ATM card and PIN number
•Do: Customer enters ATM card and PIN number
•“Validate” don’t “Check whether”
–“Checks” is not a good action verb, use “establish”, “ validate”, or “ ensure”

89. 89 Defining Requirements with Use Cases © Deloitte Inc.
Scenario Step Guidelines (cont’d)
•Show the process moving forward
–Amount of progress is related to how high or low the use case goal is
•Write each step to show clearly which actor is performing the action and what
gets accomplished
•Show the actor’s intent not the movements
–Avoid interface detail description
•Include reasonable set of actions
–Use simple actions in which one actor accomplishes a task or passes information to
another actor
•Optionally mention timing
–“At any time between steps 3-5 the customer may perform the following actions…”
–“Do steps x-y until condition”

90. 90 Defining Requirements with Use Cases © Deloitte Inc.
Scenario Steps Example
Use Case Name: Create a Degree
1.Senior Professor Logs On to the system.
2.Senior Professor adds a new degree.
3.Senior Professor enters degree attributes (name, description, department,
length, accredited).
4.System Validates degree attributes.
Steps 5 and 6 can be repeated until the Senior Professor manages all the
courses he/she intended to add to the degree.
6.Senior Professor Creates a Course Overview for the Degree.
7.Senior Professor adds the course to the degree.
8.Senior Professor submits the degree/course overview to be approved by the
Department Head.
9.System notifies Department Head of pending items.
10.Senior Professor Logs out.

91. 91 Defining Requirements with Use Cases © Deloitte Inc.
Refreshment Break
•15 mins

92. 92 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 6
•Create Main Scenarios for the ACME University Degree Management
System (ADMS)

93. 93 Defining Requirements with Use Cases © Deloitte Inc.
End of Day 1
•Be prepared to finish the Class Task in the morning!

94. 94 Defining Requirements with Use Cases © Deloitte Inc.
Beginning of Day 2
•Please complete the class task from yesterday afternoon!

95. 95 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Main Scenarios
•Distribute Handout

96. 96 Defining Requirements with Use Cases © Deloitte Inc.
Key Points
•A use case collects one or more scenarios that define how the primary
actor attempts to achieve a specific goal
•The main scenario is the most common flow of events which result in
the primary actor achieving its goal
•Extensions are used to describe less common scenarios and failures
•Scenarios consist of even leveled steps that describe an actor
performing an action that brings the primary actor closer to achieving a
specific goal
•Scenarios should be free of interface detail and most other technological
considerations

97. 97 Defining Requirements with Use Cases © Deloitte Inc.
Patterns

98. 98 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: PreciseAndReadable
•Problem:
–Use cases that are too complicated for non-technical readers, or too imprecise
for developers, are deficient and likely to result in poorly built, inadequate
systems.
•Context:
–A use case should be readable by both the stakeholders and the developers
–Developers tend to add detail and solutions
–Non-technical stakeholders are likely to miss necessary considerations
–We want to encourage a dialogue between the stakeholders and the
developers to ensure the accuracy of the requirements
–Dual models are unacceptable because they can become disjointed and are
difficult to maintain
•Solution:
–Write use cases to be readable enough so that the stakeholders bother to
read and evaluate it, and precise enough so that the developers understand
what they are building.

99. 99 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: LeveledSteps
•Problem:
–Excessively large or excessively small use case steps obscure the goal and
make the use case difficult to read and comprehend.
•Context:
–Excessively small steps make a use case long and hard to read, and they
obscure the "why"
–Excessively large steps may bury important behavior
–Mixing levels of detail in a scenario is distracting
•Solution:
–Keep scenarios to three to nine steps. Ideally, the steps are all at similar
levels, and at a level of abstraction just below the use case goal.

100. 100 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: ActorIntentAccomplished
•Problem:
–Both readers and developers get confused about a system's behavior if it is
not clear which actor has responsibility for performing a step, and what the
actor is trying to accomplish in that step.
•Context:
–Writing quality use cases is hard work. It takes a lot of mental energy to
create good prose
–The developer needs to know clearly what they are to implement, at what
moments the system should wait for input, and when the system should take
initiative
•Solution:
–Write each step to show clearly which actors perform the action and what the
actor gets accomplished.

101. 101 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: ForwardProgress
•Problem:
–Writers have to decide how much behavior to put into any one step. They can
easily write too much detail, making the use case long and tiring to read.
•Context:
–Clear, succinct steps lower the mental cost of understanding and evaluating a
use case.
–A desire for completeness and detail may lead to the inclusion of steps that
are tangential to the goal of the use case.
•Solution:
–Eliminate or merge steps that do not advance the actor. Simplify passages
that distract the reader from this progress.

102. 102 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: TechnologyNeutral
•Problem:
–Including technology constraints and implementation details in a use case
description increases the complexity and obscures the goal of the use case.
•Context:
–Many people like to think in concrete terms
–Technology is volatile; including details of a specific technologies will cause
rework
–Technological details impose improper constraints on future activities
–Adding technological details increases the cost of both reading and writing
use cases
–Sometimes technology is a requirement
•Solution:
–Write each use case in a technology neutral manner.

103. 103 Defining Requirements with Use Cases © Deloitte Inc.
Refreshment Break
•15 mins

104. 104 Defining Requirements with Use Cases © Deloitte Inc.
Extensions

105. 105 Defining Requirements with Use Cases © Deloitte Inc.
Module Objectives
•Upon successful completion of this module you will be able to:
–Define Alternate Scenarios and Exceptions
–Distinguish how Alternate Scenarios and Exceptions differ from Main
Scenarios
–Use Alternate Scenarios and Exceptions to capture behavior that differs from
the Main Success Scenario
–Brainstorm all possible Alternate Scenarios and Exceptions that can exist for a
Use Case

106. 106 Defining Requirements with Use Cases © Deloitte Inc.
Extensions
•Extensions consist of alternate scenarios and exceptions
–used to capture any steps that are considered a deviation from the main
success scenario
•Alternate Scenarios have goals and contain steps that are so similar to
the main scenario that they are not given their own use case
–Use Case: Review Degree Changes
•Main Scenario:  capture the steps for approving a new degree
•Alternate Scenarios  capture the steps for rejecting a new degree
•Exceptions are used to handle error situations or non-standard behavior

–Use Case: Purchase Course Textbook
–Exceptions  Invalid Payment, book out of stock, system down
•Extensions contain the most interesting system requirements

107. 107 Defining Requirements with Use Cases © Deloitte Inc.
Writing Extension: Options
Option 1: Write out all steps
•Maintenance nightmare
•Each change to a scenario has to be copied to all other scenarios that contain the same
text
–Ex:
•Use Case Scenario 1: Approve Degree and Course Overview
1.Department Head Logs On to the system.
2.Department Head browses all pending courses/degrees.
3.Department Head selects a pending course/degree to review.
4.Department Head approves courses/degrees.
5.System notifies Senior Professors of status.
6.Professor Logs out.
•Use Case Scenario 2: Reject Degree and Course Overview
1.Department Head Logs On to the system.
2.Department Head browses all pending courses/degrees.
3.Department Head selects a pending course/degree to review.
4.Department Head rejects courses/degrees.
5.System notifies Senior Professors of status.
6.Professor Logs out.
•etc.

108. 108 Defining Requirements with Use Cases © Deloitte Inc.
Writing Extension: Options (cont’d)
Option 2: Write if statements throughout the text
•Hard to understand when extended nesting happens
–Ex:
•Use Case Name: Create Course Detail
1.Professor Logs On to the system.
2.If the professor has saved course details that have not been submitted,
2.1 Professor browses un-submitted courses
4.Else,
3.1 Professor browses courses that are assigned to him/her and selects a course.
4.If course syllabus is not finished,
4.1 Professor enters detailed course syllabus.
5.If course notes are not finished
5.1 Professor attempts to upload course notes.
5.2 If Professor was unable to upload course notes
5.2.1 If the problem was file format,
5.2.1.1 System displays list of valid file formats.
5.2.1.2 Go to step 5.1.
5.2.2 Else, If the problem was file upload error,
5.2.2.1 System displays error.
5.2.2.2 Go to step 5.1.
17.If textbook has not been assigned to the course,
6.1 Professor Assigns Textbook to the Course.
19.If the Professor has finished entering course details,
7.1 Professor submits the course details.
8.Else,
8.1 Professor saves course details without submitting.
9.If course details were submitted
9.1 System attempts notifies Senior Professor of the course detail submission.
9.2 If the system was not able to notify Senior Professor
9.2.1 System keeps trying until it is successful
10.Professor Logs out.

109. 109 Defining Requirements with Use Cases © Deloitte Inc.
Writing Extension: Options (cont’d)
Option 3: Write…
•A main success scenario as a simple sequence running from start to
completion
•A scenario extension for each branch point

110. 110 Defining Requirements with Use Cases © Deloitte Inc.
Extension Basics: Alternate Scenarios
•Alternate Scenarios have goals and contain steps that are so similar to
the main scenario that they are not given their own use case
•In each Use Case, create a section called alternate scenarios
•List the name of the alternate scenario using the same goal-oriented
naming convention as use cases
–Ex: Reject Degree and Course Overview

111. 111 Defining Requirements with Use Cases © Deloitte Inc.
Extension Basics: Alternate Scenarios (cont’d)
•List and describe all steps that differ from the main
–Use Case Name: Review Degree and Course Overview
•Main Scenario:
1.Department Head Logs On to the system.
2.Department Head browses all pending courses/degrees.
3.Department Head selects a pending course/degree to review.
4.Department Head approves courses/degrees.
5.System notifies Senior Professors of status.
6.Professor Logs out.
•Alternate Scenarios
–AS1: Reject Degree and Course Overview
4.Department head rejects course.
4a. Department head enters rejection reason.
•Nested alternate scenarios
–Avoid unless absolutely necessary
–Creates highly unreadable use cases

112. 112 Defining Requirements with Use Cases © Deloitte Inc.
CRUD
•CRUD: operations on a database
–Create a Frizzle
–Retrieve a Frizzle
–Update a Frizzle
–Delete a Frizzle
•Are the CRUD operations part of a larger Use Case, Manage Frizzles, or
are they separate?
–No Consensus available
•In principle, they are separate because each is a separate goal
•This causes clutter and triples number of Use Case to track
•Use Case Name: Manage Course Overview

113. 113 Defining Requirements with Use Cases © Deloitte Inc.
CRUD (cont’d)
•Main Scenario:
1.Senior Professor Logs On to the system.
2.Senior Professor creates a new course.
3.Senior Professor enters course overview attributes (name, description, number of credits, high level
syllabus).
4.Senior Professor submits the course overview.
5.System notifies Department Head of pending item.
6.Senior Professor Logs out.
•Alternate Scenarios
–AS1: Modify Existing Course Overview
1.Senior Professor browses and selects existing course.
2.Go to MS step 3.
–AS2: Retire Course
1.Senior Professor browses and selects existing course.
2.Senior Professor nominates course to be retired.
3.System notifies all department heads who have degrees that would be affected by course retirement.
4.Go to MS step 6.

114. 114 Defining Requirements with Use Cases © Deloitte Inc.
Extension Basics: Exceptions
•Handle situations where the system or a secondary actor is forced to
respond in a non standard way
–Usually caused by a system or business error
•Contains a sequence of action steps describing what happens under a
particular condition
•Ends with delivery or abandonment of the use case goal

115. 115 Defining Requirements with Use Cases © Deloitte Inc.
Extension Basics: Exceptions (cont’d)
•Applies to steps in main and alternate scenarios
•Below the main success scenario, for every point where the behavior
can branch because of a particular condition:
–Write down the condition
–Write down the alternate or the main scenario step(s) that the condition can
apply to
–Write down the steps that can handle the condition

116. 116 Defining Requirements with Use Cases © Deloitte Inc.
Exceptions Example
Use Case Name: Create Course Detail
•Main Scenario
1.Professor Logs On to the system.
2.Professor browses courses that are assigned to
him/her and selects a course.
3.Professor enters detailed course syllabus.
4.Professor uploads course notes.
5.Professor Assigns Textbook to the Course.
6.Professor submits the course details.
7.System notifies Senior Professor of the course detail
submission.
8.Professor Logs out.
•Alternate Scenarios
•AS1: Save Course Details for Future Submission
–Optionally do any of the steps 3-5 from MS.
1.Save course details.
2.Go to MS step 8.
•AS2: Submit Previously Saved Course Details
1.Professor browses un-submitted courses.
–Optionally do any of the steps 3-5 from MS.
3.Go to MS step 6.
Exceptions
•EX1: System Down (Applies to all steps)
a)Display error message to user
b)Use case ends
•EX2: Unable to Upload Files (Applies to MS step 4)
1.System displays message showing error.
2.Go to MS step 4.
•EX3: Invalid File Format (Applies to MS step 4)
1.System displays list of invalid file formats (.exe .bat
.vbs).
2.Go to MS step 4.
•EX4: Unable to Notify Senior Professor (Applies to MS step
7)
1.System continues to attempt to notify department
head until it is able to.
2.Go to MS step 8.

117. 117 Defining Requirements with Use Cases © Deloitte Inc.
Brainstorming All Conceivable Failures and Alternative
Courses
4.List alternate and failure scenarios
–Consider the following:
•An alternative success path
–Ex: Clerk uses a shortcut code
•The primary actor behaving incorrectly
–Ex: Invalid password
•Inaction by the primary actor
–Ex: Time-out waiting for password
•Every occurrence of the phrase “the system validates.” implies that there will be
an extension to handle validation failure
–Ex: Invalid account number

118. 118 Defining Requirements with Use Cases © Deloitte Inc.
Brainstorming All Conceivable Failures and Alternative
Courses (cont’d)
–Inappropriate or lack of response from a supporting actor
•Ex: Time-out waiting for response
–Internal business failure within the SuD that must be detected
•Ex: Credit card not valid
–Unexpected and abnormal internal failure, which will have an externally
visible consequence
•Ex: Corrupt transaction log discovered
–Critical performance failures of the system that you must detect
•Ex: Response not calculated within 5 seconds

119. 119 Defining Requirements with Use Cases © Deloitte Inc.
Value of Documenting Exceptions
•The first time Use Cases add a lot of value is when they are named as user
goals that the system will support
•The second time when Use Cases add a lot of value is when Use Case writers
brainstorm all the things that could go wrong in a successful scenario
•Use Case writers will likely discover new requirements not thought of before by
business domain experts
•Without failure brainstorming, many error conditions go undetected until coding
•Failure handling
–Often uses business rules that the developers do not know
–Requirements writers frequently have to research the correct system response
–Leads to creation of new actors, use cases or extensions

120. 120 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 7 (1 hour)
•Create Extension List for the ACME University Degree Management
System (ADMS)

121. 121 Defining Requirements with Use Cases © Deloitte Inc.
Refreshment Break
•1 hour

122. 122 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Extension Listing
•Distribute handouts

123. 123 Defining Requirements with Use Cases © Deloitte Inc.
Extension Writing Guidelines
5.Describe alternate and failure scenario steps
–Put an asterisk (*) instead of the step number if the replacement can
occur at any time
–Number the error condition to match either the step where the user enters
data or the following step
–Write down what the system detected, NOT what happened
•Ex: PIN time-out instead of customer forgets PIN

124. 124 Defining Requirements with Use Cases © Deloitte Inc.
Extension Writing Guidelines (cont’d)
•Merge equivalent conditions
•Sometimes it is better to make a new use case (Extension Use Case)
out of an Alternate Scenario
–Used by more than one use case
–Interrupts the Main Scenario in several non-adjacent places

125. 125 Defining Requirements with Use Cases © Deloitte Inc.
Refreshment Break
•15 mins

126. 126 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 8 (2 hours)
•Create Extension Descriptions for the ACME University Degree
Management System (ADMS)

127. 127 Defining Requirements with Use Cases © Deloitte Inc.
End of Day 2
•Be prepared to finish creating extension descriptions…

128. 128 Defining Requirements with Use Cases © Deloitte Inc.
Beginning of Day 3
•Continue writing details of your Use Case Extensions

129. 129 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Extension Description Writing
•Distribute handouts

130. 130 Defining Requirements with Use Cases © Deloitte Inc.
Refreshment Break
•15 mins

131. 131 Defining Requirements with Use Cases © Deloitte Inc.
Key Points
•Recommended method to create an extension is to write a main
success scenario as a simple sequence running from start to
completion, then writing a scenario extension for each branch point
•Extensions may be classified as either Alternate Scenarios or Exceptions
•Alternate Scenarios are not given their own use case because they have
goals and contains steps that are so similar to the main scenario

132. 132 Defining Requirements with Use Cases © Deloitte Inc.
Key Points (cont’d)
•Exceptions are used to handle situations where the system or a
secondary actor is forced to respond in a non standard way
–Usually caused by a system or business related error
•In order to manage your energy effectively, list exceptions and
alternate scenarios for each use case BEFORE describing them
•Listing all exceptions is extremely valuable
–Uncovers unforeseen requirements
–Limits assumptions made by developers while programming

133. 133 Defining Requirements with Use Cases © Deloitte Inc.
Patterns

134. 134 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: ScenarioPlusFragments
•Problem:
–Readers must be able to follow the path easily through the specific scenario
or story that they are interested in; otherwise, they are likely to become
frustrated or miss important information.
•Context:
–An interesting use case needs to capture alternatives to the main success
scenario
–Writing every alternative as a complete story will obscure the differences
between story variations
–Separating out every variant also makes the writer’s life difficult
–A large number of if statements will clutter the story
–People cope well with incremental complexity
–The main success scenarios needs to be clearly identified
•Solution:
–Write the success story line as a simple scenario without any consideration
for the possible failures. Below it, place story fragments that show what
alternatives may occur

135. 135 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: ExhaustiveAlternatives
•Problem:
–A use case may have many alternatives. Missing some alternatives means the
developers will misunderstand the system's behavior, and the system will be
deficient.
•Context:
–Developers need to know how to handle errors
–Schedule pressure limits the time developers can spend identifying variations
–Some of the variation-handling policies need significant investigation
–Having information about the variations helps developers build a robust
design
•Solution:
–Capture all the alternatives and failures that must be handled in the use case

136. 136 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: DetectableConditions
•Problem:
–Writers always wrestle with how many and which conditions to include.
•Context:
–A system cannot handle events that it cannot detect
–The developers need to know what conditions to detect
–Fear of overlooking an important alternative encourages developers to specify
irrelevant conditions that cannot be detected by the system
–Many apparently different conditions can lead to writing unnecessary
alternatives
•Solution:
–Include only detectable conditions. Merge conditions that have the same net
effect on the system.

137. 137 Defining Requirements with Use Cases © Deloitte Inc.
Extension Use Cases

138. 138 Defining Requirements with Use Cases © Deloitte Inc.
Module Objectives
•After successful completion of this module you will be able to:
–Understand what Extension Use Cases are and when to use them
–Write Extension Use Cases

139. 139 Defining Requirements with Use Cases © Deloitte Inc.
Extension Use Cases
•Consider the following example:
–You are designing a new word processing program called Wapp
–The user's main activity is typing
–She might decide to a number of things not directly connected to typing
•change the zoom factor or the font size
•run the spell checker
•etc
–The typing activity should remain ignorant of anything else that might happen
to the document
–Different software development teams want to come up with new ideas for
services without:
•Updating the base use case for each new service
•Modifying the original requirements document

140. 140 Defining Requirements with Use Cases © Deloitte Inc.
Extension Use Cases (cont’d)
•The characteristics of such a situation are:
–There is a main activity, which can be interrupted in a number of ways
–The main activity is not in control of the interruptions

141. 141 Defining Requirements with Use Cases © Deloitte Inc.
Extension Use Cases (cont’d)
•Same mechanism as described for
creating alternate scenario extensions
•Place the scenario steps into an
extension use case
•References steps in the main use case
Enroll in Course
Purchase Course
Textbook
Download Course
Notes
View Time-Table
<<Extends>>
<<Extends>>
<<Extends>>
View Course
Details
<<Extends>>
<<Extends>>
<<Extends>>

142. 142 Defining Requirements with Use Cases © Deloitte Inc.
Extension Use Cases (cont’d)
Use Case Name: Enroll in Course
1.Student Logs On to the system.
Steps 2 to 5 can be repeated until the student has reached
maximum course load for the term.
3.Student searches for courses (course name, course code,
by department, by level, by availability).
4.System displays search results (course name, course code,
department, level, availability).
5.Student selects a course to enroll in.
6.Student confirms enrolment.
7.System displays course overview, syllabus and time-table.
8.Student browses course syllabus.
9.System displays time-table.
10.Student Logs out.
Use Case Name: View Enrolled Course Details
1.Student Logs On to the system.
2.Student Browses enrolled courses and selects a course.
3.System displays course details.
4.Student Logs Out.
Use Case Name: Purchase Course Textbook
•Trigger: Any time after student is enrolled in a course (after
step 6 in Enroll in Course, or after step 3 in View Enrolled
Course Details)
1.System requests and displays payment options from
ACME University Online Bookstore.
2.Student chooses payment option.
3.Student enters shipping and payment details (Credit
card number, DOB, etc.).
4.System verifies payment confirmation using ACME
University Online Bookstore.
5.System displays purchase details to student.
Use Case Name: View Time-Table
•Trigger: Any time after student is enrolled in a course (after
step 6 in Enroll in Course, or after step 3 in View Enrolled
Course Details)
1.Student requests time-table
2.System displays time-table
Use Case Name: Download Course Notes
•Trigger: Any time after student is enrolled in a course (after
step 6 in Enroll in Course, or after step 3 in View Enrolled
Course Details)
1.Student downloads course notes

143. 143 Defining Requirements with Use Cases © Deloitte Inc.
Extension Use Cases: When to Use Them
•The alternate scenario or exception interrupts more than one use case
–Place the extension behavior into its own use case
–Reduces redundancy in the use case set
•There are many asynchronous or interrupting services
–Should not disturb the base use case
–Developed by different teams
•The alternate scenario interrupts the main scenario in non adjacent
places
–Make use case difficult to read
–Place alternate scenario into its own use case.

144. 144 Defining Requirements with Use Cases © Deloitte Inc.
Extension Use Cases: When to Use Them (cont’d)
•Locked requirements documents
–An iterative process and multiple drops
–Baselined requirements for one drop
–Need to extend a baselined use case with new or additional functionality
–Do not touch the baselined use case
–Place new functionality into a new extension use case
•Warning: Non-locked requirements documents cause extension use
cases to be fragile
–Changing the base use case can damage the starting condition mentioned in
the extending use case
•Create extension use cases ONLY when you need to (they are harder for
people to understand and maintain)

145. 145 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 9 (45 mins)
•Identify and Create an Extension Use Case where appropriate in the
ACME University Degree Management System (ADMS)

146. 146 Defining Requirements with Use Cases © Deloitte Inc.
Refreshment Break
•1 hour

147. 147 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Extension Use Case
•Class handout

148. 148 Defining Requirements with Use Cases © Deloitte Inc.
Key Points
•Very similar to alternate scenarios
•The main difference between the two is that Extension Use Cases are
housed in separate use cases
•Should be used when there is a main activity that can be interrupted in
a number of ways
•Ideal for situations where you want to preserve the base use case
•Can cause confusion among business users and should only be used if
absolutely necessary
•Feel free to abandon them if they are reducing readability

149. 149 Defining Requirements with Use Cases © Deloitte Inc.
Patterns

150. 150 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: InterruptsAsExtensions
•Problem:
–An alternative that affects more than one step in a scenario can scatter
related details throughout a use case, causing the reader to become confused
or lose track of important information.
•Context:
–Multiple diversions or alternatives that interrupt several steps in the scenario
can cause the readers to lose track of the path they are trying to follow, and
can indicate problems with the basic scenario itself
–Creating extension use cases tend to scatter important behavior and makes
them harder to understand
–Misunderstanding the extends relationship leads to its misuse
•Solution:
–Create an extension use case when an alternative course of action interrupts
a number of steps in a scenario

151. 151 Defining Requirements with Use Cases © Deloitte Inc.
Parameterized Use Cases

152. 152 Defining Requirements with Use Cases © Deloitte Inc.
Module Objectives
•After successful completion of this module you will be able to:
–Understand what Parameterized Use Cases are
–Recognize when to use them
–Write Parameterized Use Cases

153. 153 Defining Requirements with Use Cases © Deloitte Inc.
Parameterized Use Cases
•Useful for writing similar use cases
•Most common is Find a “Whatever”
–What stays constant is the logic
•User specifies the thing to be found
•System searches, brings up the list of possible matches
•User selects, perhaps resorts the list, perhaps changes search
•System finds the thing (or doesn’t)
–What changes is the data
•The name of the thing to be found
•The searchable qualities (search fields) of the thing to be found
•What to display about the thing to be found (display values, sequence)
•How to sort the results (the sort criteria)

154. 154 Defining Requirements with Use Cases © Deloitte Inc.
Parameterized Use Cases (cont’d)
•Solution: create parameterized use cases
–Have nickname for each item that changes
–Define three levels of precision for the data values
•Data Nickname –only level that shows up in the use case (e.g. Customer Profile)
•Field Lists –names the information collected under Data Nickname (e.g. Name,
Address, Day Phone, etc)
•Precise Field Definition (Field lengths, validation criteria, etc.)

155. 155 Defining Requirements with Use Cases © Deloitte Inc.
Parameterized Use Cases: Search for “Whatever” Use
Case
•Example: Purchase Book
1.Purchaser Logs into site
2.Purchaser Searches for Book
3.Purchaser selects book
4.Etc…
•Search for book is hyperlinked to the Find A Whatever use case
1.The user identifies the searchable qualities of the whatever
2.The system finds all matching whatevers and displays their display values in a list
3.The user can resort them according to the sort criteria.
4.The user selects the one of interest
Book Title, AuthorBook Title, Publisher,
ISBN, Author
Book Title, ISBN,
Category
Search for Book
Location, ScheduleMovie Title, Director,
Location, Schedule, Stars
Movie Title, Location,
Schedule
Search for Movie
Last Name, First Name,
Address Street
Full Name, Tel Number,
Address, Age
SIN Number, Last Name,
Tel Number
Search for Customer
Sort CriteriaDisplay ValuesSearchable QualitiesUse Case Name

156. 156 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 10 (30 mins)
•Identify any “almost” identical Use Cases or Use Case steps and
describe them using Parameterized Use Cases

157. 157 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Parameterized Use Cases
•Class handout

158. 158 Defining Requirements with Use Cases © Deloitte Inc.
Key Points
•Use Parameterized use cases to avoid continually writing details to
almost identical use cases
•Parameterized use cases can easily be abused
•Should only be used when steps between use cases are identical but
the data differs

159. 159 Defining Requirements with Use Cases © Deloitte Inc.
Refreshment Break
•15 mins

160. 160 Defining Requirements with Use Cases © Deloitte Inc.
Other Requirements

161. 161 Defining Requirements with Use Cases © Deloitte Inc.
Module Objectives
•Upon successful completion of this module you will be able to:
–Identify other types of requirements that must be captured in order to
completely define system needs
–Capture types of non-behavioral requirements

162. 162 Defining Requirements with Use Cases © Deloitte Inc.
Other Requirements
•Behavioral requirements are not the
only kinds of requirements used to
define a system
•Other requirements include:
–Business Rules
–Data Structures
–User Interface
–Priority and Delivery Date
–Supplementary Requirements
(Performance, Scalability, etc.)
–Exact list varies from project to project
Use Cases
B
u
si
ness
Rul
es
Per
f
or
man
ce
Req
u
ir
e
me
n
t
s
I/O Protocols UI Design
UI
Requi
r ement
s
Data F
or
mat
s

163. 163 Defining Requirements with Use Cases © Deloitte Inc.
Other Requirements (cont’d)
•It is very common to discover and collect these other requirements
while writing use cases
•Including these non-behavioral requirements directly into the use case
will
–Make the Use Case harder to comprehend
–Force the reader to address issues do not understand
•A simple spreadsheet or table can be used to capture this information

164. 164 Defining Requirements with Use Cases © Deloitte Inc.
Data Requirements
•Data requirements can be divided into three levels of precision
1.Information Nickname
2.Field Lists or Data Descriptions
3.Field Details and Checks
2.Information Nicknames:
•Sufficient to only use a Nickname within a Use Case
–Ex: Clerk collects customer data.
•The Nickname should be hyperlinked to another section of the requirements
document – Data Requirements or External Data Formats
•The data section may be developed in parallel with the use cases or after all data
Nicknames have been listed

165. 165 Defining Requirements with Use Cases © Deloitte Inc.
Data Requirements (cont’d)
1.The data section is first described using field lists
–Ex: Customer Data  First Name, Last Name, Street Address, Province,
Country, Postal Code, Home Phone Number, Business Phone Number, Date
of Birth
2.The data section should then be elaborated to describe
•Exact field formats
•Exact field lengths
•Validation behavior
–How many characters long should the customer’s first name be?
–What restrictions are there on date of birth?
–Which of the fields are mandatory?

166. 166 Defining Requirements with Use Cases © Deloitte Inc.
Data Requirements (cont’d)
Ex: Customer Data
Date < CurrentDate
– 5 years
Optional
DateAndTime
(MM/DD/YYYY)
Date of Birth
Length > 2MandatoryStringLast Name
Length > 2MandatoryStringFirst Name
Valid Values
Mandatory/
Optional
TypeField Name

167. 167 Defining Requirements with Use Cases © Deloitte Inc.
Business Rules
•Should not be put directly into the use cases
–makes it difficult to read
–Obscures its behavior
•Adorn use cases with a business rules section
–Option 1: Contain a complete description of the business rule
–Option 2: A link to the business rules section of the requirements document

168. 168 Defining Requirements with Use Cases © Deloitte Inc.
Business Rules (cont’d)
Use Case Name: Drop Course
1.Student Logs On to the system.
Steps 2 to 4 can be repeated until the student has dropped all the courses that he
wishes to.
3.Student browses enrolled courses and selects a course.
4.Student chooses to drop the course.
5.System displays course was dropped and the amount the Student will be refunded.
6.Student Logs out.
•Business Rules
–BR1: Course Cancellation and Refund Calculation (Applies to MS step 3)
–The Student will receive a refund depending on how long the class has been running.
•< 5 days  90% refund
•< 15 days  50% refund
•<30 days  No refund
•>= 30 days  The Student cannot drop course

169. 169 Defining Requirements with Use Cases © Deloitte Inc.
Non-Functional Requirements
•Addresses scalability, performance, security, flexibility, etc.
•Including non-functional requirements directly into the Use Case can
make the Use Case more difficult to read
•May change independently of functional requirements, so they should
be listed independently
•Adorn use cases with a non-functional requirements section
•Only collect non-functional requirements that apply to the specific Use
Case
•When the Use Case set is finished, collect the non-functional
requirements into a specific section or document

170. 170 Defining Requirements with Use Cases © Deloitte Inc.
Non-Functional Requirements (cont’d)
•Use Case Name: Schedule Courses
1.Professor Logs On to the system.
2.Professor browses assigned courses, and selects a course.
3.Professor searches for classroom (location, availability, assets, description).
4.System displays classroom search results.
5.Professor may sort results by location, assets and size.
6.Professor selects classroom.
7.System updates course status to available for enrollment and displays result to
professor.
8.Professor Logs out.
•Non-Functional Requirements
NF1: (Applies to MS step 2)
System must respond to a search request within 9 seconds.
NF2: (Applies to MS step 7)
System must update the course status within 20 seconds.
NF3: (Applies to step 6)
The System should be able to support 50 concurrent users scheduling classes.
NF4: (Applies to step 2)
The System should be able to support 1000 concurrent searches.

171. 171 Defining Requirements with Use Cases © Deloitte Inc.
User Interface and Navigation
•Details do not belong in the use case set
•Deliverables should trace back to a specific use case
•Can be developed in parallel with the Use Case set or after the Use
Case has been completed.

172. 172 Defining Requirements with Use Cases © Deloitte Inc.
Key Points
•Use cases ONLY capture behavioral requirements
– Not enough to design or implement a system
•Other requirements must be captured
–Ex: Data Structures, Business Rules, Non-Functional Requirements, etc.
•These requirements may be listed in the context of the entire system
and/or for each specific use case where applicable
•Use Adornments to avoid cluttering use cases with non-behavioral
requirements

173. 173 Defining Requirements with Use Cases © Deloitte Inc.
Patterns

174. 174 Defining Requirements with Use Cases © Deloitte Inc.
Pattern: Adornments
•Problem:
–The inclusion of non-functional requirements in a use case can quickly clutter
and obscure the use case.
•Context:
–The purpose of a use case is to express clearly the functional requirements of
a system
–We often discover non-behavioral information while researching functional
requirements
–Inclusion of nonfunctional requirements in the use case is distracting
–But we do not want to lose information that aids in understanding the use
case or is valuable to the developers
•Solution:
–Create additional fields in the use case template that are outside the scenario
text to hold the supplementary information that is useful to associate with the
use case

175. 175 Defining Requirements with Use Cases © Deloitte Inc.
Class Task 11 (30 mins)
•Capture all other requirements where they are implied in the problem
statement

176. 176 Defining Requirements with Use Cases © Deloitte Inc.
Solution: Other Requirements
•Class handout

177. 177 Defining Requirements with Use Cases © Deloitte Inc.
Lab Assignment Overview
•Venue Management System (VMS)

178. 178 Defining Requirements with Use Cases © Deloitte Inc.
Day 4
•Continue…

179. 179 Defining Requirements with Use Cases © Deloitte Inc.
Day 4 Lunch
•Review actor/goal list

180. 180 Defining Requirements with Use Cases © Deloitte Inc.
Supplementary Information

181. Member of
Deloitte Touche Tohmatsu
© Deloitte & Touche LLP and affiliated entities.

Deloitte, one of Canada's leading professional services firms, provides audit, tax, consulting, and
financial advisory services through more than 6,100 people in 47 offices. Deloitte operates in Québec
as Samson Bélair/Deloitte & Touche s.e.n.c.r.l. The firm is dedicated to helping its clients and its
people excel. Deloitte is the Canadian member firm of Deloitte Touche Tohmatsu.

Deloitte refers to one or more of Deloitte Touche Tohmatsu, a Swiss Verein, its member firms, and
their respective subsidiaries and affiliates. As a Swiss Verein (association), neither Deloitte Touche
Tohmatsu nor any of its member firms has any liability for each other's acts or omissions. Each of
the member firms is a separate and independent legal entity operating under the names "Deloitte,"
"Deloitte & Touche," "Deloitte Touche Tohmatsu," or other related names. Services are provided by
the member firms or their subsidiaries or affiliates and not by the Deloitte Touche Tohmatsu Verein.