Identifying Conflicts in Requirements Engineering

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
IEEE SYSTEMS JOURNAL 1
The Concept of Order of Conflict
in Requirements Engineering
Alejandro Salado and Roshanak Nilchiani
Abstract—Conventional approaches to system design use re-
quirements as boundary conditions against which the design
activity occurs. Decisions at a given level of the architecture
decomposition can result in the flowing down of conflicting re-
quirements, which are easy to fulfill in isolation but extremely
difficult when dealt with simultaneously. Designing against such
sets of requirements considerably limits system affordability. Ex-
isting research on the evaluation of such conflicts primarily seek to
determine the level of conflicts between pairs of requirements. We
assert in this paper that these methods are incomplete and using
traditional methodologies can result in missing significant conflicts
between groups of requirements. We provide a mathematical proof
for this assertion and present two case studies that support the
mathematical proof. We present the concept of “order of conflict.”
The objective of this paper is to prove why pairwise-based con-
flicting requirements identification and analysis methods based on
pairwise comparisons are flawed.
Index Terms—Conflict identification, conflicting requirements,
satellite communication, system architecture, system theory.
I. INTRODUCTION
ENGINEERED systems are being evolved and developed to
provide responses to a variety of given problems. Defining
the problem set is thus of primary importance because “it is
not possible to have an acceptable system even with the best
solution space if this is based on an incorrect problem space
formulation” [1]. Consequently, requirements engineering is
considered by some researchers as the cornerstone of the sys-
tems engineering process [2]. This argument is supported by
several independent researches that have shown the application
of good requirements engineering practices and their influences
on the success or failure of the development of a system [1]–[9].
The use of requirements engineering is therefore widespread
in the development of complex systems, being mainly used to
define the problem to be solved or, in other words, what the
system is expected to do [10], [11].
Manuscript received November 16, 2013; revised February 22, 2014;
accepted April 1, 2014. This work was supported in part by the Defense Ad-
vanced Research Projects Agency/NASA Ames under Contract NNA11AB35C
through the Fractionated Space Systems F6 Project.
A. Salado was with the School of Systems and Enterprises, Stevens Institute
of Technology, Hoboken, NJ 07030 USA. He is now with Kayser-Threde
GmbH, 81379 Munich, Germany (e-mail: asaladod@stevens.edu).
R. Nilchiani is with the School of Systems and Enterprises, Stevens Institute
of Technology, Hoboken, NJ 07030 USA (e-mail: rnilchia@stevens.edu).
Color versions of one or more of the figures in this paper are available online
at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/JSYST.2014.2315597
Although increasing efforts to improve and promote the
use of requirements have been undertaken [12]–[15], recurring
failure in complex systems remains [16], [17], which raises
the question of whether the use of systems engineering as-is
is sufficient to satisfy contemporary needs of society [18], [19].
We propose that one of the limiting factors in the successful
application of existing systems engineering practices is that
they are unable to uncover latent problems and conflicts early
enough. We base this assertion on two elements: 1) on the
recognition that “successful engineering design generally re-
quires the resolution of various conflicting design objectives
[that] are typically considered simultaneously” [20], which is
supported by recent studies on correlating a variety of factors
and cost growth [21]–[26]; 2) on previous experience that
relates the cost of correction to the development phase or status
[8]. We suggest that, if such conflicts are not apparent, then
they will eventually emerge. Therefore, the later they emerge,
the higher impact they will have on cost growth.
In engineering systems, the resolution of conflicting ob-
jectives is or should be traceable to system requirements.
Consequently, it can be argued that the problem that was
described earlier could be rephrased as that one of the problems
of existing requirement analysis techniques is that they do
not identify conflicting requirements early enough. Following
this line of reasoning, we survey existing methods that try to
identify conflicts between requirements and evaluate why they
are ineffective to exhaustively find conflicts. We achieve this
objective in three steps. First, we prove mathematically why
the principles of existing methods are by definition ineffective,
making use of an underlying mathematical theory for require-
ments. Second, we evaluate the exhaustiveness of a notional
conflict identification and analysis technique with a case study
that uses a set of three abstract requirements. Third, we test the
notional technique against a notional communication system to
evaluate its effectiveness against actual implementable systems.
This paper is organized as follows. Section II provides a liter-
ature review on requirement dependence and conflict identifica-
tion and analysis techniques. We present a mathematical proof
on the incapability of existing methods to exhaustively identify
conflicting requirements in Section III, which is preceded by
a presentation of the basic mathematical formulations of the
underlying mathematical theory that are needed to construct the
proof. Section IV showcases the effects of the ineffectiveness
proof with a notional conflict identification and analysis tech-
nique applied to two case studies, i.e., one reflecting an abstract
problem and one reflecting an implementable real system.
Finally, conclusions are summarized in Section V, along with
recommendations for future research.
1932-8184 © 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

2 IEEE SYSTEMS JOURNAL
TABLE I
REQUIREMENT DEPENDENCE TAXONOMY [32]
TABLE II
II. LITERATURE REVIEW
A. Requirement Dependence
The existence of conflicts between requirements at a given
level of a system’s decomposition inherently requires the ex-
istence of dependencies between them. In short, dependence
between requirements at a given level of a system’s decom-
position, i.e., requirement interdependence, indicates that the
fulfillment of a requirement is affected or affects the fulfillment
of another requirement that has not been derived or generated
by the first one, i.e., both requirements are not traceable in terms
of parent to child [27]. The existence of these interdependencies
or their acknowledgement appears not to be as trivial as it might
initially seem. For years, requirement dependence analysis has
been limited to traceability analysis across different levels of a
system’s decomposition, with the objectives of primarily iden-
tifying orphan requirements [2], analyzing change propagation
[28], or evaluating the effects of noncompliances from lower to
higher levels in a system’s decomposition [2].
However, recent years have seen an increase in research
in the field of requirement interdependence [27], [29], [30].
The majority of research in this field, as will be discussed
shortly, addresses requirement interdependence with the under-
lying purpose of assessing, identifying, or evaluating the effects
of change propagation among requirements [27], [29], [31],
although it has also served the purpose of challenging the use of
pairwise comparisons when prioritizing requirements [30], [32].
In order to understand how requirements relate to each
other, it is necessary to know the underlying dynamics. Con-
sequently, researchers have tried to define taxonomies of types
of dependencies between requirements that make it possible
to comprehensively model and visualize the different relations
and tensions existing between requirements. Tables I–IV list
TABLE III
TABLE IV
TABLE V
GENERALIZED REQUIREMENT DEPENDENCE TAXONOMY [30]
taxonomies of requirement dependencies proposed by several
researchers.
Kulshreshtha et al. [30] made a comprehensive survey on
existing research in the topic of requirement dependence tax-
onomies and synthesized its findings by enclosing all proposed
dependence relations in seven types, as listed in Table V.
As anticipated earlier, taxonomies include references, either
explicitly or implicitly, to the existence of conflicts between
requirements. They are referred to as CVALUE and ICOST
in [32]; constraints, preconditions, contradicts, and conflicts in
[33]; excluded in [34]; negative correlation and resource in [31];
and value/cost and conflict in [30].

