SCENARIO BASED APPROACHES - PowerPoint PPT Presentation

Loading...

PPT – SCENARIO BASED APPROACHES PowerPoint presentation | free to view - id: 114247-N2RlZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

SCENARIO BASED APPROACHES

Description:

The OOSE (use case) approach. Key Issues in Scenario and Use Case Development ... The OOSE approach. Ivar Jacobson. The use case driven approach ... – PowerPoint PPT presentation

Number of Views:452
Avg rating:3.0/5.0
Slides: 80
Provided by: Bour4
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: SCENARIO BASED APPROACHES


1
SCENARIO BASED APPROACHES
Describing users stories about how they
envisage to use the system in their
organisational setting
2
Outline
  • What, Why, When
  • Reference framework
  • The OOSE (use case) approach
  • Key Issues in Scenario and Use Case Development

3
What are scenarios?
Use cases are stories, prose essays
(S.Adolph03) A scenario can be defined as a
description of a possible set of events that
might reasonably take place (M.Jarke98) A
scenario is a sequence of interactions between
the user and the system (Potts94)
4
The Fingerprint example
Fingerprint clerk takes fingerprints of citizen
applying for passport
Citizen gives the passport form to the
clerk Clerk retrieves passport record from
passport database Clerk gives instructions on how
to position citizens hand in the fingerprint
machine Citizen positions hand in fingerprint
machine Clerk starts the fingerprint machine If
red light on fingerprint machine turns on,
citizen re-positions hand and clerk restarts the
machine Machine saves the fingerprint in the
fingerprint database and updates the passport
database
5
Definitions
  • A scenario is a description involving
  • an individual user,
  • interacting with a software system,
  • to obtain a specific result,
  • in specific conditions,
  • during a limited period of time.
  • (Nielsen95)
  • ex a specific case of withdrawal of cash from
    an ATM can be described as a scenario but the
    description of an auction transaction is not a
    scenario

6
Definitions
  • A scenario is a description of the behaviour of
    the system and
  • of its environment which manifests in specific
    situations
  • (Benner 93)
  • At a functional level, a scenario is a
    description denoting similar
  • parts of possible behaviours limited to a subset
    of purposeful
  • state components, actions and communications
    taking place
  • among two or several agents. More external
    (richer)
  • scenarios include information about roles,
    responsibilities,
  • organisation policies, (CREWS-glossary98)

7
Characterisation of the notion of a scenario
  • Main common feature
  • The USAGE - CENTRED PERSPECTIVE in requirements
    engineering and system analysis and design
  • Two key unifying characteristics
  • 1. A scenario is a description of a set of
    activities, not of an individual act
  • 2. A scenario  views  the system from the
    outside it takes the user view point

8
Characterisation of the notion of a scenario
  • Differences
  • 1. A scenario describes a transaction between the
    user and the system
  • 2. A scenario describes a context of work, the
    activities of actors in their social setting. It
    describes the resources they use and their
    objectives as well as the usage they intend to
    make of the system

9
Characterisation of the notion of a scenario
  • Cinema Analogy scenario vs. script
  • A scenario tells a story in the large
  • typical of HCI community
  • centred on the description of the work context
  • A script details interactions and dialogue among
    actors
  • predominant in OO approaches
  • focuses on the interaction between the user and
    the system

10
An example of script type of scenario
  • (Regnell95)
  • 1. Withdraw Cash, normal case
  • Actor ATM customer
  • 1.IC Invocation Conditions
  • 1.IC.1 The system is ready for transactions.
  • 1.FC Flow Conditions
  • 1.FC.1 The users card is valid.
  • 1.FC.2 The user enters a valid code.
  • 1.FC.3 The user enters a valid amount.
  • 1.FC.4 The machine has the required amount of
    cash.
  • 1.FE Flow of Events
  • 1.FE.1 The user inserts the card.
  • 1.FE.2 The system checks if the card is valid.
  • 1.FE.3 A prompt for the code is given
  • 1.FE.4 The user enters the code.
  • 1.FE.5 the system checks if the code is valid
  • 1.FE.6 A prompt enter amount or select balance
    is given.
  • 1.FE.7 The user enters the amount.
  • 1.FE.8 The system checks if the amount is valid
  • 1.FE.9 The system collects the cash.
  • 1.FE.10 The cash us ejected.
  • 1.FE.11 A prompt take cash is given.
  • 1.FE.12 The user takes the cash.
  • 1.FE.13 The card is ejected.
  • 1.FE.14 A prompt take card is given.
  • 1.FE.15 The user takes the card
  • 1.FE.16 The system collects receipt information.
  • 1.FE.17 The receipt is printed.
  • 1.FE.18 A prompt take receipt is given.
  • 1.FE.19 The user takes the receipt.
  • 1.TC Termination condition
  • 1.TC.1 The system is ready for transactions.

