Thank you Scott,
I very much did want your feedback on the
risk calculation. I don't want the pursuit of the date to risk the integrity
of the deliverable. Court filing blue is just too important to risk it.
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: Tuesday, April 19, 2005
11:50 AM
To:
courtfiling-reqts@lists.oasis-open.org
Subject: RE: [courtfiling-reqts]
Feedback on Blue use cases: general
Importance: High
>> 3. Define the "type" attribute of each use case, and
define all allowable values[Bergeron] please define what you are
specifically meaning by type
In some of the MDE use cases (e.g., lines 638-639) there is a "type" attribute.
I was suggesting that we define what this attribute is, and also define the
range of allowable values. As it stands, the unfamiliar reader will
wonder what exactly a "transaction interface" is, for example.
(It's possible I missed this definition...if so, issue withdrawn.)[Bergeron]
I believe that
there's general consensus that we need to beef up our definition section.
Regarding Don's more general comments... I'm not sure it would take all
that long to improve the form of the use cases. It strikes me that the
basic functional content is there (though when the form is improved it might improve
our ability to find holes). It's more of a refactoring. Someone
familiar with the form we agree to should be able to re-craft the document in a
few days, I would guess. (I'm not necessarily volunteering, though I may
have some time later in May where I could help out.)[Bergeron] I truly hope that we can find a volunteer
to accomplish this. I cannot volunteer to my current workload and allocation.
We need to keep this task off the mainline of our team.
I agree with Don that design could probably proceed in the meantime, just with
slightly more risk. Frequent, open discussion about how the design is
going along with the requirements refactoring (should we decide to do it) could
mitigate that risk.[Bergeron] thanks of the feedback.
> 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
>
>