[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: semi structured use case details
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]