A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template Use Case and User Story Explained with example

1. 1
Requirement Capturing
Techniques

2. HELLO!
I am Abhinav Sabharwal
You can find me at skyabhinav@gmail.com
https://www.linkedin.com/in/abhinavsabharwal/
2

3. 3
WHY THIS UPDATE
This Presentation Has been Updated
One of my friends complained that in my last presentation Basics of requirement
gathering (https://www.slideshare.net/skyabhinav/basics-of-requirment-gathering) I
have not given proper treatment to User Stories hence this detail presentation. I am
now deleting that Presentation from slideshair. I am also deleting my presentation
on User Stories(https://www.slideshare.net/skyabhinav/user-storyies-explained)
this presentation now contains material of both the presentations and more
Thanks Sarbjit Multani (https://www.linkedin.com/in/sarbjit-multani-020abaa4/) for
Inspiring this presentation

4. 1.
USE CASE
4

5. USE CASE
▸In software and systems engineering, a use case is a list of actions or event
steps,
▸Defining the interactions between a role (known as an actor) and a system,
▸To achieve a goal.
▸The actor can be a human or other external system.
5

6. ▸Lets Look at the Structure of Use Case
6
Case ID This is the unique identifier that you use to reference the use case from
other artifacts that you create as part of developing your software product
You will use the use case ID to trace between the use case and the goals it
enables. You will also trace between the use case and the functional and
non-functional requirements that support it
Title The title, or name of the use case. This should be a simple sentence that
describes the use case
Author That would be you. Enter the name of the person responsible for authoring
the use case.
Use Case Version The version of the use case can be used to keep track of each draft or
revision of the document
Status Draft/Proposal/Approve /Rejected
STRUCTURE OF USE CASE

7. 7
PRE CONDITIONS Description of the affected portions of the state of the system Before Use Case is
Started
Actors – The people who execute the use case are the actors. Not “Tim” and “Joan,” but rather
“Office Clerk” and “Department Supervisor
Normal Flow – This is where the description of your use case goes. The goal here is to write just
enough to clearly define the use case. The individuals on your team will have the
biggest impact on what enough is for you. Most use cases involve some branching or
decisions. The normal flow should not include these “if…then” constructs. The normal
flow should include the most-common or most-valuable path through the use case.
Alternate Flows This is where those uncommon and lower-value paths are documented. Imagine a use
case for processing invoices. The normal course would describe how pending invoices
are handled. An alternative flow might handle how past-due invoices are handled. A
second alternate flow could handle customers with credit-balances in their accounts.
STRUCTURE OF USE CASE

8. 8
Exception Flows Descriptions of what the user will experience when something goes wrong.
Post-conditions – Description of the affected portions of the state of the system after the use
case has completed.
Frequency of use An estimate of how often a particular use case will be exercised
Assumptions Any assumptions that are implicit in the definition of the use case
STRUCTURE OF USE CASE

9. 9
USE CASE EXAMPLE
▸Lets Take a Example of a simple Login Screen
for Gmail and see how Use Case Will Be

10. 10
USE CASE EXAMPLE

11. ▸Lets Look at the Structure of Use Case
11
Case ID 001
Title User Login
Author Abhinav Sabharwal
Use Case Version 1.0
Status Draft/Proposal/Approve /Rejected
USE CASE EXAMPLE

12. 12
PRE CONDITIONS Browser is available and Open,
Internet is available
User Has Gmail ID
Actors – Registered Gmail User
Normal Flow – 1) User Enters email id
2) Users Enter the Password
3) Credentials are successfully authenticated
4) Inbox Screen is Displayed
Alternate Flows 1) User Enters email id
2) Users Enter the Password
3) User Cancels The Login Process by Clicking on cancel button
4) User Id and password field are cleared
USE CASE EXAMPLE

13. 13
Exception Flows 1) User Enters email id
2) Users Enter the Password
3) Credentials are NOT successfully authenticated
4) Error Message is Displayed “Invalid User Id or Password”
Post-conditions – User Is Able to View Inbox and Read Messages.
Frequency of use Rarely/ Regularly /Often
Assumptions User Know how to login to Gmail account
USE CASE EXAMPLE
*Please Note: Post Condition is always in relation to Normal Flow

14. 2.
USER STORIES
14

15. USER STORIES
▸User stories are short, simple descriptions of a feature told from the
perspective of the person who desires the new capability, usually a user or
customer of the system.
▸
▸User stories are often written on index cards or sticky notes, stored in a
shoe box, and arranged on walls or tables to facilitate planning and
discussion.
▸ As such, they strongly shift the focus from writing about features to
discussing them.
▸User stories is that they can be written at varying levels of detail.
15

16. USER STORY
▸User Story is only meant to describe a feature, but not describe how to
implement it,
▸leaving out the technical aspect, User Story should describe the behavior
or flow from user’s perspective
16

17. USER STORY
▸A user story is a tool used in Agile software development
▸It is used to capture a description of a software feature from an end-
user perspective.
▸The user story describes the type of user, what they want and why.
▸A user story helps to create a simplified description of a requirement
17

18. ▸Lets Look at the Structure of User Story
18
STRUCTURE OF USER STORY

19. 19
USER STORY EXAMPLE

20. 20
USER STORY: CHARACTERISTICS
▸A story should be complete and big enough to provide a user with some
value
▸ The user story should be user-centric,
▸When the user story is done, the user can do something of value to
them