11
An example of cinema like scenario
  • (Kyng95) Archiving (use scenario)
  • The hypermedia services should be available to
    all GBL personnel in the WAN subject to suitable
    access restriction. Due to performance
    requirements, separate link servers for each LAN
    are needed, but it should be possible to link
    across LANs.
  • A journal system is an integrated part of the
    hypermedia. The secretaries currently responsible
    for registering correspondence become responsible
    for entering letters, faxes, change requests, and
    nonconformance reports into hypermedia network.
    As a supplement and partly a substitute for
    registering keywords, they establish initial sets
    of public links between new and existing
    materials in the hypermedia. When, for example,
    an incoming letter is a response to a letter
    already stored in the network, a Refer-to link
    is established between them.
  • Instead of having secretaries photocopy incoming
    materials for manual distribution and filing in
    several local archives, the entry of material
    into the hypermedia (e.g., by scanning) should
    imply automatic notification to personnel
    subscribing to that type of materiel. This
    procedure requires less photocopying, but
    probably more printers for enabling people to get
    hard copies quickly. Photocopies of certain
    materials may be made for a few persons who have
    to print anyway.
  • Other personnel can immediately inspect
    materials in the system. They can follow links
    made during journalisation, add links to
    existing materials, and annotate materials, thus
    sharing their reaction with others.
  • ...

12
Narrow versus Rich picture
  • 1. Narrow picture
  • 2. Rich picture

(Kyng 95) Description of work situation, use
scenario, exploratory scenario, ... (Nielsen 95)
use scenario
(Jacobson92), (Regnell95) Use case (Potts94),
Rubin92) Script
13
Multi purpose, multi form, multi- usage..artefacts
Narrow vs Rich Scenarios ( Kuutti95)
Abstract vs Concrete Scenarios (Jacobson95)
(Potts94)
Variety of Scenario Roles Validation
(Lalioti95) Object-Oriented Design (Jacobson95),
(Rumbaugh91), (Rubin92) Facilitating
communication between designers (Erickson95)
Proactive vs Reactive generation
strategy (Holbrook90)
Informal Rough vs Formal and Detailed
Scenarios (Jacobson95), (Rubin92), (Hsia94)
Animated generated scenarios vs Statically
captured scenarios (Lalioti95)
14
Outline
  • What, Why, When
  • Reference framework
  • The OOSE (use case) approach
  • Key Issues in Scenario and Use Case Development

15
Reference framework
  • Four views about scenarios scenario approaches
  • Contents
  • Form
  • Objective
  • Life cycle
  • Several facets per view
  • Contents
  • Context
  • Coverage
  • Abstraction
  • Argumentation
  • Several attributes per facet taking their values
    in predefined domains
  • Coverage
  • Functional SET(ENUMStructure, Function,
    Behaviour)
  • Non Functional SET(ENUMPerformance, Time,
    Friendliness, Flexibility, Portability,
    Security...)
  • Intentional SET(ENUMGoal, Problem,
    Responsibility, Opportunity...)

16
The Four Views on Scenarios
What is the knowledge expressed in a scenario?
Contents
Why using a scenario?
has
expressed under
aims at
Form
Purpose
Scenario
In Which form is a scenario expressed ?
evolves
Life cycle
How to manipulate a scenario ?
(Rolland98)
17
Form View
expressed under
composed of
Form
Description
Scenario
Medium Notation
composed of
Presentation
Animation Interactivity
Medium SET (ENUM Text, Graphics, Image, Video,
Software prototype) Notation ENUM Formal,
Semi-formal, Informal Animation
BOOLEAN Interactivity ENUM None,
Hypertext-like, Advanced
18
Form View Example
  • Medium Graphics
  • Notation Semi-formal

