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.
UNDERSTANDING REQUIREMENTSGreg Thomas
RequirementsThe lifeblood of any software Endeavour.
1 23
Determine your succesGreat requirements always lead to success while poor requirements ultimately
lead to failure and...
Who gets the blame?
When a product misses the mark?
The people who wrote the requirements!
Why?Because requirements have the ability to;
• Define the vision
• Enunciate the goals and objectives of the system.
• Ou...
It must be the fault
of the requirementsRight?
WRONG
WRONG
WRONG
WRONG!Bad requirements are everyone’s fault,
not just the person who put pen to
paper.
TEsters
Whose responsible?
everyoneEveryone has a part to play in
delivering the best product possible
and that comes down to everyone
helping on req...
Vision
System
Idea
Innovation
PLACEHOLDER
Audience
Installation
Customer
Fearless
Upgrade
Control
PLACEHOLDER
LEAD• Someon...
1
28
46
5
7 3
So where
do you
start?
#1 - Know your audience
Stakeholders don’t care about Product Backlog Items.
They care about the story and the translation...
#2 - Tell a Story
Don’t get sucked into metholodiges – what
worked for one person might not work for
you.
When you start w...
• What must exist in your world for
your requirements to work?
• Define the Pre and Post Conditions
2
1
4
3
#3 - Outline D...
#4 - SAndbox
What world does your
requirement operate in?
Keep it there, don’t jump all over
the place, stay focused.
#5 - Scenario AnalysisRun through the happy and edge paths, define them, why do they exist,
who do they serve, is it for y...
#6 - Common Sense
If it doesn’t fit,
if it seems out of place,
don’t put it in there.
If you need more information,
add it...
Who benefits from all these?
Role Audience Story Dependencies Sandbox Scenarios Common
Sense
Developer X X X X X X
Tester ...
BE AWAREDon’t get pulled into writing a requirement in a specific way
because the methodology “du jour” says you have to O...
Don’t believe me?
Then you’ve already forgotten Rule #6!
Upcoming SlideShare
Loading in …5
×
Upcoming SlideShare
OneHourOfCode
Next
Download to read offline and view in fullscreen.

3

Share

Download to read offline

How to write Great Requirements

Download to read offline

A presentation on writing software requirements that does not prescribe to any established methodology but instead is based on the idea of knowing your audience and common sense.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

How to write Great Requirements

  1. 1. UNDERSTANDING REQUIREMENTSGreg Thomas
  2. 2. RequirementsThe lifeblood of any software Endeavour.
  3. 3. 1 23 Determine your succesGreat requirements always lead to success while poor requirements ultimately lead to failure and confusion. Requirements that are “meh” can take last place for not having even tried.
  4. 4. Who gets the blame? When a product misses the mark? The people who wrote the requirements!
  5. 5. Why?Because requirements have the ability to; • Define the vision • Enunciate the goals and objectives of the system. • Outline the users and audience of the application. • Account for all dependencies and interactions In essence – they weave the story as to how a user traverses your application.
  6. 6. It must be the fault of the requirementsRight?
  7. 7. WRONG WRONG WRONG
  8. 8. WRONG!Bad requirements are everyone’s fault, not just the person who put pen to paper.
  9. 9. TEsters Whose responsible?
  10. 10. everyoneEveryone has a part to play in delivering the best product possible and that comes down to everyone helping on requirements.
  11. 11. Vision System Idea Innovation PLACEHOLDER Audience Installation Customer Fearless Upgrade Control PLACEHOLDER LEAD• Someone has to take the lead • But it’s always a group effort.
  12. 12. 1 28 46 5 7 3 So where do you start?
  13. 13. #1 - Know your audience Stakeholders don’t care about Product Backlog Items. They care about the story and the translation of their requests into an application. Know who you are writing for! idea
  14. 14. #2 - Tell a Story Don’t get sucked into metholodiges – what worked for one person might not work for you. When you start writing a requirement a certain way “just becase”, you’ve already lost your way.
  15. 15. • What must exist in your world for your requirements to work? • Define the Pre and Post Conditions 2 1 4 3 #3 - Outline Dependencies
  16. 16. #4 - SAndbox What world does your requirement operate in? Keep it there, don’t jump all over the place, stay focused.
  17. 17. #5 - Scenario AnalysisRun through the happy and edge paths, define them, why do they exist, who do they serve, is it for your audience?
  18. 18. #6 - Common Sense If it doesn’t fit, if it seems out of place, don’t put it in there. If you need more information, add it in!
  19. 19. Who benefits from all these? Role Audience Story Dependencies Sandbox Scenarios Common Sense Developer X X X X X X Tester X X X X X X Product Owner X X X X X X Stakehold er X X X X X X Product Manager X X X X X X X X X X X X
  20. 20. BE AWAREDon’t get pulled into writing a requirement in a specific way because the methodology “du jour” says you have to OR ELSE!
  21. 21. Don’t believe me? Then you’ve already forgotten Rule #6!
  • julianthefrank

    Nov. 24, 2017
  • VagnerReis6

    Aug. 30, 2015
  • GregThomas3

    Jul. 25, 2015

A presentation on writing software requirements that does not prescribe to any established methodology but instead is based on the idea of knowing your audience and common sense.

Views

Total views

1,811

On Slideshare

0

From embeds

0

Number of embeds

318

Actions

Downloads

36

Shares

0

Comments

0

Likes

3

×