Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
The Art & Science of Requirements Gathering
Vanessa Turke
UX Professional, Information Architect & Project Manager
presentation agenda:
1. The requirement gathering challenge
2. Requirements, scope, and specifications, oh my!
3. Eight st...
what are the challenges we face?
“Requirements are initiated by senior managers and
company executives as policies, aims, ...
http://www.projectcartoon.com
why we need to get better
as this
as of January 2013...
1. 634 million websites
2. 51 million websites added during the past year
3. 87.8 million Tumblr blo...
with more and more
competition,
organizations will be determined
to ‘stand out’
and many will not be able to
express
why a...
features can be difficult to
prioritize, and sometimes the
focus ends up on the wrong
content
when stakeholders come from
a variety of backgrounds,
submitted requirements
documentation can be varied
and inconsistent
documentation arrives in many different
forms
when stakeholders come from
a variety of backgrounds,
submitted requirements
documentation can be varied
and inconsistent
from super high level, to incredibly granular
what are we receiving as “specifications”
1. Request for proposal
2. Wireframes
3. Data base schema
4. Project charter
5. ...
have a goal to achieve consistency in
documentation, define a common
language, and strive to fill in gaps,
constraints and...
something here
what are traditional requirements?
1. Criteria to which the system or business must adhere.
2. Usually created before the ...
in what form do we receive them?
1. Short sentence stating high level functional requirement
2. A full description of the ...
specification as defined by IEEE standards
A document that specifies, in a complete, precise, verifiable
manner, the requi...
requirements expressed as use cases
A series of interactions by the user (Actor) with the system and
the response of the s...
two main components of use cases
Diagrams which graphically describe actors, use
cases, system boundaries, and the relatio...
requirements expressed as user stories
Narrative texts that describe an interaction of the user and the
system, focusing o...
typical user story template

As a [type of site visitor]
I need a way to [do something]
so that I can [benefit somehow].
gherkin syntax
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When som...
comparing approaches to writing
requirements
Traditional requirements: focus on system operations and what
the system shou...
all rightie then...
Requirements: a wish list of capabilities, as described in detailed
specifications
Scope: basket of it...
wikipedia on scope creep
...the incremental expansion of the scope of a project,
which may include and introduce more requ...
process to manage the
knowledge gap
product & process experts

target knowledge
simplifying

training

current knowledge

...
requirements engineering activities and
process
1. Submission or Request
2. Scoping
3. Fact gathering and research
4. Anal...
scoping

Defining the boundaries...
Scoping is best achieved by discussion with all the
stakeholders and tends to focus us...
scoping a project
1. SCOPING involves carving out a list of features and
defining the product that the project will delive...
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
...
preferences: opinions and desires
Techniques:
★ Surveys
★ Focus Groups
★ Preference Interviews
★ Card Sorting
Uses:
★ Visu...
ability: what is understood or accomplished with
a tool
Techniques:
★ Prototypes
★ Usability Testing
★ Preference Intervie...
conceptual: how to get things done
Techniques:
★ Task Interviews
★ Contextual Inquiry
★ Preference Interviews
★ Surveys
Us...
analysis
★ Filling in the details
★ What is the system purpose (goals)?
★ What objects are involved?
★ Where is the system...
modelling

★ Data flow diagrams
★ Entity relationship diagrams
validation
Getting users to understand the implications of a
requirements specification and then agree, i.e. validate, tha...
decoding the
subjective
nice pants
users

<3
technology

business
trade-off analysis
Requirements are often held by different stakeholders who
may have conflicting views, hence trade-off a...
trade-off analysis
exercise
negotiation

A discussion, explanation and negotiation of conflicting
requirements
putting it into practice
putting it into practice
1.
2.
3.
4.
5.
6.
7.
8.

Submission or request
Scoping
Fact gathering and research
Analysis
Model...
1. request : prepare an informal 2 course
dinner for 4

Must have:
★ Protein
★ Carbohydrates
★ Vegetables
★ Something swee...
2. scoping
Boundaries:
★ Dinner means after 5pm
★ Guests are available most of July
★ 2 courses are main and dessert
★ Veg...
3. fact gathering and research
Guest interviews:

★ Shellfish allergy
★ Enjoy spicy, ethic food
★ Favourite vegetables are...
4. analysis

