This document describes the key features and requirements for a vehicle. It states that the product shall have a gas engine, four wheels with rubber tires, a steering wheel, and a steel body. It also notes the product should have high torque, large wheels, high ground clearance, and be able to haul heavy cargo.
3. The product shall have a gas engine.
The product shall have four wheels.
The product shall have a rubber tire mounted to
each wheel.
The product shall have a steering wheel.
The product shall have a steel body.
6. The product shall have a gas engine.
The product shall have high torque.
The product shall have four large wheels.
The product shall have high ground clearance.
The product shall have a tough body.
The product should be able to haul heavy cargo.
8. Verbal communication?
Comprehensible by everyone?
Right size for planning?
Work for iterative development?
Encourage deferring detail?
Encourage participatory design?
Build up tactical knowledge?
8
10. Not Detailed.
Defers details.
Tool for
implementing
not just
documenting
A story is a promise of a conversation
--Mike Cohn, “User Stories Applied”
User
Stories
Verbal
Communication
Reminder
10
11. Written in this format: As an X , I want Y, so that Z
Written from the user perspective
Should NOT specify implementation
12. Lightweight documentation
To be able to code without performing business analysis
Context for the story requirement and actionable content
12
15. Format: Given <>, When <>, Then <>
Defines what has to be built to implement a
story
Defined by the customer, QA and analysts
15
17. Independent
Negotiable
Keep stories short & business language
focused
Seek a level of granularity that can be
completed in a few days
Valuable
Estimable
Small
Do not include implementation details
Testable
Do not stop talking
17
23. EMR System > Clinical Documentation > Encounter
Management
EMR System > Messaging Center > View Messages
As An XYZ I want to edit information associated with a patient
record so that it can be corrected.
24. 181 - As a physician I want to manually correct information
associated with a patient's record so that patient records are
accurate
181.1 – As a physician I want to be able to change encounter
information and mark entry as an error if applicable,
entering reason(s) why information has been erroneous so
that patient's medical record is accurate.
181.2 – As a provider I want to be able to reassociate
associated patient information (while retaining history for
original patient) so that the patient's medical record is
accurate.
25. 183 - As a physician I want to manually associate messages
that can't be automatically associated with a patient's record
183.1 - As a physician I want to be able to create a sticky
note message so that I can share information with
interested parties
183.2 - Send message
183.3 - As a physician I want to be able to forward messages
to interested parties so that I can send my messages to them
26. Title
Send a Message
Story
As a physician I want to be able to forward messages to interested parties so that I can send my messages to
them
Context (Some portions Out of Scope for this story)
The user will be allowed to create a new message, which may or may not be attached to patient details, in story
183.1 This story relates to the validation and sending of that message. It also includes recording the fact that
the message was sent, for later retrival/display with story 171.2 (View sent sticky note message). Note that, for
the purposes of this story, sending tasks with attached due dates and/or recurrence (created in story 193) are
NOT in scope.
Acceptance Criteria:
GIVEN (THAT)
I have created a sticky note
message with a valid individual
recipient and no attached patient
I have created a sticky note
message with a valid individual
recipient and an attached patient
that the recipient is NOT allowed
to see
WHEN
I request the
message to be
sent
I request the
message to be
sent
THEN
Then the message is delivered to the
recipient's message queue and added to the
sender's sent items
I see an error message informing me that the
recipient cannot view the patient
AND
The message will not be added to the
recipient's message queue or added to the
sender's sent items
Out of Scope
183.1 - Create Message
171.2 - View Sent Sticky Note Messages
New - Allow an unsent message to be saved as a draft message
Open Items:
1.
Is auditing in scope for this story?
Auditing is done when a patient is loaded. No additional auditing is required on message send.
As comical as it may come across, at some point we have all had similar conversations. User stories help these situations.
It’s a myth that requirements have the right level of detail. It’d be a herculean task to create such a requirement. It’s a grocery list, but you don’t have the recipe.
It’s a myth that requirements have the right level of detail. It’d be a herculean task to create such a requirement.
It’s a myth that requirements have the right level of detail. It’d be a herculean task to create such a requirement.
It’s a myth that requirements have the right level of detail. It’d be a herculean task to create such a requirement.
Stories are written such that they convey the gist with simplicity. Just as this picture does. Common knowledge isn’t documented, titles are self-descriptive.
Difference between use cases and stories: - Longevity - Use Cases are more prone to include details of the user interfaces. With stories, the user interfaces will come up during the conversations with the customerA user story is similar to a single scenario of a user caseA use case is a generalized description of a set of interactions between the system and one or more actors, which could be either a user or another systemScope differenceStories are kept smaller in scope for the purpose of schedulingDifference in level of completenessStory card + acceptance tests = use case main success scenario – James GrenningWritten for difference purposeUse cases are written for both customers and developers to read and agree to on a “design by contract” basisUser stories are written to facilitate release and iteration planning, and serve as a placeholder for conversations about the user’s detailed needs
EMR System: Communication within a practice and between practice and the patient is the single most important element of a good EMR system. Patient communication involves appointment scheduling, obtaining histories (medical, social, financial, etc.), receiving incoming messages from labs, etcEMR System > Messaging Center > View MessagesEMR System > Clinical Documentation > Encounter ManagementAs an XYZ I want to edit information associated with a patient record so that it can be corrected.
181 - As a physician I want to manually correct information associated with a patient's record that is incorrectly associated with a patient's record 181.1 – As a physician I want to be able to change encounter information and mark entry as an error if applicable, entering reason(s) why information has been errored so that patient's medical record is accurate. 181.2 – As a provider I want to be able to reassociate associated patient information (while retaining history for original patient) so that the patient's medical record is accurate.
183 - As a physician I want to manually associate messages that can't be automatically associated with a patient's record 183.1 - As a physician I want to be able to create a sticky note message so that I can share information with interested parties 183.2 - Send message 183.3. - As a physician I want to be able to forward messages to interested parties so that I can send my messages to them 184.1 - As a physician I want to be able to forward messages to interested parties so that I can send my messages to them