UNDERSTANDING REQUIREMENTS

Greg Thomas

Requirements

The lifeblood of any software Endeavour.

1 23

Determine your succes

Great 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.

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.

• 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.

It must be the fault of the requirementsRight?

WRONGWRONG

WRONG

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

TEsters

DEVELOPERS

The

Inte

rn

Product Owners

STakeHolders

Whose responsible?

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

Vision

SystemIdea

InnovationPLACEHOLDER

Audience

Installation

Customer

FearlessUpgrade

Control

PLACEHOLDER

LEAD• Someone has to take

the lead

• But it’s always a group effort.

1

28

46

5

7 3

So where do you start?

#1 - Know your audienceStakeholders 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

#2 - Tell a StoryDon’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.

• What must exist in your world for your requirements to work?

• Define the Pre and Post Conditions

2

1

4

3

#3 - Outline Dependencies

#4 - SAndboxWhat 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 your audience?

#6 - Common SenseIf it doesn’t fit,

if it seems out of place,

don’t put it in there.

If you need more information,

add it in!

Who benefits from all these?Role Audience Story Dependencies Sandbox Scenarios Common

Sense

Developer X X X X X XTester X X X X X XProduct Owner

X X X X X X

Stakeholder

X X X X X X

Product Manager

X X X X X X

X X X X X X

BE AWAREDon’t get pulled into writing a requirement in a specific way because the methodology “du jour” says you have to OR ELSE!

Don’t believe me?Then you’ve already forgotten Rule #6!