Getting to the core, requirements gathering in the wild

GETTING TO THE COREREQUIREMENTS GATHERING IN THE WILD

SPEAKERS

Femke Goedhart

Business Consultant - Silverside, The Netherlands

[email protected]

@FemkeGoedhart

nl.linkedin.com/in/femkegoedhart

Sophie Lavignac-Le Madec

Senior Engineer Messaging & Collaboration at SES, Luxembourg

[email protected]

lu.linkedin.com/pub/sophie-le-madec/6/2b0/653

mailto:[email protected]

http://nl.linkedin.com/in/femkegoedhart

http://lu.linkedin.com/pub/sophie-le-madec/6/2b0/653

“Knowing what you get before you get it”

REALITY….

It’s all critical!No timeWe assumed…

Scope???

THEY DON’T USE IT

DEVELOPMENT WORK

Rework40%

Development60%

Shull et al. 2002, GAO 2004

INFLUENCE OF REQUIREMENTS ON REWORK

Rework40%

Requirement Errors75%

Other25%

Leffingwell 1997

COST OF REWORK

1x

Requir

emen

ts

phase

Develo

pmen

t

phase Pr

oduc

tion

phase

COST OF REWORK

1x

2-3x

Requir

emen

ts

phase

Develo

pmen

t

phase Pr

oduc

tion

phase

Requir

emen

ts

phase

Develo

pmen

t

phase Pr

oduc

tion

phase

1x

2-3x

100x

Boehm 1981; Grady 1999; Haskins 2004

COST OF REWORK

All we really need is some document

management!Ok, but is that all?

Example

Well yes, but we expect it to also do … and … and …

Mmm…. ok, is document

management really what you need then?

Example

Development phase

Requirements phase

Signoff

$$$

$

REQUIREMENTSVision & Scope

User Requirements

Software Requirements specification

INCREASING LEVELS OF DETAILS:

Vision & Scope document

User requirements document

Software requirements specification

Business requirementBusiness rules

User requirement

Quality Attribute

External interfaces

Functional requirement

System requirement

Constraints

Non-Functional requirement

Software Requirements Third edition, Wiegers & Beatty

START WITH THE WHY

Vision & Scope document

User requirements document

Software requirements specification

WHY

HOW

WHAT

REQUIREMENT DOCUMENTS?

Vision & Scope

User Requirements

Software Requirements specification

Project Charter

Functional Design

Technical Design

Project requirements document

Project initiation document

etc, etc…

Requirements Engineering

Requirements Development Requirements Management

Analysis ValidationSpecificationElicitation Change Mgt

STAGES


ElicitationRequirements DevelopmentRequirements Engineering

Budget & Time?

Waterfall or Agile?

User centric or Product centric?

SCOPE


Discover

Design

Develop

Test

Discover

Dev

elop

Design

Test

Sprint #1

Sprint #2

Sprint #3

Discover

Dev

elop

DesignTest

Discover

Dev

elop

Design

Test

AGILE OR

WATERFALL?

WHO ?ElicitationRequirements DevelopmentRequirements Engineering

OWNER

WHO ELSE?ElicitationRequirements DevelopmentRequirements Engineering

Who will use it?

Who will depend on it?

Who has a stake in it?OW

NER

WHO ELSE?• Direct users

• Indirect users

• Stakeholders

• Sponsors

• Acquirer

• Management

• Compliance auditor

• Suppliers

• Regulatory body

• Quality assurance

• Etc, etc…….


Who will use it?

Who will depend on it?

Who has a stake in it?OW

NER


Yes! that’s what we want!

Well I think something else is more important!

That’s not what I wanted!

Example

TACTICS FOR GATHERING REQUIREMENTS

• Interviews

• Focus groups

• Observation

• Document studies

• RFP Documents

• Workshops

• Questionnaires

• Incident & compliance systems

• SME’s

• Market research

• Review of current systems

• ….


TACTICS FOR GATHERING REQUIREMENTS

• Interviews

• Focus groups

• Observation

• Document studies

• RFP Documents

• Workshops

• Questionnaires

• Incident & compliance systems

• SME’s

• Market research

• Review of current systems

• ….


Talking

!=

Listening!

METHODS


