a) The user can run the system on Windows XP and Linux. This is specifying an implementation detail rather than a user goal or need. Good user stories focus on what the user needs, not how it will be implemented. b) All graphing and charting will be done using a third-party library. This specifies an implementation detail rather than a user goal or need. Good user stories focus on what the user needs, not how it will be implemented. g) The system will use Log4J to log all error messages to a file. This specifies an implementation detail rather than a user goal or need. Good user stories focus on what the user needs, not how it will be implemented

1. User Stories in
Requirements Engineering
PREPARED BY
MD. SHAFIUZZAMAN

2. “The hardest single part of building a software system is deciding
what to build. No part of the work so cripples the resulting system
if done wrong. No other part is more difficult to rectify later.”—
Fred Brooks
“You start coding. I’ll go find out what they want.” —Computer
analyst to programmer

3. How will you find the answers of the
following questions?
 What does the customer want?
 How will the end-users interact with the software?
 What will be the business impact?

4. Customer statement of requirements
 starting point of requirements engineering
 informal description of what the customers think they need from a software
system to do for them
 problem could be identified by management personnel, through market
research, by ingenious observation, or some other means
 opinion-based
 evolves over time with changing market conditions or better understanding of
the problem

5. Goal of requirements engineering
 fact-finding: how the problem can be solved in the current practice
 envisioning: how the planned system might work

6. Final outcome of requirements
engineering
 Software Requirements Specification (SRS) document

7. Stakeholder
 an individual, team, or organization with interests in, or concerns related to, the
system-to-be
 types:
 customers
 end users
 business analysts
 systems architects
 developers
 testing and quality assurance engineers
 project managers
 future maintenance organization
 owners of other systems that will interact with the system-to-be

8. Process
 requirements gathering
 requirements analysis
 requirements specification

9. Requirements gathering
 what is to be accomplished
 how the system will fit into the needs of the business
 how the system will be used on a day-to-day basis

10. Requirements analysis
 refining of and reasoning about the requirements
 creation and elaboration of user scenarios that describe how the
end-user will interact with the system
 negotiation with the customer to determine the priorities, what is
essential, and what is realistic

11. Requirements specification
 problem statement in a semiformal or formal manner to ensure
clarity, consistency, and completeness
 function and quality of the software-to-be
 constraints that will govern its development
 can be a written document, a set of graphical models, a formal
mathematical model, a collection of usage scenarios (or, “use
cases”), a prototype, or any combination of these

12. User Stories
A LIGHT WAY TO MODEL REQUIREMENTS

13. “The best performance improvement is the transition from the
nonworking state to the working state.”
—John Ousterhout

14. Customer statement of requirements
I want to create a job posting site. It can do following things:
1. A user can search for a job.
2. A company can post job openings.
It should have all features that all existing job posting sites have as well as
some exciting features so that people are attracted to our site

15. “A user can search for jobs.”- Where Are
the Details?
o What values can users search on? State? City? Job title? Keywords?
o Does the user have to be a member of the site?
o Can search parameters be saved?
o What information is displayed for matching jobs?

16. “A user can search for jobs.”- Where Are
the Details?
o A user can search for jobs by attributes like location, salary range,
job title, company name, and the date the job was posted
o A user can view information about each job that is matched by a
search
o A user can view detailed information about a company that has
posted a job

17. Not recommended
“A user can view information about each job that is matched by a
search”
 A user can view a job description
 A user can view a job’s salary range
 A user can view the location of a job

18. How Long Does It Have to Be?
 understand the expectations of a project’s users
 acceptance test
Try it with an empty job description.
Try it with a really long job description.
Try it with a missing salary.
Try it with a six-digit salary.

19. Bad Example
 The software will be written in C++.
 The program will connect to the database through a connection
pool.

20. Customer Team
 includes those who ensure that the software will meet the needs
of its intended users
 team may include testers, a product manager, real users, and
interaction designers

21. Why does the customer team write the
stories?
 The customer team, rather than the developers, writes the user
stories for two primary reasons
 each story must be written in the language of the business, not in technical
jargon, so that the customer team can prioritize the stories for inclusion into
iterations and releases
 as the primary product visionaries, the customer team is in the best position
to describe the behavior of the product

22. Assignment

23. Which of the following are not good
stories? Why?
a) The user can run the system on Windows XP and Linux.
b) All graphing and charting will be done using a third-party library.
c) The user can undo up to fifty commands.
d) The software will be released by June 30.
e) The software will be written in Java.
f) The user can select her country from a drop-down list.
g) The system will use Log4J to log all error messages to a file.
h) The user will be prompted to save her work if she hasn’t saved it for 15 minutes.
i) The user can select an “Export to XML” feature.
j) The user can export data to XML.