Rex,
Our product does exactly as you stated, acts as a
box that can sometimes be an EFSP and sometimes an EFM. I call it two-way
automation. In the meeting in Vegas one person objected to calling things
components, and we talked about just calling them functional features, and then
a component could have the functional features of a Receiving unit, or a review
unit, and so forth. Thus if you want the review process embedded in the
CMS, that is fine. I have worked with several CMS vendors and some
say they want that feature in the CMS for single sign-on management for clerks
and judges, but they are not in a position to handle it at this
time.
Dallas
----- Original Message -----
From:
Rex McElrath
To:
Sent: Thursday, January 13, 2005 1:40
PM
Subject: [courtfiling-reqts] FW:
[courtfiling-blue] User Use Cases--comments
Scott,
I agree with your points about the use
cases. I think the assembling/submitting filings and information
queries are key “features” provided. Taking assembling/submitting,
receiving/reviewing, and querying separately and in different combinations,
such as in query for a case number and assemble/submit a related document
based on the queried information, gives a good basic package for functions
that need to be performed. Unless specific storing/processing functions
are deemed within scope to be defined for the CourtRecord component, then for
the communications, the ones listed seem sufficient to describe possible
communications.
To the CF Blue
Requirements group,
In general, when looking over the wiki and the latest user use cases released
on the CFBlue subcommittee list, I keep getting the sense that the EFSP, EFM,
and CM concepts have somewhat been renamed and slightly abstracted into
FilingAssembly, FilingReview, and CourtRecord and we’re still at a level of
distinction among several specific pieces which gives us mostly a one way
street into the courts. It seems like the use case components start as
abstracted pieces, but then as they are defined fall back in line with the
older specific function EFSP, EFM, and CM/DM that we have tried to move away
from after the Seattle FTF when each end of the communications was deemed a
black box in which only the functions related to communications between black
boxes were to be defined.
A possible example of the above statements about the components seeming
to fall back to older terminology restrictions when being defined can be seen
with the “FilingReview” component from the wiki. For small
implementations, the review filings function will be beneficial as a distinct
and separate component, as it was found in many EFM scenarios, but larger
installations will likely customize their existing case management systems to
interact with a middleware to provide the review of the filings within the
case management system interface. Can the review function be either a
part of receiving the filing as a possible function that is performed or a
part of an extension to querying by the CourtRecord component of the
FilingReview component/EFM/middleware?
For example of this type of review setup, one court that we are working with
will possibly have the filings to come into a temporary db space that is
accessible by their case management system for them to be able to review and
accept/reject the documents from within their case management system.
Assuming that the case management system would fall into the realm of a
CourtRecord component would a situation like this violate the FilingReview
component use case on the wiki or the user use case of ReviewFiling?
Going from the way that the components seemed to be used in some of the
use cases, as being similar to the older EFM/CM terminology of being
specifically distinct components a situation like this would seem like it
would violate the use cases even though the distinct functions are provided
for, but with a mix of the components.
Also, could the components be mirrored on each side, for both filer and
court? If both the filer and the court can assemble/submit,
receive/review, store/process communications and query for information then
the specification is more in the lines of data exchange which will make
electronic filing more beneficial for filer and court. This would also
broaden the usefulness of e-filing/data exchanges to allow for communications
such as district attorney’s communicating with police as well as the
courts.
Please
let me know what you think and excuse any butchering of the terminology if I
have understood it incorrectly.
Thanks,
Rex
Rex
McElrath
Administrative Office
of the Courts
244 Washington St.
SW
Suite
300
Atlanta, GA
30334
404-657-9218
From: Scott
Came [mailto:]
Sent: Tuesday, January 11, 2005 8:51
PM
To:
Subject: [courtfiling-blue] User Use
Cases--comments
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
http://www.justiceintegration.com
