Use-Case Writing

1. Harsh Jegadeesan’s CLASSROOM
EFFECTIVE USE-CASE WRITING
BITS Pilani
Off-Campus Work-Integrated Learning Programmes

2. AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
Supplementary Specification
2
9/22/2008 Object Oriented Analysis & Design

3. ACKNOWLEDGEMENT
This part of the lecture is based on:
Integrated Requirements Engineering: A Tutorial
Ian Sommerville, Lancaster University
International Requirements Engineering
Conference (RE ’04).
A copy of this could be got from:
IEEE Software January- February 2005
3
9/22/2008 Object Oriented Analysis & Design

4. MOTIVATION FOR REQUIREMENTS
ENGINEERING
Before any software system is developed:
We must understand what the system is supposed to
do
How its use can support goals of individuals /
organizations
This involves:
Understanding Application Domain
Systems Operational Constraints
Specific Functionality Required by stake-holders
Essential characteristics like performance, security,
reliability and dependability
4
9/22/2008 Object Oriented Analysis & Design

5. WHAT IS REQUIREMENTS ENGINEERING?
Requirements Engineering is the structured set
of activities which:
Help develop system understanding
Identifying stake-holders and needs
Document system specification for stake-holders and
engineers involved
Challenges:
Numerous and distributed stake-holders
Varying and conflicting goals
Difficulties in Articulating these goals
5
9/22/2008 Object Oriented Analysis & Design

6. RELATIVE COSTS OF FIXING SOFTWARE
FAULTS
200
30
10
3 4
1 2
6
Requirements Specification Planning Design Implementation Integration Maintenance
9/22/2008 Object Oriented Analysis & Design

7. THE FUNDAMENTAL PROCESS
DISCLAIMER
RE varies significantly with:
- Size and type of the application developed
- Size and Culture of the companies involved
- The Software Acquisition Process
For Instance,
Large Military and Aerospace Projects – Formal
RE
Small Companies – RE is Brainstorming
7
9/22/2008 Object Oriented Analysis & Design

8. THE RE ACTIVITY CYCLE
8
Courtesy: The Integrated Requirements Engineering: A Tutorial
9/22/2008 Object Oriented Analysis & Design

9. ELICITATION
Process: Identify sources of information about the
system and discover requirements from these
Identifying stakeholders & user classes
Customers or Clients
Developers
Users - novice users, expert users, occasional
users, disabled users
Goals & Tasks
Focus on Problem domain
And needs of stakeholders
9
Scenarios & Use cases
9/22/2008 Object Oriented Analysis & Design

10. ELICITATION -TECHNIQUES
Elicitation Techniques
Traditional techniques
Questionnaires, surveys, interviews, documents
Group elicitation techniques
Prototyping
Model-driven techniques
Cognitive techniques
Contextual techniques
Need for guidance on use of these Techniques
10
9/22/2008 Object Oriented Analysis & Design

11. THE RE ACTIVITY CYCLE
Courtesy: The Integrated Requirements Engineering: A Tutorial 11
9/22/2008 Object Oriented Analysis & Design

12. ANALYSIS
Process: Understand the Requirements their
overlaps and conflicts
Enterprise Modeling
Organizational Structure
Business Rules
Data Modeling
Entity-Relationship-Attribute
Behavioral Modeling
Functional behavior of Stakeholders.
Existing
Required 12
9/22/2008 Object Oriented Analysis & Design

13. ANALYSIS [2]
Domain Modeling
Abstract description of the world
Advantage: Requirement reuse within a
domain
Advantage: detailed reasoning about the
domain
Modeling Non-Functional Requirement
Difficult to measure and test
Analyzing Requirement Models
Requirement animation, automated reasoning 13
Knowledge based critique, consistency check
9/22/2008 Object Oriented Analysis & Design

14. THE RE ACTIVITY CYCLE
Courtesy: The Integrated Requirements Engineering: A Tutorial 14
9/22/2008 Object Oriented Analysis & Design

15. VALIDATION
Process: Go back to system stake-holders and find
out whether requirements are what they really
need
A prototype may be needed to capture
requirements depending on the software process
that is followed. Validation of requirements could
be done using a throw-away prototype or through
incremental development
15
9/22/2008 Object Oriented Analysis & Design

16. THE RE ACTIVITY CYCLE
Courtesy: The Integrated Requirements Engineering: A Tutorial 16
9/22/2008 Object Oriented Analysis & Design

17. NEGOTIATION
Process: Inevitably, stakeholders’ views will differ,
and proposed requirements might conflict. Try to
reconcile conflicting views and generate a
consistent set of requirements.
Negotiation must be done using techniques like
group discussions whereby all the stake-holders
are in a common platform. This helps in the
emergence of a clear holistic view from the stake-
holders’ end.
17
9/22/2008 Object Oriented Analysis & Design

