Nonfunctional Requirements:
From Elicitation to Conceptual Models
Luiz Marcio Cysneiros, Member, IEEE Computer Society, and
Julio Cesar Sampaio do Prado Leite, Member, IEEE Computer Society
Abstract—Nonfunctional Requirements (NFRs) have been frequently neglected or forgotten in software design. They have been
presented as a second or even third class type of requirement, frequently hidden inside notes. We tackle this problem by treating NFRs
as first class requirements. We present a process to elicit NFRs, analyze their interdependencies, and trace them to functional
conceptual models. We focus our attention on conceptual models expressed using UML (Unified Modeling Language). Extensions to
UML are proposed to allow NFRs to be expressed. We will show how to integrate NFRs into the Class, Sequence, and Collaboration
Diagrams. We will also show how Use Cases and Scenarios can be adapted to deal with NFRs. This work was used in three case
studies and their results suggest that by using our proposal we can improve the quality of the resulting conceptual models.
Index Terms—Software design, requirements elicitation, nonfunctional requirements, goal graphs, UML conceptual models.


1 INTRODUCTION
SOFTWARE systems, aside from implementing all thedesired functionality, must also cope with nonfunctional
aspects such as: reliability, security, accuracy, safety,
performance, look and feel requirements, as well as
organizational, cultural, and political requirements. These
nonfunctional aspects must be treated as nonfunctional
requirements (NFRs) of the software. They should be dealt
with from the beginning and throughout the software
development process [9], [10].
Ineffectively dealing with NFRs has led to a series of
failures in software development [5], [26], including the
very well-known case of the London Ambulance System
[17], where the deactivation of the system right after its
deployment was strongly influenced by NFRs noncom-
pliance. Literature [7], [15], [11] has been pointing out
these requirements as the most expensive and difficult to
deal with.
In spite of their importance, NFRs have, surprisingly,
received little attention in the literature and are poorly
understood compared to less critical aspects of the software
development [10]. The majority of the work on NFRs uses a
product-oriented approach, which is concerned with mea-
suring how much a software system is in accordance with
the set of NFRs that it should satisfy [25], [2], [16], [31], [30].
There are, however, a few that propose to use a process-
oriented approach in order to explicitly deal with NFRs
[10], [25], [3], [41]. Most of these works propose the use of
techniques to justify design decisions on the inclusion or
exclusion of requirements that will impact the software
design.
Unlike the product-oriented approach, our approach is
concerned with making NFRs a relevant and important part
of the software development process. It is also possible to
find standards [22], [39], [33] that can offer some guidance
on eliciting NFRs. However, these standards basically give
different taxonomies for some of the NFRs. The elicitation
process per se is shallow. There is also a lack of guidance on
how one might integrate the NFRs into design.
We propose a strategy to elicit NFRs and guide the
software engineer to obtain conceptual models that will
have explicit traces to the NFRs and vice-versa.1 Our
elicitation process is based on the use of a lexicon that will
not only be used to anchor both functional and nonfunc-
tional models, but also to drive NFR elicitation. A lexicon
representing the common vocabulary used in the domain is
built. Later, NFRs are added to this lexicon. Possible
solutions for implementing these NFRs are also added to
the lexicon.
The lexicon will then drive the construction of NFRs
graphs [8] slightly extended to fit our strategy. NFR graphs
are and/or graphs that decompose nonfunctional require-
ments, from vague abstractions to more concrete descrip-
tions. Heuristics for conflict detection are then used to guide
the NFRs reasoning. Finally, the strategy provides a
systematic way of integrating the elicited NFRs into use
cases and scenarios as well as class, sequence and
collaboration diagrams. The integration process can also
be used to validate ongoing projects in such a way that,
even if one has a project where the conceptual models are
328 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 30, NO. 5, MAY 2004
. L.M. Cysneiros is with the Department of Mathematics and Statistics,
Information Technology Program, York University, 4700 Keele St.,
M3J1P3, Toronto, Canada. E-mail: cysneiro@mathstat.yorku.ca.
. J.C.S.d.P. Leite is with the Departamento de Informa´tica, Pontificia
Univiversidade Cato´lica do Rio de Janeiro, R. Marques de Sa˜o Vicente, 225
Rio de Janeiro, Brasil 22453-900. E-mail: julio@inf.puc-rio.br.
Manuscript received 12 Aug. 2002; revised 30 Aug. 2003; accepted 1 Mar.
2004.
Recommended for acceptance by J. Knight.
For information on obtaining reprints of this article, please send e-mail to:
tse@computer.org, and reference IEEECS Log Number 117119.
1. Our work is based on the results of the doctoral dissertation of Dr.
Cysneiros and on our ongoing research on the aspects of nonfunctional
requirements. This journal paper builds upon, and uses the results of, other
published materials [11], [12], [14], but provides a new and integrate view of
our results.
0098-5589/04/$20.00
2004 IEEE Published by the IEEE Computer Society