SALADO AND NILCHIANI: CONCEPT OF ORDER OF CONFLICT IN REQUIREMENTS ENGINEERING 3
In conclusion, research in the field of requirements engi-
neering supports the interaction and interdependencies of cer-
tain requirements within a set of requirements as a source of
conflict. In the next section, we explore techniques that have
been proposed to identify and analyze conflicting requirements
within a set of requirements for a system’s development.
B. Requirement Prioritization
Requirements engineering is ultimately about defining
boundaries to a problem so that a newly developed system
satisfies stakeholder needs that led to those boundaries [11].
Requirements are prioritized primarily to resolve conflicts
between requirements, i.e., when two or more requirements
cannot be fulfilled simultaneously due to a variety of reasons
[35]. Prioritization techniques are usually based on pairwise
comparisons between requirements, in which their levels of
importance are compared against each other when a decision
needs to be taken. The importance level can be 1-D [36]–[39],
i.e., it reflects one type of importance, or multidimensional
[40], i.e., it weights different importance levels, such as value
to stakeholder, cost, and risk [41]–[46], or chooses a different
priority type depending on the objective of the decision [47].
Requirement prioritization assumes two types of conflicts.
First, there is technical incompatibility between two or more
requirements. Second, cost or schedule constraints are not com-
patible with the implementation of two or more requirements.
In both cases, requirement prioritization techniques inform
which requirement should be withdrawn from implementation,
in order to make the technical solution either feasible or com-
patible with given programmatic constraints. Since cost and
schedule constraints can be considered effectively as require-
ments [48], the second case infers that conflicts that do not exist
between pairs of requirements can appear in triplets.
A survey of the literature on requirement prioritization jus-
tifies the acknowledgment of the existence of conflicts be-
tween requirements and, in fact, these techniques can be seen
as conflicting requirements management techniques. However,
requirement prioritization techniques address how to resolve
conflicts and assume that either these have been identified in
advance by using other techniques [49] or they have appeared
during system development.
C. Conflicting Requirements
As discussed in the previous section, the importance of deal-
ing with conflicts between requirements for a successful system
development is widely recognized. Conflicting requirements
are usually detected in a continuous manner during a system’s
development. In fact, this has led the development of design
processes toward iterative approaches to achieve high levels of
effectiveness [2], [11]. Different identification approaches are
employed, however, during a system’s development. While con-
flicts between requirements naturally emerge during detailed
design and testing activities, they must be actively sought dur-
ing the early phases. Since cost of repairing defects increases
as a system’s development matures, early identification of
conflicting requirements is therefore of paramount importance
for successfully developing a system [8]. Several approaches
and techniques to resolve those conflicts have been proposed.
However, literature on identifying such conflicts remains scarce
and often vague, particularly in the field of systems engineering.
Existing work primarily concerns software systems, but as will
be discussed later here, the results are only partially applicable
to systems engineering due to the focus on logical statements
and the isolation from laws of physics and social laws and
regulations.
The identification and resolution of conflicting requirements
not only is of concern in large-scale systems but also can be
found in various domains, i.e., in software systems [50], embed-
ded systems [51], antenna systems [52], [53], financial systems
[54], or even personal decision systems [55] or legislations [56].
The absence of conflicts between requirements or, in a dif-
ferent terminology, the consistency of a set of requirements
is therefore considered a quality of good sets of requirements
extensively in existing literature [13], [57]–[62].
Conflicting requirements can be defined as those in which
“the solution to one requirement prohibits implementing the
other” [50]. A more rigorous definition is given in mathematical
form [63] and will be presented in the next section of this
paper. Some authors in the field of software systems have
further granulated the meaning of conflicting requirements. For
example, Liu and Yen [64] propose that conflicting require-
ments do not necessarily imply they are mutually exclusive,
but only that they reduce the available solutions to some de-
gree. The extreme would be reflected by so-called mutually
exclusive requirements, in which a solution would be certainly
impossible.
In fact, the concept of conflicting requirements has been
also categorized in various ways in software systems. A com-
prehensive categorization that integrates various dimensions is
proposed in [49], as follows:
1) process-level deviation, which indicates inconsistency
between a process-level rule and a specific process state;
2) instance-level deviation, which indicates inconsistency
between a product-level requirement and a specific state
of the running system;
3) terminology clash, which indicates that a single real-
world concept is given different syntactic names in the
requirements specification;
4) designation clash, which indicates that a single syntactic
name in the requirements specification designates differ-
ent real-world concepts;
5) structure clash, which indicates that a single real-world
concept is given different structures in the requirements
specification;
6) conflict, which indicates that a set of two or more asser-
tions cannot be fulfilled at the same time;
7) divergence, which indicates that a set of two or more
assertions cannot be fulfilled simultaneously for a given
scenario;
8) competition, which indicates divergence for a single
requirement;
9) obstruction, which indicates divergence with only one
assertion.

