Re: Requirements 1.0 - comments on D-UC-004

Jon Dart wrote:

> I am finding this use case (D-UC-004, Alternative paths based on 
> business rules) hard to follow. I think there are some good points in 
> there, but it really looks like there is >1 use case in this section, 
> which are not clearly distinguished. Also the text doesn't seem to 
> correlate very well with the diagrams. For example, the text talks 
> about a "quality check," but the diagrams show a step called "Handle 
> Questionaire". Also at one point a "Quality Coordinator" is mentioned 
> - this text implies to me that there's a third actor, in addition to 
> Buyer and Seller, but the remaining discussion only talks about Buyer 
> and Seller.
>
> I could nit-pick on the text and diagrams, but maybe it would be more 
> helpful if I tried to lay out clearly one or more of the use cases I 
> think are in this section.
>
> One of them is this (I'm taking the existing text and stripping out 
> bits that don't apply, at least as far as I can tell):
>
> "The seller's view of the ordering process is:
>   1. Pick a product
>   2. Possibly apply a quality check
>   3. Pay for a product
>   4. Possibly apply a quality check
>   5. Ship the product.
>
> Sometimes the quality checks are added to the ordering process, and 
> sometimes not. For example, (I'm guessing here, but based on some 
> industry experience) some Buyers might have a standing agreement with 
> the Seller that all products pass a quality check before shipment, 
> while others would not have such an agreement and the check could be 
> omitted (this corresponds to section 3.2.4.6, "Flow of events").

mm1: Jon, actually there are a few inferences here that are potentially 
lost if you use the alternate .gif you provided. To explain:

    * An agreement is understood prior to entry.
    * At entry, business rules can be applied or the rules can be
      applied dynamically during the process execution:
          o Parallel processing - A dependency exists and the parallel
            processes are combined at the end (quality check applied
            prior to completion).
          o Dependency: See ordering process Jon specifies above
            (quality checks used as a subprocess). Note, that business
            rules are applied at entry.
          o Dynamic: See ordering process Jon specifies above where the
            quality check may or may not be applied during process
            execution.

Therefore, the drawings could be updated.  The simplification Jon did 
only reflects part of that.

>
> Another, related use case is this: in some cases where a check might 
> normally be performed, the Buyer might request that the Seller omit 
> the quality check, in order to be able to ship faster.
>
> Together, these lead to a requirement that the choreography flow is 
> able to be altered, or one or more alternate flows selected, based on 
> the identity of a participant, or based on a request to do so (which 
> might be conveyed here as part of the incoming purchase order).
>
> See attached diagram.
>
> I think this is much clearer. However, it does leave out some bits 
> from the original diagrams/text - but like I said, I think it's making 
> multiple points, with multiple scenarios. Possibly some of the ideas 
> I've omitted could be written up in a separate use case.
>
> --Jon
>
> ------------------------------------------------------------------------
>

Received on Monday, 28 July 2003 15:02:35 UTC