Use Case Analysis Dr Zhen Jiang West Chester

  • Slides: 36
Download presentation
Use Case Analysis Dr. Zhen Jiang West Chester University E-mail: zjiang@wcupa. edu url: www.

Use Case Analysis Dr. Zhen Jiang West Chester University E-mail: zjiang@wcupa. edu url: www. cs. wcupa. edu/~zjiang

Outline l What are use cases? l How to do it? l Tips!

Outline l What are use cases? l How to do it? l Tips!

What are use cases? l An use case – A way of l is

What are use cases? l An use case – A way of l is One way direction – capturing l Co-creating (User and designer) – functional l No performance or usability – requirement for a l Goals, not design – system

What are use cases? l Each use case defines an interaction between an actor

What are use cases? l Each use case defines an interaction between an actor and the system Use case

What are use cases? l A use case is an envelope of scenarios l

What are use cases? l A use case is an envelope of scenarios l Use case name is goal statement l l Scenarios are the stories of attempts at the goal l l Order product from catalogue “sunny day”-everything works out Agent is not authorized Customer has insufficient credit Use case is goal plus scenarios l l Each use case has many scenarios Each scenarios is described in terms of steps The scenario steps form a directed graph, and every path (scenario) either succeeds in realising the goal, or fails in some way Use cases represent (textually) the graph as a whole rather than each scenario separately

What are use cases? l Scenarios of a use case (stories) Reception Check Waiting

What are use cases? l Scenarios of a use case (stories) Reception Check Waiting Failure Authorized Success Failure

l Use – – – – What are use cases? Case template Name and

l Use – – – – What are use cases? Case template Name and unique ID Version info. Scope & level Goal in context Preconditions Successful outcome Failure outcome Primary actor Secondary actors Main scenario Alternatives Variations Related info. Issues

What are use cases? l Use case model – Preamble l is made up

What are use cases? l Use case model – Preamble l is made up of Introducing any general considerations, style, assumptions that will aid the reader – Actor list l Role names and brief descriptions – Use case list l Names and unique ids – Set of use cases l Using the template – Issues l For the use case model (not for the project)

How to do it – four steps l Identify primary actors and goals l

How to do it – four steps l Identify primary actors and goals l Write a scenario (path) in which the goal is delivered l Identify failure conditions for scenario steps l Follow each alternative (exception) until it ends or rejoins

Step ¼ Primary actors and goals l Identify primary actors and goals Actors are

Step ¼ Primary actors and goals l Identify primary actors and goals Actors are roles, not people or things l A single person may be many actors l Any interaction across a system boundary implies an actor l l Ask: what people and other systems will drive our system? l Result: a list of actor names and brief descriptions l Ask: what does each actor want our system to do? (The goal of each actor when using our system) l Result: a list of use case names, top-level coverage of functional requirements