18. THE RE ACTIVITY CYCLE
Courtesy: The Integrated Requirements Engineering: A Tutorial 18
9/22/2008 Object Oriented Analysis & Design

19. DOCUMENTATION AND MANAGEMENT
Write down the requirements in a way that
stakeholders and software developers can
understand.
Control the requirements changes that will
inevitably arise.
This leads to effective communication of
requirements (Improving Requirements
Engineering Communication in Multiproject
Environments)
19
9/22/2008 Object Oriented Analysis & Design

20. OUTCOME OF RE PROCESS
Statement of Requirements (a.k.a A
Requirements Document) that defines what is to
be implemented
Research Community argues that, more complete
and consistent a requirement document is more
likely that the software would be reliable
Formal Description Vs Natural Language
Description
Formal – Complete, Concise yet costly
Natural Language – Vague, client disputes yet cheap
during changing requirements
20
9/22/2008 Object Oriented Analysis & Design

21. AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
Supplementary Specification
21
9/22/2008 Object Oriented Analysis & Design

22. WHAT IS A USE-CASE?
“A set of user instances, where each instance is a
sequence of actions a system performs that yields
an observable result of value to a particular
actor”
Actor – Something with a behavior such as person,
computer system etc.
Scenario – Specific sequence of actions and
interactions between actors and system under
discussion (SuD) 22
9/22/2008 Object Oriented Analysis & Design

23. ACTORS
Actors have ‘goals’ in the system
There are three kinds of actors
Primary Actor: has user goals fulfilled through
using services of the SuD
Supporting Actors: provides a service to the
SuD
E.g. Automated payment authorization
service
Offstage Actor: has interest in the behavior of
the use-case
E.g. Government tax Agency 23
9/22/2008 Object Oriented Analysis & Design

24. SCHEMATIC DIAGRAM
AN ACTOR HAS GOALS; GOALS NAME USE CASES; A USE
CASE HAS SCENARIOS NAMING SUB-USE CASES.
Actor
has
Goal names Use case
contains calls
condition
Scenario
succeed / fail
24
Courtesy: Use-Cases in Theory & Practice, Alistair Cockburn
9/22/2008 Object Oriented Analysis & Design

25. ALISTAIR COCKBURN’S DEFINITION
Use-Case :
Purpose = requirements
Contents = consistent prose
Plurality = multiple scenarios per use case
Structure = semi-formal
25
9/22/2008 Object Oriented Analysis & Design

26. KEY POINTS ABOUT USE-CASES
Use-cases are requirements, primarily functional
requirements
Use Cases are text documents, not diagrams and
use-case modeling is primarily an art of writing
texts, not drawing
Any use-case must add observable value to an
actor
Use-Cases are important part of the iterative
planning
Use-Case realizations drive design
26
9/22/2008 Object Oriented Analysis & Design

27. USE CASE TYPES
Define ‘what’ the system must do (functional
requirements) without deciding ‘how’ it will do it
(design)- Black Box Use-cases
Formality Types:
Brief: Terse one-paragraph summary; covers main
success scenario
Casual: multiple paragraphs; cover various scenarios
Fully dressed: most elaborate; all steps and
variations are discussed in detail (www.usecases.org
format)
27
9/22/2008 Object Oriented Analysis & Design

28. AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
Supplementary Specification
28
9/22/2008 Object Oriented Analysis & Design

29. ALISTAIR COCKBURN’S TEMPLATE
Run through of Alistair Cockburn’s Template
29
9/22/2008 Object Oriented Analysis & Design

30. SECTIONS IN USE-CASE
Primary Actor
Principal actor who calls upon system services
to fulfill a goal
Stakeholders and Interests
Contract between stakeholders within the
system boundary
Pre-Conditions / Post-Conditions
Pre-conditions must always be true before
starting
Post-Conditions suggest what might be true on
success 30
9/22/2008 Object Oriented Analysis & Design

31. SECTIONS IN USE-CASE [2]
Main Success Scenario (Basic Flow)
‘Happy path’ scenario
Defer all conditional and branching
statements to the extension section
A Scenario could be three types:
Interaction between actors
A validation by the system
A state change by the system
31
9/22/2008 Object Oriented Analysis & Design

32. SECTIONS IN USE-CASE [3]
Extensions (Alternate Flow)
Indicates all other scenarios or branches, both
success and failure
These branches are from the main scenario
and hence labeled ‘1a’, ‘3b’ etc
At the end of the extension, the scenario
merges back with the main success scenario
Sometimes a particular extension point might
be quite complex and might be expressed as a
separate use-case
E.g. ‘Paying by Credit card’ 32
9/22/2008 Object Oriented Analysis & Design

