Minutes from 6/17 Use Case Conf Call

[jevdemon@microsoft.com]

Hello all,

Thank you for your time yesterday.  We will have a follow-up call Monday, 6/23 at 1 PM PT to discuss the following:

1) Follow up on action items assigned (see below).  
2) Plan for presentation of the Use Case process to the rest of the TC 

Call numbers and passcodes remain the same:
Start time: 1 PM PT, 4 PM ET
Toll-Free (US & Canada): 866-500-6738
Toll: 203-480-8000
Participant Passcode: 600345  

I have included below a brief review of yesterday's call below.  Please respond with any questions or concerns you may have.

Template discussion:
"expected outcome" should be renamed "Purpose"
Description should discuss expected impact on the spec
We need semi-structured section to describe use cases
We need to incorporate architectural diagrams into the descriptions
review the Web Services Architecture WG's sample use case form (forwarded to the group by Yin-Leng)
we should put each use case on a separate page with links to navigate from one page to another
The use case description section should be semi-structured, ensuring that the descriptions follow a common layout - this will make it easier to communicate use cases to the TC (Ben Bloch send some ideas out about this on 6/12)

General discussion:
Use cases will raise new requirements and/or issues
Each requirement should be tied back to a use case
George Brown has done some interesting work with the Supply Chain Council’s SCOR model that may be relevant to the TC
Use Case vs. Requirement:
A use case tells the story/scenario, while a requirement should be short/crisp & state how a problem should be solved

We discussed, and seemed to agree upon, a five step process:
Collect use cases from within and by soliciting external groups to build up the "Proposed" section
Describe the use case in detail using the template.  Each use case will be documented using the template by an owner/sponsor (presumably someone from this group, possibly another TC member).  The owner is responsible for initially promoting the use case to the rest of the TC via the mailing list (brief description with a link to the template).  The owner is also responsible for discussing and making a motion to vote on the use case at a TC conf call or F2F (see next step).  The TC then votes on whether a use case should be included or rejected.
If a use case is rejected, the owner assigns the appropriate status to it and ensures the description of the use case is moved to a “for possible later consideration” page (accessible from links on the use case description document).  If a use case is approved, the group presents a timeline to the TC for the work to be performed (the work may include others from within the TC).  The group then begins working on the use case.  This work will vary depending on the use case itself – some of this work may require building sample BPEL schemas while other work might require bits of code or other resources.  This is a pretty broad area – there is no easy way to categorize this step because it is dictated by the use case itself.
The findings/recommendations from Step 3 will be presented to the TC for consideration.  As stated earlier, the exact findings/recommendations will vary depending on the use case itself.  Some use cases may cause us to discover new requirements/issues which the TC would vote to adopt or ignore.  Other reports may simply require us to report our findings with no need for voting.  Regardless of the outcome, the reporting step is critical to keeping everyone informed.
If a use case generated new issues/requirements, the group will document these and submit them to Jeff’s team.  The owner of the associated use case is responsible for ensuring the use case description is moved to a “Completed” section of the Use Case document (accessible via links from the main page).

Please let me know if you need more details on the 5 step process and I will do my best to provide them – I would also love to have some help from anyone interested in helping to document this process.  

We ended the call with the following action items:

Ben will provide some ideas (via email) for the semi-structured sections of the use case descriptions.  This may be a follow-up to his 6/12 email).
Sally St. Amand volunteered to document the voting process (step 2)
Tony and Yin-Leng volunteered to write up some ideas about working with Jeff’s team to coordinate use cases and requirements/issues.
George offered to contribute some ideas around the terms and semantics associated with each step in the process described above.
Yin-Leng expressed a concern about knowing which parts of the spec have been exercised by a given use case.  We left this as an optional action item for her – if she has some specific ideas about how this issue can be addressed please share them with the group.
	
Again, please respond if you have any questions.

JohnE