Thinking about
Requirements Engineering:
some basic principles
Karl Cox
Empirical Software Engineering
National ICT Australia and
Computer Science and Engineering
UNSW
Outline
• What is Requirements Engineering?
• Some issues with typical analysis
• Basic principles of Requirements
Engineering
• Summary
• References
What is Requirements Engineering?
•
•
•
•
Definitions
Track record
What Requirements Engineering really is
Phenomena
Some Requirements Definitions
• ZAVE (1997)
– “Requirements engineering… is concerned with
the real-world goals for functions of and
constraints on software systems. It is also
concerned with the relationship of these factors to
precise specifications of software behaviour…”
• SWEBOK (2001)
– “A requirement is defined as a property that must
be exhibited in order solve some problem of
the real world.”
• Robin Goldsmith (2004)
– “What must be delivered to provide
value.”
Software Project Track Record
• Chaos reports: 75% of projects failed or
failed to deliver key functions.
– Why? Poor / no requirements engineering.
• 2004 JobServe report: only 16% of UK
software projects are successful.
– Why? Poor / no analysis skills.
– “Projects are often poorly defined, codes of
practice are frequently ignored and there is
a woeful inability to learn from past
experience," says Professor John
McDermid
What Requirements
Engineering really is
• ZAVE (1997)
– “Requirements engineering… is concerned with
the real-world goals for functions of and
constraints on software systems. It is also
concerned with the relationship of these factors to
precise specifications of software behaviour…”
• SWEBOK (2001)
– “A requirement is defined as a property that must
be exhibited in order solve some problem of
the real world.”
• Robin Goldsmith (2004)
– “What must be delivered to provide
value.”
Where (Not what and how)
The
Computer
and
Program
The solution is
here
The World
outside the
Computer
Connections
between the
world and the
computer
The problem
is here
Phenomena
Real World
phenomena
Application
Domain
Specification
phenomena
Interface
Solution
phenomena
Machine
Some issues with
typical analysis
•
•
•
•
•
Formal methods
Context Diagrams
Object-oriented analysis
Use case analysis
Non-functional requirements
Insanity
• “We receive the results we create. As
an industry, we keep doing the same
things and expecting a different result.
That’s the definition of insanity.”
• Robin F. Goldsmith, Discovering the REAL
Business Requirements for Software Project
Success, Artech House Books, 2004
Formal Methods … and
Ambiguity
Shoes
Must Be
Worn
x  (OnEscalator(x) 
y  (PairOfShoes(y)  IsWearing (x, y))
For each individual x that is on the escalator, there is at least
one y such that y is a pair of shoes and x is wearing y.
Formal Methods … and
Ambiguity
Dogs Must
Be Carried
x  ((OnEscalator(x)  IsDog(x))  IsCarried(x))
For each individual x that is on the escalator and is a dog,
that individual is being carried.
One more for fun
Thoroughfare Only:
Passengers Must Not
Travel Between the Doors
I wouldn’t want to begin to describe this formally!
Precisely
• “There’s no point being precise about something
when you don’t know what it is you are talking
about” - John von Neumann.
• Formalism is useful only when you are confident it
represents the real world precisely AND that it is
necessary at all.
• And unfortunately this is what the formal methods
and mathematics advocates typically DON’T DO.
They forget about the informal real world because
it is too ambiguous.
• Formal methods / mathematics can only be the
handmaiden of software engineering, not the
Queen.
Context Diagrams 1
Warehouse
Orders
Customers
Shipping
Info
Acknowledgements
Order
Processing
Accounting
Info
Accounts
Dept.
“The Context Diagram documents the domain of study by
showing the set of data flows that cross into and out of the
domain.”
- Tom DeMarco, Structured Analysis and System Specification, 1978.
Context Diagrams 2
• DeMarco’s ‘domain of study’ is the system.
• “Boxes (representing sources and sinks) are used
rather sparingly in Data Flow Diagrams, and
usually not in a very rigorous fashion. Since they
represent something outside the area of our major
concern, they exist only to provide commentary
about the system’s connection to the outside
world.” - DeMarco.
• In this kind of Structured Analysis, the Context
Diagram shows the context of the system, not the
context of the problem.
Context Diagrams 3
• We should be interested in more than the
context of the system. A requirement resides
in the problem domain, or Application
Domain.
• If we want to know anything about our
requirements we must know something about
our problem context.
• We should be showing all the domains
relevant to our problem and the connections
between domains as well as the MACHINE
(general purpose computer which we
program to meet our requirements).
Context Diagrams 4
Analog
devices
e
ICU
Patients
d
c
Nurse’s
Station
Machine
b
Medical
Staff
a
Periods
& Ranges
Context Diagrams 4
Analog
devices
e
ICU
Patients
d
c
Nurse’s
Station
Machine
b
Medical
Staff
a
Periods
& Ranges
a: Period, Range, PatientName, Factor
b:EnterPeriod, EnterRange, Enter PatientName, EnterFactor
c:Notify
d:RegisterValue
e: FactorEvidence
Remember Phenomena
Real World
phenomena
Application
Domain
Specification
phenomena
Interface
Solution
phenomena
Machine
Remember Phenomena
Real World
phenomena
Application
Domain
Specification
phenomena
Interface
Solution
phenomena
Machine
Object-Oriented Analysis
• Seamless Development
– Object-oriented programming promised the idea of
encapsulation and this presented a way to
represent things in the real world.
– A software object could be represented as a
design object which was a representation of an
analysis object.
– The assumption was that to represent the real
world as an object was simple.
Object-Oriented Analysis 2
• Data-driven and process-focussed in one
• Objects are considered superior to entities
in an ERD and processes in a DFD as
they capture both in one diagrammatic
element.
• Most of UML’s class modelling is really
entity-relationship modelling.
Object-Oriented Analysis 3
• “Object-oriented designers do not usually spend their time in
academic discussions on methods to find objects; in the
physical or abstract reality being modelled, the objects are just
there for the picking! The software objects will simply reflect
these external realities.”
– Bertrand Meyer, Object-Oriented Software Construction, 1988.
• Perhaps this is a little over the top. The idea of an object comes
from programming and doesn’t fit very well with individuals in
the real world.
• Individuals such as aeroplanes, tax returns and paychecks are
certainly potential objects in an OOA but it isn’t an exact
mapping.
– When did you last send a message to a paycheck?
– What reply would you get back if you sent a message to an aeroplane?
– What methods does a tax return perform in response to messages it
receives?
Object-Oriented Analysis 4
• When the sun rises, does it send a message
to each bird to tell it to start singing?
• Clearly this is nonsensical.
• To read up on what object-oriented can really
do for software engineering take a look at:
– Steve Cook and John Daniels, Designing Object
Systems, 1994
3 Restrictions on OOA - 1
• Each object belongs to a fixed class,
determined when the object is created.
• But the world is not like this:
–
–
–
–
–
–
pupils become teachers
Bills become laws
Partnerships become corporations
Doctors become lawyers
Cotton mills become offices or hotels
Caterpillars become butterflies
3 Restrictions on OOA - 2
• Each object inherits properties and behaviour from
just one class at the next level up in the tree. That’s
single inheritance.
• But the world is not like this:
– The logistics manager wants to classify the company
equipment as production plant, office equipment and
distribution vehicles.
– The finance director classified it as owned, rented and
leased.
– The two classifications can’t coexist in the same singleinheritance hierarchy.
3 Restrictions on OOA - 3
• Objects are reactive rather than active. If you
don’t send a message to an object, it won’t do
anything.
• But the world is full of individuals, like
–
–
–
–
People
Vessels in chemical plants
Government departments
who all do things spontaneously.
• All these restrictions have programming
solutions - but they are no good at
representing the richness of the world.
Use Cases
• UML tells us that the way to do
requirements engineering is to capture
the functions that users want when they
use the computer.
• It’s the first question we ask our
customers, “What functionality do you
want?”
– This way madness lies.
Here’s a Use Case example
Borrow a book
Return a book
Library
Member
Renew a loan
Here’s the Use Case problem
The Library Member’s requirements:
borrow a book, return a book, renew
a loan
Issue a book
Process a book return
Library
Member
Libraria
n
The Librarian has to: issue a book, process
a book return, and issue a book renewal.
The Library Member’s requirements aren’t
quite the same as the Librarian’s tasks.
Issue a book renew
Use Case problems
• So what happens when a librarian’s job is to
loan books out and collect returns?
• What happens to the Library Member when
we cannot show actors one step removed
from the machine?
– Do we just forget about them or fudge them?
– But isn’t a library’s purpose to provide books and
services to its library members?
– And if we ignore this fact, what are we essentially
doing?
– We’re ignoring the problem context, and
– We’re ignoring the requirement.
– And that’s bad.
Non-functional Requirements
• “Not pertaining to the function (that is,
observable behaviour) of the machine, or to
the resulting observable effects in the
problem domain.”
• Some examples in this style,
–
–
–
–
The Ada programming language must be used;
The software must be delivered by 31 July;
The computer must be fully ruggedised;
All software modules must be tested at least up to
branch coverage;
– The software must be readily modifiable.
More non-functional
requirements
• Non-functional requirements, by their very
name, convey less importance than functional
requirements.
• Accept this at your peril.
• An example:
• “The staff meeting minutes must be
distributed to staff…
• within an hour of closing of the meeting.”
“Non-functional” examples
• These were considered non-functional for an office
lighting control system:
– The control panels should be easy and intuitive to use;
– No hazardous conditions for persons, equipments or the
building are allowed;
– The system issues warnings on unreasonable inputs at
its control panels;
– In any case of failure the system shall provide a
stepwise degradation of functionality down to manual
operability;
– If the outdoor sensor does not work correctly, the control
system for room lighting should behave as if the sensor
were continuing to show the last correct measurement
of outdoor light before the failure.
Non-functional really means…
•
•
•
•
You haven’t understood the problem in detail, so
You haven’t understood the requirement, meaning
You need to re-examine the problem in order to
Identify the real requirement.
• To separate function from non-function is
amateurism and over-complicates because
• it’s also hard to trace between both in
documentation, that’s why most documents don’t
even try,
• …and that’s where things can start to go wrong.
Insanity, revisited
• “We receive the results we create. As an
industry, we keep doing the same things and
expecting a different result. That’s the definition
of insanity.”
• Robin F. Goldsmith, Discovering the REAL Business
Requirements for Software Project Success, Artech House
Books, 2004
• Sticking to the typical ways will drive us all
insane. The answer’s not in the machine but in
the world.
• Would you use a hammer to paint a portrait?
That’s what it will feel like if you follow the latest
panacea and don’t question what you’re doing
and why.
Basic Principles of
Requirements Engineering
•
•
•
•
•
Jackson’s principles
Thinking outside the box
“Why isn’t important”
“It’s not a requirement if it isn’t implemented”
The Three Descriptions
Jackson’s Principles 1*
• The Principle of Dispassionate Methodology
– Don’t get your method advice from a method
enthusiast. The best advice comes from people
who care more about your problem than about
their solution.
– *These principles are taken from Michael Jackson’s,
Software Requirements and Specifications, 1995.
Jackson’s Principles 2
• The Principle of Beneficent Difficulty
– A method without limitations, whose
development steps are never impossible to
complete, whose stages diagnose and
recognise no difficulty, must be very bad
indeed.
• The Principle of Separation of Concerns
– Never mix intention and problem context in
the same description.
Jackson’s Principles 3
• The Principle of Close-Fitting Requirements Methods
– Close fitting requirements methods allow a good tight grip
on the problem.
• The Principle of Exploiting the Appropriate
Methodology
– A method should exploit the stipulated characteristics of the
principle parts of its problem.
• The Principle of Problem Sensitivity
– A method for solving problems must be closely expressed
in terms of the problems it can help you solve.
• If the method doesn’t talk about a problem, how can it help you
solve it?
Jackson’s Principles 4
• The Principle of Deferred Invention
– Invention should be delayed until description of
what is already given has been completed.
• The Principle of Commensurate Care
– The care taken in each aspect of a development
should be proportional to PxD, where P is the
probability that it will go wrong and D is the size of
the disaster if it does.
• The Principle of Domain Relevance
– Everything that’s relevant to the requirements
must appear in some part of the application
domain.
– The application domain is NOT limited to the parts
of it that are directly in contact with the machine.
Thinking outside the box
• Fred: “I couldn’t find a good definition on
Return On Investment.”
• Steve: “Really? Where did you look?”
• Fred: “In the software engineering literature.”
• Steve: “Why didn’t you look in a simple
Finance book or Accounting book?”
• Fred: “I’m an engineer, I only read
engineering journals and books.”
• Steve: “We’ll call you about the project
contract when we know more. Thanks, Fred.”
The “Why” isn’t important
• Fred: “Why isn’t important, it’s just a Post-it Note on
a class diagram.”
• Why did Fred say this? Well, Jane, his customer,
had asked,
• “Could you explain why you’ve modelled these two
classes - what are they representations of in my
problem?”
• Fred looked bemused and moved on to his next
point. Obviously Jane didn’t know about software.
Jane stopped listening and wondered how much
more time she’d be wasting today.
• The classes were part of design and had nothing to
do with identifying the problem.
• Fred’s a UML enthusiast.
It’s Not a Requirement!
• “It’s not a requirement if it isn’t implemented.”
• What does this really mean?
• When is a requirement not a requirement?
• WHEN YOUR CUSTOMER DOESN’T WANT IT
ANYMORE
• If you don’t happen to implement it, or can’t
implement it yet, but your customer WANTS it, it is
still a requirement.
• And that means it needs recognition now,
• and that means documenting it in your requirements
documentation now.
The 3 Descriptions
• 1. The Problem Context
– What’s in the problem domain? What’s the boundary, or
the scope, of the problem domain?
• 2. The Requirements
– What are the effects we want to machine to bring about in
the problem domain?
• 3. The Specification
– How do we describe the external behaviour of the
machine to enforce the requirements that will bring about
the desired effects in the problem domain?
• Don’t mix these up. If you do, you won’t be sure if
your talking about context, requirement or
specification.
• If you’re not sure, you’ll get the software wrong.
Summary
• The problem is in the world.
• The requirement is needed in the world.
• The machine is not the requirement, nor the
problem.
• The specification isn’t the requirement.
• Question your methods.
• Question everything about your software
problem.
• The generality of a method is inversely
proportional to its utility.
• Asking “why?” is good.
Some Useful References
• Michael Jackson, Software Requirements and Specifications,
Addison-Wesley, 1995.
– A seminal work. An entertaining, insightful book. Problem frames were
presented to world for the first time. A classic. Most of this
presentation is inspired by or taken from this work.
• Michael Jackson, Problem Frames, Addison-Wesley, 2001.
– Yet another seminal work. This book focusses entirely on
understanding and describing problems in much more detail than his
1995 work. This book tends to frighten (some) academics. A classic.
• Ben Kovitz, Practical Software Requirements, Manning
Publications, 1999.
– Described as idiosyncratic by an academic, described as delightful by
a practitioner. Who are you going to believe? An excellent introduction
to problem frames but can be hard going elsewhere.
• Ian Bray, An Introduction to Requirements Engineering,
Addison-Wesley, 2002.
– Was going to be called a “duffer’s guide” but Ian soon realised that
duffers are no good at requirements! An excellent introduction to a
whole range of techniques and tools, with a focus on problem frames.
Some more useful references
• Don Gause and Gerry Weinberg, Exploring Requirements,
Dorset House, 1989.
– One of the very first books on requirements elicitation and still just
about the best. An entertaining, seminal classic.
• Don Gause and Gerry Weinberg, Are Your Lights On?
Dorset House, 1990.
– Yet another classic, more generally focussed than the 1989 book.
More cartoons in this book!
• Alan Davis, Just Enough Requirements Management,
Dorset House, 2004
– Hot off the press, Al Davis talks about what is really needed in
practice and discusses the critical idea of requirements triage further.
• Bashar Nuseibeh and Steve Easterbrook, “RE: The
Roadmap”, Int. Conf. on Software Engineering, 2000
– A paper! This set out the future research directions of RE and
provides an excellent introduction to the subject. A classic of its own.