In my environment, abstract design
elements of the level we are discussing are called MDEs Major Design Elements.
Component is reserved for a set of 1 or more functions packaged together to be
bound into a runtime application.
Regards,
Don
Donald L. Bergeron
Systems Designer
LexisNexis
O 937-865-1276
H 937-748-2775
M 937-672-7781
From: Dallas Powell
[mailto:]
Sent: Friday, January 14, 2005
4:09 PM
To: Rex McElrath;
Subject: Re: [courtfiling-reqts]
FW: [courtfiling-blue] User Use Cases--comments
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
