----- Original Message -----
Sent: Tuesday, February 10, 2004 12:36
PM
Subject: Re: [egov] Proposed Use Case
template
Hi Folks,
I hesitated about responding to the initial suggestion because there is
such a wide variance in the way use-cases are described in different contexts.
(And I have been hesitating a long time before deciding to be more active in
this TC, as a prospective member.)
I have seen more than three different kinds of use case descriptions in
the TCs in which I have participated. These have included word processing
documents, spreadsheets and Visio diagrams in addition to visual programming
tools. Also, I was thrown by the combination of a specific kind of use-case
diagram from UML combined with a set of textual elements that begin to
describe some very context-dependent categories into which it is assumed
specific use cases will fall. Unfortunately my own experience doesn't agree
with this approach because it starts with a structure and in my experience
processes don't occur that way even if a process seeks to create that kind of
organized structure as an end result.
I am concerned that these high level overviews can't capture adequately
how and where specific kinds of information is introduced into these
processes. I am not suggesting that these methods be dropped, but set aside
for the moment in favor of capturing "scenarios" drawn from actual experience
with the specific kinds of processes to be modeled. In other words, I would
rather see textual descriptions, for which a Word Template can be downloaded
from the "Business Scenarios" document directory at
http://www.oasis-open.org/apps/org/workgroup/wsrp/documents.php
where I suggest just downloading the first one in order to see the
template and an example of how it was used. While working on WSRP 1.0, we
developed 10-12 of these "Scenarios" then narrowed down the field to a few
that offered use-cases that appeared to capture the key ingredients we needed
to address in the specification and worked from there down to specifics for
the final. It was somewhat of a rigorous process and took more than 18 months,
but it worked fairly well.
I would prefer to see, say three different kinds of environmental impact
statements from different governments for different kinds of large scale
projects in different environments, such as oil pipelines, timber processing
plants and toxic waste treatment facilities, to chose just one area of
governmental concerns, and see where such projects develop common features
that can then be abstracted into the kinds of use-case models as I see being
developed here.
If what is being proposed fits the actual scenarios, then we will know
that we are grounded. Being grounded is more important, it seems to me, than
creating structures at this point, although I am sure that a great deal of
experience with "systems" has gone into this model, and it may well be
accurate and useful, but I can't tell that in the abstract.
Please take no offense, Farrukh, I hope it proves out that your model is
well drawn and fits many more instances than those I cite, but I have no
background that enables me to reckon that.
However, you have certainly defined an extremely important
consideration.
Ciao,
Rex
At 9:18 AM -0500 2/10/04, Farrukh Najmi wrote:
Hi Tim,
Thanks for these valuable
suggestions Tim. Some questions and comments below...
Tim Benson
wrote:
A useful use case template. I have several
minor suggestions, which, if accepted in full, would add one extra
heading, merge four and make minor changes to three others:
(a) Add
a heading "Scope, Goal and Context". This might replace or supplement the
present "Description", as well as "Exceptions", "Special Requirements" and
"Assumptions" (all of which are somewhat ambiguous terms, liable to be
used in different ways by different authors)
I find Description as more general and
descriptive than "Scope, Goal and Context". It is also more universally used
in practice. What do others think?
Exceptions are very distinct and
important a section. It is to list what can be some out-of-the-ordinary
paths or outcomes within the use case.
For example a use case to register
a new student in a course may have an identified exception that the student
has not paid their fees and therefor will
not be registered.
I
agree that "Special Requirements" and "Assumptions" are ambiguous. Maybe
they can be combined into one title: "Special Requirements" and
"Assumptions"?
(b) Suggest adding Cockburn's
classification of "High level", "User goal" and "Sub-function" to
categorise use cases into those which can be met using more than one "user
session", one "user session" or a small part of a "user session"
respectively.
I am not clear on above suggestion. On a
net search I
found:
http://www.dotnetcoders.com/web/learning/uml/diagrams/usecase.aspx
But
that does not explain what you meant. Can you post a link?
(c) Explicitly identify the primary actor
to whom the use case provides value, or initiates the use case - perhaps
add a phrase "(list primary actor first)".
Excellent suggestion. Will add this
phrase.
(d) Change "Pre-conditions" to
"Pre-conditions and Triggers" - it is often useful to identify a specific
trigger event especially in interoperability.
Good suggestions. Will do.
(e) Change "Priority" to "Priority and
Frequency of Occurrence" - these are two different
dimensions.
Priority is meant to be simple Low,
Medium, Hi distinction. There are many factors that may decide on priority
besides frequency of occurance.
Do you think we should list "Frequency of
Occurrence" as a separate title?
I will send a revised template for
use cases based on what we agree upon in the discussion on this thread later
this week. Team please share your
thoughts.
--
Regards,
Farrukh
To unsubscribe
from this mailing list (and be removed from the roster of the OASIS TC), go
to
http://www.oasis-open.org/apps/org/workgroup/egov/members/leave_workgroup.php.
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley,
CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email:
rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request