The usage view for ATM Customer (Regnell95)
19
Form Example
  • Medium Text
  • Notation Semi-formal

Scenario for the meeting scheduler (Potts94)
20
Purpose View
aims at
Purpose
Scenario
Descriptive Exploratory Explanatory
Descriptive BOOLEAN Exploratory BOOLEAN
Explanatory BOOLEAN
21
Purpose View Examples
  • Descriptive scenario
  • Use case Withdraw Cash (Regnell95)
  • Script Scenario for the meeting scheduler
    (Potts94)
  • ...
  • Exploratory scenario
  • Alternative design solutions in the library
    system example (Holbrook90)
  • With bar codes
  • Without bar codes
  • Explanatory scenario
  • Explanation of Titanic wreck causes (Titanic
    movie )
  • Explanation of airplane crash (Writh92)

22
Contents View
composed of
has
Contents
Abstraction
Scenario
Instance Type Mixed
composed of
composed of
Argumentation
Coverage
Context
System internal System interaction Organisational
context Organisational environment
Position Arguments Issues Decisions
Functional Intentional Non Functional
System internal BOOLEAN System interaction
BOOLEAN Organisational context
BOOLEAN Organisational environment BOOLEAN
Position BOOLEAN Arguments BOOLEAN Issues
BOOLEAN Decisions BOOLEAN
Instance BOOLEAN Type BOOLEAN Mixed BOOLEAN
Functional SET(ENUMStructure,Function,
Behaviour) Intentional SET(ENUMGoal, Problem,
Responsibilitiy, Opportunity, Cause, Goal
dependency) Non Functional SET(ENUMPerformance,
Time constraints, Cost constraints, User
support, Documentation, Backup/recovery,
Maintainability, Flexibility, Portability,
Security/Safety, Design constraints)
23
Contents View Examples
  • Abstraction Scenario instance "Annie out of
    town" (Potts94)

24
Contents View Examples
  • Argumentation
  • Position two alternative design solutions
    (Holbrook90)
  • With scanners
  • Without scanners
  • Arguments for alternative 1 (Holbrook90)
  • scanners bar codes lead to time saving, reduce
    library clerk load, etc.
  • Context
  • System Interaction use case Withdraw Cash
    (Regnell95)
  • Organisational Context Archiving scenario
    (Kyng95)

25
Contents View Examples
  • Coverage
  • scenario Archiving (Kyng90)
  • Intentional
  • Responsibility The secretaries currently
    responsible for registering correspondence become
    responsible for entering letters, faxes, change
    requests, and nonconformance reports into
    hypermedia network.
  • Non Functional
  • Performance The hypermedia services should be
    available to all GBL personnel in the WAN subject
    to suitable access restriction. Due to
    performance requirements, separate link servers
    for each LAN are needed, but it should be
    possible to link across LANs.
  • Design constraints The entry of material into
    the hypermedia (e.g., by scanning) should imply
    automatic notification to personnel subscribing
    to that type of material.

26
Life cycle View
composed of
evolves
Life cycle
Operation
Scenario
Capture Integration Refinement Expansion Deletion
composed of
Life span
Life span ENUMTransient, Persistent Capture
ENUMFrom_scratch, By_reuse Integration BOOLEAN
Refinement BOOLEAN Expansion BOOLEAN Deletion
BOOLEAN
27
Approaches Classification Examples
Hsia Potts Kyng Prototype Script Scenari
o Form.Desc.Medium Text(spec) Text
(table) Text Form.Desc.Notation Formal
Semi-formal Informal Form.Present.Anim False
True False Form.Present.Interac None Hypertex
t Hypertext Contents.Abstraction Type,
Instance Inst.,Type, Mixed Instance,
Type Contents.Context Syst. Interaction Syst.
Interaction Syst. Interaction Syst
Internal Context Org. Coverage.Func. B F,
B F, B Coverage.Intent. - Goal, Resp. Goal,
Responsibility Coverage.Non Func. - - Friendlin
ess, Security, Performance, Constraints
..Argumentation False False True Objective D
escriptive Descriptive Descriptive,
Explicative, Exploratory LifeCycle
.Duration Persistent Persistent Transient LifeCy
cle.Op. Capture Capture, Integr. Capture
28
Exercise (2)
Abstract from the example scenarios (See slides10
19) and put the Regnells approach in the
Reference Framework
29
Practice survey
  • 15 site visits to industrial projects to
    complement the more research-oriented scenario
    classification framework
  • Structured interview was based on a catalogue of
    questions for scenario characteristics which were
    derived from the CREWS classification framework
  • Form view
  • The majority of the projects employed natural
    language either in prose text or in structured
    text following a more or less rigid template or
    table-structure
  • Contents view
  • Nearly all the projects use scenarios to capture
    system-user interactions whereas only one third
    also considered the system context and/or the
    system internal interactions
  • Purpose view
  • The use of scenarios for concretizing abstract
    models, for improving agreement and consistency,
    for reducing complexity, and for complementing
    prototypes and glossaries was emphasized
  • Life cycle view
  • In all projects examined the fact that scenarios
    are artifacts which evolve over time and must
    therefore be managed accordingly was mentioned

