Thinking about Requirements Engineering:

some basic principles

Karl CoxEmpirical 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 World outside the Computer

The solution is here

Connections between the world and the computer

The problem is here

Phenomena

MachineApplication Domain

Interface

Real World phenomena

Specification phenomena

Solution phenomena

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

Order Processing

CustomersWarehouse

AccountsDept.

Orders

Acknowledgements

ShippingInfo

AccountingInfo

“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 4Analogdevices

ICUPatients Periods

& Ranges

MachineNurse’sStation

MedicalStaff

ab

cd

e

Context Diagrams 4

a: Period, Range, PatientName, Factor

b:EnterPeriod, EnterRange, Enter PatientName, EnterFactor

c:Notify

d:RegisterValue

e: FactorEvidence

Analogdevices

ICUPatients Periods

& Ranges

MachineNurse’sStation

MedicalStaff

ab

cd

e

Remember Phenomena

MachineApplication Domain

Interface

Real World phenomena

Specification phenomena

Solution phenomena

Remember Phenomena

MachineApplication Domain

Interface

Real World phenomena

Specification phenomena

Solution phenomena

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 single-inheritance 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

Renew a loan

Return a book

Library Member

Here’s the Use Case problem

Issue a book

Issue a book renew

Process a book return

LibrarianLibrary Member

The Library Member’s requirements: borrow a book, return a book, renew a loan

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.

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.