Usecase

1 Defining Requirements with Use Cases © Deloitte Inc.

Defining Requirements with Use Cases

Consulting Technology IntegrationJuly 15, 2005


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


Introduction


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


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


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


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


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


Overview of Use Cases


Further reference

• This course has been influenced by the writings contained in the following two books

– Patterns for Effective Use Casesby Steve Adolph, Alistair Cockburn, Andy Pols, Paul Bramble

– Writing Effective Use Cases by Alastair Cochran

http://print.google.com/print?id=V2MQPPDdre4C&pg=1&lpg=1&prev=http://print.google.com/print%3Fq%3DPatterns%2Bfor%2Beffective%2Buse%2Bcases%26oi%3Dprint&sig=B_YG500Eu3H4yM6zVcM9T5a8gKI







http://www.amazon.com/exec/obidos/tg/detail/-/0201702258/ref=pd_sxp_f/102-1692210-3400962?v=glance&s=books


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


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


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


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?


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


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


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


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


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.


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:

1. Student Logs On to the system.Steps 2 to 6 can be repeated until the student has reached maximum course load for the term.

2. Student searches for courses (course name, course code, by department, by level, by availability).

3. System displays search results (course name, course code, department, level, availability).

4. Student selects a course to enroll in.5. System displays course details.6. Student confirms enrolment.7. 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.


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.


Steps to Writing Use Cases

Writing use cases can be divided into 5 stages of precision

1. List Actors and their goals

2. Create Use case briefs

3. Describe Main success scenario

4. List alternate and failure scenarios

5. Describe alternate and failure scenario steps


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

Topic In Out

Purchasing Books Online through the AMCE University Online Bookstore

IN

Tracking student grades for courses Out

Approving and rejecting degree and course changes IN

Post and download course notes IN


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.


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.


Patterns


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


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.


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.


Actors and Goals


Module Objectives


– 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


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


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


Class Task 1 (15 mins)

• List all the actors for the ACME University Degree Management System (ADMS)


Solution: Actor List

• Student

• Senior Professor

• Professor

• Department Head

• ACME Online University Bookstore


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



• Create the Actor-Goal list for the ACME University Degree Management System (ADMS)


Refreshment Break

• 15 mins


Solution: Actor-Goal List

Actor Goal

Students Enroll in Course

Purchase Course Text Book

Senior Professors Create Degree for specific department

Create Course Overview for Specific Degree

Assign Professor to Course

Review Course Details

Department Heads Review Degree and Course Overview

Professors Create Course Details

Schedule Courses


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


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


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



• Create an Actor Profile for the ACME University Degree Management System (ADMS)


Solution: Actor Profile Table

Actor Profile: Background and Skills

Student 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.

Senior Professor Older user, however, typically has a lot of experience with computers because of daily job demands. May have difficulty with smaller fonts.

Department Head Occasional user, casual computer experience only. Impatient.


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.


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


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


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.


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


Graphical Scheme for Goal Levels

Increase Sales

Promote Product

OrderProduct

InvoiceOrder

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


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


User Goal Example

Use Case Name: Create a DegreePrimary Actor: Senior ProfessorLevel: UserScope: System (ADMS)

Main Scenario: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).Steps 4 and 5 can be repeated until the Senior Professor manages all the courses he/she intended to add to the degree.

4. Senior Professor Creates a Course Overview for the Degree.5. Senior Professor adds the course to the degree.6. Senior Professor submits the degree/course overview to be approved by the

Departments Head.7. System notifies Department Head of pending items.8. Senior Professor Logs out.


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


Summary Level Example (Kite)

Use Case Name: Manage Degrees

Primary Actor: ACME University

Level: Summary

Scope: System (ADMS)

Main Scenario:

1. Senior Professors Create A Degree.

2. Senior Professors Create Course Overviews for courses in the degree.

3. Department Head Reviews Degree and Course Overview.

4. Senior Professors Assign Professors to the Course.

5. Professors Create Course Details.

