CONCEPTS OF SOFTWARE

ENGINEERING
Customer Requirements (User stories)

Dr. Abdul Karim ABED

Definition
 Requirements is the process that determines the
properties a particular system should have.

 The requirements process generates the information

on which the design will be based.

 For this, you have to know where a system is to be

used, by whom, and what services it should provide.
 Definition
3

 Software requirements are documentation that

completely describes the behavior that is required
of the software-before the software is designed,
built and tested.
Definition
 Requirements vs. Design
 In principle, requirements should state what the
system should do and the design should describe
how it does this
 Requirements document the behavior of the
software that will satisfy the user needs
 Design shows how those requirements will be

implemented technically
Definition
 Requirements Elicitation is the process of
discovering the requirements for a system
by communication with customers,
system users and others who have a stake
in the system development.
Definition
Requirements Elicitation Techniques
 Interviews with the users, stakeholders and anyone
else whose perspective needs to be taken into
account during the design, development and testing
of the software
 Observation of the users at work
 Reading existing documents
 Survey / Questionnaires
 Meetings: e.g. meet with stakeholders towards the end
of each stage
Advantages of a Good Requirements

 The main advantages of a good Requirements is:

1) It establishes the basis for agreement between the client
and the supplier on what the software product will do.
The client clearly describes what it expects from the
supplier, and the developer clearly understands what
capabilities to build in the software.
Advantages of a Good Requirements

2) Requirements provides a reference for validation of the

final product.
That is, the requirement helps the client determine if the
software meets the requirements.
Without a proper requirement , there is no way a client can
determine if the software being delivered is what was
ordered, and there is no way the developer can convince
the client that all the requirements have been fulfilled.
Advantages of a Good Requirements

3) A high-quality Requirements is a prerequisite to high-

quality software.
We know that errors can exist in the requirement . It is also
known that the cost of fixing an error increases almost
exponentially as time progresses.
Hence, by improving the quality of requirements, we can
have a huge savings in the future by having fewer
expensive defect removals.
Requirements perspectives
Functional Requirement
 Describe functionality or system services.

Example:
 The user shall be able to search either all of the

initial set of databases or select a subset from it.

Requirements perspectives
Non-functional requirements
 Define system properties and constraints e.g.

reliability, response time and storage

requirements.

• Non-functional requirements may be more critical

than functional requirements. If these are not met,
the system is useless.
Requirements perspectives
Example:
The system shall not disclose any personal
information about customers apart from their name
and reference number to the operators of the
system.
Requirements are a Communication Problem
 Written requirements
 can be well thought through, reviewed and edited
 provide a permanent record
 are more easily shared with groups of people
 time consuming to produce
 may be less relevant or superseded over time
 can be easily misinterpreted
Requirements are a Communication Problem

 Verbal requirements
 Direct feedback and clarification
 Easier to clarify and gain common understanding
 More easily adapted to any new information
known at the time
 Can spark ideas about problems and opportunities
User Stories
User Stories
Seek to combine the strengths of written
and verbal communication,
where possible supported by a picture.
In XP methodology user stories is part of
Exploration Phase
The XP lifecycle
Exploration Phase
 The purpose of the exploration phase is to give
both players (Development and Business) an
approval for what all the system should eventually
do
Exploration Phase
The Players
 The two players in the XP are Development and

Business.
 Development consists collectively of all the people

who will be responsible for implementing the

system.
 Business consists collectively of all the people who

will make the decisions about what the system is

supposed to do.
Exploration Phase
Exploration has three moves
 Write a story—Business writes a story describing

something the system needs to do. The stories are

written on index cards, with a name and a short
paragraph describing the purpose of the story.
Exploration Phase
 Estimate a story—Development estimates how long
the story will take to implement. If Development can't
estimate the story, it can ask Business to clarify or
split the story. A simple method for estimating stories
is to ask yourself, "How long would this take me to
implement if this story was all I had to implement,
and I had no interruptions or meetings?"
 In XP we call this Ideal Engineering Time. As you
will later, before you commit to a schedule you
measure a ratio between ideal time and the calendar.
Exploration Phase
 Split a story—If Development can't estimate a
whole story, or if Business realizes that part of a
story is more important than the rest, Business can
split a story into two or more stories.
 User Stories

What is a User Story?

A concise, written description of a piece of
functionality that will be valuable to a user
(or owner) of the software.
It provides a simple way for developers and
customers to split up what the system needs to
do so the system can be delivered in pieces.
User Stories
 The emphasis on the word simple is essential.
There are many books out there that go into great
detail about requirements engineering, use case
design, and similar topics. These present some
useful ideas, but as ever XP looks for the simplest
approach that could possibly work. So as we look
at stories, remember that the whole point is to make
them too simple to work in the hope that we might
just get away with it.
The Story Writing Process
 The process of writing stories is iterative, requiring