Easterbrook [65] proposes three broad types of conflicts that
have different levels of severity:
1) conflicting interpretations, which indicate that descrip-
tions do not match, usually because different perspectives
interpret things differently;
2) conflicting designs, which indicate when design state-
ments get into requirements and they want to reflect
different designs, even if the solution is the same;
3) conflicting terminologies, which indicate that the terms in
which things are described do not match.
In addition, he differentiates them from the following prob-
lems of consistency:
1) consistency of aspects, which indicates that dynamic
and functional requirements are not captured in a static
model;
2) consistency of views, which indicates overlap between
use cases. In this case, they distinguish between con-
flict, where the execution of one activity may prevent
the execution of another, and dependence, where they
have sequential constraints, i.e., one activity requires a
predecessor.
The term consistency has been also used to refer to alterna-
tives that may be inoperable due to the context in which they
have to operate, in contrast with the term conflict, which is left
to refer to actions that need to be executed simultaneously [66].
Using this understanding, four types of inconsistencies and two
types of conflicts were proposed in [66].
Inconsistencies:
1) Unneeded variant. The requirement is not needed
because it is never used in that context.
2) Unadoptable variant. The requirement is expected to
be used in the context, but the operational mode never
uses it.
3) Incompatible contexts. It cannot be adopted in any
context where it can be activated.
4) Static contribution. The inconsistency in quality con-
texts occurs when the conjunction of a context of one
contribution to a soft goal and a context of a goal
model variant, in which this contribution exists, is
inconsistent.
Conflicts:
1) Conflicting changes: “two or more system executable
processes try simultaneously to change the same ob-
ject in the system environment into different states.”
2) Exclusive possession: “two or more executable pro-
cesses need an exclusive possession of an object in
the environment.”
Based on our previous work [48], we suggest that such
distinction between context and environment is not necessary
because contexts or environments of operation are requirements
on their own merit, and therefore, there is no real concep-
tual difference between them. Literature in software systems
also addresses conflicting sources. They include participants’
perceptions of the problem; conflict between different goals,
between suggested solution components, between stated con-
straints, between perceived needs, between resource usage, as
well as discrepancies between priorities; and uncoordinated
changes introduced in the specification during the usual evo-
lution of requirements [65], [67], [68]. However, major con-
cerns are expressed with respect to “undetected inconsistencies,
which may lead to incorrect and unreliable systems, whose
faults are only discovered when it is too late,” i.e., during
operation [68].
Despite this criticality, the detection and elimination of con-
flicts “relies [almost] entirely on the intuition of experienced
modelers” [67]. This is also a concern expressed in the field
of systems engineering that resulted in the appearance of con-
straint theory [69].
The majority of techniques and methodologies used to iden-
tify conflicts are based on pairwise comparisons. Graph theory
has been proposed to support the identification of conflicts
between functional requirements by comparing critical pairs of
use cases [67]. A similar approach based on pairwise compar-
isons has been proposed for identifying conflicts between fuzzy
or imprecise requirements, i.e., those that are formulated using
nonquantitative terms such as “maximize,” “low,” or “high”
[64]. Following this line of thought, pairwise comparisons are
used to evaluate potential conflicts between viewpoints: when
viewpoints need to be compared, when there is a need to reason
with knowledge from several viewpoints, when the originators
insist their viewpoints are better, and when a coherent descrip-
tion is needed for further progress [65].
However, recognizing that most “techniques consider binary
conflicts only, that is, conflicts among pairs of requirements,”
some authors in software systems have already criticized pair-
wise comparison methods based on the fact that there may
be requirements that are not conflicting pairwise, but are con-
flicting when the three are considered simultaneously [29],
[68]. Unfortunately, these concerns persist today in the field
of systems engineering, as will be discussed in the following.
In software systems, given the need for “formal techniques
and heuristics for identifying n-ary conflicts from specifications
of goals/requirements and from known properties about the
domain” [29] and to identify “implicit (or hidden) inconsis-
tencies,” i.e., those on which the conflicts arise “between the
consequences of some requirements, rather than between the
requirements themselves” [68], some authors have proposed
different methods, which are primarily based on the use of
propositional logic, that evaluate a set of requirements as a
whole. Table VI provides an overview of such techniques.
In addition, heuristics have been also proposed as a mecha-
nism to seek for constraints [29], as follows:
1) If there is a satisfaction goal and a safety goal concerning
the same object.
2) If there is a confidentiality goal and an information goal
concerning the same object.
3) If there are two optimize goals interfering on the same
object’s attribute.
4) If there are several possible instantiations of the same
satisfaction goal among multiple agent instances.
5) If there is an achieve goal with a target condition Q and an
avoid goal on a condition S with Q overlapping S, then
two goals are divergent if it is possible for their respective
preconditions P and R to hold simultaneously.

TABLE VI
OVERVIEW OF CONFLICT IDENTIFICATION TECHNIQUES BASED
ON PROPOSITIONAL LOGIC IN SOFTWARE SYSTEMS
In conclusion, research in software systems has only ad-
dressed conflicts between functional requirements. However,
more types of requirements need to be addressed in systems en-
gineering. Taking our previous work as a reference [48], where
we propose four types of requirements to define any system,
i.e., functional requirements, performance requirements, re-
source requirements, and interaction requirements, there would
be a total of ten types of conflicts between requirements. Soft-
ware systems have only addressed one of them. Therefore, we
can affirm that the topic of identifying conflicting requirements
in systems engineering remains largely unexplored.
III. CONCEPT OF ORDER OF CONFLICT
A. Mathematical Background
Rigor in the probing of existing techniques to identify ex-
istence of conflicting requirements is achieved by framing the
activity under a formal underlying theory that enables precise
definitions and formal mathematical proofing techniques. This
research is grounded on the theoretical elements on require-
ments engineering defined in our recent paper [63] and in the
formal System Design Language (SDL) proposed by Wymore
in [70]. Conflicting requirements are defined there as those that
severely reduce the solution space when having to be fulfilled
simultaneously, being mutually exclusive when no solution
exists.
Following this concept, we will explore the conflicts between
requirements that reduce the solution space dramatically or
result in an impossible space.
B. Fundamental Flaw in Identifying Conflicts as Pairwise
Comparisons Between Requirements
As discussed earlier, existing techniques to identify and
evaluate conflicts between requirements are based on evaluating
conflict potential between pairs of requirements within a set
of requirements. However, we assert in this paper, and math-
ematically prove later, that an exhaustive evaluation of conflicts
between pairs of requirements is not sufficient to determine
whether conflicts exist within a set of requirements.
Fig. 1. Visual proof of Theorem 2.
Definition 1: Conflict identification is a function that de-
termines the level of tension between a requirement and one or
more requirements. It is denoted by rci
rci ∈ FNS(R, C). (1)
Note that FNS(A, B) is “the set of all functions defined over
the set A not empty with values in the set B not empty” [70].
R is the set of all requirements.
The function has been defined as a transformation from the
requirement domain into the set of complex numbers, so that
it can accommodate a wide variety of metrics that different
techniques may use for evaluation.
Theorem 1: Conflicts within a set of requirements cannot
be decomposed as proper subsets of conflicts between pairs of
requirements, for sets of requirements with size larger than 2.
That is
RSUBSETS = {Ri : #Ri ≥ 2; Ri ⊂ Rj} (2)
rci(RSUBSETS) ⊂ rci(Rj). (3)
Note that #Ri is the size of the set Ri, according to
SDL [70].
Proof: Proof for this theorem is possible through visual
representation of sets. Fig. 1 depicts three sets of systems, with
each set containing the systems that fulfill a particular require-
ment: set A contains the systems that fulfill requirement A;
set B contains the systems that fulfill requirement B; and
set C contains the systems that fulfill requirement C. Inter-
section of sets are the result of fulfilling various requirements
simultaneously, as defined in [63]. Therefore, it can be con-
cluded that there are no conflicts between the following pairs
of requirements:
1) requirements A and B: two compliant solutions;
2) requirements A and C: two compliant solutions;
3) requirements B and C: two compliant solutions.
However, it can be seen that the intersection of sets A, B, and
C leads to an empty set. This leads to the conclusion that there is
no system that is able to simultaneously fulfill requirements A,
B, and C. Consequently, there is a conflict between those three
requirements, which could not be related to conflicts between
pairs of requirements.
By extension, this proof is also valid for sets of requirements.
QED.

