As I had initially mentioned the use of components as being
premature let me just state that I agree with Don that a component is a set of
classes and I would expect the focus of Blue to be on actors and their roles in
interacting with use cases which might be implemented in any number of component
configurations, that is, that the focus would not be on runtime
architecture.
regards,
james
James Cusick
Wolters Kluwer
From: Bergeron, Donald L. (LNG-DAY)
[mailto:]
Sent: Friday, January 14,
2005 4:31 PM
To: 'Dallas Powell'; Rex McElrath;
Cc: Bergeron, Donald L.
(LNG-DAY)
Subject: RE: [courtfiling-reqts] FW: [courtfiling-blue]
User Use Cases--comments
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
