[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
Dallas, Ok. Seeing the components as functional features does make them make sense. I think where my confusion came in is with the user and wiki use cases such as below (p. 4): User Use Case Example: NotifyOfClerkReviewResults Actor: FilingReviewComponent Goal: Acting on behalf of the human Clerk, the FilingReviewComponent wishes to notify the FilingAssemblyComponent of the results of the clerk's review of a FilingMessage, so that the FilingAssemblyComponent can distribute this information to the original human filers. Wiki Use Case Example: ReceiveFilingConfirmation Success Guarantee: The FilingAssemblyComponent receives a FilingConfirmation containing the results of the previously initiated SubmitFiling transaction, including whether the Filing was rejected or accepted. It seems, with the filer, that they send the message from an assembly component to a service which delivers the message to the court. Wouldn’t the same procedure need to be mirrored in functional units for a message going back to the filer? It seems like the court would send the message back to the filer by the assembling of an XML package, even if a potentially rudimentary accept/reject notice, sending the message through a sending service to the filer who would then need to receive the message, review it’s contents, and potentially store the data of the message, just as the court did on it’s side. Even though the functions may have different significance levels depending on which side is performing the action, such as when the clerk reviews the filing versus the filer reviewing what is sent to them, in essence doesn’t a review of some form have to take place on both sides? This is an example of where I picked up the sense that the FilingAssemblyComponent was acting as an EFSP. If the FilingAssemblyComponent is a functional feature, as I believe it needs to be, why is it performing receiving and reviewing functions? Again, please excuse me if I’m misunderstanding the use cases, but I am trying to get a handle on them. Thank you for your response, Rex From: Dallas Powell [mailto:dpowell@tybera.com] 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: courtfiling-reqts@lists.oasis-open.org 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:scott@justiceintegration.com]
Blue Drafting Subcommittee Members: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]