Post on 14-May-2015
description
GETTING TO THE COREREQUIREMENTS GATHERING IN THE WILD
SPEAKERS
Femke Goedhart
Business Consultant - Silverside, The Netherlands
f.goedhart@Silverside.nl
@FemkeGoedhart
nl.linkedin.com/in/femkegoedhart
Sophie Lavignac-Le Madec
Senior Engineer Messaging & Collaboration at SES, Luxembourg
sophie.lavignac@ses.com
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
ROI?
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
Software Requirements Third edition, Wiegers & Beatty
Requirements Engineering
Requirements Development Requirements Management
Analysis ValidationSpecificationElicitation Change Mgt
Software Requirements Third edition, Wiegers & Beatty
ElicitationRequirements DevelopmentRequirements Engineering
Budget & Time?
Waterfall or Agile?
User centric or Product centric?
SCOPE
ElicitationRequirements DevelopmentRequirements Engineering
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…….
ElicitationRequirements DevelopmentRequirements Engineering
Who will use it?
Who will depend on it?
Who has a stake in it?OW
NER
ElicitationRequirements DevelopmentRequirements Engineering
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
• ….
ElicitationRequirements DevelopmentRequirements Engineering
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
• ….
ElicitationRequirements DevelopmentRequirements Engineering
Talking
!=
Listening!
METHODS
ElicitationRequirements DevelopmentRequirements Engineering
Creative Problem Solving (Isaken & Treffinger) • Mess finding • Data finding • Problem finding • Idea finding • Solution finding • Acceptance finding
METHODS
ElicitationRequirements DevelopmentRequirements Engineering
Iterative question asking (Sakichi Toyoda) • Why? • Why? • Why? • Why? • Why? <-Root cause
ElicitationRequirements DevelopmentRequirements Engineering
Requirements Engineering
Requirements Development Requirements Management
Analysis ValidationSpecificationElicitation Change Mgt
Software Requirements Third edition, Wiegers & Beatty
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
AnalysisRequirements DevelopmentRequirements Engineering
MOSCOWAnalysisRequirements DevelopmentRequirements Engineering
• Must • Should • Could • Won’t (or would)
MOSCOWAnalysisRequirements DevelopmentRequirements Engineering
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
MOSCOWAnalysisRequirements DevelopmentRequirements Engineering
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)
AnalysisRequirements DevelopmentRequirements Engineering
KEEP IT SIMPLE STUPID
Requirements Engineering
Requirements Development Requirements Management
Analysis ValidationSpecificationElicitation Change Mgt
Software Requirements Third edition, Wiegers & Beatty
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
SpecificationRequirements DevelopmentRequirements Engineering
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…”
SpecificationRequirements DevelopmentRequirements Engineering
TALK THE TALK…
SpecificationRequirements DevelopmentRequirements Engineering
User
??
Developer
??
TALK THE TALK…
SpecificationRequirements DevelopmentRequirements Engineering
User
??
Developer
??
Management
$$$?
example
ElicitationRequirements DevelopmentRequirements Engineering
ElicitationRequirements DevelopmentRequirements Engineering
Requirements Engineering
Requirements Development Requirements Management
Analysis ValidationSpecificationElicitation Change Mgt
Software Requirements Third edition, Wiegers & Beatty
EXPECTATION GAPValidationRequirements DevelopmentRequirements Engineering
Time —>
What the developer builds
What the user wants
Expectation gap
Software Requirements Third edition, Wiegers & Beatty
EXPECTATION GAPValidationRequirements DevelopmentRequirements Engineering
Time —>
What the developer builds
What the user wants
Expectation gap
contact pointcontact point
Software Requirements Third edition, Wiegers & Beatty
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!
ValidationRequirements DevelopmentRequirements Engineering
4-EYES PRINCIPLE
ValidationRequirements DevelopmentRequirements Engineering
ValidationRequirements DevelopmentRequirements Engineering
SIGN OFF ON THE REQUIREMENT BASELINE
ElicitationRequirements DevelopmentRequirements Engineering
Example
Requirements Engineering
Requirements Development Requirements Management
Analysis ValidationSpecificationElicitation Change Mgt
Software Requirements Third edition, Wiegers & Beatty
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”
Change managementRequirements DevelopmentRequirements Engineering
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
Change managementRequirements DevelopmentRequirements Engineering
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
f.goedhart@Silverside.nl
@FemkeGoedhart
nl.linkedin.com/in/femkegoedhart
Sophie Lavignac-Le Madec
sophie.lavignac@ses.com
lu.linkedin.com/pub/sophie-le-madec/6/2b0/653