| Panel | ||
|---|---|---|
| ||
Suggest user story > use case mapping User story captures the full problem that needs to be solved. Use cases describe the specific combination of role/task/outcome that fulfill the user story “As a <person in this role> I would like to <accomplish this> so that i can <do this>. “ bonus points for “unlike now <where I have this issue> Use case mapping Breakdown tasks like search | select | add new | edit | delete |
| Panel | ||
|---|---|---|
| ||
| One useful way to shake out use cases is to think in terms of “happy path” - where everything goes smoothly and the user behaves perfectly well, and “sad path” where the user does something not intended or otherwise something will go wrong. |
...
Use cases are NOT system requirements. E.g. “the system displays the patient’s lab results sorted by most recent first” is NOT a use case.
Examples of Use Cases:
Prescribing-Dispensing Use Cases
WHY Use cases?
Use cases allows an analyst with no detailed or technical knowledge of current system to document the user’s needs
Use cases force the analyst to think specifically about the user’s needs without worrying about system constraints or design considerations, even for analysts with extensive knowledge of the system.
Use cases are easily understandable by everyone
Use cases are easily reviewable by users or other stakeholders