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

 


Help: OASIS Mailing Lists Help | MarkMail Help

courtfiling-blue message

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


Subject: 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
scott@justiceintegration.com
http://www.justiceintegration.com

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