Re: Fwd: Monica's stuff

Steve Ross-Talbot wrote:

> Dear Monica,
>
> Martin and I spent quite a while on the requirements document in 
> Dublin a week ago. One thing we did after our meeting was go back to 
> your usecase which was included in the last version of the reqdoc.
>
> Our take on the use case is documented below. We believe there to be 
> one fairly important requirement that is not covered in the document 
> at all. As such we have suggested a variation on usecase 2 to 
> incorporate this requirement.

mm1: I just spoke with Abbie Barbir re: above. Here is my response:

    * We'll continue to discuss broadcast related requirements. I don't
      believe we need to capture it any more fully with my case.
    * Role changes or reversal (in original list of requirements 10 Feb
      2004) are related to business semantics and do not need to be
      included here.
    * Abbie has captured one requirement that has to do with dynamic
      changes during the entire choreography lifecycle.
    * /RE: "See above since this is simply a case of tagging
      sub-choreographies with descriptive names which may have no value
      other than at the business  level. Although it might be nice to
      think of them as having unique names (aka a URI)."
      /
          o I agree that the naming requirement may only be relevant at
            the business semantic level and could be provided by the
            choreography.

Thanks.

> .......
>
>> Variation
>> ------------
>> A buyer is in communication with various suppliers who are in turn in 
>> communication with various manufacturers. At the order placing stage
>> between supplier and manufacturer the supplier places orders with 
>> several of the manufacturers in parallel with some delivery date checks
>> with the manufacturer. When the order is placed the QA function 
>> discovers a problem with one of the manufacturers. They don't want to 
>> cancel
>> the order unless the situation cannot be resolved within 2 weeks. 
>> From a business perspective the supplier want to suspend further 
>> activity with
>> the specific manufacturer until the issue is resolved. From a CDL 
>> perspective this can be modeled as part of the overall external 
>> observable
>> behaviour. All that should be required is to make it explicit in the 
>> CDL description that this is part of the QA choreography (a named sub
>> choreography) for the purpose of clarity and possibly so that 
>> business tools may extract such information for auditing or 
>> monitoring purposes.
>>
>> From Monica's use case (for requirement 1):
>>
>> 3.     Once the assessor(s) has(ve) evaluated the credit information, 
>> a risk assessment is provided to the approver.
>>
>> a.     If a separate interaction is required, this is a sub-process 
>> of the risk assessment between the assessor and approver. [subprocess]
>>
>> b.     If credit information is missing to effectively provide a risk 
>> assessment, either, based on specific rules, either could occur:
>>
>>                                                 i.         Request 
>> for more information from the approver (and to the customer).
>>
>>                                                  ii.         Error 
>> and reply to the approver to reinitiate the process.
>> My take:
>>
>> See above since this is simply a case of tagging sub-choreographies 
>> with descriptive names which may have no value other than at the 
>> business
>> level. Although it might be nice to think of them as having unique 
>> names (aka a URI).
>>
>

Received on Monday, 1 March 2004 05:21:34 UTC