Theorem 1 informs that methods aimed at identifying con-
flicting requirements that are based on conflicts between pairs
of requirements are fundamentally flawed and techniques that
look at sets of requirements as wholes are needed.
C. Order of Conflict
Given the results of Theorem 1 and consequences on the ef-
fectiveness of conflicting requirements identification and anal-
ysis techniques, we propose the concept “order of conflict” as a
metric to evaluate the level of exhaustion a technique may offer.
This level of exhaustion is given by the size of the requirement
subset, against which each requirement is evaluated for conflict
identification and analysis.
Definition 2: The conflict order is the level of exhaustion,
on which the function conflict identification has been exercised.
The maximum conflict order of a conflict identification function
is given by the number of requirements within the set of
requirements to be fulfilled.
Given rci(RSUBSETS)
Order 1 : #Ri ≤ 2 ∀ Ri ∈ RSUBSETS and #Ri
= 2 for some Ri ∈ RSUBSETS (4)
Order 2 : #Ri ≤ 3 ∀ Ri ∈ RSUBSETS and #Ri
= 3 for some Ri ∈ RSUBSETS (5)
Order n : #Ri ≤ n + 1 ∀ Ri ∈ RSUBSETS and #Ri
= n + 1 for some Ri ∈ RSUBSETS. (6)
Under these definitions, conflict identification and analysis
techniquesdescribedinSection IIareconsideredtobeoforder2.
Since the conflict-order metric measures a level of exhaus-
tion, it may be used for trading off computational needs or
required effort against the associated risk level. This capability
is proposed as future research, and therefore, it is not further
elaborated in this paper.
IV. APPLICATION: CASES WHERE LACK OF
COMPLETENESS RESULTS IN UNIDENTIFIED CONFLICTS
In the previous section, we have formally demonstrated
why pairwise comparisons cannot be trusted when identifying
conflicting requirements because of their lack of completeness
when exhausting all one-to-one relations. Here, we provide two
practical examples that showcase this flaw in practice.
The first case presents a mathematical problem, where each
mathematical statement can be seen as an abstraction of a
system requirement. The case shows how, while solutions exist
for permutations of such statements, no solution can be found
when all statements are considered simultaneously.
The second case is a notional case study that reflects an early
design of a communication system for a satellite against a set of
actual system requirements. The case shows how, while systems
can be built to satisfy any pair of requirements, there is no
system that can meet all system requirements simultaneously.
Therefore, both cases support the mathematical proof pre-
sented in the previous section and showcase how pairwise
comparison methods for conflict identification are not able to
detect actual conflicts that will arise when developing a system.
Fig. 2. Solutions to inequalities.
TABLE VII
CASE I: PAIR RELATIONSHIPS TO BE EVALUATED FOR CONFLICT
IDENTIFICATION AND RESULTING SYSTEMS OF INEQUALITIES
A. Case 1: System of Inequalities
This case study uses a mathematical problem, where each
mathematical statement can be seen as an abstraction of a
system requirement. The case shows how, while solutions exist
for permutations of such statements, no solution can be found
when all statements are considered simultaneously.
Consider the following inequalities 7, 8, and 9 and their
visualizations in Fig. 2 (note that vertical lines represent the
solutions to inequality 7, horizontal lines represent the solutions
to inequality 8, and diagonal lines represent the solutions to
inequality 9). That is
y > 2 · x + 3 (7)
y > −2 · x + 200 (8)
y < 50. (9)
Each inequality can be considered an abstraction of a require-
ment. Conflict identification techniques that are based on one-
to-one comparisons, which evaluate pairs of requirements to
determine their level of tension, would exhaust every one-to-
one relationship, as listed in Table VII. It shall be noted that,
making use of symmetry, only half of the relationships need
to be explored. Such pair relationships result in the system of
inequalities given in Table VII.
Solving the systems of inequalities resulting from pairs 1, 2,
and 3 yields the results displayed in Fig. 2. As conveyed by
the areas defined by line crossings, solutions exist for each one
of the three systems of inequalities and, thus, for each pair of
“abstracted” requirements. Since solutions exist on each pair
and we assume that the reduction in solution space is not con-
sidered severe, conflict identification and analysis techniques