★ Purpose of the dinner is to celebrate a birthday
★ The host is one of the four The location will be on the
...
5. recipe for moros y cristianos - (data modelling)
1 Small Spanish Onion – (diced small)
1 Small Cubanelle Pepper (diced ...
_http://theposhlatincook.com/tag/dominican-rice-and-beans-recipe/
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 produc...
8. negotiation
★ Documentation: menu and ingredients
★ List of assumptions and constraints
★ Finalized budget, schedule an...
an emerging field
Requirements Engineering is"designing the right thing" as
opposed to software engineering’s "designing t...
Thanks | Questions?
The Art and Science of Requirements Gathering
The Art and Science of Requirements Gathering
The Art and Science of Requirements Gathering
The Art and Science of Requirements Gathering
Upcoming SlideShare
Loading in …5
×

The Art and Science of Requirements Gathering

3,052 views

Published on

Published in: Technology, Education
  • Be the first to comment

The Art and Science of Requirements Gathering

  1. 1. The Art & Science of Requirements Gathering Vanessa Turke UX Professional, Information Architect & Project Manager
  2. 2. presentation agenda: 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
  3. 3. 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
  4. 4. http://www.projectcartoon.com
  5. 5. why we need to get better as this
  6. 6. 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 http://royal.pingdom.com/2013/01/16/internet-2012-in-numbers/
  7. 7. with more and more competition, organizations will be determined to ‘stand out’ and many will not be able to express why and how they want to do this
  8. 8. features can be difficult to prioritize, and sometimes the focus ends up on the wrong content
  9. 9. when stakeholders come from a variety of backgrounds, submitted requirements documentation can be varied and inconsistent
  10. 10. documentation arrives in many different forms
  11. 11. when stakeholders come from a variety of backgrounds, submitted requirements documentation can be varied and inconsistent
  12. 12. from super high level, to incredibly granular
  13. 13. what are we receiving as “specifications” 1. Request for proposal 2. Wireframes 3. Data base schema 4. Project charter 5. Text requirements list 6. Entity relationships 7. Photoshop files 8. Publication workflows 9. Powerpoint presentations 10. Spreadsheets 11.User stories 12. Branding guidelines
  14. 14. have a goal to achieve consistency in documentation, define a common language, and strive to fill in gaps, constraints and assumptions
  15. 15. something here
  16. 16. 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 requirements specification. http://www.scrumalliance.org/community/articles/2010/april/new-to-user-stories
  17. 17. 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 http://www.scrumalliance.org/community/articles/2010/april/new-to-user-stories
  18. 18. 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 Examples are: ★ requirement specification ★ design specification ★ product specification ★ test specification
  19. 19. 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 coding. http://www.scrumalliance.org/community/articles/2010/april/new-to-user-stories
  20. 20. 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 response.
  21. 21. 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
  22. 22. typical user story template As a [type of site visitor] I need a way to [do something] so that I can [benefit somehow].
  23. 23. gherkin syntax 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 http://docs.behat.org/guides/1.gherkin.html
  24. 24. comparing approaches to writing requirements 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. http://www.scrumalliance.org/community/articles/2010/april/new-to-user-stories
  25. 25. all rightie then... Requirements: a wish list of capabilities, as described in detailed specifications 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 or result http://en.wikipedia.org/wiki/Scope_(project_management)
  26. 26. 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.
  27. 27. process to manage the knowledge gap product & process experts target knowledge simplifying training current knowledge new clients Jared Spool: http://chicago2011.drupal.org/keynotes
  28. 28. requirements engineering activities and process 1. Submission or Request 2. Scoping 3. Fact gathering and research 4. Analysis 5. Modelling 6. Validation 7. Trade-off Analysis 8. Negotiation
  29. 29. scoping 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.
  30. 30. 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. http://en.wikipedia.org/wiki/Scope_(project_management)
  31. 31. fact gathering and research Background research: interviews, observation, questionnaires, text and document analysis
  32. 32. 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 http://www.usabilityfirst.com/usability-methods/
  33. 33. preferences: opinions and desires Techniques: ★ Surveys ★ Focus Groups ★ Preference Interviews ★ Card Sorting Uses: ★ Visual Interpretation ★ Branding ★ Target Market
  34. 34. ability: what is understood or accomplished with a tool Techniques: ★ Prototypes ★ Usability Testing ★ Preference Interviews ★ Log Analysis ★ Customer Feedback ★ Card Sorting Uses: ★ Interaction Design ★ Interaction Flow ★ Page Layout ★ Nomenclature
  35. 35. conceptual: how to get things done Techniques: ★ Task Interviews ★ Contextual Inquiry ★ Preference Interviews ★ Surveys Uses: ★ Software Structure ★ Information Architecture ★ Content Location ★ Contextual Information ★ Contextual Marketing ★ Gap Analysis
  36. 36. 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)?
  37. 37. modelling ★ Data flow diagrams ★ Entity relationship diagrams
  38. 38. validation 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
  39. 39. decoding the subjective
  40. 40. nice pants
  41. 41. users <3 technology business
  42. 42. trade-off analysis 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. http://www.interaction-design.org/encyclopedia/requirements_engineering.html
  43. 43. trade-off analysis exercise
  44. 44. negotiation A discussion, explanation and negotiation of conflicting requirements
  45. 45. putting it into practice
  46. 46. putting it into practice 1. 2. 3. 4. 5. 6. 7. 8. Submission or request Scoping Fact gathering and research Analysis Modelling Validation Trade-off analysis Negotiation
  47. 47. 1. request : prepare an informal 2 course dinner for 4 Must have: ★ Protein ★ Carbohydrates ★ Vegetables ★ Something sweet
  48. 48. 2. scoping Boundaries: ★ 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
  49. 49. 3. fact gathering and research Guest interviews: ★ 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
  50. 50. 4. analysis ★ 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
  51. 51. 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 markets 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 _http://theposhlatincook.com/tag/dominican-rice-and-beans-recipe/
  52. 52. _http://theposhlatincook.com/tag/dominican-rice-and-beans-recipe/
  53. 53. 6. validation - walkthrough Platillo Moros y Cristianos is a famous Cuban dish
  54. 54. 6. validation - walkthrough Creme Caramel is a dessert served in Cuba
  55. 55. 7. trade-off analysis ★ Chocolate vs. vanilla? ★ Add a birthday cake or include candles? ★ Organic vs. conventional produce? ★ Have the dinner indoors if raining?
  56. 56. 8. negotiation ★ Documentation: menu and ingredients ★ List of assumptions and constraints ★ Finalized budget, schedule and scope
  57. 57. 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 subsequent implementation". ~ Nuseibeh and Easterbrook, 2000
  58. 58. Thanks | Questions?

×