The document focuses on usage models in requirements engineering, particularly highlighting definitions and distinctions among usage models, use cases, and scenarios. It emphasizes the importance of understanding user interactions and system behavior, along with detailed methodologies for modeling through diagrams such as UML. Practical examples like an ATM system illustrate the structure of use cases and how to derive scenarios from them.

1. Requirements
Engineering:
Usage Models
CECS 542
Dr. Birgit Penzenstadler
1
Photo credit: David Marcu, Unsplash

2. Usage Models
• Defini=on
• Use cases
• Scenarios
• Rela=on
• Cockburn template
• Elabora=on
Dr. Birgit Penzenstadler 2
K Rayker, stock.xchng

3. Usage Model
• Def.: A usage model describes the
system behavior from the point of
view of the user („Black box“) by
modeling interac=on sequences.
• It specifies the use cases
(from the system vision)
• Why? Understanding of intended
uses by means of the system.
• Nota=ons:
– Use case overview diagram
– Structured text (templates)
– UML ac=vity diagrams
– Message Sequence Charts
Dr. Birgit Penzenstadler 3
Context Layer
System Layer
Requirements Layer
Stakeholder Model Objectives
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
Architecture Overview
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
Deployment Requirements
System Constraints
Domain Model
Service ModelUsage Model
Quality Requirements
Risk List
Project Scope
Process Requirements
Glossary
Glossary
Glossary

4. Use cases & Scenarios
• Def.: A use case is a series of system events
triggered by an actor that leads to results for the
actor.
• Def.: A scenario is an ordered set of interac=ons
between partners, usually a system and a group
of actors.
• A Usage Model in AMDiRE has three parts:
– Use Case Overview Diagram („bubble“ diagram)
– Use Case Templates (one per „bubble“)
– Scenario diagrams (one per use case template)
Dr. Birgit Penzenstadler 4

5. Use Case Overview Diagram
Dr. Birgit Penzenstadler 5
[uml-diagrams.org 2010]

6. Another
Use Case
Overview
Diagram
Dr. Birgit Penzenstadler 6
[Scoa W. Ambler 2007]

7. Elabora=on of a Usage Model
• Deducing the Use Cases
– Iden=fica=on of Use Case by
business processes
– Analysis of business processes
• Task distribu=on to actors
• Iden=fica=on of usage func=ons
• Defini=on of the role of the system, e.g.:
– Passive support (data administra=on),
– Ac=ve support (task performance)
– Informal start: What are the system features?
• Stepwise descrip=on and refinement of the scenarios and their interac=on
– Focus on analysis and modeling of
• Informa=on flow (for later data modeling)
• Interac=on and control flow at the system border
7
Usage
Model
Business Processes
... ... ...
User System
External
Systems
Stake
holder

8. Exercise: ATM
• Use case overview
• Use case template
• Scenario
Dr. Birgit Penzenstadler 8
[Scoa W. Ambler 2007]

9. ATM Use Case Overview
Dr. Birgit Penzenstadler 9

10. Rela=on: Use Cases and Scenarios
Dr. Birgit Penzenstadler 10
Use Case
Scenario
(1) (2)
• For each „bubble“ in the overview diagram:
• Use Cases summarize a set of scenarios to a
specific usage of the system.
– Use Case:
Task, objec=ve, causal rela=on (pre- and
post-condi=ons)
– Scenario:
Sequence of Events (steps, events,
interac=on)
Itera&ve Elabora&on
(compare to refinement and abstrac=on of
goals in the earlier lecture)
(1) Cluster scenarios to tasks
(2) Elicit task-specific scenarios,
analyse and walk through them

11. Use cases
& Scenarios:
Cockburn
template
Dr. Birgit Penzenstadler 11
• Use: Use cases and
scenarios complement
each other.
• Techniques: Structured
text and/or sequence/
interac=on diagrams
• Elicita&on: itera=ve;
combine scenarios to
tasks, „play out“ task-
specific scenarios and
analyse

12. Example
UCI winter 2014 Dr. Birgit Penzenstadler 12

13. Exercise: ATM
• Use case overview
• Use case template
• Scenario
Dr. Birgit Penzenstadler 13
[Scoa W. Ambler 2007]

