User Stories and Use Cases
- David DeSimone
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
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.
What is a Use Case:
A use case is a description of the ways in which a user interacts with a system or product. E.g “A clinician would like to cancel a prescription for a patient that has not been filled”
A use case may establish success scenarios or failure scenarios
Use cases are written from the user’s (the “actor”) point of view
Each actor (any role of users that interact with the system) may have a set of their own use cases. Examples of actors:
Clinicians
Pharmacists
Data Managers
Etc...
Use cases should be limited to one interaction at a time. E.g. a use case such as “Doctor views the patients lab results and orders additional lab tests” should be broken up into multiple cases.
* Note that there is a more formal way of documenting use cases which includes preconditions, triggers etc... if we would like to use these in a more robust way. There is tons of documentation online available.
What a Use Case is NOT:
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