Creative Problem Solving (Isaken & Treffinger) • Mess finding • Data finding • Problem finding • Idea finding • Solution finding • Acceptance finding

METHODS


Iterative question asking (Sakichi Toyoda) • Why? • Why? • Why? • Why? • Why? <-Root cause

SMART• Specific

• What? Why? Who? Where? Which?

• Measurable • How much? How many? Is it quantifiable?

• Attainable • Can it be achieved with the resources & facilities available?

• Relevant • Does it relate to the project vision & scope?

• Timely • Can I set a date to it?

AnalysisRequirements DevelopmentRequirements Engineering

PRIORITISE


MOSCOWAnalysisRequirements DevelopmentRequirements Engineering

• Must • Should • Could • Won’t (or would)


Requirement M S C W

Insert multiple order lines x

Create an export of closed orders x

Allow to copy order details to allow quick registration x

Allow for inserting personal notes on orders x


Requirement Costs M S C W

Insert multiple order lines $100 x

Create an export of closed orders $1500 x x

Allow to copy order details to allow quick registration $250 x

Allow for inserting personal notes on orders $100 x x

EISENHOWER DECISION MATRIXAnalysisRequirements DevelopmentRequirements Engineering

Urgent Not Urgent

Important

Not Important

PRIORITISEAnalysisRequirements DevelopmentRequirements Engineering

Urgent Not Urgent

Important Must! Should

Not Important Could

Won’t (Nice to

have)


KEEP IT SIMPLE STUPID

UNIFIED MODELLING LANGUAGE

Structural UML diagrams

• Class diagram

• Component diagram

• Composite structure diagram

• Deployment diagram

• Object diagram

• Package diagram

• Profile diagram

SpecificationRequirements DevelopmentRequirements Engineering

Behavioural UML diagrams

• Activity diagram

• Communication diagram

• Interaction overview diagram

• Sequence diagram

• State diagram

• Timing diagram

• Use case diagram


VISUALISE

WRITE IT DOWN • Build prototypes

• Provide demo’s of similar functionality

• Models & Diagrams

• Draw out process- and workflows

• Mockups of screens & forms

• Use cases, function descriptions

• Tell it as a story: “a day in the life of…”


TALK THE TALK…


User

??

Developer

??

TALK THE TALK…


User

??

Developer

??

Management

$$$?

example


EXPECTATION GAPValidationRequirements DevelopmentRequirements Engineering

Time —>

What the developer builds

What the user wants

Expectation gap


EXPECTATION GAPValidationRequirements DevelopmentRequirements Engineering

Time —>

What the developer builds

What the user wants

Expectation gap

contact pointcontact point


PLAY IT BACK!

“I ‘ve heard that…”

“I understand you want…”

“You expect it to…”

etc. etc…

ValidationRequirements DevelopmentRequirements Engineering

ROLE

Check your personal feelings at the door but don’t forget to keep an eye on project

scope & constraints!


4-EYES PRINCIPLE



SIGN OFF ON THE REQUIREMENT BASELINE


Example

Change managementRequirements DevelopmentRequirements Engineering

THINGS CHANGE

– Douglas Hofstadter

“Hofstadter's Law: It always takes longer than you expect, even when you

take Hofstadter's Law into account”


MANAGE CHANGES• Set up a formal RFC (Request For Change) process

• Register all changes and use version control

• Translate into effect (impact on time, costs & end result)

• (Re-)Prioritise

• Communicate

• Sign off on changed requirements


WRAP UP

• Treat Requirements Gathering as if it’s a project on its own

• Assign or free up enough resources

• Evaluate afterwards (improvements for future projects)

• Incorporate an outsiders view

• Don’t set it in stone…. things change, just make sure you manage it!

• Be open… you might be pleasantly surprised!

QUESTIONS?

Femke Goedhart

[email protected]

@FemkeGoedhart

nl.linkedin.com/in/femkegoedhart

Sophie Lavignac-Le Madec

[email protected]

lu.linkedin.com/pub/sophie-le-madec/6/2b0/653

mailto:[email protected]

http://nl.linkedin.com/in/femkegoedhart

http://lu.linkedin.com/pub/sophie-le-madec/6/2b0/653

Getting to the core, requirements gathering in the wild

Technology

Transcript of Getting to the core, requirements gathering in the wild