33. SECTIONS IN USE-CASE [4]
Special Requirements
If a non-functional requirements relates
specifically to a use-case then record it with
the use-case
These are normally qualities like performance,
reliability and usability
Technology and Data variation list
‘How’ something must be done
Technical constraint imposed by the
stakeholder and hence necessary to capture
33
9/22/2008 Object Oriented Analysis & Design

34. INCREASING LEVELS OF PRECISION
Actor and Goals
List of Actors and which of their goals the
system would support.
Use-Case Brief or Main Success Scenario
Pursue main success scenario
Failure Conditions
Based on MSS, deliberate all failures that could occur
Do not worry about Failure handling at this step
Failure Handling
How system is supposed to respond to each failure.
New business rules, new actors and goals could 34
surface
9/22/2008 Object Oriented Analysis & Design

35. AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
Supplementary Specification
35
9/22/2008 Object Oriented Analysis & Design

36. CHALLENGES IN USE-CASE DISCOVERY
Tasks can be grouped at many levels of
granularity from one or a few small steps to
enterprise level activities
We use Elementary Business Processes (EBP) and
Goals as a framework to identify use-cases
Which is a valid use-case?
Negotiate a Supplier Contract
Handle Returns
Log In
All these are valid at different levels
36
9/22/2008 Object Oriented Analysis & Design

37. EBP GUIDELINE
For requirements analysis focus on use-cases at
the level of a Elementary Business Process (EBP)
Caveat
Although base-use cases must follow the EBP
guideline, there could be sub-use cases which
exists at a lower level
Actors have goal a EBP use-case is called a user-
goal level use-case, this leads to a recommended
procedure
1. Find the user goals
2. Define a use-case for each
37
9/22/2008 Object Oriented Analysis & Design

38. INVESTIGATING USER GOALS VS. INVESTIGATING
USE-CASES
Goal Hierarchy
Prevent theft, data
corruption
Identify to the system
Cashier at PoS Scenario
1. Quickly log-in Sub-goal Log In
2. Capture Sales Main Goal / Base
use-case
38
9/22/2008 Object Oriented Analysis & Design

39. DESIGN SCOPE VS. GOAL LEVEL
(SCOPE VS. LEVEL)
Scope
Which system boundary do we mean?
“Spatial extent” of the system
Level
Why do we want this goal?
“strategic” vs. “user task” vs. “sub-function”
39
9/22/2008 Object Oriented Analysis & Design

40. SCOPE
Dept. 1 Dept. 3
Sys. 1
System
Organization
C1 C2
Component
Dept. 2
C3
Sys. 2
Organization
40
9/22/2008 Object Oriented Analysis & Design

41. LEVEL
project goal
Strategic Goals
“White”
advertise order invoice
“Blue”
User Goals
set up reference monitor place create send
promotion promotion promotion order invoice invoice
“Indigo”
Subfunctions identify register user identify identify
promotion product customer
41
9/22/2008 Object Oriented Analysis & Design

42. AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Design Scope & Goal Level of Use-Case
4 Steps to Use-Cases
Supplementary Specification
42
9/22/2008 Object Oriented Analysis & Design

43. STEP I – CHOOSING SYSTEM BOUNDARY
1
Choosing the System Boundary
-Clarified by defining what is outside
-Once external Actors are identified the
boundary becomes clear
43
9/22/2008 Object Oriented Analysis & Design

44. STEP 2 & 3 – FINDING PRIMARY
ACTORS & GOALS
1
Choosing the System Boundary
2
Finding Primary Actors
3
Finding Goals
Identify Primary Actors by asking
questions e.g. Who start/stops the
system?
Actors have goals that must be satisfied 44
by the system
9/22/2008 Object Oriented Analysis & Design

45. ACTOR- GOAL LIST
Courtesy: Applying UML & Patterns, Craig Larman
9/22/2008 Object Oriented Analysis & Design 45

46. STEP 4 – DEFINE USE-CASES
1
Choosing the System Boundary
2
Finding Primary Actors
3
Finding Goals
4
Define Use-Cases
Start use-cases with a verb
CRUD goals into one use-case Manage ‘X’ 46
9/22/2008 Object Oriented Analysis & Design

47. AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
Supplementary Specification
47
9/22/2008 Object Oriented Analysis & Design

48. SUPPLEMENTARY SPECIFICATIONS
Apart from use-cases, there are other kind of
requirements
Documentation
Packaging
Supportability
Licensing
More of non-functional in nature for the scope of
the entire SuD
48
9/22/2008 Object Oriented Analysis & Design

49. REFERENCES
Applying UML & Patterns, Craig Larman
Text: Part II - Inception 6,7,8, 25
Writing Effective Use-cases, Alistair Cockburn
www.usecases.org for the Use-case Template
49
9/22/2008 Object Oriented Analysis & Design