lots of feedback.
 Customers will propose a story to the programmers.
The programmers will ask themselves if the story can
be tested and estimated, and if it is of appropriate size.
 If the story cannot be estimated, the programmers will
ask the customer to clarify the story. If the story is too
big, the developers will ask the customer to split the
story.
User Story Cards parts

User Story Cards have 3 parts

1. Card - A written description of the user story for planning purposes
and as a reminder

2. Conversation - A section for capturing further information about the

user story and details of any conversations

3. Confirmation - A section to convey what tests will be carried out to

confirm the user story is complete and working as expected
User Story Description

User Story Description (Card)

As a [user role] I want to [goal]
so I can [reason]

For example:
• As a registered user I want to log in
so I can access subscriber-only content
User Story Description

 Who (user role)

 What (goal)

 Why (reason)
 gives clarity as to why a feature is useful
 can influence how a feature should function
 can give you ideas for other useful features
that support the user's goals
User Story Example: Front of
Card
User Story Example: Back of
Card
Examples of specifying value to users
 Good:
 “A user can search for jobs”
 “A company can post new jobs”
 Bad:
 “The software will be written in C++”
 “The program will connect to the database through a
connection pool”
?How detailed should a User Story be

Detailed enough for the team to start work from,

and further details to be established and clarified
.at the time of development
INVEST in Good User Stories
 Estimatable – User Stories need to be possible to
estimate. They need to provide enough information
to estimate, without being too detailed.
 Small – User Stories should be small. Not too

small. But not too big.

 Testable – User Stories need to be worded in a

way that is testable, i.e. not too subjective and to

provide clear details of how the User Story will be
tested.
Story Responsibilities (Customers)
 Writing stories that
 Are promises to converse rather than detailed
specification
 Have value to users or to yourself
 Are independent
 Are testable
 Are appropriately sized
 Have the conversations with the developers
Story Responsibilities (Developers)
 Help the customers write stories that
 Are promises to converse rather than detailed specs
 Have value to the users or the customer
 Are independent
 Are testable
 Are appropriately sized
 Describing the need for technology/infrastructure in
terms of value to users or customers
 Have the conversations with the customers
Users
 Can be more than one type of user for system
 Different user types may have different roles and
different stories
 Disfavored users (e.g., hackers) may be included as
well as favored users
 Obviously, the value to users piece gets flipped for
disfavored users
Guidelines for Good Stories
 Start with goal stories
 Write closed stories (stories that have a definite end
point)
 “A recruiter can review resumes from applicants to one
of her ads” instead of “A recruiter can manage the ads
she has placed”
Guidelines for Good Stories
 Size your story appropriately for the time frame it
may be implemented in
 Keep the UI out as long as possible
 Don’t rely solely on stories if something are better
expressed in other ways
 Include user roles in stories rather than saying “user”
 Write for a single user (“A Job Seeker” not “Job
Seekers”
 Use Active Voice
Example
 travel booking project
 Find lowest fare.
 Present to the customer the ten lowest fares for a particular route .
 Show available flights.
 Show possible flights (with connections) between any two planets .
 Sort available flights by convenience.
 When you're showing the flights, sort them by convenience: time of journey,
number of changes, closeness to desired departure and arrival time .
 Purchase ticket.
 Purchase ticket charging to a credit card. Check credit card validity when doing
this.
 Do customer profile.
 Keep customer details for quick reference, for example, credit card info, home
address, dietary and gravitational needs
Story Estimation
 Estimation is one of the harder parts of a software
project.
 Development estimates how long the story will take
to implement. If Development can't estimate the story,
it can ask Business to clarify or split the story.
 Examples of Methods for estimating stories are: By
analogy or by Planning Poker
Estimate by analogy
 Comparing a user story to others
 “This story is like that story, so its estimate is what
that story’s estimate was.”
 Compare the story being estimated to multiple
other stories.
Planning Poker
 The best way found for agile teams to estimate is by
playing planning poker
 This method tries to make the meetings more short
and productive, by making them more fun and
dynamic.
Example (III)

 All members have converged except for the 3rd

 A new round of expositions and voting can be made.
 It’s also possible to take 3 or 5 as the estimation.
Example
 As a salon owner I want to be able to sell items on a
ticket so I can generate revenue.
(Split to)
- As a salon owner I want to be able to sell services on
a sales ticket so I can generate revenue.
- As a salon owner I want to be able to sell products on
a sales ticket so I can generate revenue.
- As a salon owner I want to be able to sell gift
certificates on a sales ticket so I can generate revenue.
Example
 As a salon owner I want to be able to sell services
on a sales ticket so I can generate revenue.
(Split to)
– As a salon owner I want to be able to sell
individual services on a sales ticket so I can
generate revenue.
– As a salon owner I want to be able to sell packages
so I can increase revenue.