6. Senior Professors Review Course Details.

The following must take place before each semester.

7. Professors Schedule Courses.

8. Students Enroll in Courses.


Summary Level Example (Cloud)

Use Case Name: Graduate with Degree

Primary Actor: Student

Level: Summary

Scope: Business (ACME University)

Main Scenario:

1. Student Applies to ACME University.

2. ACME University Accepts Student.

3. Student Accepts Offer.

Student must repeat steps 4-7 until he/she has completed all the courses necessary to complete his degree.

4. Student Enrolls in Semester.

5. Student Takes Classes.

6. Etc.


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


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)



• Assign goal levels to the Actor-Goal List for the ACME University Degree Management System (ADMS)


Solution: Assigning Goal Levels

Actor Goal Level

Students Enroll in Course User

Purchase Course Text Book User

Senior Professors Create Degree for specific department User

Create Course Overview for Specific Degree User

Assign Professor to Course User

Review Course Details User

Department Heads Review Degree and Course Overview User

Professors Create Course Details User

Schedule Courses User

ACME University Manage Degrees Summary


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.


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


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


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.


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


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


Patterns


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.


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.


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


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


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.


Refreshment Break

• 1 hour


Preconditions Triggers and Guarantees


Objectives


– Describe the necessary starting conditions for a use case

– Describe how the use case will protect the interest of all system stake holders


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


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


Preconditions Triggers and GuaranteesExamples

• 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


Key Points

• Only include these sections if they add value


Scenarios


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


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


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

Actor Goal Brief

Student Enroll in Course 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.



• Create briefs for all user goals in the ACME University Degree Management System (ADMS)


Solutions: Use Case Briefs

Actor Goal Level Briefs

Students Enroll in Course User 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.

Purchase Course Text Book User 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.

Senior Professors Create Degree for specific department

User 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.

Create Course Overview for Specific Degree

User 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.

Assign Professor to Course User Senior Professors will assign professors responsible for teaching the course.

Review Course Details User Senior Professors will review all changes made to course details by Professors.


Solution: Use Case Briefs (cont’d)

Actor Goal Level Briefs

Department Heads

Review Degree and Course Overview User Department heads will review degree and course overview changes made by Senior Professors.

Professors Create Course Details User 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.

Schedule Courses User Before each semester the assigned Professor needs to schedule a course choosing time and classroom.

ACME University Manage Degrees Summary 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.


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


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


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”


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”


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.

5. Senior Professor Creates a Course Overview for the Degree.

6. Senior Professor adds the course to the degree.

7. Senior Professor submits the degree/course overview to be approved by the Department Head.

8. System notifies Department Head of pending items.

9. Senior Professor Logs out.


Refreshment Break

• 15 mins


Class Task 6

• Create Main Scenarios for the ACME University Degree Management System (ADMS)


End of Day 1

• Be prepared to finish the Class Task in the morning!


Beginning of Day 2

• Please complete the class task from yesterday afternoon!


Solution: Main Scenarios

• Distribute Handout


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


Patterns


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.


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.


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.


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.


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.


Refreshment Break

• 15 mins


Extensions


Module Objectives


– 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


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


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 Overview1. 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 Overview1. 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.


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 courses3. 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.

6. If textbook has not been assigned to the course,6.1 Professor Assigns Textbook to the Course.

7. 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 submitted9.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 successful10. Professor Logs out.


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


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


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


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


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.


– AS1: Modify Existing Course Overview

2. Senior Professor browses and selects existing course.

3. Go to MS step 3.

– AS2: Retire Course

2. Senior Professor browses and selects existing course.

3. Senior Professor nominates course to be retired.

4. System notifies all department heads who have degrees that would be affected by course retirement.

5. Go to MS step 6.


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


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


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.



• AS1: Save Course Details for Future Submission

– Optionally do any of the steps 3-5 from MS.

6. Save course details.7. Go to MS step 8.

• AS2: Submit Previously Saved Course Details

2. 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)

4. System displays message showing error.

