TOM GILB, “WHAT'S WRONG WITH REQUIREMENTS
SPECIFICATION? AN ANALYSIS OF THE
FUNDAMENTAL FAILINGS OF CONVENTIONAL
THINKING ABOUT SOFTWARE REQUIREMENTS, AND
SOME SUGGESTIONS FOR GETTING IT RIGHT. “
J. SOFTW. ENGINEERING & APPS. 3(9) PP. 827-838
SEP 2010
CONSULTANT, AUTHOR, BLOGGER
KNOWN GUEST LECTURER
50+ YEARS OF EXPERIENCE
Presented by Lior Ebel
Summary
2

Bad requirements often lead to project failure

Problems:
 We
think as programmers, not as Engineers/Managers
 Code delivery, use cases & functions take over value
delivery
 Management does not work to improve this

10 principles for improvement are outlined
1ST PRINCIPLE: UNDERSTAND
THE TOP LEVEL CRITICAL
OBJECTIVES
‘Worst Requirement Sin of All’
What’s Typically Wrong
4

Not measurable or quantified


Mixing optional designs


E.g. “need password” instead of “need X level security”
Insufficient background description


E.g. “Will provide a much more efficient user experience”
E.g. “Major improvements in data quality over current practices”
Failure to sufficiently explain business target details
How to Get it Right
5



Top 10 critical requirements should (and can) be put
in one page
Can take one day of work to reach a good first
draft
Case study: It took 1 hour to rewrite one of the
previous problematic requirements to be clear,
measurable & quantified
2ND PRINCIPLE: LOOK
TOWARDS VALUE DELIVERY
Systems Thinking, not Just a Focus on Software
Concentrate on Value
7




Value: The benefit we think we get from something
Requirements typically are not closely enough
coupled with value
We concentrate on functionality & user stories
Product owners and marketing management define
value
Concentrate on Value – Cont’d
8

Dangers:
 Failure
to deliver value, even if requirements met
 Failure to understand full prerequisites needed to
deliver value

How can we systematically document value as part
of requirements?
 Planguage
language
– A proposed requirements specification
3RD PRINCIPLE: DEFINE A
‘REQUIREMENT’ AS A
‘STAKEHOLDER-VALUED END
STATE’
What is a ‘Requirement’?
10

Many opinions, most at variance with each other

Requirement: ‘stakeholder-valued end state’

Make a distinction:
A
requirement
 A requirement specification
 An implemented requirement
 A partial or full design of implementing a requirement
 Types & concepts of requirements: functional,
performance, resource and more
4TH PRINCIPLE: THINK
STAKEHOLDERS, NOT JUST
USERS AND CUSTOMERS!
Stakeholders
12

Stakeholder: anyone or anything that has an interest
in the system

Not only users & customers need to be considered

Stakeholders can be:
 IT
development/maintenance
 Senior management
 Government
 And more…
5TH PRINCIPLE: QUANTIFY
REQUIREMENTS AS BASIS
SOFTWARE ENGINEERING
The Problem
14


Classic Engineering is about
numbers & measures
So called ‘Software Engineers’ use only words to
define requirements
 E.g.

‘high usability’
Lord Kelvin (1824-1907): “If you can’t
measure it, you can’t improve it”
Quantification
15



Most software projects strive for
‘improved quality’ over previous products
Software Engineers quantify things, but we don’t
‘quantify quality’. Claim: any quality can be
quantified
Quality: How well something functions - a scalar or
binary value
Quantifying Quality with Planguage
16







Ambition: high-level summary
Scale: formal scale of measure
Meter: the measuring process/instrument
Meter ~= speedometer , Scale ~= Km/hour
Goal: requirement level type – stakeholder valued future state (80% ±
10%)
There is also a Value language element (to support 2nd Principle)
Example:
6TH PRINCIPLE: DON’T MIX
ENDS AND MEANS
End and Means
18



We specify solutions & designs instead of value or
quality requirements
Reason: solutions are easier - concrete and not
abstract
Problems:
 Might
not get where we really want
 Solution described by us might not be optimal

Why do I want X? because I want Y, and assume I’ll
get it with X. Why do I want Y?...
7TH PRINCIPLE: FOCUS ON
REQUIRED SYSTEM QUALITY,
NOT JUST ITS FUNCTIONALITY
Functionality vs. Quality
20

Functionality: what a system does

Quality: how well it does it

Quality improvements drive most new projects


Requirements focus too much on functionality and
too little on quality
Example of good quality statement: “Time to set up
typical market research report has reduced from
65 min to 20 min”
8TH PRINCIPLE: ENSURE THERE
IS ‘RICH SPECIFICATION’
Requirement Specifications need Far More
Information than the Requirement itself
Requirement Background
22


Requirement itself: Scale, Meter, Goal, Definition,
Constraint, Value, etc.
Requirement background: Useful information, not central
for implementation


Benchmarks, Owner & Stakeholders, Version, Impact &
Supports
Benefits:

Helps prioritize, understand, present for audience, establish
relationships and dependencies between requirements
9TH PRINCIPLE: CARRY OUT
SPECIFICATION QUALITY
CONTROL (SQC)
Control the Quality of Requirements
24


Requirements specifications should pass quality
control tests before being internally released
Claim: Initial inspection of new requirements
validating rules:
 ‘Unambiguous
to reader’
 Testable
 ‘No
optional design’
Finds 26% - 66% of text as ambiguous or unclear
10TH PRINCIPLE: RECOGNIZE
THAT REQUIREMENT CHANGE
Use Feedback and Update Requirements as
Necessary
Requirements are Dynamic
26


Develop requirements with ongoing feedback from
stakeholders about value
External factors can change requirements:
 Politics
 Law
 International
differences
 Economics
 Technological

change
Prepare and support an evolving process
Final Words & Conclusions
27




Requirements are problematic
Gilb is pessimistic about the future, and says
requirements process should be thought at University
Gilb proposes 10 principles
My opinion:
 Well
written, important for sw. eng. because it exhibits
the fundamental problems
 The methods proposed do not immediately justify
massive investment, but are rather ‘best practices’
 A positive step, not mature yet
THANK YOU! QUESTIONS?