Dewi Mairiza, Didar Zowghi and Nurie Nurmuliani
Faculty of Engineering and Information Technology
University of Technology, Sydney, Australia
Keywords: Non-Functional Requirements (NFRs), Conflicts, Catalogue, Relative, Relationship.
Abstract: Two of the most significant characteristics of non-functional requirements (NFRs) are “interacting” and
“relative”. Interacting means NFRs tend to interfere, conflict, and contradict with one other while relative
means the interpretation of NFRs may vary depending on many factors, such as the context of the system
being developed and the extent of stakeholder involvement. For the purpose of understanding the interacting
characteristic of NFRs, several potential conflict models have been presented in the literature. These models
represent the positive or negative inter-relationships among various types of NFRs. However, none of them
deal with the relative characteristic of NFRs. In fact, multiple interpretations of NFRs in the system being
developed may lead to positive or negative inter-relationships that are not always obvious. As a result, the
existing potential conflict models remain in disagreement with one other. This paper presents the result of
an extensive and systematic investigation of the extant literature over the notion of NFRs and conflicts
among them. A catalogue of NFRs conflicts with respect to the NFRs relative characteristic is presented.
The relativity of conflicts is characterized by three categories: absolute conflict; relative conflict; and never
conflict. This catalogue could assist software developers in identifying the conflicts among NFRs,
performing further conflict analysis, and identifying the potential strategies to resolve those conflicts.
In the early eighties, the term Non-Functional
Requirements (NFRs) was introduced as the
requirements that restrict the type of solution that a
software system might consider (Yeh 1982).
However, although this term has been in use for
almost three decades, studies to date indicate that
currently there is still no general consensus in the
software engineering community regarding the
notion of NFRs. In the literature, the term NFRs is
considered within two different perspectives: (1)
NFRs as the requirements that describe the
properties, characteristics or constraints that a
software system must exhibit; and (2) NFRs as the
requirements that describe the quality attributes that
the software product must have (Mairiza, Zowghi &
Nurmuliani 2009).
In software development, NFRs are recognized
as a very critical factor to the success of software
projects. NFRs address the essential issue of the
quality of the system (Chung et al. 2000; Ebert
1998; Firesmith 2003). Without well-defined NFRs,
a number of potential problems may occur, such as a
software which is inconsistent and of poor quality;
dissatisfaction of clients, end-users, and developers
toward the software; and causing time and cost
overrun for fixing the software (Chung et al. 2000).
NFRs are also considered as the constraints or
qualifications of the operations (Mittermeir et al.
1989). NFRs place restrictions on the product being
developed, development process, and specify
external constraints that the product must exhibit
(Kotonya & Sommerville 1998). Furthermore,
Charette (1990) claims that NFRs are often more
critical than individual Functional Requirements
(FRs) in the determination of a system's perceived
success or failure (Sommerville 2004; Wiegers
2003). Neglecting NFRs has led to a series of
software failures. For example systemic failure in
London Ambulance System (Breitman, Prado Leite
& Finkelstein 1999; Finkelstein & Dowell 1996),
performance and scalability failure in the New
Jersey Department of Motor Vehicles Licensing
System (Boehm & In 1996b), failure in the initial
design of the ARPANet Interface Message Processor
Mairiza D., Zowghi D. and Nurmuliani N. (2010).
In Proceedings of the Fifth International Conference on Evaluation of Novel Approaches to Software Engineering, pages 20-29
Software (Boehm & In 1996a), and some other
examples as described in (Boehm & In 1996a,
1996b; Breitman, Prado Leite & Finkelstein 1999;
Leveson & Turner 1993).
Although NFRs are widely recognized to be very
significant in the software development, a number of
empirical studies reveal that NFRs are often
neglected, poorly understood and not considered
adequately in developing a software application. In
the development of software system, users naturally
focus on specifying their functional or behavioral
requirements, i.e. the things the product must do
(Chung et al. 2000; Wiegers 2003). NFRs are often
overlooked in the software development process
(Ebert 1998; Grimshaw & Draper 2001). A number
of studies investigating practices of dealing with
NFRs in the software industry also reported that
commonly software developers do not pay sufficient
attention to NFRs (Ebert 1998; Grimshaw & Draper
2001; Heumesser et al. 2003; Yusop, Zowghi &
Lowe 2008). NFRs are not elicited at the same time
and the same level of details as the FRs and they are
often poorly articulated in the requirements
document (Heumesser et al. 2003; Yusop, Zowghi &
Lowe 2008). Furthermore, in the requirements
engineering literature, NFRs have received less
attention and not as well understood as FRs (Chung
et al. 2000). Majority of software engineering
research, particularly within requirements
engineering area only deal with FRs, i.e. ensuring
that the necessary functionality of the system is
delivered to the user (Paech & Kerkow 2004).
Consequently, capturing, specifying, and managing
NFRs are still difficult to perform due to most of
software developers do not have adequate
knowledge about NFRs and little help is available in
the literature (Lauesen 2002).
NFRs tend to interfere, conflict, and contradict
with one another. Unlike FRs, this inevitable conflict
arises as a result of inherent contradiction among
various types of NFRs (Chung et al. 2000; Ebert
1998). Certain combinations of NFRs in the
software system may affect the inescapable trade
offs (Boehm & In 1996b; Ebert 1998; Wiegers
2003). Achieving a particular type of NFRs can hurt
the achievement of the other type(s) of NFRs.
Hence, this conflict is widely acknowledged as one
of many characteristics of NFRs (Chung et al. 2000).
Prior studies reveal that dealing with NFRs
conflicts is essential due to several reasons (Mairiza,
Zowghi & Nurmuliani 2009). First of all, conflicts
among software requirements are inevitable (Chung,
Nixon & Yu 1995; Chung, Nixon & Yu 1996;
Chung et al. 2000; Curtis, Krasner & Iscoe 1988).
Conflicting requirements are one of the three main
problems in software development in term of the
additional effort or mistakes attributed to them
(Curtis, Krasner & Iscoe 1988). A study of two-year
multiple-project analysis conducted by Egyed &
Boehm (Boehm & Egyed 1998; Egyed & Boehm
1998) reports that between 40% and 60% of
requirements involved are in conflict, and among
them, NFRs involved the greatest conflict, which
was nearly half of requirements conflict (Robinson,
Pawlowski & Volkov 2003). Lessons learnt from
industrial practices also confirm that one of the
essential aspects during NFRs specification is
management of conflict among interacting NFRs
(Ebert 1998). Experience shows most systems suffer
with severe tradeoffs among the major groups of
NFRs. For example: the tradeoffs between security
and performance requirements; or between security
and usability requirements. In fact, conflict
resolutions for handling NFRs conflicts often results
in changing overall design guidelines, not by simply
changing one module (Ebert 1998). Therefore, since
conflict among NFRs has also been widely
acknowledged as one of NFRs characteristics,
managing this conflict as well as making this
conflict explicit is important (Paech & Kerkow
2004). NFRs conflicts management is important for
finding the right balance of attributes satisfaction, in
achieving successful software products (Boehm & In
1996b; Wiegers 2003).
A review of various techniques to manage
conflicts among NFRs have been presented in the
literature (Mairiza, Zowghi & Nurmuliani 2009).
Majority of these techniques provide a
documentation, catalogue, or list of potential
conflicts among various types of NFRs. These
catalogues represent the interrelationships among
those NFRs types. Apart from strength and
weaknesses of each technique, however, NFRs are
also relative (Chung et al. 2000). NFRs can be
viewed, interpreted, and evaluated differently by
different people and different context within which
the system is being developed. The interpretation
and importance of NFRs may vary depending on the
particular system being developed as well as the
extent of stakeholder involvement. Consequently,
the positive or negative relationships among those
NFRs types are not always obvious. These
relationships might change depending on the
meaning of NFRs in the context of the system being
developed. Due to this relative characteristic of
NFRs, existing potential conflict models that
represent the relationship among NFRs are often in
disagreement with each other. For example,
according to Wiegers (2003), efficiency
requirements have negative relationship (conflict)
with usability requirements, but according to Egyed
& Grünbacher (2004), these two types of NFRs have
positive relationship (support). Given that none of
the existing conflicts catalogues deal with the
relative characteristics of NFRs, we are motivated to
pose the following research question:
Can we develop a catalogue of conflicts
among NFRs with respect to the relative
characteristic of NFRs?”
A catalogue of conflicts with respect to the NFRs
relative characteristic is presented as the novel
contribution of this paper. This catalogue is
developed as a two-dimensional conflict-relationship
between various types of NFRs. It represents the
relationship between each NFR type, such as how
each type of NFR is associated with the other types
of NFRs considering the NFRs relative
characteristic. The conflict-relationships are
represented in three categories: absolute conflict;
relative conflict; and never conflict.
This paper is organized in six sections. The first
section is the introduction to NFRs and conflicts
among them. The second section describes the
research framework and source of information used
in this study. The superset list of NFRs is presented
in section three continued by presenting the
catalogue of NFRs conflicts in section four. Section
five describes the benefits and potential applications
of the conflicts catalogue in the software
development projects. Then, section six concludes
this paper by highlighting some open issues which
are acquired from the investigation.
To get a significant and comprehensive snapshot of
the NFRs conflicts model, an extensive investigation
of the literature over the last three decades has been
performed. This investigation was conducted by
exploring the articles from academic resources and
documents from software development industry.
Four general types of sources of information have
been identified: (1) journal papers; (2) conference
proceedings; (3) books; and (4) documents from
software industry. Selection of those sources is made
in order to confirm the completeness of the
information by obtaining the academics and
practitioners perspectives related to the notion of
NFRs and conflicts among them. The study
conducted by Chung et al. (2000) was used as the
starting point for selection of the papers to be
Our study has examined 182 sources of
information. All of them are literatures within the
discipline of software engineering. They cover
various issues of NFRs and conflicts among them.
The research articles reviewed are published in key
journals and conference proceedings of the software
engineering literature, such as the Journal of
Systems and Software; IEEE Transaction on
Software Engineering; IEEE Software; Lecture
Notes in Computer Science; Journal of Information
and Software Technology; Requirements
Engineering Journal; Requirements Engineering
Conference, International Conference on Software
Engineering, and Requirements Engineering
Foundations of Software Quality Workshop.
Each source was then systematically analyzed
using content analysis technique. Content analysis is
a research technique that uses a set of procedures to
make valid inferences from texts or other
meaningful matter (Krippendorff 2004; Weber
1989). This technique is well-founded and has been
in used for over sixty years. The analysis covers
three essential issues: the NFRs types, the definition
and attributes
of each type, and the conflict
interdependencies among these types. Content
analysis technique was selected because it enables
researchers to identify trends and patterns in the
literature through the frequency of key words, and
by coding and categorizing the data into a group of
words with similar meaning or connotations
(Stemler 2001; Weber 1989). This technique is also
applicable to all domain contexts (Krippendorff
2004; Neuendorf 2001).
To develop a catalogue of NFRs conflicts, a
research framework was followed. This framework
consists of three research stages as follows:
(1) To create a comprehensive catalogue of NFRs
types, their definition and attributes
(2) To identify the interdependencies among
various NFRs types
(3) To perform a normalization process to
standardize the NFRs in the conflicts
In this paper, the term attribute is considered as the major
components of each NFRs type. In the literature, attribute is also
referred as NFRs subtypes (Chung et al. 2000) or quality sub
factors (Firesmith 2003).
ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering
have definition
accuracy; analyzability; attractiveness;
changeability; communicativeness;
completeness; complexity; composability;
confidentiality; consistency; correctness;
defensibility; dependability; evolvability;
extendability; flexibility; immunity;
installability; interoperability; learnability;
likeability; localizability; maturity;
operability; quality of service;
recoverability; replaceability; stability;
suitability; survivability
without definition and attributes
accountability; additivity; adjustability;
affordability; agility; anonymity; atomicity;
auditability; augmentability; certainty;
compatibility; comprehensibility;
comprehensiveness; conciseness; configurability;
conformance; controlability; customizability;
debuggability; decomposability; demonstrability;
distributivity; durability; effectiveness;
enhanceability; expandability; expressiveness;
extensibility; feasibility; formality; generality;
legibility; manageability; measurability; mobility;
nomadicity; observability; predictability;
provability; reconfigurability; repeatability;
replicability; self-descriptiveness; simplicity;
standardizability; structuredness; supportability;
susceptibility; sustainability; tailorability;
traceability; trainability; transferability;
trustability; uniformity; variability; verifiability;
versatility; viability; visibility; wrappability
have definition and attributes
accessibility; adaptability; availability;
efficiency; fault tolerance; functionality;
integratability; integrity; maintainability;
modifiability; performance, portability;
privacy; readability; reliability; reusability;
robustness; safety; scalability; security;
testability; understandability; and usability
Table 2: NFRs Definition and Attributes (Mairiza, Zowghi, & Nurmuliani 2010).
requirements that specify the capability of
software product to provide appropriate
performance relative to the amount of
resources needed to perform full functionality
under stated conditions
response time, space, capacity, latency,
throughput, computation, execution speed,
transit delay, workload, resource utilization,
memory usage, accuracy, efficiency
compliance, modes, delay, miss rates, data loss,
concurrent transaction processing
requirements that specify the capability of
software product to operates without failure
and maintains a specified level of performance
when used under specified normal conditions
during a given time period
completeness, accuracy, consistency,
availability, integrity, correctness, maturity,
fault tolerance, recoverability, reliability,
compliance, failure rate/critical failure
requirements that specify the end-user-
interactions with the system and the effort
required to learn, operate, prepare input, and
interpret the output of the system
learnability, understandability, operability,
attractiveness, usability compliance, ease of use,
human engineering, user friendliness,
memorability, efficiency, user productivity,
usefulness, likeability, user reaction time
requirements that concern about preventing
unauthorized access to the system, programs,
and data
confidentiality, integrity, availability, access
control, authentication
requirements that describe the capability of the
software product to be modified that may
include correcting a defect or make an
improvement or change in the software
testability, understandability, modifiability,
analyzability, changeability, stability,
maintainability compliance
The superset list of these 114 NFRs types can be
found in our previous publication (Mairiza, Zowghi
& Nurmuliani 2010).
Further investigation to the superset list indicates
that 23 NFRs types (20.18%) have definition and
attributes, 30 types (26.32%) only have definition,
and the rest 61 types (53.50%) were introduced
without definition or attributes. Since this finding
indicates that more than 50% of NFRs types listed in
the literature do not have any definitions and
attributes characterization, therefore, it confirms the
previous claim made by Glinz (2005, 2007) which
stated that in the literature, many NFRs were
introduced without definition or clarifying
examples”. The detailed list of these classifications
is presented in Figure 1.
The top five of the most frequently discussed
NFRs types in the literature are presented in Table 2.
These top five NFRs were identified by performing
the frequency analysis techniques towards each NFR
type listed in the literature. The definitions and
attributes are decomposed by integrating the existing
definitions and attributes based on general
complementary description stated in the scholarly
The catalogue of conflicts is a two-dimensional
matrix that represents the typical interrelationships
among 20 types of normalized NFRs, in term of the
conflict emerges among them. In this catalogue, the
relativity of NFRs conflicts is presented in three
categories: absolute conflict; relative conflict; and
never conflict (as presented in Figure 2).
Absolute Conflict: this relationship represents a
pair of NFRs types that are always in conflict. In
the catalogue, this conflict relationship is labeled
as „X‟.
Relative Conflict: this relationship represents a
pair of NFRs types that are sometimes in
conflict. It consists of all pairs of NFRs that are
claimed to be in conflict in the literature but they
are also claimed as not being in conflict in the
other cases. This disagreement occurs due to
several factors, such as the different
interpretation/meaning of NFRs in the system
being developed, the context of the system, the
stakeholder involvement, and the architectural
design strategy implemented in that system. In
the conflict catalogue, this type of conflict
relationship is labeled as „*‟.
ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering
Figure 2: Catalogue of Conflicts among NFRs.
Never Conflict: this relationship represents a
pair of NFRs types that are never in conflict in
the software development projects. It consists of
all pairs of NFRs who have never been declared
as being in conflict with each other. They may
contribute either positively (e.g. support (Sadana
& Liu 2007) or cooperative (Egyed &
Grünbacher 2004)) or indifferent to one another
(e.g. low or very little impact on the other
(Wiegers 2003)). In the conflict catalogue, this
conflict relationship is labeled as „O‟.
Further analysis of this conflicts catalogue
indicates that 36 pairs of NFRs are absolute conflict
(e.g. accuracy and performance; security and
performance; and usability and reusability); 19 pairs
are relative conflict (e.g. reliability and performance;
usability and security; and performance and
usability); and 50 pairs are never conflict (e.g.
accuracy and maintainability; security and accuracy;
and usability and recoverability). The rest of
relationships are not known due to there is no
information available in the literature about how
those pairs of NFRs contribute to each other. In the
conflicts catalogue, it is presented as “the blank
Furthermore, this catalogue shows that NFRs
with the most conflict with other NFRs is
performance. Performance has absolute conflict with
accuracy, availability, confidentiality, dependability,
interoperability, maintainability, portability,
reusability, safety, security, and understandability,
and it has relative conflict with functionality,
recoverability, reliability, and usability.
The investigation also indicates that certain
attributes of a particular type of NFR can be in
conflicts with each other. These conflicts point to the
self-conflicting relationships for a particular type of
NFR. Self-conflicting relationship is defined as a
situation where the attributes of a single type of NFR
are in conflict. For example, the relative conflict
between performance and performance
requirements. Performance requirements can be
characterized among others by “response time” and
“capacity”. In many systems, these two attributes are
in conflict. For example in a road traffic pricing
system (Brito & A. 2004; Moreira, Araujo & Brito
2002), multi-user attribute
has negative contribution
to the response time of the system. This means that
increasing the number of concurrent users in the
system may diminish the response time of the
The investigation by using frequency analysis
technique also indicates that conflicts between
security and performance requirements are the most
frequently conflicts discussed in the literature.
33.33% of the reviewed articles talk about this
conflict, followed by conflicts between security and
usability requirements (23.33%) and conflicts
between availability and performance requirements
(20%). This result indicates that those three types of
conflicts (i.e. conflicts between security and
In these papers (Brito & A. 2004; Moreira, Araujo & Brito
2002), the term “attribute” is considered as “concern”.
performance, between security and usability, and
between availability and performance) are the three
most frequent conflicts in the software projects and
the most considered and essential to deal with in the
software development process. The top ten
conflicting NFRs that are often discussed in the
literature are presented in Table 3.
Table 3: Conflicting NFRs in Literature.
Conflicting NFRs
Nature of
Security and Performance
Security and Usability
Availability and Performance
Performance and Portability
Reusability and Performance
Interoperability and Performance
Maintainability and Performance
Reliability and Performance
Usability and Performance
Usability and Reusability
The catalogue of conflicts among NFRs, as
presented in Figure 2, extends and complements
previously published NFRs conflict models. Our
work focuses on the extent and relativity of NFRs
conflicts, that is, on negative links between NFRs
and its corresponding level. Most of the existing
conflict models in the literature, however,
concentrate on both positive and negative
interrelationships. For example, Wiegers (2003) has
developed a relationship matrix that represents the
positive and negative relationships between
particular type of NFRs; Egyed & Grünbacher
(2004) created a model of potential conflict and
cooperation among NFRs; and Sadana & Liu (2007)
have also defined conflict relationship and support
relationship as the two types of contribution of a
particular type of NFR on the other types of NFRs.
Utilizing our NFRs catalogue of conflicts in
conjunction with the existing conflict models
extends the overall understanding of how NFRs
associate with each other (positive or negative) and
how this negative association can be characterized in
term of the relative characteristic of NFRs.
Our NFRs catalogue of conflicts could be used
by software developers in dealing with conflicts
among NFRs. The conflicts catalogue can be used to
identify which NFRs of the system that are really in
conflict, including how relative the conflicts are in
term of the relative characteristic of NFRs. If the
conflict identified is an absolute conflict”, then
software developers may need to identify the
potential strategies to resolve this conflict, such as
the prioritization. On the other hand, if it is a
relative conflict”, then software developers need to
understand and evaluate this particular NFR in term
of numerous factors involve in the development
project, such as the meaning of this particular type
of NFR in the context of the system being
developed; the stakeholder involvement; or system
development methodology used in the project, in
order to further investigate whether those NFRs are
really in conflict.
This catalogue can also be used to analyze the
conflicts among NFRs. By using this catalogue in
conjunction with the framework presented by
Sadana & Liu (2007), software developers would be
able to develop a structural hierarchy of functional
and non-functional requirements affected by each
conflict type. Therefore, this catalogue could further
assist in the analysis of NFRs conflicts from the
perspective of functional requirements.
By utilizing this catalogue in conjunction with
the “NFR Prioritizer” method presented by Mala &
Uma (2006), this catalogue would assist software
developers to analyze the tradeoffs among NFRs and
prioritize the NFRs. In term of analyzing the NFRs
tradeoff, this catalogue can be used as the basis to
develop the “NFR Taxonomy” that will be used to
identify the type of relationships among NFRs. The
NFR Taxonomy represents the conflicting or
dependable association between each NFR type. The
example of NFR taxonomy is presented as follow
(Mala & Uma 2006):
This taxonomy represents that usability
contributes positively to accessibility, installability,
operability while it also contributes negatively to
maintainability. Then, by combining the weight of
user preference on each NFR type and the level of
NFRs tradeoff derived from the NFR Taxonomy,
software developers would be able to prioritize the
NFRs of the system in term of the existence of
conflicts among them.
Furthermore, this catalogue can also be used in
conjunction with the “Trace Analyzer” technique
developed by Egyed & Grünbacher (2004). The aim
of this technique is to identify the true conflicts
among NFRs. By tracing the relationship between
ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering
the system test case and the software program code,
trace analyzer can analyze whether the conflicts
listed in the NFRs conflict catalogue are really in
conflict in the developed system.
In term of resolution, the catalogue of conflicts
can also be used to resolve the conflicts among
NFRs. For example, by using this catalogue in
conjunction with the “Non-Functional
Decomposition (NFD)” framework developed by
Poort & de With (2004), software developers would
be able to decompose the NFRs of the system when
the NFRs conflicts identified.
Majority of techniques to manage the NFRs conflicts
provide the NFRs documentation, catalogue, or list
of potential conflicts among various types of NFRs.
However, none of them deal with relative
characteristic of NFRs. In fact, it is widely
acknowledged that NFRs are also relative. NFRs can
be viewed, interpreted, and evaluated differently by
different people and different context within which
the system is being developed. The interpretation
and importance of them may also vary depending on
the particular system being developed as well as the
extent of stakeholders‟ involvement. Consequently,
the positive or negative relationships among them
are not always obvious.
In this paper we present a catalogue of conflicts
among NFRs by considering this relative
characteristic. We present the relativity of conflicts
based on three categories: absolute conflict; relative
conflict; and never conflict. This distinction would
assist developer to perform further analysis towards
the conflict identified and investigate the potential
strategy to resolve the conflict.
This catalogue can be used to identify the
conflicts among NFRs in various phase of software
development project. For example, in the
requirements engineering phase, during the
elicitation process, system analysts would be able to
identify which NFRs of the system that will be in
conflict and how relative this conflict is. This
analysis would allow developers to identify the
conflicts among NFRs early and to discuss this
potential conflict with the system‟s stakeholder
before specifying the software requirements. As
another example, during the architecture design
process, system designers would also be able to use
this catalogue to analyze the potential conflict
among NFRs in term of the architecture decision
(e.g. layering, clustering, and modularity). The
relativity of conflict relationship presented in the
catalogue, would allow system designers to
investigate the potential architecture strategies to get
the best solution based on the type of conflicts
among NFRs. Furthermore, by using this catalogue
as the basis of conflict identification, we can adopt
numerous existing conflict analysis and conflict
resolution techniques, such as (Egyed & Grünbacher
2004; Mala & Uma 2006; Poort & de With 2004;
Sadana & Liu 2007) to further investigate and
evaluate the NFRs conflicts. Some examples of the
existing techniques and the potential utilization of
the catalogue in these techniques have been
described in Section 5 “Using the Catalogue”.
In the process of investigating conflicts and
developing the conflicts catalogue, we also
identified 114 NFRs types listed in the literature.
Among these 114 types, more than 50% NFRs were
introduced without any definition or attributes
characterization while only 20% were provided with
definition and attributes characterization. This
statistic and the list of NFRs types without
definitions and attributes presented in this paper are
expected to encourage software engineering
community, particularly requirements engineering
community to further investigate the unclear NFRs
types and establish the clear concept about these
types of NFRs.
Further research will focus on collecting data
from software practitioners to complement the
catalogue. Those NFRs that have been removed
from the initial catalogue due to lack of definitions
and/or attributes will also be further investigated to
improve the completeness of the catalogue. The
catalogue from industry can also be compared with
the one developed from the content analysis.
Moreover, besides collecting data to develop the
conflicts catalogue, we would also perform further
research on investigating the relative conflicts
among NFRs. This study would not only investigate
how those NFRs dynamically generate conflicts with
each other in term of the context-based of the
system, but also to develop a framework to assist
developers in identifying in which situations those
NFRs are in conflict and in which situations are not.
The self-conflicting relationships will be covered in
this study.
This study is conducted as part of a long term
project of investigating conflicts among NFRs.
Findings of this investigation, especially the
conflicts catalogue, will be used as the basis to select
those NFRs that are known to be frequently in
conflict. The ultimate goal is to develop an
integrated framework to effectively manage the
conflicts among particular NFR by considering the
NFRs relative characteristic. This framework should
be able to identify not only the existence and the
extent of conflict, but also to characterize and find
the potential strategies to resolve the conflict.
In this study, we do not claim that the catalogue
of conflicts presented is an exhaustive list. But, this
catalogue represents what could be found in the
current literature. We propose to conduct further
research to compare and contrast our findings from
the comprehensive review of research literature and
the state of the practice.
We would like to thank The International
Schlumberger Foundation Paris for funding this
research through Faculty for the Future Award
Alexander, I. & Maiden, N. 2004, Scenarios, stories, use
cases: through the systems development life-cycle,
John Wiley & Sons, Ltd, Chichester, England.
Boehm, B. & Egyed, A. 1998, 'WinWin requirements
negotiation processes: a multi-project analysis', 5th
International Conference on Software Processes.
Boehm, B. & In, H. 1996a, 'Aids for identifying conflicts
among quality requirements', IEEE Software, March
Boehm, B. & In, H. 1996b, 'Identifying quality-
requirements conflict', IEEE Software, vol. 13, no. 2,
pp. 25-35.
Breitman, K.K., Prado Leite, J.C.S. & Finkelstein, A.
1999, 'The world's a stage: a survey on requirements
engineering using a real-life case study', Journal of the
Brazilian Computer Society, vol. 6, no. 1, pp. 1-57.
Brito, I. & A., M. 2004, 'Integrating the NFR framework
in a RE model', paper presented to the Early Aspects:
Aspect-Oriented Requirements Engineering and
Architecture Design, Lancaster, UK.
Charette, R.N. 1990, Applications strategies for risk
analysis, McGraw-Hill, New York.
Chung, L., Nixon, B.A. & Yu, E. 1995, 'Using non-
functional requirements to systematically support
change', The second international symposium on
requirements engineering, IEEE, York, pp. 132-139.
Chung, L., Nixon, B.A. & Yu, E. 1996, 'Dealing with
change: an approach using non-functional
requirements', Requirements Engineering, vol. 1, no.
4, pp. 238-260.
Chung, L., Nixon, B.A., Yu, E. & Mylopoulos, J. 2000,
Non-functional requirements in software engineering,
Kluwer Academic Publishers, Massachusetts.
Curtis, B., Krasner, H. & Iscoe, N. 1988, 'A field study of
the software design process for large systems',
Communication of the ACM, vol. 31, no. 11, pp. 1268-
Ebert, C. 1998, 'Putting requirement management into
praxis: dealing with nonfunctional requirements',
Information and Software Technology, vol. 40, no. 3,
pp. 175-185.
Egyed, A. & Boehm, B. 1998, 'A comparison study in
software requirements negotiation', 8th Annual
International Symposium on Systems Engineering
Egyed, A. & Grünbacher, P. 2004, 'Identifying
requirements conflicts and cooperation: how quality
attributes and automated traceability can help', IEEE
Software, vol. 21, no. 6, pp. 50 - 58.
Finkelstein, A. & Dowell, J. 1996, 'A comedy of errors:
the London ambulance service case study', Eigth
International Workshop Software Specification and
Design, pp. 2-5.
Firesmith, D. 2003, 'Using quality models to engineer
quality requirements', Journal of Object Technology,
vol. 2, no. 5, pp. 67-75.
Glinz, M. 2005, 'Rethinking the notion of non-functional
requirements', Third World Congress for Software
Quality, Munich, Germany, pp. 55-64.
Glinz, M. 2007, 'On non-functional requirements', 15th
IEEE International Requirements Engineering
Conference (RE '07), IEEE, pp. 21-26.
Grimshaw, D.J. & Draper, G.W. 2001, 'Non-functional
requirements analysis: deficiencies in structured
methods', Information and Software Technology, vol.
43, pp. 629-634.
Heumesser, N., Trendowicz, A., Kerkow, D., Gross, H. &
Loomans, L. 2003, Essential and requisites for the
management of evolution - requirements and
incremental validation, Information Technology for
European Advancement, ITEA-EMPRESS
Kotonya, G. & Sommerville, I. 1998, Non-functional
Krippendorff, K. 2004, Content analysis: and introduction
to its methodology, Second edn, Sage Publications,
Inc., Thousand Oaks, USA.
Lauesen, S. 2002, Software requirements: styles and
techniques, Addison-Wesley.
Leveson, N.G. & Turner, C.S. 1993, 'An investigation of
the Therac-25 accidents', IEEE Computer, vol. 26, no.
7, pp. 18-41.
Mairiza, D., Zowghi, D. & Nurmuliani, N. 2009,
'Managing conflicts among non-functional
requirements', 12th Australian Workshop on
Requirements Engineering (AWRE '09), Sydney.
Mairiza, D., Zowghi, D. & Nurmuliani, N. 2010, 'An
investigation into the notion of non-functional
requirements', 25th ACM Symposium On Applied
Computing ACM, Switzerland.
Mala, G.S.A. & Uma, G.V. 2006, 'Elicitation of non-
functional requirements preference for actors of
ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering
usecase from domain model', Lecture Notes in
Computer Science, vol. 4303/2006, pp. 238-243.
Mittermeir, R.T., Roussopoulos, N., Yeh, R.T. & Ng, P.A.
1989, Modern software engineering, foundations and
current perspectives, Van Nostrand Reinhold Co, New
York, NY, USA.
Moreira, A., Araujo, J. & Brito, I. 2002, 'Crosscutting
quality attributes for requirements engineering', 14th
international conference on Software engineering and
knowledge engineering, ACM, Ischia, Italy.
Neuendorf, K.A. 2001, The content analysis guidebook,
First edn, Sage Publications, Inc.
Paech, B. & Kerkow, D. 2004, Non-functional
requirements engineering - quality is essential, 10th
International Workshop on Requirements
Engineering: Foundation for Software Quality, pp. 27-
Poort, E.R. & de With, P.H.N. 2004, 'Resolving
requirement conflicts through non-functional
decomposition', Fourth Working IEEE/IFIP
Conference on Software Architecture (WICSA '04),
Robertson, S. & Robertson, J. 2006, Mastering the
requirements process, 2nd edn, Addison-Wesley,
Robinson, W.N., Pawlowski, S.D. & Volkov, V. 2003,
'Requirements interaction management', ACM
Computing Surveys, vol. 35, no. 2, pp. 132-190.
Sadana, V. & Liu, X.F. 2007, 'Analysis of conflict among
non-functional requirements using integrated analysis
of functional and non-functional requirements', 31st
International Computer Software and Applications
Conference (COMPSAC 2007), IEEE.
Sommerville, I. 2004, Software Engineering, 7 edn,
Pearson Education Limited, Essex, England.
Stemler, S. 2001, 'An overview of content analysis',
Practical Assessment, Research & Evaluation, vol. 7,
no. 17.
Weber, R.P. 1989, Basic content analysis, Sage
Publications, Inc.
Wiegers, K.E. 2003, Software requirements, 2nd edn,
Microsoft Press, Washington.
Yeh, R.T. 1982, 'Requirements analysis - a management
perspective', COMPSAC '82, pp. 410-416.
Yusop, N., Zowghi, D. & Lowe, D. 2008, 'The impacts of
non-functional requirements in web system projects',
International Journal of Value Chain Management
vol. 2, no. 1, pp. 18-32.