OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

courtfiling-reqts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.





Donald L. Bergeron
Systems Designer
O 937-865-1276
H 937-748-2775
M 937-672-7781

From: Dallas Powell [mailto:dpowell@tybera.com]
Sent: Friday, January 14, 2005 4:09 PM
To: Rex McElrath; courtfiling-reqts@lists.oasis-open.org
Subject: Re: [courtfiling-reqts] FW: [courtfiling-blue] User Use Cases--comments




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.



----- Original Message -----

From: Rex McElrath

Sent: Thursday, January 13, 2005 1:40 PM

Subject: [courtfiling-reqts] FW: [courtfiling-blue] User Use Cases--comments




      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. 









Rex McElrath

Administrative Office of the Courts

244 Washington St. SW

Suite 300

Atlanta, GA  30334




From: Scott Came [mailto:scott@justiceintegration.com]
Sent: Tuesday, January 11, 2005 8:51 PM
To: courtfiling-blue@lists.oasis-open.org
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?


Scott Came
President and Principal Consultant
Justice Integration Solutions, Inc.
Olympia, Washington

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]