courtfiling-reqts message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [courtfiling-reqts] Feedback on Blue use cases: general
- From: "Scott Came" <scott@justiceintegration.com>
- To: courtfiling-reqts@lists.oasis-open.org
- Date: Tue, 19 Apr 2005 08:50:17 -0700 (PDT)
>>
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.)
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.)
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.
> 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
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]