Chapter 2 - Gathering Requirements

Knowing what the customer wants?

1
Agenda
• Requirements and Requirements Gathering
• Brainstorming
• User Stories
• Planning
• Estimation Game

2
 Capture basic ideas

3
Requirements
 The requirements for a system are the descriptions of what the
system should do—the services that it provides and the
constraints on its operation.
 These requirements reflect the needs of customers for a system
that serves a certain purpose such as controlling a device,
placing an order, or finding information.
 The process of finding out, analyzing, documenting and
checking these services and constraints is called requirements
engineering (RE).
4
Requirements Gathering
• Requirements gathering begins with a problem
statement

5
First Step: Impose Structure
• Identify all of the different things the system has to do.

6
In particular: Find Requirements

7
In particular: Find Requirements
• A requirement is a single thing that the software
has to do
• Written in User’s Language
• Informal: because we don’t have a lot of
information But, allows us to validate initial
understanding of domain

8
 Translate Entire Problem Statement

9
 Then, return to customer and

• ask questions
• Did I get this right?
• What did you mean by…
• and gather more requirements
• Is this really all of the
functionality that you need?
• If we built all of this, what
would you want in version 2.0?

10
Problem: Not Enough?
• One problem that you’ll encounter is that this back and forth
may not be enough to get to crisp detailed requirements
• or you feel that you just don’t have a good grasp on the
big picture
• This can be especially true if “customer” ≠ “end user”
• Next step is to hold a brainstorming session with as many
different stakeholders as possible
• what the book calls a “bluesky session”
11
 Next?
Brainstorming or Bluesky session

12
Brainstorming
 is a method of generating ideas and sharing knowledge to
solve a particular commercial or technical problem, in
which participants are encouraged to think without
interruption.
 is a group activity where each participant shares their ideas
as soon as they come to mind.
 At the conclusion of the session, ideas are categorized and
ranked for follow-on action.
13
Brainstorming or Bluesky session
• Brainstorming session
• Goal: get stakeholders to generate tons of candidate
requirements; not everything will make it into the final
system
• Things to Avoid
• The Silent Tomb®: Leave job titles at the door, people
should not feel afraid to speak up just because the boss is
there.
• Criticizing people rather than ideas
• Developer jargon “NOT ‘AJAX’ but ‘rich user interface’”
• XMind (free) (Brainstorming and mind mapping tools)

14
XMind
XMind is a mind mapping and brainstorming software, developed by XMind
Ltd. In addition to the management elements, the software can be used to capture
ideas, clarify thinking, manage complex information, and promote team
collaboration.

15
Gray Skies
• If things go wrong during the bluesky session: “bad boss”
• Make use of other techniques
• Interview end users and have them pretend to interact
with their “ideal system”, what the book calls “role
playing”
• Observe them working on tasks related to the system
• how would the task change if the system were
present?
• Review the documents they use now
• ask if the document would go away if the system were
present or how would it change?

16
 Next ?
Construct User Stories

17
 Next? User Stories
• Transform requirements gathered so far into user stories
• A user story describes how the user interacts with the software you’re
building
• It should be written from your customer’s perspective and describe what
the software is going to do for the customer
• User stories are essentially informal use cases
• It Defines:
• The Actor/User
• The Goal/Task
• The Benefit / Value
18
User Stories
• SHOULD
• describe one thing the system should do for the customer
• be written using language that the customer understands
• be written by the customer !!
• be short. No longer than three sentences
• SHOULD NOT
• be a long essay
• use technical terms unfamiliar to the customer
• mention specific technologies (save those for design)
19
Example 1: User Story

20
Example 2: User Story

21
 Requirements

22
Types of Requirements
• There are different types of requirements:
• functional
• non-functional

23
Functional Requirements
 These are statements of services the system should
provide
 How the system should react to particular inputs
 How the system should behave in particular situations.
 In some cases, the functional requirements may also
explicitly state what the system should not do.

24
Non-functional requirements
 These define system properties and constraints e.g. reliability,
response time and storage requirements.
 Constraints are I/O device capability, system representations, etc.
 Process requirements may also be specified mandating a
particular IDE, programming language or development method.
 Non-functional requirements may be more critical than
functional requirements. If these are not met, the system may be
useless.
Non-functional classifications
 Product requirements
 Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.

 Organizational requirements
 Requirements which are a consequence of organizational policies and procedures
e.g. process standards used, implementation requirements, etc.

 External requirements
 Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements,
etc
Examples of nonfunctional requirements in the
Mentcare system
 Product requirement
 The Mentcare system shall be available to all clinics during normal working hours
(Mon–Fri, 0830–17.30).
 Downtime within normal working hours shall not exceed five seconds in any one
day.

 Organizational requirement
 Users of the Mentcare system shall authenticate themselves using their health
authority identity card.

 External requirement
 The system shall implement patient privacy provisions as set out in HStan-03-
2006-priv.
Metrics for specifying nonfunctional requirements
Requirements Life Cycle
• We now have a life cycle for use at the start of a project
• Capture basic ideas from problem statement
• Return with first pass, ask questions, set-up bluesky session
• ITERATE
• Construct User Stories
• Find holes with stories and fix them with customer feedback,
find new requirements, ask questions to assess completeness
• Finish with initial set of clear, customer-focused user stories
• This defines the WHAT of the project, next up is the WHEN
29
 Exercise

30
What kind of a requirement the system is providing ?
 The processing of each request should be done within 10 seconds.
 The site should load in 3 seconds when the number of
simultaneous users are > 10000 .
 An operating system requires that users enter a password and