TABLE VIII
NOTIONAL SYSTEM REQUIREMENTS
that are based on pairwise comparison would determine a low
level of conflict for the given example.
As inferred from the assessment, because every system of
inequalities formed by any permutation of two of the inequal-
ities presented earlier has a set of valid solutions, the level of
conflict is considered very low, and as a result, existing conflict
identification methods would suggest proceeding with system
development without signaling a need to challenge existing
requirements or to account for the associated risk.
However, trying to find a solution in the space formed by
the three inequalities [see (10)] yields a significantly different
scenario. Fig. 2 shows that there is no area or even point
that solves the three inequalities simultaneously. Consequently,
although pairwise analyses identified a low level of conflict
and, therefore, of development risk, actual execution of the
development activities would face all consequences of trying
to design a system without solution. That is
y > 2 · x + 3
y > −2 · x + 200
y < 50.
(10)
This result supports the mathematical proof that was pre-
sented in the previous section: exhaustion of conflict analy-
sis between pairs of requirements does not provide complete
information on the existence of actual conflicts between re-
quirements. Consequently, any method that aims at identify-
ing conflicts between requirements should explore the set of
requirements as a whole and not on a one-to-one basis.
B. Case 2: A Satellite Communication System
Here, we use a notional case study that reflects an early
design of a communication system for a satellite against a set of
actual system requirements. The case shows that, while systems
can be built to satisfy any pair of requirements, there is no
system that can meet all system requirements simultaneously.
Satellite communication systems are usually characterized
by two figures of merit. Gain over equivalent noise temperature
(G/T) is used to evaluate the performance of a satellite’s
receiver for uplink communication, and effective isotropic ra-
diated power (EIRP) is used to evaluate the performance of a
satellite’s transmitter for downlink communication [71]. The
present case study addresses an early design of a satellite’s
transmitter for a given set of requirements. The set of require-
ments is given in Table VIII. Although it is a very basic subset
of what an actual set of requirements would contain, the pro-
posed requirements provide the necessary boundary conditions
to support the assertions of the present research. In essence, the
proposed requirements consist of one performance requirement
and two resource requirements.
TABLE IX
POTENTIAL AMPLIFIERS
TABLE X
POTENTIAL ANTENNAS
Using a generic model of a satellite transmitter, it is as-
sumed that it is formed of an amplifier, an antenna, and radio-
frequency cables that connect both subsystems [71]. For this
architecture, EIRP can be calculated as follows [71]:
EIRP = Pout · Gt · Ll (11)
where Pout represents the power at the output of the amplifier,
Gt represents the gain of the antenna, and Ll represents the
line losses. Assuming a narrow-band system, line losses can
be assumed constant for a given length. For this case study,
they are arbitrarily set to −3 dB, and cables are considered to
be massless. Transmitter power consumption Pin is a function
of Pout and the amplifier’s efficiency ηamp, as given in the
following equation:
Pout = Pin · ηamp. (12)
A set of 26 notional amplifiers, as listed in Table IX, has
been constructed using parametric estimations for mass and
efficiency using source data given in [71].
Antenna gain Gt is proportional to the antenna diameter and
can be calculated according to the following equation [71]:
Gt =
π2
· D2
· ηant
λ2
(13)
where D is the antenna diameter, ηant is the antenna efficiency,
and λ is the operating wavelength. Given the multifactorial
nature of antenna efficiency in actual developments, it has been
set to a constant value of 55%. A set of 15 antennas, as listed in
Table X, has been constructed using parametric estimation for

TABLE XI
CASE I: PAIR RELATIONSHIPS TO BE EVALUATED FOR CONFLICT
IDENTIFICATION AND RESULTING CONFLICT ASSESSMENT
Fig. 3. Tradespace for requirements in pair 3.
mass using source data in [71] that leads to the following direct
relation between antenna mass and antenna diameter:
Antennamass = π ·
D
2
2
· 10.25. (14)
Given the preceding assumptions and relations, EIRP can
be computed as a function of consumed power and antenna
diameter. That is
EIRP = f(Pin, D). (15)
Therefore, since the three elements of the function are con-
strained independently, this problem could be, in principle,
abstracted as a system of three inequalities, and as a result, we
could anticipate the same results, as in Case 1. Nevertheless, it
is worth exploring the effects of conflicting requirements on the
solution space for a notional system.
As previously discussed, conflict identification techniques
that are based on one-to-one comparisons, which evaluate pairs
of requirements to determine their level of tension, would
exhaust every one-to-one relationship, as listed in Table XI. It
shall be noted that, making use of symmetry, only half of the
relationships need to be explored.
A tradespace is filled up with 390 systems, which result from
exhausting every combination of the notional amplifiers and
antennas given in Tables IX and X, respectively. Evaluation
of potential solutions is performed for each pair defined in
Table XI. Figs. 3–5 show the corresponding tradespace for
pairs 1, 2, and 3, respectively.
Since solutions exist on each pair and we assume that the
reduction in solution space is not considered severe, conflict
identification and analysis techniques that are based on pairwise
comparison would yield the results showed in Table X, where a
level of 1 would reflect no conflict and a level of 5 would reflect
extreme conflict resulting in an empty solution space.
As inferred from the assessment, because every pair of
requirements formed by any permutation of two requirements
presented earlier have a set of valid solutions, the level of
conflict is considered very low, and as a result, existing conflict
identification methods would suggest proceeding with system
development without signaling a need to challenge existing
requirements or to account for the associated risk.
However, visualizing a tradespace that accounts for the three
requirements simultaneously yields a significantly different
scenario. Fig. 6 displays as a function of EIRP and power con-
sumption only systems that fulfill requirement 3, i.e., they fulfill
the mass requirement. Interestingly enough, there is no single
solution that can actually satisfy the three requirements simul-
taneously. Consequently, although pairwise analyses identified
a low level of conflict and, therefore, of development risk,
actual execution of the development activities would face all
consequences of trying to design a system without solution.
When solutions that do not fulfill the mass requirement are
removed from the tradespace, then there is no solution that is
acceptable.