(Weidenhaupt98)
30
Scenario vs. specification
1. Scenarios complement specifications 2.
Scenarios replace specifications Higlighting
some differences
  • Scenarios
  • concrete descriptions
  • focus on specific instances
  • based on work context
  • fragmented
  • informal, approximate
  • envisaged results
  • Specifications
  • abstract descriptions
  • focus on types
  • technology driven
  • complete
  • formal, rigorous
  • specified results

31
Why scenarios are needed?
RE and OO community Object model complexity
and communication overhead within the
development team is not acceptable anymore
CREWS-practice survey, (Weiderhaupt98).
In HCI, scenario-based design has emerged as a
paradigm to reconcile a long lasting conflict
formal modelling approaches proved too narrow to
provide effective guidance to designers whereas
purely experiential approaches could not be
replicated, verified and explained (Carroll95).
32
When are scenarios used?
  • Development
  • Activities
  • Requirements
  • Engineering
  • User-Analyst
  • Communication
  • Justification of design solutions
  • Scenario role
  • To ease requirements elicitation
  • To concretise goals
  • To capture contextual information
  • Ease communication between stakeholders and
    engineers
  • To illustrate problems which are important for
    users, to understand situations in which they
    will use IT solutions, and how
  • To constitute a glossary of words and terms used
    in a project
  • To evaluate different alternative solutions of
    system use
  • Pay-off analysis

33
When are scenarios used?
  • Scenario role
  • Examine system usability
  • Estimate what will be the effects of the system
    on user work activities and tasks
  • Understand system functionalities
  • Help system validation testing
  • Document design solutions
  • Development
  • Activity
  • Perspective
  • Evaluation
  • System
  • Testing
  • Documentation and
  • training

34
Outline
  • What, Why, When
  • Reference framework
  • The OOSE (use case) approach
  • Key Issues in Scenario and Use Case Development

35
The OOSE approachIvar Jacobson
  • The use case driven approach

OBJECTORY Object Factory for Software
Development OOSE Object Oriented Software
Engineering
36
OOSE development process models
Analysis
Construction
Testing
Requirements model Analysis model
Design model Implementation model
Testing model
37
Requirements model
  • Goal To define system boundaries and specify
  • functional requirements
  • Components
  • Use Case Model
  • Interface Descriptions
  • Problem Domain model

38
Use Case model
  • Goal
  • To help in understanding, eliciting and defining
    system functional requirements. To model the
    system behaviour from an external users point of
    view
  • Concepts
  • Actor A role played by a user or that which
    interacts with the system
  • Use Case To state what the users should be able
    to do with the system

39
Process of use case construction
  • Actor identification
  • Use case identification
  • Use case description
  • Normal case
  • Exception cases
  • Refining use cases
  • extend relationship
  • Abstracting from use cases
  • use relationship

40
The Actor concept
  • The word Actor implies an individual in action
  • However,
  • An actor represents/models
  • a role played by a system end-user, or anything
    that interacts
  • with the system
  • an actor indicates a general category of
    individuals who
  • can play a given role
  • Ex Kim, is a customer of MyTelCo, Chris is a
    clerk, and Pat
  • is a sales manager. Any one of them can Place an
    Order
  • Customer, Clerk and Sale manager are the allowed
    actors for
  • the Place an Order use case