14. • Use Case: <number> <the name should be the goal as a short ac=ve verb phrase>
• CHARACTERISTIC INFORMATION
– Goal in Context: <a longer statement of the goal, if needed>
– Scope: <what system is being considered black-box under design>
– Level: <one of: Summary, Primary task, Subfunc=on>
– Precondi=ons: <what we expect is already the state of the world>
– Success End Condi=on: <the state of the world upon successful comple=on>
– Failed End Condi=on: <the state of the world if goal abandoned>
– Primary Actor: <a role name for the primary actor, or descrip=on>
– Trigger: <the ac=on upon the system that starts the use case, may be =me event>
• MAIN SUCCESS SCENARIO
– <put here the steps of the scenario from trigger to goal delivery, and any cleanup aner>
– <step #> <ac=on descrip=on>
• EXTENSIONS
– <put here there extensions, one at a =me, each refering to the step of the main
scenario>
– <step altered> <condi=on> : <ac=on or sub.use case>
– <step altered> <condi=on> : <ac=on or sub.use case>
• SUB-VARIATIONS
– <put here the sub-varia=ons that will cause eventual bifurca=on in the scenario>
– <step or varia=on # > <list of sub-varia=ons>
– <step or varia=on # > <list of sub-varia=ons> Dr. Birgit Penzenstadler 14
1 of 2

15. • RELATED INFORMATION (op=onal)
– Priority: <how cri=cal to your system / organiza=on>
– Performance Target:
<the amount of =me this use case should take>
– Frequency: <how onen it is expected to happen>
– Superordinate Use Case:
<op=onal, name of use case that includes this one>
– Subordinate Use Cases:
<op=onal, depending on tools, links to sub use cases>
– Channel to primary actor:
<e.g. interac=ve, sta=c files, database>
– Secondary Actors:
<list of other systems needed to accomplish use case>
– Channel to Secondary Actors:
<e.g. interac=ve, sta=c, file, database, =meout>
• OPEN ISSUES (op=onal)
– <list of issues about this use cases awai=ng decisions>
• SCHEDULE
– Due Date: <date or release of deployment>
2 of 2
Dr. Birgit Penzenstadler 15

16. • Use Case: 1 withdraw money
• CHARACTERISTIC INFORMATION
– Goal in Context: user withdraws money from the ATM
– Scope: ATM
– Level: Primary task
– Precondi=ons: user has an ATM card and has access to ATM
– Success End Condi=on: user gets money
– Failed End Condi=on: user doesn’t get money
– Primary Actor: customer (= user)
– Trigger: ATM card entered by user
• MAIN SUCCESS SCENARIO
1. User enters card
2. System prompts for PIN
3. User enters PIN
4. System prompts op=ons for withdrawal / transfer / deposit money
5. User selects withdraw
6. System prompts for amount
7. User enters amount
8. System returns money
• EXTENSIONS
– 5. condi&on selec=on of different account: ac&on Withdraw from different account
– <step altered> <condi=on> : <ac=on or sub.use case>
– <step altered> <condi=on> : <ac=on or sub.use case>
• SUB-VARIATIONS
– 4. condi&on user entered wrong PIN: ac&on system displays error message
– 8. not enough money: system displays error message
– <step or varia=on # > <list of sub-varia=ons>
• RELATED INFORMATION (op=onal)
– Priority: cri=cal
– Performance Target: one minute
– Frequency: very onen (depends on loca=on of ATM)
– Superordinate Use Case: <op=onal, name of use case that includes this one>
– Subordinate Use Cases: <op=onal, depending on tools, links to sub.use cases>
– Channel to primary actor: interac=ve
– Secondary Actors: <list of other systems needed to accomplish use case>
– Channel to Secondary Actors: <e.g. interac=ve, sta=c, file, database, =meout>
• OPEN ISSUES (op=onal)
– <list of issues about this use cases awai=ng decisions>
• SCHEDULE
– Due Date: May 2014
Example
Use Case
ATM
Dr. Birgit Penzenstadler 16

17. Use Cases vs. Scenarios vs. Func=onal
Requirements
17
Use Case
Use Case: Set of all scenarios
Scenario: Concrete interac=on sequence
Func=onal requirement (roughly):
A (system-)reac=on to a s=mulus
Functional
requirement
Scenario

