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.

1. UNDERSTANDING REQUIREMENTSGreg Thomas

2. RequirementsThe lifeblood of any software Endeavour.

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. Who gets the blame?
When a product misses the mark?
The people who wrote the requirements!

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. It must be the fault
of the requirementsRight?

7. WRONG
WRONG
WRONG

8. WRONG!Bad requirements are everyone’s fault,
not just the person who put pen to
paper.

9. TEsters
Whose responsible?

10. everyoneEveryone has a part to play in
delivering the best product possible
and that comes down to everyone
helping on requirements.

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. 1
28
46
5
7 3
So where
do you
start?

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. #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. • 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. #4 - SAndbox
What world does your
requirement operate in?
Keep it there, don’t jump all over
the place, stay focused.

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. #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. 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. 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. Don’t believe me?
Then you’ve already forgotten Rule #6!