User Stories and Use Cases

Owned by David DeSimone
Last updated: Dec 21, 2022
2 min read



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