semi structured use case details

["Ben Bloch" <ben_b54@hotmail.com>]

UseCasers:

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
handlers

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:

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
these.

Thoughts?

Ben

LiveSpecs06V01_PreciseUseCases.pdf