This document discusses user stories and requirements elicitation. It defines user stories and explains the three parts - the card, conversation, and confirmation. The card is a simple statement written in a certain format. The conversation involves discussion to clarify and expand on the user story. The confirmation is a test case to validate that the goal of the user story is met. An example user story is provided for a video uploading feature on YouTube. Requirements and test steps are added during the conversation and confirmation parts. The document also discusses using user stories to capture requirements and ensure they are independent, negotiable, valuable, estimable, small, and testable.

1. Joint Application
Development (JAD)
Sessions: Requirements
Elicitation

2. The “Move to Agile” According to Dilbert
2

3. Joint Application Development
Wikipedia says:
Joint application design (JAD) is a process used in the
prototyping life cycle area of the Dynamic Systems
Development Method (DSDM) to collect business
requirements while developing new information
systems for a company. "The JAD process also includes
approaches for enhancing user participation, expediting
development, and improving the quality of
specifications."
3

4. Requirements Elicitation
Wikipedia says:
requirements elicitation is the practice of obtaining the
requirements of a system from users, customers and
other stakeholders.
4

5. Where and When Does This Process Occur?
5

6. What is a User Story
• A user story describes a small piece of system
functionality, in a simple and easy to read sentence.
• A well written user story will describe what the
desired functionality is, who it is for, and why it is
useful.
• There are 3 parts to a fully fleshed out user story.
• If you like marketing-speak, then you can call them
the “3 C’s”:
– The Card
– The Conversation
– The Confirmation

7. The Card
• A typical user story follows
one of these templates:
– “As a [user], I want [function],
so that [value]”
– “As a [Noun], I want [Verb], so
that [Business Goal]”
• We refer to this as “The
Card” because often they are
written on 3x5 bits of plain
card, usually to give a
physical constraint which
limits the possible length of
the story.

8. An Example from the Real World:
• Here’s a few hypothetical examples written for
YouTube. I’ve defined a “Creator” as someone
who contributes videos to the site, and “User”
as someone who just watches them:
• As a Creator, I want to upload a video
so that any users can have access to
my videos 24/7.
• As a User, I want to search for videos
by keywords so that I can find videos
that are relevant to my search
criteria.

9. The Conversation
• Think of the conversation as an open dialogue
between everyone working on the project, the
clients, and or the Stakeholders.
– Anyone can
• Raise questions
• Ask for things to be clarified
– The answers should be recorded down as bullet points on
the card for later reference
– It is also a stage where you can reevaluate your user
story
– Possibly split it into multiple stories if required
– This is not to be taken Personally

10. Conversation Example 1
• For example, we discuss the creator upload user story, and
decide that there are actually multiple things that can
happen, so we split them, and expand on them:
– As a Creator, I want to upload a video from my local machine so
that any users can view it.
• Examples of requirements from the User Story
– The “Upload” button shall be a persistent item on every page
of the site.
– <BR> Videos must not be larger than 100MB, or more than 10
minutes long.
– <BR> File formats must be .flv, .mov, .mp4, .avi, and .mpg.
– Upload progress shall be shown in real time.

11. Conversation Example 2
• As a Creator, I want to edit the video’s metadata while
a video is uploading, to save myself time.
• Examples of requirements from the User Story
– The system shall have editable fields that include Video
Name, description, tags, and privacy settings.
– Once saved, the system shall take the user to their
video’s dedicated page.

12. The Confirmation
• The confirmation is basically just a test case.
– A test case is a series of steps that a user must do to
achieve the User Story.
– A test plan is a collection of test cases.
– With full coverage of your system in your test plans, you
can easily test every core piece of functionality and tick
them off as you go through them.

13. Confirmation Example
• A test case for our YouTube example might look like
this:
– As a Creator, I want to upload a video from my local
machine so that any users can view it.
1. Click the “Upload” button.
2. Specify a video file to upload.
1. Check that .flv, .mov, .mp4, .avi, and .mpg extensions are
supported.
2. Check that other filetypes aren’t able to be uploaded.
3. Check that files larger than 100MB results in an error.
4. Check that movies longer than 10 mins result in an error.
3. Click “Upload Video”.
4. Check that progress is displayed in real time.

14. An Example from Our Real World:
The Role:
As a: Systems Administrator
The Action:
I want to:
configure the message that will be displayed when posting
attendance is restricted by Last earned date
The Goal/Benefit Achieved by the Action:
So that…(Benefit):
Instructors/Registrar can be alerted as to which faculty
member/department needs to be notified when attendance posting
may be rejected if they attempt to post attendance for a date that is
prior to the day after the last earned date, instead of a generic
message.

15. How do I know I’ve Met my Goal/Benefit?
As the customer, how will I be able to test / or accept that the
feature goal / benefit has been met?
The Confirmation:
Log in as system administrator and turn on the option that
attendance cannot be posted before or equal to last earned
date.
Configure a message to be seen if an instructor/registrar
attempts to post attendance prior to or equal to the last earned
date
Log in as instructor/registrar
Attempt to enter attendance for a date prior to or equal to last
earned date
The message that was configured should be displayed.
15

16. Requirements Elicitation to include Non-Functional
Requirements
16

17. Invest in your User Story
It stands for all the things a good user story should be:
I • Independent
N • Negotiable
V • Valuable
E • Estimable
S • Small
T • Testable

18. User Stories in Action at CMC…
18

19. Collaboratively Capturing our User Stories Using SharePoint

20. Where & When Does this Process Occur?
20

21. Questions & Answers
21