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