Making Requirements Measurable
Bashar Nuseibeh Suzanne Robertson
Department of Computing
Imperial College
London SW7 2BZ, UK
+441715948286
ban 0 doc.ic.ac.uk
ABSTRACT
Increasingly sophisticated technology makes it possible
to build more complex systems more quickly. However a
system is only useful to the customer if it addresses the
real requirements. Eliciting and specifying customer
requirements in a precise and unambiguous way is
critical to the success of a project. Customers often find
it difficult to articulate their requirements, and for large,
complex systems these requirements are often
conflicting.
This full-day tutorial focuses on guiding participants
through the requirements definition process. After
presenting an overview of requirements engineering
activities, the tutorial focuses on how to assess
("measure") requirements for testability, relevance,
completeness, consistency, coherence, traceability and
satisfaction. A requirements template is used as a guide
to discovering requirements and building the
specification. A requirement is regarded as "measurable"
i f there is an unambiguous way of determining whether a
given solution fits that requirement. Participants in this
tutorial will examine requirements measurability by
building a requirements specification for a familiar
system. The tutorial combines a presentation of issues
and techniques in an interactive, participative format that
encourages "hands-on" learning of requirements definition
and specification.
Keywords: requirements engineering, specification,
validation, verification, testability.
MOTIVATION AND BACKGROUND
Increasingly sophisticated technology makes it possible
to build more complex systems more quickly. However a
system is only useful to the customer if it addresses the
real requirements. During the last few years we have all
heard disaster stories about expensive development efforts
Permission to make digitalhard copies of all or part of this material for
personal or classroom use is granted without fee provided that the copies
are not made or distributed for profit or conuiiercial advantage, the copy-
right notice, the title ofthe publication and its date appear, and notice is
given that copyright is by pemiission of the ACM, Inc. To copy otherwise,
to republish, to post on servers or to redistribute to lists, requires specific
pemiission andlor fee
ICSE 97 Boston MA USA
Copyright 1997 ACM 0-89791-914-9/97/05 ..$3.50
64 7
Atlantic Systems Guild Ltd.
11 St. Marys Terrace
London W2 lSU, UK
+441712623395
Suzanne0guild.demon.co.uk
that failed to deliver the functionality required by their
users. The question is why do we build systems that do
not fit into the world? Over and over again the problem
is that the customers' requirements were not specified.
Systems developers have become aware that requirements
engineering is a critical activity in the development of
useful systems.
A requirements engineer needs to be able to collect
requirements from a variety of customers. Often those
requirements are vague, fuzzy and expressed as solutions.
A requirements engineer needs to have a mechanism for
iterating from a first-cut requirement to a requirement
that passes well defined quality criteria. The challenge is
to assure the quality of each requirement and to connect
those requirements with business goals.
TUTORIAL CONTENT AND CONDUCT
This full-day tutorial focuses on guiding participants
through the requirements definition process. The
emphasis of this exercise is on making requirements
measurable so that they can be negotiated, communicated
and traced throughout the project. A requirement i s
measurable if there is an unambiguous way of
determining whether a given solution fits that
requirement.
Participants in this tutorial examine requirements
measurability by building a requirements specification
for a familiar (but nevertheless complex) system. The
tutorial consists of a number of units that each combine
lecture and workshop. Tutors explain a requirements
concept, then participants, working in teams, apply that
concept. The VOLERE requirements process and
template, a distillation of experience from many projects,
is used as a guide [33. Then there is a discussion to
communicate the experience and questions of each of the
groups. The topics covered by the tutorial include:
Introducing Requirements Engineering;
Defining the global requirements;
Defining the Context;
Use-cases as a functional requirements triggering tool;
Using the template to define non-functional
requirements:
,. Defining fit criteria;
* Requirements quality criteria.
The introduction to the tutorial includes an introduction
to the tutorial objectives, format and notes. It also
provides a mini-tutorial to the field of requirements
engineering under the following headings: context,
groundwork, acquisition, modelling, analysis,
measurement, communication and documentation [ 1,2].
The tutorial instructors then introduce the notion of
making requirements measurable. This includes a
discussion of how to elicit requirements by identifying
all the factors that might cause misfit between the
system and the world. It also illustrates how to take the
potential misfits, express them as requirements and how
to define an agreed measurement for each requirement.
The requirements template (developed by the authors) is
then introduced, with a discussion of the types of
functional and non-functional requirements that are
defined in the template. Advice on how to use the
template as the basis for building a requirements
specification is also provided.
The instructors describe the case study, a
charginglticketing system for an undergroundlsubway
train service. The purpose and constraints of the case
study project are described, and a session of interactive
context setting follows. This includes applying the
constraints and individual knowledge to build a context
diagram. The context is used as the starting point for
defining the project boundaries.
In groups of no more than five people each, and guided
by the instructors, the participants then use different
sections of the requirements template to specify the
requirements for case study system. Participants are
requested to write each requirement on a snow card (a
rectangular, ruled card measuring approximately 20cm by
12cm), and number each card with the appropriate
requirement type (prescribed by the requirements
template). After the tutorial, the instructors will
amalgamate all the requirements and make a composite
requirements specification available to all attendees.
The exercise is then reviewed by the tutorial participants
and the instructors. This includes team presentations of
findings and general discussion. It is an opportunity for
all participants to comment on and learn from other
groups. Presentations are prepared on overhead
transparencies and make use of flip-charts provided at the
tutorial. Finally, the instructors present some
conclusions and lessons learned. They review the
exercise, discuss the requirements engineering process in
light of the tutorial activities, and provide some advice
on how to tailor the generic process to suit a given
project. The tutorial concludes with a summary of issues
raised and lessons leamed.
648
CONCLUSION
Requirements Engineering has clearly emerged as a
critical activity in software systems development, and
associating some form of "measurement" is crucial to its
effective deployment. This tutorial combines a
presentation of issues and techniques of requirements
definition in an interactive, participative format that
encourages "hands-on" learning.
REFERENCES
I . Finkelstein, A. Requirements Engineering: a
review and research agenda, in Proceedings of First
Asia-Pacific Software Engineering Conference
(Tokyo, Japan, December 1994), IEEE CS Press.
2. Nuseibeh, B. From Requirements to Satisfied
Customer: A road map, Keynote Address, DTI
workshop on "RE - Connecting with the
Customer" (Gloucester, UK, September 1995).
3. Robertson, S. and Robertson, J. C o m p l e t e
Systems Analysis: The Workbook, The Textbook,
the Answers, Dorset House, UK, 1994.
TUTORS' BIOGRAPHIES
Bashar Nuseibeh is a Lecturer and Head of the
Software Engineering Laboratory in the Department of
Computing, Imperial College, London. He holds an
MSc and PhD in Software Engineering from Imperial
College. His research interest are in Distributed Software
Engineering, including requirements engineering, process
modelling and technology, and technology transfer. He is
an Editor-in-Chief of the Automated Software
Engineering Journal and Chairman of the BCS RE
Specialist Group. He serves on many committees
including the IEEE Symposium and Conference series on
RE (ICRE '96, ISRE '97 & ICRE '98), the Editorial
Board of the RE Journal, and the Executive Board of the
RE European Network of Excellence (RENOIR).
Suzanne Robertson is a teacher and consultant
specialising in modelling techniques for system
development. She has over 30 years of development and
consulting experience and has co-authored courses on
systems analysis, systems design, requirements
engineering, quality assessment and problem solving.
She is currently developing techniques for identifying and
reusing requirements patterns. She studied Information
Processing at the New South Wales Institute of
Technology and is a member of the IEEE, the ACS. She
serves on many committees including the BCS's Reuse
Specialist Group, the steering committee of Object
Technology '97, and the programme committee of the
International Conference for Software Reuse (ICSR '98).
She is a principal of the Atlantic Systems Guild (with
Tom De Marco, Peter Hruschka, Tim Lister, Steve
McMenamin, John Palmer, James Robertson). The guild
is a New York, London and Germany based think-tank,
that researches and communicates system development
techniques.