Requirements Eng (1997) 2:165-169

9 1997 Springer Verlag London Limited Requirements

Engineering

Viewpoints

.,~,'~ ~, ~ ~: ' ~ = " ~ .... -4 :; ~ , - ' ~ ~' - ";, ~ ;~; = :~s .... :~'~_~ ~., iI ~.~j_~;.~-~

Towards the Engineering of Requirements

T. Gilb
ResultPlanningLtd Kolbotn Norway

1. What is Engineering?
In the 1980s, Professor Billy Koen of the Department of
Mechanical Engineering, Austin, University of Texas,
defined the engineering method as 'the use of heuristics
to cause the best change in a poorly understood
situation within the available resources'. He also
stressed the importance of controlling risk by using the
heuristics of making only small changes already known
to have worked in the past, of planning paths of retreat
in case of failure, and of feeding back results to improve
future performance [1, p. 301].
Here is my rephrased version of Koen's definition of
engineering:
Engineering is the use of principles in a systematic
way,
to find designs,
which deliver the requirements,
within resource constraints,
under conditions of uncertainty.
Correspondence and offprint requests to: Tom Gilb, Result Planning
Ltd., Iver Holtersvei 2, N-1410 Kolbotn, Norway.
Email: Gilb@acm.org.Web site: http://www.Result-Planning.com
Here are some remarks concerning this definition (I'11
discuss the terms 'designs' and 'requirements' later in
this article):
9 'Principles' are rules of thumb that guide the choices
and actions of engineers. Principles are not rigid laws.
They reflect the experience learnt from previous
engineering projects. I see professional codes of
conduct playing a part as well.
9 'In a systematic way' must include brainstorming and
testing random insights.
9 'Deliver' implies a process that continues beyond
design stages to project delivery stages. Success is
determined by successfully meeting all the specified
requirements.
9 'Conditions of uncertainty'9 exist because we must
deal with combinations of designs being applied into
ever-changing environments. The results are 'com-
plex to predict' and the resulting risk has to be
handled.
I believe that such a definition of engineering is
relevant to Software engineering. However, does cur-
rent practice measure up? Are we 'engineering'? I
consider that the software engineering industry is only
just beginning to adopt the engineering practices of the
more traditional engineering disciplines.
Let me discuss the current state of requirements
specification and give some pointers on how, I believe,
166
true engineering of requirements ought to be carried
out. Today, too many requirements specifications con-
tain what I shall call 'false' requirements.
2. What are 'False' Requirements?
'False' requirements occur when the requirement speci-
fication contains statements which are not really what is
needed or desired. This happens when:
(i) the requirements are not stated in a quantified and
measurable way.
It is commonplace to find requirements statements,
such as 'reduced costs', 'improved management con-
trol', 'high usability' and 'increased customer satisfac-
tion', with no clear definition of what is intended; no
homing in on the key issues to reduce ambiguity and no
quantification of the current and required levels at
future dates.
I once analysed about 40 design specifications for a
mobile telephone. Almost all of the specifications
simply included the wording 'increased ease of service'
as one of their justifications. There was no definition, in
writing, of the levels and types of serviceability that
were to be aimed for.
Once pointed out, the mobile telephone engineers
agreed with me and we spent a day defining the
serviceability requirements. 'Increased ease of service'
actually expanded to approximately 18 different types
of serviceability, each with its own quantified require-
ments levels.
(ii) design ideas are used in place of the true
requirements.
I have noticed that there is a strong tendency to specify
design ideas under the heading of 'Requirements'. For
example, 'an object-orientated database is required',
'an improved handbook is needed' or 'a WINDOWS 95
interface is to be provided'. Usually, there are no clear
agreed quantified requirements to even lend any
support to the choice of the design. For example, the
requirements giving rise to the request for 'an improved
handbook' are probably to do with reducing training
times and improving the quality of answers given to
customers. But you need to explore this and quantify
the requirements.
Design ideas given as requirements must be treated
with caution because they lead to the following
negative effects:
a. The true requirement is not stated and not known.
Further, the actual process of determining the true
requirements is highly likely to bring to light new
T. Gilb
requirements or alter the understanding o f what is
wanted.
b. Alternative better designs are not searched for.
c. The overall design cannot be optimized to satisfy a
larger set of requirements. (the true requirement and
other concurrent requirements).
True requirements are best stated m terms of the
desired end-state effects, not the means for getting
those effects. True requirements are best stated at the
highest level of generality consistent with the end state
required. This generality will permit a broader and
more satisfactory set of design solutions to be
considered.
3. What are 'Requirements?'
I map 'requirements' under the following categories:
9 Functions: 'what' the system must be able to do.
9 Qualities: 'how well' the function will perform.
9 Costs: what we will budget as 'costs' (any input
resource: money, people or time) for creating and
maintaining the functions and their qualities.
9 Constraints: any restrictiorL on the freedom of the
requirements or the design.
I also differentiate between the two essentially differ-
ent types of requirement statement:
9 Not quantifiable, but testable for presence.
9 Quantifiable (on a scale of measure).
Functions are not quantifiable, they tend to be either
present or absent. All qualities and costs are quantifi-
able. Constraints can be of either type.
3.1. Functions
Time and again, current practice focuses on specifying
functionality. Personally, I find 'functions' of less use
when designing than the other categories. This is
because it is usually fairly self-evident what function-
ality is required. It is actually the other categories that
determine the choice of design.
One further issue concerning functions: they should
only be specified in detail on an 'as needs' ba~i~. There
is little point specifying the current functionality in
great detail if it is not a proposed candidate for
imminent redesign. In a fast-moving business environ-
ment, change is occurring fairly rapidly and it is
essential that any study of functionality should be
accurate. So, unless you are planning specific system
Towards the Eng#'~edngof Requirements
chpnges, leave the ;functional description at a reaso=-
ably high leweiL
Note, I ,eq~aate 'function' with process'. So, this also
applies to the mapping of business processes!
Qualities and Costs
At flais point, I shall inlroduce some of the terminology
of a language I have ,deveJoped for specifying quanti-
fied requirements. I call ~t Planguage, which is'short for
Planning Language. (Planguage also can be used for
evaluating design ideas and planning evolutionary
worksteps. It is available free on the Web [2].) I want to
demonstrate some of the precision wi~h which require-
ments ought to be captured.
As stated earlier, all quality and cost requirements
are 'quanti~abqe'. That is, at least one scale of measure
can be found t o help define the requh'ement. I use the
parameter 'Scale' for this.
All quality and cost requir.emenCrs "aTe also 'measur-
able'. That is, at least one practical, eeonomic process
can b e defined for determining where we are on the
specified scale of measure. I use the parameter 'Meter"
for this.
It is essential that finite limits are set for require-
ments, otherwise pote.z~ally infinite resources, which
9no one has, could be required to attain the unlimited
quality levels.
There are several categories of requirement levels~
9 survival level: the level required for system survival,
and for any p~yment to be made or for any value to
be acknowledged. I use the parameter 'Must' for
this.
9 success level: the level required for eeasonable
satisfaction, and full payment or val,a~e. I use the
parameter 'Plan' for this.
These requirement levels can be specified for any set of
conditions, such as time, space (component, market)
and event. I call these conditions 'qualifiers' and
enclose them in square brackets.
For example:
Availability: "depends o11 Rch~abillt3 and Maintain-
ability'
Reliability:
Scale: Mean Time Between Failure per user in on-
line hours per user.
Meter: Calculate average time between reported
user failure situations.
Plan [Release Version 1] 24 hours.
167
Maintainability:
Scale: Average time to repair a failure; from
'failure actually experienced' until 'completely and
correctly fixed', including all negative side effects.
Meter: Observation by analyst of at least 50
representative failures.
Plan [Release Version 1] 10 hours.
3.2. Constraints
Constraints divide a requirements or design territory
into two areas: allowed and not allowed. Analysts and
designers are free to specify requirements and design
only in the 'allowed' area. True constraints do occur and
they need to be handled appropriately (they need to be
questioned and their consequences considered). How-
ever, too often constraints on design are s i a ~ y 'false
requirements'; someone gave an example o~ the type o f
design they were thinking of and the designer incor-
rectly failed to translate it into gemeric, higher-level
requirements.
The following constraint cafL~gories are useful, but
not exhaustive:
9 quality level
o cost level
9 functionality
9 design
9 political
9 cultural
9 legal
3.3. What Bse is Important about Requirements?
Requirements are a mul.fidimensional set of end-state
needs, all vying for the same project resources. The fil of
design to requirements is not likely to be perfect, thus
there is a negotiable 'grey area' between them. Trade-
offs must be made and, maybe, the requirements have
to be amended.
It is essential to ensure you keep control of what you
understand as the critical requirements. These can
change over time. Only critical requirements are worth
specifying and controlling. Critical requirements, by
definition, are those which if not met threaten the
survival of the entire system.
168
4. How are 'Requirements' and 'Design'
Related?
The notion of requirements implies a defined view-
point, which could come from several sources, e.g.
ser~ior management, a customer, a user, a marketir~g
plan. Requirements are a defined viewpoint's inputs to
a design process.
'Design' is any set of ideas intended to satisfy a set of
requirements. Designs are the outputs of the design
process. Consider the following processes:
1. Architectural Requirements GOES TO [Architect
Process] BECOMES Architecture.
2. Architecture and Engineering Requirements GOES
TO [Engineering Process] B E C O M E S Engineering
Design.
3. Engineering Design GOES TO [Production Engi-
neering PROCESS] BECOMES Manufacturing
Desigrt.
The design output of one level or stage of work (level of
design) becomes the 'requirements" input to the next
stage. All requirements are someone's 'design ideas'.
Design ideas can be viewed as a set of requirements for
the nex! work process. The design process is one of
moving, in one or more stages, towards a concrete real
system.
(Note that, 'design ideas' are only "false require-
ments' when they are not real constraints or when they
are specified instead of the underlying function, quality
and cost requirements. At certain levels or stages of
work, design ideas do become the true requirements
(constraints).)
5. How are 'Requirements' and 'Engineering'
Related?
Specifying requirements using a method such as Plan-
guage is essential if we are to truly engineer require-
ments. Only with such specification do we explicitly
communicate the quality levels, the cost levels, the
constraints and the timescales required. This enables us
to have a basis for comparison of the fit of the design
ideas against the requirements. In addition, it helps the
search for new design ideas as it focuses on the critical
qualities that need to be delivered. It can also cope with
evolutionary concepts, but that's another story!
T. Glib
6. What Can we do to Improve
Requirements Engineering Practices?
9 We musl define requirements clearly and
unambiguously
9 We must teactz a discipline of specii=icat~on at tI~e
systems level.
9 We must dearly connect design to requirements.
9 We must carry out rigorous quality control of
requirements and design.
9 We must not allow highly defective (ambiguous,
unclear, inconsistent) specification to be used as
inputs to other work processes.
9 We must not specify too much detail too early. We
must systematically get the benefit of early cycles of
evolutionary deliveries, to help us re-specify require-
meats more realistica~l):
GILB PUNCH-LINE
We cannot expect to improve software engineering
design, testing and quality control until we have
considerably improved our ability to articulate quality
requirements and other requirements in unambigu-
ously clear testable format, and untU we even under-
stand the distinction between ends and means.
7. What are the Fundamental Principles of
Requirements?
1. All requirements are testable for presence in the real
world of their implementation.
2. Some requirements are binary in nature, some are
scalar variables.
3. All requirements reflect someone's subjective values
and priorities.
4. For any given set of requirements, there are other
sets of reqt~irements which would probably satisfy
the specifier's real needs, values and priorities better
or equally well.
5. All requirements are in natural conflict with all
others for common resources.
6. Requirements are not static, but are forever chang-
ing as the world affecting us changes our needs,
values and priorities.
7. Requirements engineering is the systematic process
of determining the complete relevant set of values
held by stakeholders, and processing them until a
satisfactory level of 'delivery of the reqt~ired end
states' has been made to them. This implies that it
7owards the Engineenng of Requirements 169

9 must include design, testing, quality control, projact References

management, specification languages and all other
relevant disciplines to enable it to succeed. 1. Gilb T. Principles of software engineering management.
Addison-Wesley/Longman, 1988
2. A DoD web site containing my new book manuscript
(RDM) (http://www.stsc.hill.af.mil/SWTesting/gilb.html)
3. Gilb T. Requirements-driven management: a planning-
language. Crosstalk (DoD US) June 1997 (electronic
Acknowledgement downloadable copies at STSC site, http://www.stsc.hill.
af.mil/Crosstalk/1997/jun/jun97ind.html)
This article was edited by Lindsey Brodie 4. Gilb T. Evolutionary object management. Object Expert
(lindsey@brodie.source.co.uk). UK 1997; January/February: p.24--29 & 72.