Re: [re-online] Suggestion to "Definition of Scenario technique".
--part1_31.35487b8d.2b9c042f_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hi, all,
Alistair here... I was more or less sent here to peek in on this discussion
as it touches on use cases . . . sorry for intruding --
Just to start with, I should say I agree with most of what's been written in
the last few days:
- use cases are only one part of a system requirements picture
- people should be told that loud and clear and told where they start and
end being applicable
- people try to use them for all sorts of requirements for which they are
not suited (e.g. UI design, data format description, business rule
description, etc.)
- they are a particular instance of "scenario-based" form.
- they describe system usage
- creating a use case is "design" in the sense that whoever is doing the
creation is removing options and making decisions
- writing down a use case is "documenting" the decisions that have been
made, however and whenever they got made.
So that's mostly all just stuff I've seen you write anyway.
Here's how I teach use cases:
- A use case is a "form" of writing, just as is an outline, a table, a FSM,
a sonnet, a haiku, etc. As such, it has areas of applicability. It happens
to be good at describing branching behavior (the main path / alternate paths
format), and therefore should be considered whenever that shows up.
- It happens that that shows up in describing inter-actor behavior, and so
it gets appreciated in process reengineering documents, system behavioral
requirements documents, and occasionally in system design documents
(describing how subsystems collaborate to respond to an external event). Out
of those, there are other reasonably competing forms of writing for all but
the system behavioral requirements, and so UCs get most widely used for
those.
- A use case is a collection of scenarios, organized as one main one and a
collection of what someone else called "patches" to that one. I occasionally
say that the interaction set is a directed graph - a 2D structure - that we
slice in a particular way and glue together onto a 1D structure.
- A use case's scenarios are held together by their being related to a
particular (usually external) actor's goal with respect to the system under
discussion.
- More generally, a use case captures the behavioral portion of a contract
between stakeholders in the system's behavior. Thus, the IRS or SEC or FTC
becomes a stakeholder in the behavior of an ATM, even though none of those
organizations ever directly use an ATM.
- Among the other formats of writing, tables most naturally fit together
with use cases, and the writers should look for ways to simplify their
writing by combining tables into use cases, or linking use cases to tables.
Example: putting a financial instution's products online. There are hundreds
or thousands of products. For very many of them, the generic description of
interactions is common, and the differences are most naturally handled
through (large) tables relating to the product set.
I hope some of this is useful to you. I hope not to intrude on your
discussion too much.
Alistair Cockburn
President, Humans and Technology
Program Director, Agile Development Conference
(http://AgileDevelopmentConference.com)
Author of
"Surviving Object-Oriented Projects" (1998)
"Writing Effective Use Cases" (Jolt Productivity Award 2001)
"Agile Software Development" (Jolt Productivity Award 2002)
Contact Information:
http://alistair.cockburn.us
alistair.cockburn@acm.org
1814 E. Fort Douglas Circle
Salt Lake City, UT 84103
Work Phone: 801.582-3162
Fax: 775.416.6457
"La perfection est atteinte non quand il ne reste rien a ajouter,
mais quand il ne reste rien a enlever." (Saint-Exupery)
--part1_31.35487b8d.2b9c042f_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<HTML><FONT FACE=3Darial,helvetica><FONT SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=
=3D"Arial" LANG=3D"0">Hi, all, <BR>
<BR>
Alistair here... I was more or less sent here to peek in on this discussion=20=
as it touches on use cases . . . sorry for intruding --<BR>
<BR>
Just to start with, I should say I agree with most of what's been written in=
the last few days:<BR>
- use cases are only one part of a system requirements picture<BR>
- people should be told that loud and clear and told where they start and e=
nd being applicable<BR>
- people try to use them for all sorts of requirements for which they are n=
ot suited (e.g. UI design, data format description, business rule descriptio=
n, etc.)<BR>
- they are a particular instance of "scenario-based" form.<BR>
- they describe system usage<BR>
- creating a use case is "design" in the sense that whoever is doing the cr=
eation is removing options and making decisions<BR>
- writing down a use case is "documenting" the decisions that have been mad=
e, however and whenever they got made.<BR>
<BR>
So that's mostly all just stuff I've seen you write anyway.<BR>
<BR>
Here's how I teach use cases:<BR>
- A use case is a "form" of writing, just as is an outline, a table, a FSM,=
a sonnet, a haiku, etc. As such, it has areas of applicability. It ha=
ppens to be good at describing branching behavior (the main path / alternate=
paths format), and therefore should be considered whenever that shows up.&n=
bsp; <BR>
- It happens that that shows up in describing inter-actor behavior, and so=20=
it gets appreciated in process reengineering documents, system behavioral re=
quirements documents, and occasionally in system design documents (describin=
g how subsystems collaborate to respond to an external event). Out of=20=
those, there are other reasonably competing forms of writing for all but the=
system behavioral requirements, and so UCs get most widely used for those.<=
BR>
- A use case is a collection of scenarios, organized as one main one and a=20=
collection of what someone else called "patches" to that one. I occasionally=
say that the interaction set is a directed graph - a 2D structure - that we=
slice in a particular way and glue together onto a 1D structure.<BR>
- A use case's scenarios are held together by their being related to a part=
icular (usually external) actor's goal with respect to the system under disc=
ussion.<BR>
- More generally, a use case captures the behavioral portion of a contract=20=
between stakeholders in the system's behavior. Thus, the IRS or SEC or FTC b=
ecomes a stakeholder in the behavior of an ATM, even though none of those or=
ganizations ever directly use an ATM.<BR>
- Among the other formats of writing, tables most naturally fit together wi=
th use cases, and the writers should look for ways to simplify their writing=
by combining tables into use cases, or linking use cases to tables. E=
xample: putting a financial instution's products online. There are hundreds=20=
or thousands of products. For very many of them, the generic description of=20=
interactions is common, and the differences are most naturally handled throu=
gh (large) tables relating to the product set.<BR>
<BR>
I hope some of this is useful to you. I hope not to intrude on your discussi=
on too much.<BR>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>
Alistair Cockburn<BR>
President, Humans and Technology<BR>
Program Director, Agile Development Conference<BR>
(http://AgileDevelopmentConference.com)=
<BR>
<BR>
Author of <BR>
"Surviving Object-Oriented Projects" (1998)<BR>
"Writing Effective Use Cases" (Jolt Productivity Aw=
ard 2001)<BR>
"Agile Software Development" (Jolt Productivity Awa=
rd 2002)<BR>
<BR>
Contact Information:<BR>
<BR>
http://alistair.cockburn.us>
alistair.cockburn@acm.org<BR>
<BR>
1814 E. Fort Douglas Circle<BR>
Salt Lake City, UT 84103<BR>
<BR>
Work Phone: 801.582-3162<BR>
Fax: 775.416.6457<BR>
<BR>
"La perfection est atteinte non quand il ne reste rien a ajouter,<BR>
mais quand il ne reste rien a enlever." (Saint-Exupery)<BR>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></HTML=
>
--part1_31.35487b8d.2b9c042f_boundary--
To send a message to this mailing list send it to re-online@it.uts.edu.au.
To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the
message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6
: Mon Mar 10 2003 - 09:00:09 EST