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: comments on Blue Use Case Spec


A few comments on the document:

GENERAL - as stated on the call, I think that eliminating the components and focusing on pure use cases and interaction scenarios would be most advisable. Thus, Filing Review Component would disappear and there would be a "Review Filing" use case instead. This would be called by a "File" use case for example.

Line 57 - this section is called "Terminology" but it only lists the 4 components. I think if you want to define terms you should define the key terms found in the document, ie, filer, clerk, docket, court record, etc

Line 58 - not sure why the focus is on a filing assembler, some filings may not require any assembly at all, I think there should be a "filer" as an actor who interacts with a "create filing" and a "receive filing" use case.

Line 80 - why is definition bound to a component, this is restrictive, should simply state that a filer files a filing

Line 83 - same as line 80

Line 168 - I think some of the bullets under (b) filing data might be optional but does not appear so in this form

Line 197 - I disagree that the filing component should implement the filing acceptance logic, it is the filing reviewer that is the only arbiter of each filing, again this gets back to the use case view instead of the component view, let the implementor decide where and if they want to put stop filters in front of the court, it might be easier to submit the filing and see if it passes the filing reviewer.

Line 224 - says "clerk is signed on", I disagree with this realtime dependence on the clerk, the system should work in an off line mode as well, better to say "clerk is notified", this can be done asynchronously

Line 239-242 - this sounds like a different use case, not the Review component, should be a use case called "Filing Reciept" or something, these steps all have to do with getting a filing from a filer not the review process, that is a seperate use case in my mind

Line 242 - again, the word "displays" indicates an online scenario, this is not necessary in implementing such a system

Line 280 - reads "clerk indicates", this should read "Filing is marked as rejected" as this might be done automaticially by the system and not by the clerk

Line 286 - unclear on the meaning of this line

Line 317 - wording requires online connectivity, why is this required, payment can be processed off line


James Cusick
Software Engineering Manager
Wolters Kluwer

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