41
The Actor concept
  • Types of actors
  • primary actor - the one who calls on the system
    to deliver one of its services. The primary actor
    is often, but not always, the initiator of the
    use case
  • ex a company clerk representing a customer can
    be the ultimate primary actor (acting for someone
    else)
  • secondary actor an external actor that provides
    a service to the system under design now
    referred to as supporting actor (Cockburn01). It
    interacts with the SuD but does not trigger the
    UC
  • ex printers, readers etc. that are needed by
    the system
  • SuD system under development treated as a
    black box
  • other system - other system(s) with which the
    system under design (SuD) shall interact

42
Example Recycling System
  • The system controls a recycling machine for
    bottles, boxes and crates.
  • Any customer can bring the three types of
    elements at a time
  • The system must control elements.
  • The system calculates the number of elements
    brought by a customer and reimburses him
    accordingly. The customer may ask for a receipt
    which details the elements, the value returned
    for each of them and the total value.
  • An operator uses the system once a day to get a
    recap of returned elements and the total value
    given to customers.
  • The operator is entitled to change value of
    parameters such as the amount given for each
    element.
  • An alarm calls the operator if an element is
    blocked or if there is no paper for customer
    receipt in the machine..

43
Identification of actors
Example
44
Exercise (3)
You have been hired to create the requirements
document for a new ATM. Decide whether each item
in the following list is a stakeholder, a primary
actor, a secondary actor, the SuD, or not an
actor at all The ATM The customer The ATM
card The bank The front panel The bank owner The
serviceman The printer The bank clerk The main
bank computer system The bank robber List the
primary actors
45
The Use Case concept
  • A use case models
  • a set of transactions between the user and the
    system
  • what the system is expected to do in response to
    external stimuli from users
  • Each transaction is associated to an actor who
    initiates the use case
  • Cockburn s more recent view
  •  The system is a mechanism to carry out a
    contract between various stakeholders, use cases
    provide the behavioural part of this contract
    (A. Cockburn01)
  • Use Cases specify all the different ways to use
    the system and therefore, define the whole
    required behaviour of the system (the Unknown)

46
Identification of use cases Example recycling
system
47
Identification of use cases Difficulties
Naming Create file, Delete file, Level of
abstraction It is not unusual to see use cases
with names like Create employee record, Read
employee record Delete employee record
48
Identification of use cases Suggestions
A use case shall identify a valuable service that
the system delivers to the actor to satisfy her
business purpose Name a use case by the
VerbPhraseName describing the intention of the
primary actor
Attach every use case to a goal ! a user goal
(an operationalisable goal)!
49
Identification of use cases Example recycling
system
The primary actor has a goal that the system
shall help him to reach Name use case with the
goal VerbPhraseName
50
Exercise (4)
List goals that the various ATM primary actors
will have with respect to the ATM
51
Use case description
With textual scenarios A scenario describes one
transaction with the system initiated by the
primary actor A scenario is a sequence of
interactions between the system and its primary
actor
52
Use case description
  • Base scenario the scenario describing the most
    frequent sequence of interactions between the
    user and the system (to achieve the goal)
  • Example Put Element
  • Exception scenario a scenario describing a
    variant of the base scenario that corresponds to
    an exceptional system functioning
  • Example Blocked Element
  • A use case description contains exactly one base
    scenario and zero or more exception scenarios

53
Example
  • Use case Put Element
  • When the customer puts an element it is measured
    to determine its type. If the element is
    accepted, the customer amount is incremented as
    well as the daily total for this type of element.
    If the element is not accepted , the message
    invalid element is shown on the machine panel.
  • When the customer pushes the receipt button
    the system calculates the total and prints the
    following information on the receipt for every
    type of element, the name, the number of put
    elements the corresponding amount and the total
    sum to deliver to the customer.

54
Use case description
Being critical !!
A use case description shall focus on interactions
Internal action
Internal action
  • Use case Put Element
  • When the customer puts an element it is measured
    to determine its type. If the element is
    accepted, the customer amount is incremented as
    well as the daily total for this type of element.
    If the element is not accepted , the message
    invalid element is shown on the machine panel.
  • When the customer pushes the receipt button
    the system calculates the total and prints the
    following information on the receipt for every
    type of element, the name, the number of put
    elements the corresponding amount and the total
    sum to deliver to the customer