Fig. 6. Tradespace for all requirements. Systems not compliant to requirement
3 are removed.
This result supports the mathematical proof that was pre-
sented in the previous section: exhaustion of conflict analy-
sis between pairs of requirements does not provide complete
information on the existence of actual conflicts between re-
quirements. Consequently, any method that aims at identify-
ing conflicts between requirements should explore the set of
requirements as a whole and not on a one-to-one basis.
V. CONCLUSION
The present paper begins with a review of existing tech-
niques to identify and analyze conflicting requirements. They
are based on comparing the existence of conflicts between
pairs of requirements within a set of requirements. However,
the present research mathematically demonstrates that pairwise
comparisons between requirements, as an approach to identify
conflicts, is fundamentally flawed. As a result, existing tech-
niques are not able to exhaustively identify conflicts within a
set of requirements, but it is recognized that they may serve the
purpose of mitigating the risk that these conflicts do exist.
The present research supports the mathematical proof, to-
gether with two case studies that show, using a notional conflict
identification and analysis technique, the consequences of the
ineffectiveness of existing methods.
The first case study explores the existence of solutions to a
system of three inequalities versus the existence of solutions
for any permutation of two inequalities within the system. The
research shows that, although solutions exist for every pairset
of inequalities, they do not ensure that a solution exists for
the set of three inequalities. Consequently, existing conflict
identification and analysis techniques were not able to detect
the conflict.
The second case study explores the different alternatives
to design a notional satellite communication system against a
set of three requirements. While solutions exist for fulfilling
any pairset of two requirements, it is shown that there is no
single implementable solution that is able to fulfill the three
requirements simultaneously. Consequently, existing conflict
identification and analysis techniques were not able to detect
the conflict.
In conclusion, the present paper has formally demonstrated,
together with practical examples, that analyzing conflicts be-
tween pairs of requirements does not ensure a conflict-free
set of requirements. As a result, existing conflict identification
and analysis techniques are fundamentally flawed and cannot
be trusted when evaluating the level of conflict within a set
of requirements, which has a direct impact on the chance of
developing a successful system.
The results presented in this paper support the generation of
new research in the following areas:
1) development of heuristics, principles, or theories that
enable the identification of conflicting requirements in
advance to architectural or design activities;
2) theoretical development of techniques that can exhaus-
tively explore the existence of conflicts within a set of
requirements early in the system lifecycle;
3) development of computational methods that can reduce
the required effort to exhaustively explore the existence
of conflicts within a set of requirements.
REFERENCES
[1] W. Brace and K. Thramboulidis, “From requirements to design
specifications—A formal approach,” in Proc. Int. Design Conf., 2010,
pp. 639–650.
[2] D. M. Buede, The Engineering Design of Systems: Models and Methods,
2nd ed. Hoboken, NJ, USA: Wiley, 2009, ser. Systems Engineering and
Management.
[3] J. Weinberg, Quality Software Management. Volume 4 Anticipating
Change. New York, NY, USA: Dorset House, 1997.
[4] K. Lyytinen and T. Hirschheim, “Information systems failures—A survey
and classification of the empirical literature,” Oxford Surv. Inf. Technol.,
vol. 4, no. 1, pp. 257–309, Jan. 1987.
[5] K. T. Yeo, “Critical failure factors in information system projects,” Int. J.
Project Manag., vol. 20, no. 3, pp. 241–246, Apr. 2002.
[6] D. Dada, “The failure of E-government in developing countries: A litera-
ture review,” Electron. J. Inf. Syst. Dev. Ctries., vol. 26, no. 7, pp. 1–10,
2006.
[7] K. El Emam and A. Birk, “Validating the ISO/IEC 15504 measure of
software requirements analysis process capability,” IEEE Trans. Softw.
Eng., vol. 26, no. 6, pp. 541–566, Jul. 2000.
[8] B. W. Boehm and P. N. Papaccio, “Understanding and controlling soft-
ware costs,” IEEE Trans. Softw. Eng., vol. 14, no. 10, pp. 1462–1477,
Oct. 1988.
[9] S. McConnell, “From the editor—An ounce of prevention,” IEEE Softw.,
vol. 18, no. 3, pp. 5–7, May/Jun. 2001.
[10] “Systems engineering handbook,” Washington, DC, USA, NASA/SP-
2007-6105 Rev1, 2007.
[11] “INCOSE systems engineering handbook v. 3.2.2,” San Diego, CA, USA,
INCOSE-TP-2003-002-03.2.2, Oct. 2011.
[12] I. F. Hooks, Managing Requirements, NJIT Requirements Engineering
Handout. Newark, NJ, USA: New Jersey Inst. Technol., 2001.
[13] “Guide for writing requirements, version 1,” San Diego, CA, USA,
INCOSE-TP-2010-006-01, Apr. 17, 2012.
[14] N. Niu, A. Y. Lopez, and J.-R. C. Cheng, “Using soft systems method-
ology to improve requirements practices: An exploratory case study,”
IET Softw., vol. 5, no. 6, pp. 487–495, Dec. 2011.
[15] H. Kaindl, S. Brinkkemper, J. A. Bubenko, B. Farbey, S. J. Greenspan,
C. L. Heitmeyer, J. C. Sampaio do Prado Leite, N. R. Mead,
J. Mylopoulos, and J. Siddiqi, “Requirements engineering and technology
transfer: Obstacles, incentives and improvement agenda,” Requirements
Eng., vol. 7, no. 3, pp. 113–123, Sep. 2002.
[16] A. T. Bahill and S. J. Henderson, “Requirements development, verifica-
tion, and validation exhibited in famous failures,” Syst. Eng., vol. 8, no. 1,
pp. 1–14, 2005.
[17] R. E. Schwenn, R. C. Chitikila, D. R. Laufer, A. D. Rozzi, and
W. P. Smythe, “Defense acquisitions: Assessment of selected weapon pro-
grams,” United States Government Accountability Office, Washington,
DC, USA, Report GAO-11-233SP, Mar. 2011.