username when logging in so that the system can authenticate their
identity.
 An operating system provides a receipt to users upon performing a
transaction, and the system records information about the
transaction in a saved file.
31
What kind of a requirement the system is providing ?
 The processing of each request should be done within 10 seconds.
 The site should load in 3 seconds when the number of
simultaneous users are > 10000 .
 An operating system requires that users enter a password and
username when logging in so that the system can authenticate their
identity.
 An operating system provides a receipt to users upon performing a
transaction, and the system records information about the
transaction in a saved file.
32
Instagram
 Instagram is a free photo and video sharing app that
allows users to upload photos or videos to our service and
share them with their followers.
 They can also view, comment and like posts shared by
their friends on Instagram.

33
What kind of a requirement the system is providing ?
 Users should be able to upload images and video, write
descriptions, and publish the updates.
 Users should be able to respond to content posted by other
users, commend, and follow them.
 The system should display content with the smallest delay
possible, and scale to handle dozens of thousands of new users.
 Instagram should provide users with natural and seamless
navigation.

34
What kind of a requirement the system is providing ?
 Users should be able to upload images and video, write
descriptions, and publish the updates.
 Users should be able to respond to content posted by other
users, commend, and follow them.
 The system should display content with the smallest delay
possible, and scale to handle dozens of thousands of new users.
 Instagram should provide users with natural and seamless
navigation.

35
 Play planning poker

36
(On to) Estimates
• At some point during the requirements gathering process, the
customer will ask
• How long will all of this take to develop?
• You need to supply a project estimate
• which will be the sum of the estimates for your user stories
• So, now you need to supply estimates for each user story
• How do we come up with this estimate?
• Planning Poker is a popular estimation technique in agile.

37
Planning Poker
• Addresses the problem in which two or more team members
come up with wildly different estimates for a story
• i.e. when a single user story generates estimates of say “3
days”, “2 weeks”, and “3 months” from three different
developers
• The underlying cause for these different estimates is
assumptions;
• what did you assume was true or not true about the project to
generate the number that you did?
38
Example: Different Estimates 1
• Task: “Add a comment on a product page”
• One team member might think:
• “Simple. We need a form, a script to process the form, and a
place to store the comment in the database. 3 days.”
• Another might think:
• “Hmm. How do we relate the comment to the product? Do we
have one comment table per product in the database? Will I
need to change the product class? Maybe there is code from
some other place in the system that I can re-use. 2 weeks.”
39
Example: Different Estimates 2
• Task: “Add a comment on a product page”
• Finally, another might think:
• “Ugh. Complete database re-design. No code to re-use (this is the first
time we’re allowing comments). What user interface should we use?
Can the user embed HTML in their comments? How do we handle
smileys? How will this impact the product model class? Do we keep
the comments forever? Do we need moderation? Can a user edit a past
comment? Who gets to delete comments? Yuck!! 3 months!”
• Based on your assumptions, you’ll get completely different numbers.
How do you get these assumptions to the surface? Planning Poker!
40
Planning Poker I

• Create “deck” of cards. 13 cards per “player”.

• Each card contains an estimate spanning from “already
done” to “wow this is going to take a long time”.
• 0, .5, 1, 2, 3, 5, 8, 13, 20, 40, 100 days
• One card has a “?” meaning “not enough information”
• One card has a coffee cup meaning “lets take a break ”

41
Planning Poker II
• Place a user story in the middle of the table
 Each team member thinks about the story and forms
initial estimate in their heads
 Each person places the corresponding card face down
on the table; note: estimate is for entire user story
 Everyone then turns over the cards at the same time

42
Planning Poker III
• The larger the difference between the estimates, the less
confident you are in the estimate, and the more assumptions you
need to highlight and discuss.
• So, the next step in planning poker is
• Put assumptions on trial for their lives
• Have each team member list the assumptions they made and
then start discussing them
• Again, you need to criticize the assumption not the person
• Goal is to get agreement on what assumptions truly apply
43
Planning Poker IV
• If the assumptions reveal a misunderstanding of the
requirements, then go back to the client and get that
misunderstanding clarified
• Otherwise, start to eliminate as many assumptions as
possible, then have everyone revise their estimates and play
planning poker again to see if the spread has decreased
• Your goal is convergence. Once estimates cluster around a
common number, assign that number and move to the next
story.
44
Planning Poker V
• Your life cycle is thus
• Talk to customer: clarify misunderstandings,
assumptions
• Play planning poker
• Clarify assumptions, possibly by returning to step 1
• Come to a agreement estimate for the user story
• Do this until all user stories have an estimate assigned

45
Planning Poker VI

• Things to watch out for

• Big estimates (== bad estimates)
• They indicate that the story is too big; decompose;
try again

46
What to do – Big estimates ?
• Break your story into smaller ones (Using the AND rule)
• Any user story that has an AND in its title or description
can probably be split into two or more smaller ones
• Talk to your customer again
• May be there are some assumptions that push your
estimation up. By talking with your customer, you may
get a better understanding and those assumptions might
go away.
47
 Summary

48
Requirements Life Cycle

49
 Tasks

50
Create stories
• In teams of 5-6 write user stories for a system of your choice,
for example
• A packaged holiday website
• Procedure:

1. Firstly pick your system and consider the different users,

include at least 5 in your stories

2. Write stories including acceptance criteria

3. feedback discussion

51
Planning Poker
• List user stories for a system of your choice
• Prioritize the list
• Estimates relatively, choices are ? 0 ½ 2 3 5 8 13 20
40 100
• Read and discuss item short
• Make a decision on a paper (private)
• Show cards at the same time
52