OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

courtfiling-reqts message

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


Subject: RE: [courtfiling-reqts] Use cases, components, etc.


Scott and all,

 

I’m sorry I had a conflict with yesterday’s ECF TC conference call and missed this discussion of what we mean by a use case.  However, I am in general agreement with Scott on the two issues he addresses, and would like to see us resolve these semantic issues quickly and move on.

 

To paraphrase Scott, if we’re not using the accepted definition of use cases (ala Jacobson and Cockburn), we should call them something else.  And we need to have some way of grouping the use cases according to function.  I don’t have a problem with the term “component” but if we are not going to use that term, we need to agree on some other term soon.

 

  Jim

 


From: Scott Came [mailto:scott@justiceintegration.com]
Sent: Tuesday, February 08, 2005 8:45 PM
To: courtfiling-reqts@lists.oasis-open.org
Subject: [courtfiling-reqts] Use cases, components, etc.

 

First of all, Tom or Eric, if this isn't the right list for requirements methodology discussions, please let me know and I'll post it to the right one. I thought the Blue Drafting SC list was just for focused discussion regarding specific changes to proposed deliverable documents, and that the Requirements SC list was for hashing out other issues. But lately there has been a blurring of the lists, so feel free to point me to the right place if I'm not in it.

I had some thoughts regarding the issues of use case form discussed on today's call, but it was my phone causing static on the call (I think) so I wanted to stay muted, plus I didn't want to derail the limited conference call time. So I'll raise the issues here...

Issue #1: Use Case methodology

I think it's important to keep in mind that eventually, if we're successful, our requirements will be read by implementers who have not participated in our deliberations. They will primarily be interested in the formal specification, but will look to the requirements for background.

As many of us know, most technicians and analysts mean something quite specific when using the term "use case." It is a particular form of documenting the behavioral requirements of something (usually but not always a piece of software.) This form has been developed by Jacobson, Cockburn, and others. There is some quibbling over just what should be in a use case, and over how formal one should be, but there does seem to be consensus among the principals that a use case should identify, at a minimum:

1. A system under design/analysis
2. A primary actor
3. A goal the actor wishes to achieve by using the system under design/analysis
4. A sequence of interactions between actor and SUD that results in the actor's achievement of the goal

(Note that use cases are primarily a textual, not graphical, form. Jacobson's use case diagrams can be useful for context, but the formal requirements need to be textual.)

With our future broader audience in mind, I think we should either stick to this basic form in writing our use cases, or we should call what we're producing something else. Calling our requirements use cases but not including all the parts could weaken our requirements model in the eyes of our audience, and could confuse them.

In particular, I think it is important to label the system under analysis/design...to give it a name. Maybe it's just "the system" or "the e-filing system" or something vague, but it does need to have a name. (And it should be noted that back in December the former requirements subcommittee had some significant discussion over this issue, with the consensus being that it should be called "the LegalXML System.")

I also think it needs a definition, in addition to a name. That definition will tell our audience what is in and out of the scope of the standard.

Without naming an SUD, the first question readers ask will be, "for what are these use cases the requirements?" I think that's a significant question, and the answer should be clear, and it should be stated clearly in each use case.

Issue #2: The need for components

My understanding has always been that Blue is intended to support the broadest possible range of business models. (Perhaps this needs to be reconfirmed by the TC?) It is certainly true that some business models will involve selling products to customers that implement only the "externally facing" behavior of Blue; that is, the Blue functions that are used directly by human beings or external information systems (e.g., court CMSes or DMSes). Customers who find this kind of solution attractive will likely not care much about the internal "componentry" of the product, and will not find individually defined components in the Blue standard very useful.

However, there are potential business models in which a vendor may wish to specialize in implementing only certain components, and in doing so will expect standard-compliant vendors of other components to interoperate in ways defined by the standard. That is, I should be able to market a compliant Filing Assembly component and have it interoperate with some other vendor's compliant Filing Review component.

Of course, our "user use cases" are useful in supporting both models. Whether the entire e-filing solution is purchased from one vendor or several, there are still externally-facing behavioral requirements, and those need to be documented.

But we need well-defined components, and requirements for them, if we are to support the second business model, no? If I wish to go into business as a vendor of the component-that-sits-at-the-court-and-receives-filings-and-presents-them-for-clerk-review, then I need to know what it means to make such a thing. As a customer, if I purchase such a thing, and it says on the box (not literally) that it is a Blue-compliant Filing Assembly component, then I need to know what that means.

Therefore, unless we intend not to support the second model (which I don't think I've heard proposed), we need to continue down the path of defining components and requirements for their interfaces.

I'm not wedded to the word "component," though again the old requirements subcommittee debated this at some length and couldn't come up with anything better. Regardless, whatever the name is, as long as we define it properly somewhere, it shouldn't matter too much.

Thanks.
--Scott

Scott Came
President and Principal Consultant
Justice Integration Solutions, Inc.
Olympia, Washington
360-402-6525
scott@justiceintegration.com
http://www.justiceintegration.com



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