[18] M. D. Griffin, “How do we fix systems engineering?” presented at the
61st International Astronautical Congress, Praque, Czech Republic, 2010,
Paper IAC-10.D1.5.4.
[19] P. D. Collopy, “A research agenda for the coming renaissance in systems
engineering,” presented at the 50th AIAA Aerospace Sciences Meeting
Including the New Horizons Forum and Aerospace Exposition, Nashville,
TN, USA, 2012.
[20] C. A. Mattson and A. Messac, “Pareto frontier based concept selection
under uncertainty, with visualization,” Optim. Eng., vol. 6, no. 1, pp. 85–
115, Mar. 2006.
[21] P. Malone, H. Apgar, S. Stukes, and S. Sterk, “Unmanned aerial vehicles
unique cost estimating requirements,” in Proc. IEEE Aerosp. Conf., 2013,
pp. 1–8.
[22] P. Malone and L. Wolfarth, “Measuring system complexity to sup-
port development cost estimates,” in Proc. IEEE Aerosp. Conf., 2013,
pp. 1–13.
[23] M. Dwyer, D. Selva, B. Cameron, E. Crawley, and Z. Szajnfarber, “The
impact of technical complexity on the decision to collaborate and com-
bine,” in Proc. IEEE Aerosp. Conf., 2013, pp. 1–11.
[24] D. A. Bearden, “A complexity-based risk assessment of low-cost planetary
missions: When is a mission too fast and too cheap?” Acta Astronaut.,
vol. 25, no. 2–6, pp. 371–379, Mar. 2003.
[25] R. Valerdi, The Constructive Systems Engineering Cost Model
(COSYSMO): Quantifying the Costs of Systems Engineering Effort in
Complex Systems. Saarbrücken, Germany: VDM Verlag, 2008.
[26] C. J. Leising, R. Wessen, and R. Ellyin, “Spacecraft complexity subfactors
and implications on future cost growth,” in Proc. IEEE Aerosp. Conf.,
2013, pp. 1–11.
[27] A. Salado and R. Nilchiani, “Assessing the impacts of uncertainty propa-
gation to system requirements by evaluating requirement connectivity,”
presented at the INCOSE International Symposium, Philadelphia, PA,
USA, 2013.
[28] R. Keller, T. Edger, C. M. Eckert, and P. J. Clarkson, “Visualising change
propagation,” in Proc. ICED, Aug. 15–18, 2005, pp. 62–63.
[29] K. G. M. Eben and U. Lindemann, “Structural analysis of requirements—
Interpretation of structural criterions,” in Proc. 12th Int. DSM Conf., 2010,
pp. 249–261.
[30] V. Kulshreshtha, J. Boardman, and D. Verma, “The emergence of require-
ments networks: The case for requirements inter-dependencies,” Int. J.
Comput. Appl. Technol., vol. 45, no. 1, pp. 28–41, Oct. 2012.
[31] W. N. Robinson, S. D. Pawloaski, and V. Volkov, “Requirement interac-
tion management,” ACM Computing Surveys, vol. 35, no. 2: pp. 132-190.
[32] P. Carlshamere, K. Sandahl, M. Lindvall, B. Regnell, and N. D. Dag, “An
industrial survey of requirements interdependencies in software product
release planning,” in Proc. 5th IEEE Int. Symp. Requirements Eng., 2001,
pp. 84–91.
[33] K. Pohl, Process-Centered Requirements Engineering. New York, NY,
USA: Wiley, 1996.
[34] W. Zhan, H. Mei, and H. Zhao, “A feature-oriented approach to modeling
requirements dependencies,” in Proc. 13th Int. Conf. Requirement Eng.,
2005, pp. 273–282.
[35] E. Hull, K. Jackson, and J. Dick, Requirements Engineering, 2nd ed.
New York, NY, USA: Springer-Verlag, 2005.
[36] W. Brackett, Software Requirements, Pittsburgh, PA, USA, Softw. Eng.
Inst., Carnegie Mellon Univ., 1990. (SEICM-19-1.2, ADA235642).
[37] D. Tudor and G. A. Walter, “Using an agile approach in a large, traditional
organisation,” in Proc. AGILE, 2006, pp. 367–373.
[38] J. Karlsson, “Towards a strategy for software requirements selec-
tion,” Licentiate thesis 513, Linköping University, Linköping, Sweden,
Oct. 1995.
[39] ID: 545-BSI, Version: 10 N. R. Mead, Requirements Prioritization Intro-
duction, Pittsburgh, PA, USA 2008, ID: 545-BSI, Version: 10.
[40] D. Firesmith, “Prioritizing requirements,” J. Object Technol., vol. 3, no. 8,
pp. 35–47, Sep./Oct. 2004.
[41] C. L. Hwang and K. Yoon, Multiple Attribute Decision Making: Methods
and Applications. New York, NY, USA: Springer-Verlag, 1981.
[42] D. Greer, D. Bustard, and T. Sunazaka, “Prioritization of system changes
using cost-benefit and risk assessments,” in Proc. 4th IEEE Int. Symp.
Requirements Eng., 1999, pp. 180–187.
[43] D. Greer and G. Ruhe, “Software release planning: An evolutionary and
iterative approach,” J. Inf. Softw. Technol., vol. 46, no. 4, pp. 243–253,
Mar. 2004.
[44] M. Ramzan, M. A. Jaffar, and A. A. Shahid, “Value Based Intelligent
Requirement Prioritization (VIRP): Expert driven fuzzy logic based pri-
oritization technique,” Int. J. Innov. Comput., Inf. Control, vol. 7, no. 3,
pp. 1017–1038, Mar. 2011.
[45] A. Gulati, S. Sharma, and P. Mehmi, “Proposing security requirement
prioritization framework,” Int. J. Comput. Sci., Eng. Appl., vol. 2, no. 3,
pp. 27–37, Jun. 2012.
[46] C. E. Otero, A. Ejnioui, L. D. Otero, and A. Qureshi, “A modified
desirability-based prioritization technique for software requirements,”
ARPN J. Syst. Softw., vol. 2, no. 3, pp. 113–118, Mar. 2012.
[47] A. Salado and R. Nilchiani, “Adaptive requirements prioritization (ARP):
Improving decisions between conflicting requirements,” Unpublished.
[48] A. Salado and R. Nilchiani, “A categorization model of requirements
based on Max-Neef’s model of human needs,” Syst. Eng., vol. 17, to be
published.
[49] A. van Lamsweerde, R. Darimont, and E. Letier, “Managing conflicts in
goal-driven requirements engineering,” IEEE Trans. Softw. Eng., vol. 24,
no. 11, pp. 908–926, Nov. 1998.
[50] S. Robertson and J. Robertson, Mastering the Requirements Engineer-
ing Process. Getting Requirements Right, 3rd ed. Reading, MA, USA:
Addison-Wesley, 2012.
[51] M. Eisenring, L. Thiele, and E. Zitzler, “Conflicting criteria in embedded
system design,” IEEE Design Test Comput , vol. 17, no. 2, pp. 51–59,
Apr.–Jun. 2000.
[52] N. Skou, “Microwave remote sensing: Needs and requirements concern-
ing technology,” in Proc. 33rd Eur. Microw. Conf., 2003, pp. 863–866.
[53] Y. Chen, S. Yang, and Z. Nie, “Improving conflicting specifications
of time-modulated antenna arrays by using a multiobjective evolution-
ary algorithm,” Int. J. Numer. Model., vol. 25, no. 3, pp. 205–215,
May/Jun. 2012.
[54] E. King and H. Adrion, “Navigating the conflicting requirements of
the IRS, SEC, and FINRA: An approach for financial services firms,”
Practice, vol. 20, no. 14, pp. 577–580.
[55] T. Vartiainen, “Student life in computing: A variety of conflicting moral
requirements,” in Proc. 10th ACE, 2008, pp. 163–169.
[56] J.-C. Domec, B. Lachenbruch, F. C. Meinzer, D. R. Woodruff,
J. M. Warren, and K. A. McCulloh, “Maximum height in a conifer is
associated with conflicting requirements for xylem design,” Proc. Natl.
Acad. Sci., vol. 105, no. 33, pp. 12 069–12 074, Aug. 2008.
[57] Institute of Electrical and Electronics Engineers, Recommended Prac-
tice for Software Requirements Specifications, IEEE Std. 830-1993,
Dec. 2, 1993.
[58] J. E. Kasser, Applying Total Quality Management to Systems Engineering.
Boston, MA, USA: Artech House, Jun. 1995.
[59] P. Kar and M. Bailey, “Characteristics of good requirements,” presented at
the 6th Int. Symp. Int. Council Systems Engineering, Boston, MA, USA,
1996.
[60] R. S. Carson, E. Aslaksen, and R. Gonzales, “Requirements complete-
ness,” presented at the 14th Int. Symp. Int. Council Systems Engineering,
Toulouse, France, 2004.
[61] A. Katasonov and M. Sakkinen, “Requirements quality control: A unify-
ing framework,” Requirements Eng., vol. 11, no. 1, pp. 42–57, Mar. 2006.
[62] C. Hood, S. Wiedemann, S. Fichtinger, and U. Pautz, Require-
ments Management—The Interfaces Between Requirements Development
and All Other Systems Engineering Processes. Heildeberg, Germany:
Springer-Verlag, 2008.
[63] A. Salado, R. Nilchiani, and D. Verma, “Aspects of a formal theory of
requirements engineering: Stakeholder needs, system requirements, solu-
tion spaces, and requirements’ qualities,” Unpublished.
[64] X. F. Liu and J. Yen, “An analytic framework for specifying and analyzing
imprecise requirements,” in Proc. 18th ICSE, 1996, pp. 60–69.
[65] S. Easterbrook, “Resolving requirements conflicts with computer-
supported negotiation,” in Requirements Engineering: Social and Tech-
nical Issues. San Diego, CA, USA: Academic, 1994, pp. 41–65.
[66] R. Ali, F. Dalpiaz, and P. Giorgini, “Reasoning with contextual re-
quirements: Detecting inconsistency and conflicts,” Inf. Softw. Technol.,
vol. 55, no. 1, pp. 35–57, Jan. 2013.
[67] J. H. Hausmann, R. Heckel, and G. Taentzer, “Detection of conflicting
functional requirements in a use case-driven approach,” in Proc. 24rd
IEEE ICSE, 2002, pp. 105–115.
[68] V. Gervasi and D. Zowghi, “Reasoning about inconsistencies in natural
language requirements,” ACM Trans. Softw. Eng. Methodol., vol. 14,
no. 3, pp. 277–330, Jul. 2005.
[69] G. Friedman, Constraint Theory: Multidimensional Mathematical Model
Management. New York, NY, USA: Springer-Verlag, 2005, ser. FSR
International Series on Systems Science and Engineering.
[70] A. W. Wymore, Model-Based Systems Engineering. Boca Raton, FL,
USA: CRC Press, 1993.
[71] J. R. Wertz and W. J. Larson, Space Mission Analysis and Design, 3rd ed.
Portland, OR, USA: Microcosm, 1999, ser. Space Technology Library.