Capturing Actors l An actor is a role Financial Planning Manager (insurance salesman l

Capturing Actors l An actor is a role Financial Planning Manager (insurance salesman l Bank teller l l Simple to capture Actor name l Brief description l l Listing l the actors helps with completeness Covering all the uses of the system l Primary cases actors are those which initiate use

Advice & guidance l Name the use cases l Remember to think about actors

Advice & guidance l Name the use cases l Remember to think about actors l Express goals from point of view of actor l Use the “ 1 person, 1 place, 1 time” rule of thumb to judge the appropriate granularity at which to identify business goals / use cases l The system doesn’t know which actor is the user (do not include name of actor in use case name) l Don’t worry too much about secondary actors

Secondary actors l Secondary actors are used by the system under design l Will

Secondary actors l Secondary actors are used by the system under design l Will appear on the system context diagram l May be mentioned in the Non-functional requirements l Usually secondary actors are system roles

Discussion l Home shopping assignment

Discussion l Home shopping assignment

Think about … l How big is a use case? l What if there

Think about … l How big is a use case? l What if there are multiple access channels? l Relationship of use cases to business processes?

Step 2/4 Simple goal delivered l For each use case, write a scenario in

Step 2/4 Simple goal delivered l For each use case, write a scenario in which the goal is delivered l The main success scenario, the happy day case Easies to read and understand l Everything else is a complication on this l l Capture the actor intent and system responsibility through to goal delivery Say what information passes between them l Number each line l User, system, user, system, … l l Result: coverage of function of each use case

Example l Place an order (UC 1) l Clerk identifies customer l System lists

Example l Place an order (UC 1) l Clerk identifies customer l System lists customer account details l Clerk creates order l System verifies and submits order l Use case end successfully

Preconditions l. A precondition is an assumption which must be true before a use

Preconditions l. A precondition is an assumption which must be true before a use case is used l Preconditions are not checked within a use case l Use preconditions to express dependencies between use cases l What must have happened before the start of the main scenario? For example: clerk is logged on.

Steps refer to lower-level goals l Main scenario: clerk identifies customer (UC 7) l

Steps refer to lower-level goals l Main scenario: clerk identifies customer (UC 7) l UC 77: l l l System prompts for customer name Clerk enters customer name System lists matching customer name and address Clerk selects customer End successfully l Alternatives (exceptions) Customer name is not found l System reports l Continue at step 1 l Use case ends in failure (account expired) l

Advice & guidance l Assume all steps succeed l Include a final “Use case

Advice & guidance l Assume all steps succeed l Include a final “Use case ends successfully” step l Start each step “System…” or “Actor…” l Choose just one success scenario (It is only a staring point from which to think about alternatives later) l Preserve system/Actor alternation by joining actions (System validates PIN and prompts for withdrawal amount) l Use language which doesn’t imply a solution, unless that particular solution is required l Preconditions should show dependencies

Discussion l Home shopping assignment l No exception l No details l Maybe no

Discussion l Home shopping assignment l No exception l No details l Maybe no relationship l Pay more attention on assumption and precondition

Step ¾ Failure conditions Identify potential failure conditions for scenario steps l Ask: what

Step ¾ Failure conditions Identify potential failure conditions for scenario steps l Ask: what can go wrong? l Result: list of conditions which will be used to develop alternative scenarios l

Failure scenarios help with completeness l Particular questions we might ask What l l

Failure scenarios help with completeness l Particular questions we might ask What l l if if their credit is too low? they run over the extended credit limit? we cannot deliver the quantity? the order is placed too late? Such questions are commonly overlooked

Advice & guidance l Brainstorm l first Failures of whole system, individual use case,

Advice & guidance l Brainstorm l first Failures of whole system, individual use case, or steps in scenarios l Don’t worry about effect of failures on use cases l Then review list to exclude: Failures which are ruled out by preconditions l IT failures l Failures which cannot be detected by system l Failures which cannot be acted upon by the system l l Use l this step to be creative Push boundaries of requirements

Discussion l Home shopping assignment

Discussion l Home shopping assignment

Step 4/4 Alternative scenarios l l l Each failure condition introduces an alternative scenario

Step 4/4 Alternative scenarios l l l Each failure condition introduces an alternative scenario Decide at which step the new scenario diverges Follow the alternative until it ends or rejoins Recoverable alternatives rejoin the main course Non-recoverable alternatives end use case in failure Result: use cases expressed as set of scenarios

Advice & guidance l l Numbering of steps is important A step may have

Advice & guidance l l Numbering of steps is important A step may have several alternatives Alternative step may themselves have alternatives End each alternative either: – Use case ends successfully – Use case ends in failure – Use case continues at step N l l Looping is allowed Finally-fill in the failure table with the failure types

Summary l Functional requirements have got to be captured somehow l It encourages asking

Summary l Functional requirements have got to be captured somehow l It encourages asking the right questions at the right time l It’s systematic l To check coverage or evenness of details l The results are quickly navigated Top-level is absorbed very quickly l Explore details where needed l Uniformity of format simplifies exploration of details l

Tips l l l l Dealing with data Connection to business rules Using generic

Tips l l l l Dealing with data Connection to business rules Using generic use cases Writing the preamble Forward to the analysis model Envisioning and designing When use cases aren’t suitable

Dealing with data Keep the data abstract l Catalogue the data under “Related information”

Dealing with data Keep the data abstract l Catalogue the data under “Related information” l This works because l Keeps focus on the systems’ use l Keeps data descriptions together l Encourages sharing these descriptions within and across use cases l

Connection to business rules Clue – detailed conditions or actions that might change l

Connection to business rules Clue – detailed conditions or actions that might change l Fear – use cases will change often l Solution – explicit business rules – back to the business! l

Using generic use cases Clue – Lots of similar things and new ones l

Using generic use cases Clue – Lots of similar things and new ones l Fear – Endless new use cases, interactions and objects l Solution – Generic (abstract) use case l

Writing the preamble Vital to set context for the reader/reviewer l Typical content l

Writing the preamble Vital to set context for the reader/reviewer l Typical content l l l Role of use case model in this project Level of detail Style Navigation, order of steps Assumptions on input error handling

Forward to the analysis model l Analysis model (AM) l Classes, associations, responsibilities, interactions

Forward to the analysis model l Analysis model (AM) l Classes, associations, responsibilities, interactions l Entities, relationships, processes (functional) AM delivers behavior described in the use cases l Keep the AM in view when doing use cases l Begin to identify data relationships (objects/entities) l Begin to identify common behavior l So-Backwards from the analysis model l

Envisioning and designing l Use cases require a vision of the system Can you

Envisioning and designing l Use cases require a vision of the system Can you imagine it? l Can you say yes/no quickly on scope? l Are you wondering what the solution is like? l l Envisioning techniques l Storyboarding Narrative for a whole business process l Screen shots to indicate system contributions l

When use cases aren’t suitable Lots of state ->statechart l Automated processing->time sequence diagram

When use cases aren’t suitable Lots of state ->statechart l Automated processing->time sequence diagram l Infrastructure->technical document l