Again, unfortunately I cannot attend
today's meeting. I think the challenge that Scott puts in front of us is
how do we get clarity and also move along in our attempt to meet the meaningful
target dates. There is no doubt in my mind that the target dates are
meaningful and critical to the success of this effort. If we do not meet
them, I fear we will lose the support of the court community as represented by
their professional organizations.
Getting court filing in blue functionally
wrong or functionally unexplainable from any RFP writers standpoint would be as
more far more devastating.
I would recommend, that we continue with
our plans for the technical committee meeting next week, where we will begin
focusing on design. But, when I say that we are focusing on design we are
setting the framework and assigning responsibilities for design work. I
further recommend that we use the published draft of the requirements that will
come out as a result of today's meeting as the baseline for the design
discussions.
I firmly believe, that one more pass of this
document taking into account all the good comments received including Scot' as
will leave this in a better position for getting the design right. The
challenge, will be finding the resources to do this last pass.
Please see my comments below.
Regards,
Don
Donald L. Bergeron
Systems Designer
LexisNexis
donald.bergeron@lexisnexis.com
O 937-865-1276
H 937-748-2775
M 937-672-7781
From: Scott Came
[mailto:scott@justiceintegration.com]
Sent: Monday, April 18, 2005 8:06
PM
To: courtfiling-reqts@lists.oasis-open.org
Subject: [courtfiling-reqts]
Feedback on Blue use cases: general
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[Bergeron] agree
* 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.[Bergeron] I agree. The system under
design construct, in the assignment to each use case is important for
readability.
3. Define the "type" attribute of each use case, and define all
allowable values[Bergeron] please define what you are specifically meaning by
type
4. Minimum guarantee should not be optional or conditional[Bergeron]
What I'm
hearing you say he is for example: that if a filer files to a court in minimum
guarantee of a receipt from that court cannot be a minimum guarantee, since the
filing may never arrived at court! The minimum must be an absolute true
minimum.
5. All guarantees should be testable (this will be very important to
implementers)[Bergeron] This is one of the basics.
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.)[Bergeron]
Agree
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.)[Bergeron] Agree
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.[Bergeron] Scott, this is very important point.
We must be aware and consider that all MDEs are actors and, at some point, all
actors could be MDEs.
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