5. Go to MS step 4.

• EX3: Invalid File Format (Applies to MS step 4)

4. System displays list of invalid file formats (.exe .bat .vbs).

5. Go to MS step 4.

• EX4: Unable to Notify Senior Professor (Applies to MS step 7)

7. System continues to attempt to notify department head until it is able to.

8. Go to MS step 8.


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


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


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


Class Task 7 (1 hour)

• Create Extension List for the ACME University Degree Management System (ADMS)


Refreshment Break

• 1 hour


Solution: Extension Listing

• Distribute handouts


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


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


Refreshment Break

• 15 mins


Class Task 8 (2 hours)

• Create Extension Descriptions for the ACME University Degree Management System (ADMS)


End of Day 2

• Be prepared to finish creating extension descriptions…


Beginning of Day 3

• Continue writing details of your Use Case Extensions


Solution: Extension Description Writing

• Distribute handouts


Refreshment Break

• 15 mins


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


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


Patterns


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


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


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.


Extension Use Cases


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


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


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



• 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 CourseDetails

<<Extends>>

<<Extends>>

<<Extends>>



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.

2. Student searches for courses (course name, course code, by department, by level, by availability).

3. System displays search results (course name, course code, department, level, availability).

4. Student selects a course to enroll in.

5. Student confirms enrolment.

6. System displays course overview, syllabus and time-table.

7. Student browses course syllabus.

8. System displays time-table.

9. Student Logs out.

Use Case Name: View Enrolled Course Details


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


1. Student requests time-table

2. System displays time-table

Use Case Name: Download Course Notes


1. Student downloads course notes


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.


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)



• Identify and Create an Extension Use Case where appropriate in the ACME University Degree Management System (ADMS)


Refreshment Break

• 1 hour


Solution: Extension Use Case

• Class handout


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


Patterns


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


Parameterized Use Cases


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


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)


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.)


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

Use Case Name Searchable Qualities Display Values Sort Criteria

Search for Customer SIN Number, Last Name, Tel Number

Full Name, Tel Number, Address, Age

Last Name, First Name, Address Street

Search for Movie Movie Title, Location, Schedule

Movie Title, Director, Location, Schedule, Stars

Location, Schedule

Search for Book Book Title, ISBN, Category

Book Title, Publisher, ISBN, Author

Book Title, Author



• Identify any “almost” identical Use Cases or Use Case steps and describe them using Parameterized Use Cases


Solution: Parameterized Use Cases

• Class handout


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


Refreshment Break

• 15 mins


Other Requirements


Module Objectives


– Identify other types of requirements that must be captured in order to completely define system needs

– Capture types of non-behavioral requirements


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

Business Rules

Performance

Requirements

I/O Protocols UI Design

UI Req

uire

men

ts

Data

Form

ats


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


Data Requirements

• Data requirements can be divided into three levels of precision1. Information Nickname

2. Field Lists or Data Descriptions

3. Field Details and Checks

1. 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


Data Requirements (cont’d)

2. 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

3. 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?


Data Requirements (cont’d)

Ex: Customer Data

Field Name TypeMandatory/

OptionalValid Values

First Name String Mandatory Length > 2

Last Name String Mandatory Length > 2

Date of BirthDateAndTime

(MM/DD/YYYY)Optional

Date < CurrentDate – 5 years


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


Business Rules (cont’d)

Use Case Name: Drop Course


Steps 2 to 4 can be repeated until the student has dropped all the courses that he wishes to.

2. Student browses enrolled courses and selects a course.

3. Student chooses to drop the course.

4. System displays course was dropped and the amount the Student will be refunded.

5. 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


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


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.


• 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.


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.


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


Patterns


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



• Capture all other requirements where they are implied in the problem statement


Solution: Other Requirements

• Class handout


Lab Assignment Overview

• Venue Management System (VMS)


Day 4

• Continue…


Day 4 Lunch

• Review actor/goal list


Supplementary Information

Member ofDeloitte 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.