courtfiling-reqts message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Use cases, components, etc.
- From: "Scott Came" <scott@justiceintegration.com>
- To: courtfiling-reqts@lists.oasis-open.org
- Date: Tue, 8 Feb 2005 20:44:30 -0800 (PST)
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]