Internal action
Too many details
55
Use case description Suggestions
A use case description shall focus on interactions
  • Every scenario action should be a communication
    action between the system
  • and the actor
  • Internal action should be limited to those which
    have an effect on the
  • interaction process

Internal action
com1
conditioncom2
When the customer puts an element it is measured
to determine its type. If the element is accepted
56
Use case description Suggestions
Internal action without impact on the
interaction
A use case description shall focus on interactions
If the element is accepted, the customer amount
is incremented as well as the daily total for
this type of element. When the customer ..
The customer puts an element
System measures element to determine its type
If the element is accepted the system asks the
user to continue
Transformed writing
57
Use case description Suggestions
Conditions can be part of the scenario
description as if statements or aggregated in a
separate section
System checks type
The customer puts an element
The system asks the user to continue
Condition the element is of one of the valid
types
The customer puts an element. The system asks
the user to continue
Alternative transformed writing
58
Use case description Suggestions
When the customer pushes the receipt button the
system calculates the total and prints the
following information on the receipt for every
type of element, the name, the number of put
elements the corresponding amount and the
total sum to deliver to the customer
Too many details not affecting the interaction
System calculates ..
Customer pushes the R button
The system prints the receipt
When the customer pushes the receipt button the
system prints the receipt
59
Use case description Suggestions
Where?
When the customer puts an element it is measured
to determine its type. If the element is accepted

ambiguous
  • A communication action involves a source actor
    and the target actor that must be
  • mentioned in the phrase to avoid ambiguities
  • Avoid anaphoric references.

Preferred writing
When the customer puts an element in the
recycling system, the system checks the validity
of the element.
60
Exercise (5)
Write the base scenario for the use case Withdraw
Money Using Fast Cash Option
61
Use case descriptionSuggestions
Clarifying base versus exceptional scenario
Attachment of a goal to a use case helps
clarifying types of scenarios
  • The primary actor has a goal the system should
    help
  • the primary actor reach the goal
  • Some scenarios show the goal being achieved
  • Some end with the goal abandoned

?
Distinguish success (normal) scenarios from
failure (exception) scenarios
62
Use case descriptionSuggestions
The striped trousers image (Cockburn01)
A use case collects together all the scenarios,
success and failure
Goal
Use Case
Sc1
Sc2
Scn
Scenarios
Fsc1
Fscn
Success
Fail
Success scenarios (goal is attained)
Failure scenarios (goal is not reached)
63
Use case descriptionSuggestions
A scenario is a thread does not include
branching
  • Each success or failure scenario is a straight
    description for one set
  • of circumstances with one outcome
  • Ex Put Element (base success scenario)
  • circumstances the customer has elements which
    are of acceptable size
  • outcome receipt
  • Withdraw Money (normal success scenario)
  • circumstances the customer has a valid card
    and credit on her account
  • outcome cash and card

64
Exercise (6)
1- Brainstorm about possible conditions for
failure in the use case Withdraw Money 2- List
failure scenarios and Name them 3- Identify
circumstances and outcome for each of them 4-
Write the failure scenario comprising three wrong
captures of the customers PIN
65
Use case descriptionSuggestions
  • Success scenarios can be further classified into
  • base scenario describes the main course of
    actions
  • variant describes alternate courses of actions
    of the base scenario
  • Ex Put Element creating blockage is a variant
    of Put Element
  • Withdraw Money with a receipt is a variant
  • of Withdraw Money

66
Use case Put Element
Being critical !!
  • When the customer puts an element it is measured
    to determine its type. If the element is
    accepted, the customer amount is incremented as
    well as the daily total for this type of element.
    If the element is not accepted , the message
    invalid element is shown on the machine panel.
  • When the customer pushes the receipt button
    the system calculates the total and prints the
    following information on the receipt for every
    type of element, the name, the number of put
    elements the corresponding amount and the total
    sum to deliver to the customer

