J.J. Cuadrado-Gallego et al. (Eds.): MENSURA 2007, LNCS 4895, pp. 168–182, 2008.
© Springer-Verlag Berlin Heidelberg 2008
Non-Functional Requirements Size Measurement Method
(NFSM) with COSMIC-FFP
Mohamad Kassab, Olga Ormandjieva, Maya Daneva, and Alain Abran
{moh_kass,ormandj}@cse.concordia.ca,
m.daneva@utwente.nl, Alain.Abran@etsmtl.ca
Abstract. Non-functional requirements (NFRs) of software systems are an im-
portant source of uncertainty in effort estimation. Furthermore, quantitatively
approaching NFR early in a project is difficult. This paper makes a step towards
reducing the impact of uncertainty due to NFRs. It offers a new generic classifi-
cation of the NFRs, and a NFR size measurement method (NFSM) that incorpo-
rates NFRs into the functional size quantification process. We chose the NFR
framework as a vehicle to integrate NFRs into the requirements modeling proc-
ess and to apply quantitative assessment procedures. Our solution proposal also
rests on the functional size measurement method, COSMIC-FFP, adopted in
2003 as the ISO/IEC 19761 standard. We discuss the advantages of our ap-
proach and the open questions related to its design as well.
1 Introduction
Empirical reports consistently indicate that improperly dealing with Non-Functional
Requirements (NFRs) leads to project failures, or at least to considerable delays, and,
consequently, to significant increases in the final cost as illustrated in the following
examples: London Ambulance System (LAS) in 1992 [1], Mars Climate Orbiter in
1998 [2] and Therac 25: The Medical Linear accelerator [28]. According to IEEE
software engineering standard 830-1998 [3], NFRs describe not what the software
will do, but how it will provide the means to perform functional tasks; for example,
software quality attributes, software design constraints and software interface re-
quirements. During requirements elicitation and analysis, NFRs tend to be stated in
terms of either the qualities of the functional tasks or the constraints on them, which
are expressed as functional requirements (FRs), as the former affect the semantics of
the latter.
While estimating development effort is a major activity in managing the scope of
the requirements, this activity has, by and large, been neglected for NFRs in practice.
This is particularly true because the NFRs are subjective in their nature and they have
a broad impact on the system as a whole. Furthermore, NFRs can often be interacting,
in that attempts to achieve one NFR can hurt or help the achievement of other NFRs.
As NFRs have a global impact on the systems, localized solutions may not suffice [4].
In addition, current software engineering approaches fail in addressing the presenta-
tion of how the NFRs can affect several FRs simultaneously. Since this is not
supported from the requirements phase to the implementation phase, some of the
software engineering principles such as abstraction, localization, modularization,

NFRs Size Measurement Method (NFSM) with COSMIC-FFP 169
uniformity and reusability, can be compromised. Furthermore, the resulting system
could be more difficult to maintain and evolve.
Despite the above challenges that arise when dealing with NFRs, it is important to
be able to make decisions about the scope of software by given resources and budget
based on a proper estimation of building both FRs and NFRs. As the effort is a func-
tion of size [18], one way to respond to the need to deal comprehensively with the
effect of NFRs on the effort of completing the software project is to measure their
corresponding functional size. In this paper, the use of the COSMIC-FFP [10, 11]
functional size measurement method is proposed to quantify NFR size in a software
project. To the best of our knowledge, this is the first attempt to deploy such an ap-
proach for NFRs in a project.
The NFR framework outlined in [4] has been chosen to illustrate the application of the
proposed measurement method. It was the first framework to propose a process-oriented
and qualitative decomposition approach for dealing with NFRs in requirements engineer-
ing (RE). A cornerstone of this framework is the concept of the “softgoal”, which is used
to represent the NFR. A softgoal is a goal that has no clear-cut definition or criteria to
determine whether or not it has been satisfied. In fact, the framework speaks of softgoals
being “satisficed” rather than satisfied, to underscore their ad hoc nature, with respect to
both their definition and their satisfaction. One drawback of the softgoal approach im-
plied in the NFR framework becomes apparent when we look at solution architecture
tradeoffs. The term softgoal reflects the fact that extensive interdependencies exist be-
tween the various NFRs, and it is often not feasible to entirely fulfill each and every
system goal. Tradeoffs must therefore be made. To understand these tradeoffs with re-
spect to the NFR framework, the subgoals are decomposed into operationalizations,
which provide both candidate design solutions for achieving the goal and the basis for
weighing potential tradeoffs. However, the decision-making process for selecting from
among different candidate operationalizations which ‘satisfice’ a particular NFR is a
qualitative process; that means it typically is not based on defined quantitative criteria.
Furthermore, this process is only carried out informally, leaving undocumented the
knowledge and the rationale that led to the decisions. This makes it difficult to trace back
to the selection criteria on which those decisions were developed.
The above shortcomings underline the need to consider quantitative criteria which
make it easier for analysts and software engineers to weigh the various design options
and make tradeoffs. In this paper, we address this need by proposing that the softgoal
concept in the context of the NFR framework be coupled with NFR size measurement
(NFSM). Having the functional size for the softgoal operationalization stated this way
provides quantitative criteria for the decision-making task to select the most suitable
operationalizations from the candidate alternatives.
The rest of this paper is organized as follows: Section 2 provides a discussion on
the types of NFRs. Section 3 presents related work and the NFR framework. Section 4
explains the NFSM method. Section 5 provides a critical discussion of the approach.
Section 6 summarizes the key points of the solution proposal and discusses avenues
for future research.