Use Cases

1
Use Cases

• Lecture 5
• Spring 2004

2
Executive Summary

• What matters is not that we finish, but how we
  finish the Use Cases.

3
Agenda

• Overview
• What really matters in Systems Analysis?
• Noahs Ark
• Alistair Cockburn

4
SDLC
Overview
You are here
This is an excellent example of a data flow
diagram (DFD), a lost art form. Despite
appearances, the labels in the rounded boxes
are verbs. They represent processes, not
entities. The labels for the arrows are nouns.
This DFD models the flow of deliverables
between the processes. Being verb-centric makes
this a dynamic model.
This diagram was designed by Professor H. James
Nelson of The Ohio State University, my SDLC
teacher at the University of Utah. Please note
that his SDLC Methodology had 6, not 4, Phases.
5
SDLC
Overview
Input
According to this DFD, at the Analysis Phase you
receive a Request as input and (some time
later) you output a New Process Model. For help
at this you can get Facts and Recommendations
from a SQUARE box labeled System User.
Please understand that different people at
different times have different names for
essentially the same things.
Note In DFDs, square boxes are entities (People,
Places, and Things).
I prefer Requirements Document and End-user.
I do not have a preferred name for the INPUT
because, as a (Systems) Analyst, I take what is
given me. What have I not told you?
Facts and Recommendations
This DFD was designed by Professor H. James
Nelson of The Ohio State University.
6
Agenda

• Overview
• What really matters in Systems Analysis?
• Noahs Ark
• Alistair Cockburn

7
What really matters?
What if you had to pick just one?

• Get the user involved
• Use a problem-solving approach
• Establish phases and activities
• Establish standards for development and
  documentation
• Justify systems as capital investments
• Don't be afraid to cancel or revise scope
• Divide and conquer
• Design systems for growth and change
• Proper planning and project management

Source Text, page 47
8
What really matters?
One of these is stating a problem
Business

• You Name It
• Project Request
• System Request
• Project Charter
• Request Document
• Request For Proposal (RFP)
• Business Analysis Document
• A lot of yelling and screaming

The rest are stating solutions
you
9
What really matters

• is knowing what the problem is

How do you do that?
10
What really matters?
Does the Project Sponsor truly know what the
problem is?
11
What really matters?
Does the Project Request specify what the
problem is?
12
Do you know what the problem is?
Unless you do, this is what you are about to
do
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
What really matters?
Back here again

• Get the user involved
• Use a problem-solving approach
• Establish phases and activities
• Establish standards for development and
  documentation
• Justify systems as capital investments
• Don't be afraid to cancel or revise scope
• Divide and conquer
• Design systems for growth and change
• Proper planning and project management

What if you had to pick just one?
Source Text, page 47
17
What really matters is

• Get the user involved
• Use a problem-solving approach
• Establish phases and activities
• Establish standards for development and
  documentation
• Justify systems as capital investments
• Don't be afraid to cancel or revise scope
• Divide and conquer
• Design systems for growth and change
• Proper planning and project management

Wrong!
Source Text, page 47
18
Says who?
19
Depending on circumstances any of these might be
the solution
20
What really matters is

• Get the user involved
• Use a problem-solving approach
• Establish phases and activities
• Establish standards for development and
  documentation
• Justify systems as capital investments
• Don't be afraid to cancel or revise scope
• Divide and conquer
• Design systems for growth and change
• Proper planning and project management

Right!
But howdoyou do that?
Source Text, page 47
21
The HOW Game
22
What really matters
Soundslikeweregoingincircles. But were
not. Wearespiraling.

• is knowing what the problem is

How do you do that?
You use problem-solving
How do you do that?
You start with a problem statement
23
What really matters

• is having a good initial problem statement

How do you do that?
You try to get to take everything into account!
How do you do that?
You look around and try not miss anything or
anybody
24
And how do you do that?
25
Agenda

• Overview
• What really matters in Systems Analysis?
• Noahs Ark
• Alistair Cockburn

26
Noahs Ark

• Imagine you are Noah that your system is the Ark
  and that your deadline is the date set for the
  Great Deluge
• You will need to accommodate into your ark
  everybody you want to survive
• As well as everything they need to survive
• Thats it! You got yourself a darn good problem
  statement
• This method is called Stakeholder Analysis

27
Noahs Ark

• Imagine you are Noah that your system is the Ark
  and that your deadline is the date set for the
  Great Deluge
• You will need to accommodate into your ark
  everybody you want to survive
• As well as everything they need to survive
• Thats it! You got yourself a darn good problem
  statement a whole slew of them

28
Noahs Ark

• The Stakeholder and their Interests list is the
  starting point in finding out the problem
• With each ordered pair (Stakeholder, Interest)
  you have a potential problem/opportunity that
  deserves your attention
• We then rely on the Method of Drafting Use Cases
  to hone in on a potential solution addressing ALL
  of these concerns
• Then we will build the system and discover that
  we left somebody behind and start all over again.
  This time, though, its

Noahs Ark 2.0
29
Agenda

• Overview
• What really matters in Systems Analysis?
• Noahs Ark
• Alistair Cockburn

30
Alistair Cockburn

• What matters is how we draft the Use Cases
• Two reasons
• after the Use Cases are made, it becomes harder
  and harder to see where the problem is
• Drafting, if done well, is problem-solving

31
Alistair Cockburn

• In the Stakeholder-Interest List you will see
• Stakeholders that are NOT people but
  institutions, values, and even things
• A stakeholder can be a
• Person,
• Place,
• Thing, (another system, for example)
• Organization (another business, for example), or
• Idea (cultural norms and assumptions, for example)

32
Alistair Cockburn

• In the Stakeholder-Interest List you will also
  see
• Stakeholders that are users of the system
• Another word for these is ACTOR (Alistair
  Cockburn calls them Primary Actors)
• An Actors Interest is called a GOAL (of the
  system)
• The set of steps you need to do to carry out a
  Goal done are also called Goals

33
Alistair Cockburn

• In business we have
• Mission ? Vision ? Goals ? Objectives ? . . .
• In SDLC circles these are all uniformly called
  Goals but they have LEVELS
• So take care to use the right language as a
  function of who you are talking to!
• Most people are not Systems Analysts or MBAs
• Always keep your jargon as simple as possible

34
Alistair Cockburn

• The Stakeholder-Interest List plus the
  Actor-Goal List form the start.
• Alistairs drafting method starts off assuming
  that you can readily
• draft a good list Actor-List and
• identify all the stakeholders and their interests

35
Alistair Cockburn
What matters most is that you finish each level
before going to the next.

• Precision Level 1 Actor goal list
• Precision Level 2 The main success scenario
• Precision Level 3 The extension conditions
• Precision Level 4The extension handling steps

Source Writing Effective Use Cases
36
Executive Summary

• What matters is not that we finish, but
• how we finish the Use Cases.