18. Example: Scenario Purchase Item
Dr. Birgit Penzenstadler 18
Def.: A
scenario is an
ordered set of
interac=ons
between
partners,
usually a
system and a
group of
external
actors.

19. How-to: Scenarios in a diagram
• UML Sequence Diagram:
– For user interac=on
– For message sequences
• UML Ac=vity Diagram:
– For process flows
– For system-internal interac=on
à Depends on your system what works beaer.
Dr. Birgit Penzenstadler 19

20. Differen=a=on
• Sequence diagrams describe interac=ons among classes in terms of an
exchange of messages over =me. Sequence diagrams show a detailed flow
for a specific use case or even just part of a specific use case. They are
almost self explanatory; they show the calls between the different objects
in their sequence and can show, at a detailed level, different calls to
different objects.
• Ac&vity diagrams illustrate the dynamic nature of a system by modeling
the flow of control from ac=vity to ac=vity. An ac=vity represents an
opera=on on some class in the system that results in a change in the state
of the system. Typically, ac=vity diagrams are used to model workflow or
business processes and internal opera=on.
• Sequence diagram models the sequen=al logic, ordering of messages with
respect to =me.
• Ac&vity diagram high-level business processes, including data flow, or to
model the logic of complex logic within a system.
Dr. Birgit Penzenstadler 20

21. Sequence Diagram
Dr. Birgit Penzenstadler 21
the getFigureAt() method call’s return is shown labeled with the name of the object
that was returned. A common practice, as we have done in Figure A1.7, is to leave
off the return arrow when a void method has been called, since it clutters up the di-
850 APPENDIX 1 AN INTRODUCTION TO UML
:MouseListener :Drawing :GraphicsaFigure:Figure
.setColor(red)
.highlight(graphics)
.getFigureAt(point)
.mouseClicked(point)
aFigure
.drawRect (x,y,w,h)
.drawString(s)
FIGURE A1.7
A sample
sequence
diagram

22. Sequence Diagram: frame
Dr. Birgit Penzenstadler 22
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
An empty UML 2 frame element

23. Sequence Diagram: in/out messages
Dr. Birgit Penzenstadler 23
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A sequence diagram that has incoming and
outgoing messages

24. Sequence Diagram: Lifelines
Dr. Birgit Penzenstadler 24
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
An example of the Student class used in a
lifeline whose instance name is freshman

25. Sequence Diagram: Messages
Dr. Birgit Penzenstadler 25
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
An example of messages being sent between
objects, including return messages

26. Sequence Diagram: help method
Dr. Birgit Penzenstadler 26
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
The system object calling its determineAvailableReports method

27. Sequence Diagram: asynch/synch
Dr. Birgit Penzenstadler 27
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A sequence diagram fragment showing an
asynchronous message being sent to instance2

28. Sequence Diagram: guard
Dr. Birgit Penzenstadler 28
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A segment of a UML 1.x sequence diagram in
which the addStudent message has a guard

29. Sequence
Diagram:
alterna=ve
Dr. Birgit Penzenstadler 29
hap://www.ibm.com/developerworks
/ra=onal/library/3101.html
A sequence diagram fragment
that contains an alterna=ve
combina=on fragment

30. Sequence Diagram: op=on
Dr. Birgit Penzenstadler 30
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A sequence
diagram fragment
that includes an
op=on
combina=on
fragment

31. Sequence
Diagram:
loop
Dr. Birgit Penzenstadler 31
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
An example sequence
diagram with a loop
combina=on fragment

32. Sequence
Diagram:
reference
Dr. Birgit Penzenstadler 32
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A sequence
diagram that
references two
different
sequence
diagrams Problem – it seems like cash is returned either way

33. Sequence Diagram
Dr. Birgit Penzenstadler 33

34. Use case template to MS Diagram
• Use case template extension – depicted as
op=on in message sequence diagram
• Use case template subvaria=on – depicted as
alterna=ve in message sequence diagram
Cephei, 12.12.2012 Dr. Birgit Penzenstadler 34

35. Exercise: ATM
• Use case overview
• Use case template
• Scenario
Dr. Birgit Penzenstadler 35
[Scoa W. Ambler 2007]

36. ATM Scenario in
UML Sequence diagram
Dr. Birgit Penzenstadler 36