The Art & Science of Requirements Gathering
UX Professional, Information Architect & Project Manager
1. The requirement gathering challenge
2. Requirements, scope, and specifications, oh my!
3. Eight steps to making this process better
4. Requirements gathering in practice: an allegory...
5. Summary and questions
what are the challenges we face?
“Requirements are initiated by senior managers and
company executives as policies, aims, objectives and
other high-level statements of intent. This necessitates
considerable scoping activity as requirements start with
vaguely expressed intentions and users’ wish lists...”
~ Usability in Government Systems: User Experience Design for Citizens and Public
Servants (Google eBook) by Elizabeth Buie & Dianne Murray
as of January 2013...
1. 634 million websites
2. 51 million websites added during the past year
3. 87.8 million Tumblr blogs
4. 17.8 billion page views for Tumblr
5. 59.4 million WordPress sites around the world
6. 3.5 billion webpages run by WordPress viewed each month
7. 37 billion pageviews for Reddit.com in 2012
8. 191 million visitors to Google Sites
with more and more
organizations will be determined
to ‘stand out’
and many will not be able to
why and how they want to do
features can be difficult to
prioritize, and sometimes the
focus ends up on the wrong
when stakeholders come from
a variety of backgrounds,
documentation can be varied
what are we receiving as “specifications”
1. Request for proposal
3. Data base schema
4. Project charter
5. Text requirements list
6. Entity relationships
7. Photoshop files
8. Publication workflows
9. Powerpoint presentations
12. Branding guidelines
have a goal to achieve consistency in
documentation, define a common
language, and strive to fill in gaps,
constraints and assumptions
what are traditional requirements?
1. Criteria to which the system or business must adhere.
2. Usually created before the coding begins
3. Nearly always written as text
4. Often defined as constraints, conditions, or capabilities to
which the system must conform
5. Focus on system operation
6. Contain explicit tests or acceptance criteria
7. Often written atomically; meaning that thousands of
independent shall statements can comprise a software
in what form do we receive them?
1. Short sentence stating high level functional requirement
2. A full description of the requirement
3. Description of how it is essential to the overall system
4. Description of any technical issues of the requirement
5. Description of user interface requirements
6. Description of business requirement
7. Description of technical requirement
8. Description of cost and schedule
specification as defined by IEEE standards
A document that specifies, in a complete, precise, verifiable
manner, the requirements, design, behaviour, or other
characteristics of a system, component, product, result, or
service and the procedures for determining whether these
provisions have been satisfied
★ requirement specification
★ design specification
★ product specification
★ test specification
requirements expressed as use cases
A series of interactions by the user (Actor) with the system and
the response of the system
Focus on interactions:
Written in such a way as to succinctly define the user/system
activities and data that define the interaction.
Use cases can be written atomically as well, but the use case
diagram is meant to tie together the use cases.
Use cases are intended to be drilled down in successive levels
of detail, reducing the need for nailing down the details before
two main components of use cases
Diagrams which graphically describe actors, use
cases, system boundaries, and the relationship
between all of these (focused on the user).
Text written in a call-and-response format that shows
an action by the user, followed by the system’s
requirements expressed as user stories
Narrative texts that describe an interaction of the user and the
system, focusing on the value a user gains from the system.
A good user story uses the “INVEST” model:
★ Independent. Reduced dependencies = easier to plan
★ Negotiable. Details added via collaboration
★ Valuable. Provides value to the customer
★ Estimable. Too big or too vague = not estimable
★ Small. Can be done in less than a week by the team
★ Testable. Good acceptance criteria
typical user story template
As a [type of site visitor]
I need a way to [do something]
so that I can [benefit somehow].
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
comparing approaches to writing
Traditional requirements: focus on system operations and what
the system should do
Use cases: focus on users and their interaction with the system
in mind, the capabilities of the user and how these capabilities
are met via a system response.
Work flows or business flows: show system and user
interaction in a call-and-response format.
User stories: focus on customer value, a metaphor for the work
being done, not a full description of the work. The actual work
being done is fleshed out via collaboration revolving around the
user story as system development progresses.
all rightie then...
Requirements: a wish list of capabilities, as described in detailed
Scope: basket of items selected from the requirements that we set
out to deliver which makes up the product, service or result being
delivered to the customer
Project Scope - the work to be performed to deliver the product,
service or result
Product Scope - the features and functions of the product, service
wikipedia on scope creep
...the incremental expansion of the scope of a project,
which may include and introduce more requirements that
may not have been a part of the initial planning of the
project, while failing to adjust schedule and budget.
process to manage the
product & process experts
Jared Spool: http://chicago2011.drupal.org/keynotes
requirements engineering activities and
1. Submission or Request
3. Fact gathering and research
7. Trade-off Analysis
Defining the boundaries...
Scoping is best achieved by discussion with all the
stakeholders and tends to focus users’ attention on where
the boundaries of the system investigation should lie, and
helps to identify at least an initial scope for the system.
scoping a project
1. SCOPING involves carving out a list of features and
defining the product that the project will deliver.
2. PROJECT SCOPE is the work that needs to be
accomplished to deliver a product, service, or result
with the specified features and functions.
3.PRODUCT SCOPE is the features and functions that
characterize a product.
fact gathering and research
Background research: interviews, observation,
questionnaires, text and document analysis
three classes of research
1. Preferences: opinions and desires
2. Ability: what is understood or accomplished with a tool
3. Conceptual: how to get things done
ability: what is understood or accomplished with
★ Usability Testing
★ Preference Interviews
★ Log Analysis
★ Customer Feedback
★ Card Sorting
★ Interaction Design
★ Interaction Flow
★ Page Layout
conceptual: how to get things done
★ Task Interviews
★ Contextual Inquiry
★ Preference Interviews
★ Software Structure
★ Information Architecture
★ Content Location
★ Contextual Information
★ Contextual Marketing
★ Gap Analysis
★ Filling in the details
★ What is the system purpose (goals)?
★ What objects are involved?
★ Where is the system located?
★ When should things happen?
★ Why is the system necessary (goals or problems it
intends to solve)?
★ Data flow diagrams
★ Entity relationship diagrams
Getting users to understand the implications of a
requirements specification and then agree, i.e. validate, that
it accurately reflects their wishes.
A walkthrough of any of:
★ Data flow diagrams
★ Prototype demo
★ Scenario-based representations
★ Animated simulations
Requirements are often held by different stakeholders who
may have conflicting views, hence trade-off analysis is an
essential activity for comparing, prioritizing and deciding
between different requirements or design options.
Ranked lists or matrix-based techniques using decision tables
are helpful for this analysis.
The modelling techniques proposed by Chung (1993) and Yu (1993) for mapping
relationships and dependencies between goals, tasks, actors and soft goals (alias nonfunctional requirements), contains some guidance for trade-off analysis.
putting it into practice
Submission or request
Fact gathering and research
1. request : prepare an informal 2 course
dinner for 4
★ Something sweet
★ Dinner means after 5pm
★ Guests are available most of July
★ 2 courses are main and dessert
★ Vegetables should be organic
★ Protein cannot be red meat
★ Must take place outside
★ Drinks not included
3. fact gathering and research
★ Shellfish allergy
★ Enjoy spicy, ethic food
★ Favourite vegetables are peppers
★ 3 guests like chocolate desserts best
★ 1 guests likes vanilla desserts best
★ 2 of the guests love Cuban food
★ 1 of the guests loves asian food
★ All four love ‘comfort food’
★ Guests are from the same family
★ Purpose of the dinner is to celebrate a birthday
★ The host is one of the four The location will be on the
host’s patio Host will provide furniture
★ Host will provide beverages Dishes, cutlery, napkins
and stemware will be needed No server or bartender
will be required A good date for the event is July 5, 6,
12, or 13 Guests can arrive at 5:30 The dinner is
expected to last 2-3 hours
★ Host will cleanup
5. recipe for moros y cristianos - (data modelling)
1 Small Spanish Onion – (diced small)
1 Small Cubanelle Pepper (diced small)
2 Garlic Fingers (minced)
2 tbsp FRESH Chopped Cilanto
2 tbsp FRESH Culantro leaves – Find this at local Latin or Asian
2 tbsp + 1/4 cup Extra Virgin Olive Oil
1 tbsp Sea Salt
1/2 tsp Fresh Ground Black Pepper
2 tsp Dried Thyme
Pinch of Saffron
2 tbsp Sofrito
1/4 cup FRESH Sazón
1/4 cup Red Cooking Wine
1/3 cup PITTED Alcaparrados
8oz can Spanish Tomato Sauce
2 Bay Leaves
4 Cups Long Grain Rice – I use organic brown rice
1 Quart (4 cups) organic vegetable stock
6. validation - walkthrough
Platillo Moros y Cristianos is a famous Cuban dish
6. validation - walkthrough
Creme Caramel is a dessert served in Cuba
7. trade-off analysis
★ Chocolate vs. vanilla?
★ Add a birthday cake or include candles?
★ Organic vs. conventional produce?
★ Have the dinner indoors if raining?
★ Documentation: menu and ingredients
★ List of assumptions and constraints
★ Finalized budget, schedule and scope
an emerging field
Requirements Engineering is"designing the right thing" as
opposed to software engineering’s "designing the thing
right" ~ Barry Boehm, 1981
"Software systems requirements engineering (RE) is the
process of discovering that purpose, by identifying
stakeholders and their needs, and documenting these in a
form that is amenable to analysis, communication, and
~ Nuseibeh and Easterbrook, 2000