courtfiling-blue message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: User Use Cases--comments
- From: "Scott Came" <scott@justiceintegration.com>
- To: courtfiling-blue@lists.oasis-open.org
- Date: Tue, 11 Jan 2005 17:50:42 -0800 (PST)
Blue Drafting Subcommittee Members:
(It feels like I should be
submitting these comments to the Requirements Subcommittee list, but I'll
do so to this list, since it's where the document was posted...)
I believe the vision for the "user use cases" was (Shane or
others, correct me if I'm wrong) to reflect the way in which a human user
interacts with (and derives value from) the e-filing system as a whole.
In other words, they are to describe the e-filing workflows from the
perspectives of human actors (in particular, filers and clerks, but
potentially others as well.)
These use cases are contrasted
with the "component use cases", which describe the interactions
between components in the Blue architecture. Component use cases will
actually be the basis for the specification, since compliance is an
attribute of components. That is, from the software vendor/implementer
point of view, the specification will need to define the required behavior
of components in the architecture, which components vendors will build to
the standard and offer to the marketplace.
Both sets of use
cases are valuable. The user use cases illustrate how Blue orchestrates
human-facing e-filing processes, which is useful to demonstrate its
relevance to potential users of those processes. The component use cases
tell implementers what to implement, and should ultimately "roll
up" to user use cases. (One advantage to using html to document the
use cases is that the user use cases can contain links to component use
cases, as a means of demonstrating the workflow.)
That said...
The "scope" (or "system-in-scope" or
"system-under-design") for user use cases should be Electronic
Filing System. (This is what I recall we decided to call the set of
components as a whole.) It should not be individual components. Also,
for user use cases, individual components should not be Actors (they
should always be human actors, or potentially software systems outside the
e-filing boundary.) Finally, the Goal of user use cases should not
reference components.
I suspect the only true user use cases in
the submitted document are: Filer performs AssembleFiling, Clerk performs
ReviewFiling, ??? performs QueryCourtRecord, and ??? performs
QueryCourtPolicy. (We still need some actor names here...no good ideas
spring to mind.)
The others listed are probably component use
cases, either supplementary to or in addition to those already defined on
the wiki.
Maybe it would be helpful, in framing these user use
cases, to step back for a moment and answer the question: What features
do we intend for Blue-compliant e-filing systems to provide, and to which
human users? That is, if we shrinkwrapped a Blue implementation, what
features would be described on the back of the box? Clearly:
assembling/submitting filings to the court, reviewing filings, and
performing information queries (of the court record). What else?
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]