21. 21
DISCOVER RIGHT STORIES
▸Capture your insights about the users and customers is working
with personas.
▸ Personas are fictional characters that are based on first-hand
knowledge of the target group.
▸ Personas consist of a name and a picture; relevant
characteristics, behaviors, and attitudes; and a goal.
▸The goal is the benefit the persona wants to achieve, or the
problem the character wants to see solved

22. 22
DISCOVER RIGHT STORIES

23. 23
INVEST IN USER STORY

24. 24
INVEST IN USER STORY
▸Test user stories by using INVEST acronym
▸Independent — Can the story stand alone by itself ?
▸Negotiable — Can this story be changed or removed without impact to
everything else?
▸Valuable — Does this story have value to the end user?
▸Estimable — Can you estimate the size of the story?
▸Small —Is it small enough?
▸Testable — Can this story be tested and verified?

25. ▸A story should be small enough to be coded and tested within an
iteration—ideally just a few days
▸The agile recommendation is to break down a set of user stories into
smaller ones, containable into a single sprint duration, or ideally, not
more than a week.
▸Avoid having child stories, it is not a good recommendation to have
user story in nested hierarchy
25
SIZE & DETAIL OF USER STORY

26. ▸Sometimes a story will be small enough if we do too much slicing vertically,
other time it get way too bigger, as we keep on stuffing the feature in one
single user story.
▸This is why we have story points. The points are a fuzzy measurement of
how big or small a story is,
▸User Story should be estimated by the engineer(s) who are implementing it
or someone with superior knowledge about the work.
▸Organization/team there should have a standard scale for story points
measure, so you can compare multiple stories
26
STORY POINT & USER STORY

27. 27
DoD & CoS FOR USER STORY
▸As you fine-tune your estimation, the team should be able to reliably pick
up as many stories as they can handle
▸Define your Definition of Done (DoD) for stories, acceptance criteria or
condition of satisfaction (CoS )
▸This helps set expectations within the team as to when a team should
consider something done.

28. 28
DoD & CoS FOR USER STORY
▸Acceptance criteria complement the narrative:
▸They allow you to describe the conditions that have to be fulfilled so that the
story is done.
▸The criteria enrich the story, they make it testable,
▸As a rule of thumb, use three to five acceptance criteria for detailed stories

29. 3.
H - METHOD
29

30. 30
H - METHOD
▸The H-method is an analysis tool that aids the BA in organizing a fact
finding interview with a business representative or system user.
▸Let’s consider a typical interviewing process.
▸Without the use of a framework for organizing an interview, an analyst and
business representative will often participate in a relatively unstructured
dialogue in which the analyst asks questions such as:
▸Tell me what you do?
▸What does your system do?
▸Who do you interact with?
▸Why is “x” important?

31. 31
H - METHOD
▸Based on the answers given the analyst will continue to ask follow up
questions.
▸The success of the fact finding is typically dependent upon the experience
level of the analyst.
▸While this method can work, the analyst will often walk away with several
pages of unstructured notes.
▸Important information must then be extracted and organized into something
meaningful and useful.
▸ Only then we will be able to determine if we have all of the necessary
pieces of information or if there are still gaps in their understanding

32. 32
H - METHOD
▸Based on the answers given the analyst will continue to ask follow up
questions.
▸The success of the fact finding is typically dependent upon the experience
level of the analyst.
▸While this method can work, the analyst will often walk away with several
pages of unstructured notes.
▸Important information must then be extracted and organized into something
meaningful and useful.
▸ Only then we will be able to determine if we have all of the necessary
pieces of information or if there are still gaps in their understanding

33. 33
H - METHOD
▸The H-method uses the following “H” shaped diagram to provide a
structured framework to guide the interview and to allow the analyst to
captured information in an organized way from the start.

34. 34
H - METHOD
▸The H-method uses the following “H” shaped diagram to provide a
structured framework to guide the interview and to allow the analyst to
captured information in an organized way from the start.

35. 35
H - METHOD
▸Inputs & Outputs
▸By defining the inputs and outputs, the scope can be further refined.
▸By defining what comes into the area, and what is produced, it helps define
scope at a lower level of detail.
▸Functionality
▸Functionality will be at different levels of granularity.
▸At the first interview, it is better to keep focused on getting information
rather than sorting information.

36. 36
H - METHOD
▸Data
▸The question "What are the people, places and things you want to keep
track of?" is invaluable for a BA.
▸ The vast majority of users don't think in terms of databases.
▸. Data comes up all through a discussion. When it does, drop it in this box.
▸Business Rules
▸As rules emerge, they should be dropped into the business rules box. Like
data, they are woven through everything the BA is told.

37. 37
H - METHOD
▸Business Processes
▸Depending on the scope of the discussion, it may be useful to break it down
into discreet business processes.
▸For example, an order fulfillment area may have the following business
processes:
▸Order placement
▸Order fulfillment
▸Invoice creation
▸It is up to the Business Analyst to determine the appropriate level of
granularity to use when undertaking the analysis

38. 38
H - METHOD EXAMPLE

39. 39
H - METHOD EXAMPLE

40. 40
CONCLUSION
▸There are many methodologies including functional decomposition, DFD,
Workflows, Use Cases etc. that can be used
▸IT is up to B.A to choose the one that fits the project, I have explained here
three of the most popular ones

41. 41
THANKS!
Any questions?
You can find me at skyabhinav@gmail.com