Re: [wsbpel-uc] Input on scenarios

[Monica Martin <monica.martin@sun.com>]

Sally St. Amand wrote:

> Harvey and other UC subgroupies-
>
> As a follow on to my earlier email I am attaching a template that I 
> propose we discuss at our next subgroup telecon call. Harvey, I did 
> not know if you intended to take additional steps beyond what you have 
> done (& are doing) on the usage scenarios.
>
> As we discussed, use cases will emanate from the scenarios. Some of 
> which we already have; for example the Simpl EB. If we are going to 
> solicit use cases from a broad audience we will need a template as to 
> what we need.
>
> I took the template John developed, added in elements from the WS-I 
> submission, the doc Ben sent out earlier, et al and constructed this 
> template.
>
> First and foremost it needs to be understandable to someone who 
> stumbles on to the BPEL TC website and thinks they have a contribution 
> to make. If the template doesn't meet that test we need to make it so.
>
> I labeled it as I did because one of the perspectives we need to make 
> sure doesn't get lost is "usage centered design" and testing the spec.
>
> As I said my focus was on getting a format we all think will do the 
> job of soliciting examples and serving up the examples to the full TC. 
> Based on the work you are doing, a template and processes we have 
> already described, e.g. Voting on Use Cases, we could have a 
> methodology for acting that we can present to the TC? Including once 
> the subgroup agrees on the template, load in an actual (the Simple EB 
> seems prime).
>
> Also, a thread amongst ourselves to get a document more refined by 
> next Monday's call might save some time on the call.
>
> Sally
>
>  
>
mm1: First, thank you for doing this Sally.  Secondly, on the template 
as provided:

    * Suggest alternate paths or flows not just outcomes. The use case
      may have some different events that impact the outcome. We need to
      document both.
    * May be associated with 0...n issues.
    * May also be associated with other use cases and usage scenarios
      (overlaps likely will occur).
    * Suggest you separate any notes/assumptions and requirements
      section.  Do we perceive the requirements to be only non-functional?

Thanks.