courtfiling-reqts message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Feedback on Blue use cases: general
- From: "Scott Came" <scott@justiceintegration.com>
- To: courtfiling-reqts@lists.oasis-open.org
- Date: Mon, 18 Apr 2005 17:06:06 -0700 (PDT)
I have some comments on wd-LegalXML-Requirements-08 (April 4, 2005).
Before I get into them, let me echo
the sentiment of previous reviewers that this document (and the work and emerging consensus behind it) will become a
good foundation for the Blue electronic court filing specification. I appreciate the hard work of all who have
contributed to getting it this far.
Also, I have not been as engaged in the development of the document as
I would have liked. I have attempted to get through all the comments made on the list, but I was not at the SLC
face-to-face, and so if any of these comments are contrary to consensus reached there, please let me know and I will
revise or withdraw them.
In general terms, I am in agreement with a couple of points that I took away from
posts by Shane and Rex, specifically:
* There are some sections of the document more mature than others,
and therefore some areas are ready for moving forward while others likely need more work
* In many ways the
document gets into too many implementation (white-box) issues
Also, my own general observations are:
* Echoing a comment by Roger (but with a more technical perspective), I think it would be helpful in general
to define some of our technical terms better. Terms like "MDE" and "non-functional requirement",
and use case terminology would benefit from clear definition
* In general, I find the use cases fairly difficult
to read and follow (perhaps I am representative of a reader who hasn't been as engaged in the discussions around
previous drafts, and am therefore a good usability test case). I think we should select and define a use case form,
and stick with it everywhere. I would suggest that we not invent one...rather, we should use something like Alistair
Cockburn's use case guidelines (which is probably as close to a documented and accepted best practice as we're going
to get.)
Some specific form issues that I believe would help usability are:
1. Define actors
separately, in a separate section, rather than defining them in each use case (the use case should just name the
actor)
2. Clearly define a system-under-design in each use case (Cockburn calls this "scope"),
even if it is the same in every use case. This is critical. An example is 4.1.1 (line 729), "Submit Filing
using Filing MDE". Is there another way to submit a filing? On line 731, we have a "filer's
process"...what is that? In step 1 of the MSS, we have "filer sends a Filing Message to the Filing MDE,
which sends the message to the Clerk Review MDE." So, what is the thing in scope here: the Filing MDE or Clerk
Review MDE? These use cases--whether for the "efiling system" as a whole, or specific MDEs--are
requirements that implementers will want to implement in their products (or courts will want to put into their RFPs.)
The "efiling system" use cases will be of only contextual value to the implementer who just wants to
specialize in one MDE (or component...sorry); some of the MDE use cases may be irrelevant to the vendor (or court)
interested in selling (or buying) a single, monolithic solution. There is a need for both kinds of requirements--we
agreed on that in December; we should just be more specific in naming what the scope of each use case is, so it's
clear to the implementer (or buyer) what the requirement applies to.
3. Define the "type"
attribute of each use case, and define all allowable values
4. Minimum guarantee should not be optional or
conditional
5. All guarantees should be testable (this will be very important to implementers)
6. A consistent structure should be used for scenario steps; something like "actor does X", "system
does Y", "actor does Z", and so on. In a summary level use case, the verbs are typically other
(user-goal level) use cases; in user-goal level use cases, the actions are "black boxes" representing either
information exchange or integrated business process (or both). Cockburn has all kinds of useful guidelines on how to
structure this prose precisely so it can be more normative and testable, which again will be appreciated by
implementers who haven't been at our table (and even those that have :). It is important, for user-goal level use
cases especially, that the actions (the direct object of the verb) be implementation-neutral, only indicating the
business purpose and not the implementation of what the system will do. (I suspect this is some of what Rex was
getting at.)
7. In the "human-oriented" use cases (section 2) it seems that sometimes MDEs enter
the fray, and when they do the "client" or "requesting" MDE is called a "process". This
is confusing. I missed the definition of what a "process" is, so maybe that would help. But in any case,
it is very confusing to implementers to mix up the "efiling system" that actors interact with and individual
MDEs (what we used to call components) that other MDEs interact with. (Yes, humans can interact directly with MDEs,
but I think it will make life difficult on implementers (or at least some implementers with some kinds of business
models) if we mix these concepts in a single use case without using clear language to describe what's going on.)
8. In general, especially in integrated systems like the one envisioned by Blue, it is dangerous to assume
actors will be humans. Yes, yes...eventually all information systems have to produce value for people, somewhere.
But in many cases, it is conceivable that in some business models our use case actors will be software agents rather
than humans. The language in the introduction (lines 99, 110) and implications elsewhere in the document (e.g., lines
125, 128) seem to imply a bias against this. My suggestion would be to soften that language, and to define actors as
"roles with goals" rather than the traditional human players of those roles. Some of their names may
change, and we may look at the use cases a little differently, but in any case I think the use cases would be
cleaner.
9. A clearer statement in the introduction as to how we expect this document to be used would be
helpful. We could then test the document by actually putting it to some of those uses (at least in a simulated
sense.) The current introduction explains what the document is, but not why it is needed, who the audience would be,
etc. More specifically, is this document intended to be normative? Will someone or something be seeking to be
"compliant" with this document in some way?
I have some specific comments on the non-functional
requirements that I will post under separate cover.
Thanks all.
--Scott
Scott Came
Principal Consultant
Justice Integration Solutions, Inc.
Olympia, Washington
scott@justiceintegration.com
http://www.justiceintegration.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]