Branching
2 scenarios Base scenario Variant (2 legs)
67
Exercise (7)
1- Brainstorm about possible variations of the
course of actions in the base success scenario
of the use case Withdraw Money 2- List variant
scenarios and Name them 3- Identify
circumstances and outcome for each of them 4-
Write the variant scenario comprising two wrong
captures of the customers PIN
68
Use case refinement Extend relationship
  • The extend relationship
  • Optional parts of a use case
  • Alternative scenarios which occur rarely
  • Sub-scenarios which are valid only in some
    exceptional cases

69
Use case refinement Extend relationship
Example Recycling system
  • Use case Unblock element
  • When an element is blocked, an alarm is
    activated to call the operator. The operator
    removes the element, sets the alarm and then, the
    customer can put down new elements. The
    transaction continues but the blocked element is
    not counted.

70
Use case refinement Use relationship
  • Abstract use case description of parts which are
    shared by different use cases
  • the description of an abstract use case is reused
    in several other use cases
  • An abstract use case is not instantiated as such
  • Concrete use case a use case really instantiated

71
Use case refinement Use relationship
Example Recycling system
  • Put element et Generate daily report, share the
    abstract use case Print.

72
Key issues in scenario use case development
Use cases are stories, prose essays, and so
bring along all the associated difficulties of
story writing in general I did not understand
this as the fundamental problem for the first
four years (Rusty Walters in Writing Effective
Use Cases, Cokburn01)

More discussion about use cases on
www.usecases.org
73
Key issues in scenario use case development
Example of use case horror
Register for course 1- Display a blank
schedule 2- Display a list of all classes in the
following way the left window lists all the
courses in the system in alphabetical order. The
lower window displays the times the highlighted
Course is available. The third window shows all
the courses currently in the schedule 3- Do 4-
Student clicks on a course 5- Update the lower
window to show the times the course is
available 6- Student clicks on a course time and
then clicks on the Add course button 7- Check
if the student has the necessary prerequisites,
and that the course is open 8- If the course is
open and the student has the necessary
prerequisites, add the student to the course.
Display the updated schedule showing the new
course. If no, put up a message you are missing
requisites. Choose another course. 9- Mark the
course offering as enrolled in the schedule 10-
End do when the student clicks on Save
Schedule 11- Save the schedule and return to the
main selection screen.
74
Exercise (8)Part of assignment 3
Propose a better written use case!
75
Key issues in scenario use case development
  • Problem
  • Solution
  • 1- Scenario authoring
  • Too many details, too low level details,
    non-behavioural information,
  • improper sentence writing
  • Style and Content guidelines, sentence phrase
    templates,
  • scenario template
  • Cokburns template, LEcritoire linguistic rules
    patterns, Adolphs
  • pattern, Leites NL based approach, Pottss
    scenario template
  • 2 Difficulty with levels
  • Different levels of abstraction in the same
    scenario (details of a system
  • check or calculation in an interaction scenario),
    different writers describe
  • different levels of UC goals (Get cash to Insert
    ATM card)
  • Provide taxonomy of goals (and therefore of
    scenarios)
  • Provide mechanism to handle level change

76
Key issues in scenario use case development
  • Cokburns White, Blue Indigo goals (Writing
    effective use cases)
  • White summary goals Blue user goals Indigo
    sub functions
  • Rollands Contextual, Functional Physical
    goals (LEcritoire)

77
Key issues in scenario use case development
  • 3- Complete identification of use case variations
  • missing variations exceptions poor
    identification of
  • obstacles and conditions for goal failure
  • precise definition of variations and exceptions
  • rules for systematic discovery of strips in the
    two legs!!
  • CompleteSingleGoal ExhaustiveAlternatives in
    Patterns for
  • effective use cases Alternative discovery rules
    in LEcritoire

78
Key issues in scenario use case development
  • 4- Complete definition of use case family
  • missing use cases tracking functionalities over
    use cases
  • relating goal and use case
  • rules for systematic discovery of system goals
  • ANDed goal discovery rules in LEcritoire

79
Key issues in scenario use case development
  • 5- Providing guidance to the requirements
    engineer
  • ad-hoc chaotic processes
  • patterns for best practice (Patterns for
    Effective UC)
  • formally defined process (LEcritoire, Leite00)
  • tool support (LEcritoire, Prime CREWS (Polh98),
  • Savre (Sutcliffe98))
About PowerShow.com