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