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

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").

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