[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel-uc] Input on scenarios
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.