Scott and all,
I’m sorry I had a conflict with yesterday’s
ECF TC conference call and missed this discussion of what we mean by a use
case. However, I am in general agreement with Scott on the two issues he
addresses, and would like to see us resolve these semantic issues quickly and
move on.
To paraphrase Scott, if we’re not using
the accepted definition of use cases (ala Jacobson and Cockburn), we should
call them something else. And we need to have some way of grouping the
use cases according to function. I don’t have a problem with the
term “component” but if we are not going to use that term, we need
to agree on some other term soon.
Jim
From: Scott Came
[mailto:scott@justiceintegration.com]
Sent: Tuesday, February 08, 2005
8:45 PM
To:
courtfiling-reqts@lists.oasis-open.org
Subject: [courtfiling-reqts] Use
cases, components, etc.
First of all, Tom or Eric, if this isn't the right list for
requirements methodology discussions, please let me know and I'll post it to
the right one. I thought the Blue Drafting SC list was just for focused
discussion regarding specific changes to proposed deliverable documents, and
that the Requirements SC list was for hashing out other issues. But lately
there has been a blurring of the lists, so feel free to point me to the right
place if I'm not in it.
I had some thoughts regarding the issues of use case form discussed on today's
call, but it was my phone causing static on the call (I think) so I wanted to
stay muted, plus I didn't want to derail the limited conference call time. So
I'll raise the issues here...
Issue #1: Use Case methodology
I think it's important to keep in mind that eventually, if we're successful,
our requirements will be read by implementers who have not participated in our
deliberations. They will primarily be interested in the formal specification,
but will look to the requirements for background.
As many of us know, most technicians and analysts mean something quite specific
when using the term "use case." It is a particular form of
documenting the behavioral requirements of something (usually but not always a
piece of software.) This form has been developed by Jacobson, Cockburn, and
others. There is some quibbling over just what should be in a use case, and
over how formal one should be, but there does seem to be consensus among the
principals that a use case should identify, at a minimum:
1. A system under design/analysis
2. A primary actor
3. A goal the actor wishes to achieve by using the system under design/analysis
4. A sequence of interactions between actor and SUD that results in the actor's
achievement of the goal
(Note that use cases are primarily a textual, not graphical, form. Jacobson's
use case diagrams can be useful for context, but the formal requirements need
to be textual.)
With our future broader audience in mind, I think we should either stick to
this basic form in writing our use cases, or we should call what we're
producing something else. Calling our requirements use cases but not including
all the parts could weaken our requirements model in the eyes of our audience,
and could confuse them.
In particular, I think it is important to label the system under
analysis/design...to give it a name. Maybe it's just "the system" or
"the e-filing system" or something vague, but it does need to have a
name. (And it should be noted that back in December the former requirements
subcommittee had some significant discussion over this issue, with the consensus
being that it should be called "the LegalXML System.")
I also think it needs a definition, in addition to a name. That definition will
tell our audience what is in and out of the scope of the standard.
Without naming an SUD, the first question readers ask will be, "for what
are these use cases the requirements?" I think that's a significant
question, and the answer should be clear, and it should be stated clearly in
each use case.
Issue #2: The need for components
My understanding has always been that Blue is intended to support the broadest
possible range of business models. (Perhaps this needs to be reconfirmed by the
TC?) It is certainly true that some business models will involve selling
products to customers that implement only the "externally facing"
behavior of Blue; that is, the Blue functions that are used directly by human
beings or external information systems (e.g., court CMSes or DMSes). Customers
who find this kind of solution attractive will likely not care much about the
internal "componentry" of the product, and will not find individually
defined components in the Blue standard very useful.
However, there are potential business models in which a vendor may wish to
specialize in implementing only certain components, and in doing so will expect
standard-compliant vendors of other components to interoperate in ways defined
by the standard. That is, I should be able to market a compliant Filing
Assembly component and have it interoperate with some other vendor's compliant
Filing Review component.
Of course, our "user use cases" are useful in supporting both models.
Whether the entire e-filing solution is purchased from one vendor or several,
there are still externally-facing behavioral requirements, and those need to be
documented.
But we need well-defined components, and requirements for them, if we are to
support the second business model, no? If I wish to go into business as a
vendor of the
component-that-sits-at-the-court-and-receives-filings-and-presents-them-for-clerk-review,
then I need to know what it means to make such a thing. As a customer, if I
purchase such a thing, and it says on the box (not literally) that it is a
Blue-compliant Filing Assembly component, then I need to know what that means.
Therefore, unless we intend not to support the second model (which I don't
think I've heard proposed), we need to continue down the path of defining
components and requirements for their interfaces.
I'm not wedded to the word "component," though again the old
requirements subcommittee debated this at some length and couldn't come up with
anything better. Regardless, whatever the name is, as long as we define it
properly somewhere, it shouldn't matter too much.
Thanks.
--Scott
Scott Came
President and Principal Consultant
Justice Integration Solutions, Inc.
Olympia, Washington
360-402-6525
scott@justiceintegration.com
http://www.justiceintegration.com