OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-uc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: semi structured use case details


As promised, here are some thoughts from my earlier email, on adding a bit
more structure on use case details.  Here is what I sent:
     - Risk Factors (eg frequency, impact of failure)
     - Case conditions (invariants, preconditions, etc)
     - Interactions, including success, alternative path and exception

In my view, there are 2 general approaches we could take:
1. keep these or similar high level categories
2. go to defined or suggested subcategories, eg for Interactions:

  - Success Path
    - Define Preconditions
    - Define Post conditions
  - Alternative Paths/Exception Handlers
   - Handler 1:
     - Define invariants
     - Define path
   - Handler 2:
     - Define invariants
     - Define path

I would propose that no matter whichever approach is chosen, fields should
not be mandatory but should serve as guidelines for semi-structured text.
Among other things, this would enable existing use cases/diagrams to be
submitted as is if they were already complete and free standing.

I have also attached some guidelines I personally like I have used before
(from LiveSpec).  If you like this approach, I can scour for a template of




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]