Alejandro Salado was born in Zamora, Spain, in
1984. He received the B.Sc. and M.Sc. degrees in
electrical engineering from the Polytechnic Univer-
sity of Valencia, Valencia, Spain; the M.Sc. degree
in project management and the M.Sc. degree in
electronics engineering from the Polytechnic Univer-
sity of Catalonia, Barcelona, Spain; the postgraduate
Master in Space Systems Engineering SPACETECH
from the Delft University of Technology, Delft, The
Netherlands; and the Ph.D. degree in systems en-
gineering from the Stevens Institute of Technology,
Hoboken, NJ, USA.
He is a Systems Engineer with Kayser-Threde GmbH (an OHB company),
Munich, Germany, where he primarily contributes to the development and
veriﬁcation of space systems. He is currently acting as a Chief Architect for
the Space Weather project and as a Systems Engineer for the Plato instrument,
actively contributing to the improvement of the company’s systems engineering
capability and leading an initiative to transform it into model centricity. He
was previously a Satellite Systems Engineer with EADS Astrium GmbH, an
Electronics Engineer with SENER-NTE S.A., a Stagiere Electrical Systems
Engineer with the European Space Agency, and an Intern Electronics Engineer
with Delta-Utec SRC. He has been exposed to a wide variety of manned and
unmanned space systems and his efforts have contributed to several projects,
including Plato, Space Weather (SWE), Environmental Mapping and Analysis
Program (EnMAP), Defense Advanced Research Projects Agency’s F6 Pro-
gram, Galileo In-Orbit Validation (IOV), Muscle Atrophy Research and Exer-
cise System (MARES), and Young Engineer’s Satellite 2 (YES2) among others.
His research interests include the generation and prioritization of requirements,
the design of elegant systems, and the development of affordable space systems.
Dr. Salado is a member of the International Council on Systems Engineering
(INCOSE). He was a recipient of the Fulbright International Science and
Technology Award in 2010; the Stevens Fellowship in 2010; and a Team
Guinness World Record for the longest manmade structure ever deployed in
space, with the YES2 project, in 2009.
Roshanak Nilchiani received the B.Sc. degree in
mechanical engineering from the Sharif University
of Technology, Tehran, Iran, in 1998; the M.S. de-
gree in engineering mechanics from the University
of Nebraska–Lincoln, Lincoln, NE, USA, in 2001;
and the Ph.D. degree in aerospace systems from
the Massachusetts Institute of Technology (MIT),
Cambridge, MA, USA, in 2005.
She is currently an Assistant Professor in systems
engineering with the School of Systems and Enter-
prises, Stevens Institute of Technology, Hoboken,
NJ, USA, where she joined as an Assistant Professor in 2006. Prior to
Stevens, during 2005–2006, she was a Technical Consultant with 4Frontiers
Corporation, a pioneer startup space company. From 2002–2005, she was a
Doctoral Research Assistant with the Space Systems Policy and Architecture
Research Consortium (SEAri Lab), MIT, focusing on decision making and
design under uncertainty, within the context of space systems. At MIT, she also
served as a Mission Analyst Consultant for a mars mission project in 2003. She
has about 40 journal and conference papers published. Her research has been
supported by the Defense Advanced Research Projects Agency, the Department
of Defense, and the Department of Homeland Security. Her research focuses on
computational modeling of complexity and system “ilities” for space systems
and other engineering systems, including the relationship between system
complexity, uncertainty, emergence, and risk. The other track of her current
research focuses on quantifying, measuring, and embedding resilience and
sustainability in large-scale critical infrastructure systems.
Dr. Nilchiani is an Associate Member of the American Institute of Aeronau-
tics and Astronautics and a member of the Society of Women Engineers, New
York Academy of Sciences, and International Council on Systems Engineering
(INCOSE). She has been a Reviewer for the IEEE systems journal and Wiley
Systems Engineering Journal.

Identifying Conflicts in Requirements Engineering

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Identifying Conflicts in Requirements Engineering

Similar to Identifying Conflicts in Requirements Engineering (20)

Recently uploaded

Recently uploaded (20)

Identifying Conflicts in Requirements Engineering