ugc cse ppr

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 Conflictin Requirements Engineering

Alejandro Salado and Roshanak Nilchiani

Abstract—Conventional approaches to system design use re-quirements as boundary conditions against which the designactivity occurs. Decisions at a given level of the architecturedecomposition can result in the flowing down of conflicting re-quirements, which are easy to fulfill in isolation but extremelydifficult when dealt with simultaneously. Designing against suchsets of requirements considerably limits system affordability. Ex-isting research on the evaluation of such conflicts primarily seek todetermine the level of conflicts between pairs of requirements. Weassert in this paper that these methods are incomplete and usingtraditional methodologies can result in missing significant conflictsbetween groups of requirements. We provide a mathematical prooffor this assertion and present two case studies that support themathematical 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 onpairwise comparisons are flawed.

Index Terms—Conflict identification, conflicting requirements,satellite communication, system architecture, system theory.

I. INTRODUCTION

ENGINEERED systems are being evolved and developed toprovide responses to a variety of given problems. Defining

the problem set is thus of primary importance because “it isnot possible to have an acceptable system even with the bestsolution space if this is based on an incorrect problem spaceformulation” [1]. Consequently, requirements engineering isconsidered by some researchers as the cornerstone of the sys-tems engineering process [2]. This argument is supported byseveral independent researches that have shown the applicationof good requirements engineering practices and their influenceson the success or failure of the development of a system [1]–[9].The use of requirements engineering is therefore widespreadin the development of complex systems, being mainly used todefine the problem to be solved or, in other words, what thesystem 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 NNA11AB35Cthrough the Fractionated Space Systems F6 Project.

A. Salado was with the School of Systems and Enterprises, Stevens Instituteof Technology, Hoboken, NJ 07030 USA. He is now with Kayser-ThredeGmbH, 81379 Munich, Germany (e-mail: [email protected]).

R. Nilchiani is with the School of Systems and Enterprises, Stevens Instituteof Technology, Hoboken, NJ 07030 USA (e-mail: [email protected]).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/JSYST.2014.2315597

Although increasing efforts to improve and promote theuse of requirements have been undertaken [12]–[15], recurringfailure in complex systems remains [16], [17], which raisesthe question of whether the use of systems engineering as-isis sufficient to satisfy contemporary needs of society [18], [19].

We propose that one of the limiting factors in the successfulapplication of existing systems engineering practices is thatthey are unable to uncover latent problems and conflicts earlyenough. We base this assertion on two elements: 1) on therecognition that “successful engineering design generally re-quires the resolution of various conflicting design objectives[that] are typically considered simultaneously” [20], which issupported by recent studies on correlating a variety of factorsand cost growth [21]–[26]; 2) on previous experience thatrelates the cost of correction to the development phase or status[8]. We suggest that, if such conflicts are not apparent, thenthey 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 wasdescribed earlier could be rephrased as that one of the problemsof existing requirement analysis techniques is that they donot identify conflicting requirements early enough. Followingthis line of reasoning, we survey existing methods that try toidentify conflicts between requirements and evaluate why theyare ineffective to exhaustively find conflicts. We achieve thisobjective in three steps. First, we prove mathematically whythe 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 notionalconflict identification and analysis technique with a case studythat uses a set of three abstract requirements. Third, we test thenotional technique against a notional communication system toevaluate 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 proofon the incapability of existing methods to exhaustively identifyconflicting requirements in Section III, which is preceded bya presentation of the basic mathematical formulations of theunderlying mathematical theory that are needed to construct theproof. Section IV showcases the effects of the ineffectivenessproof with a notional conflict identification and analysis tech-nique applied to two case studies, i.e., one reflecting an abstractproblem and one reflecting an implementable real system.Finally, conclusions are summarized in Section V, along withrecommendations 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.

http://www.ieee.org/publications_standards/publications/rights/index.html

mailto: [email protected]

mailto: [email protected]


2 IEEE SYSTEMS JOURNAL

TABLE IREQUIREMENT DEPENDENCE TAXONOMY [32]

TABLE IIREQUIREMENT DEPENDENCE TAXONOMY [33]

II. LITERATURE REVIEW

A. Requirement Dependence

The existence of conflicts between requirements at a givenlevel of a system’s decomposition inherently requires the ex-istence of dependencies between them. In short, dependencebetween requirements at a given level of a system’s decom-position, i.e., requirement interdependence, indicates that thefulfillment of a requirement is affected or affects the fulfillmentof another requirement that has not been derived or generatedby the first one, i.e., both requirements are not traceable in termsof parent to child [27]. The existence of these interdependenciesor their acknowledgement appears not to be as trivial as it mightinitially seem. For years, requirement dependence analysis hasbeen limited to traceability analysis across different levels of asystem’s decomposition, with the objectives of primarily iden-tifying orphan requirements [2], analyzing change propagation[28], or evaluating the effects of noncompliances from lower tohigher levels in a system’s decomposition [2].

However, recent years have seen an increase in researchin the field of requirement interdependence [27], [29], [30].The majority of research in this field, as will be discussedshortly, addresses requirement interdependence with the under-lying purpose of assessing, identifying, or evaluating the effectsof change propagation among requirements [27], [29], [31],although it has also served the purpose of challenging the use ofpairwise comparisons when prioritizing requirements [30], [32].

In order to understand how requirements relate to eachother, it is necessary to know the underlying dynamics. Con-sequently, researchers have tried to define taxonomies of typesof dependencies between requirements that make it possibleto comprehensively model and visualize the different relationsand tensions existing between requirements. Tables I–IV list

TABLE IIIREQUIREMENT DEPENDENCE TAXONOMY [34]

TABLE IVREQUIREMENT DEPENDENCE TAXONOMY [31]

TABLE VGENERALIZED REQUIREMENT DEPENDENCE TAXONOMY [30]

taxonomies of requirement dependencies proposed by severalresearchers.

Kulshreshtha et al. [30] made a comprehensive survey onexisting research in the topic of requirement dependence tax-onomies and synthesized its findings by enclosing all proposeddependence relations in seven types, as listed in Table V.

As anticipated earlier, taxonomies include references, eitherexplicitly or implicitly, to the existence of conflicts betweenrequirements. They are referred to as CVALUE and ICOSTin [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 ofconflict. In the next section, we explore techniques that havebeen proposed to identify and analyze conflicting requirementswithin a set of requirements for a system’s development.

B. Requirement Prioritization

Requirements engineering is ultimately about definingboundaries to a problem so that a newly developed systemsatisfies stakeholder needs that led to those boundaries [11].Requirements are prioritized primarily to resolve conflictsbetween requirements, i.e., when two or more requirementscannot be fulfilled simultaneously due to a variety of reasons[35]. Prioritization techniques are usually based on pairwisecomparisons between requirements, in which their levels ofimportance are compared against each other when a decisionneeds 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 valueto stakeholder, cost, and risk [41]–[46], or chooses a differentpriority type depending on the objective of the decision [47].

Requirement prioritization assumes two types of conflicts.First, there is technical incompatibility between two or morerequirements. Second, cost or schedule constraints are not com-patible with the implementation of two or more requirements.In both cases, requirement prioritization techniques informwhich requirement should be withdrawn from implementation,in order to make the technical solution either feasible or com-patible with given programmatic constraints. Since cost andschedule constraints can be considered effectively as require-ments [48], the second case infers that conflicts that do not existbetween 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 seenas conflicting requirements management techniques. However,requirement prioritization techniques address how to resolveconflicts and assume that either these have been identified inadvance by using other techniques [49] or they have appearedduring system development.

C. Conflicting Requirements

As discussed in the previous section, the importance of deal-ing with conflicts between requirements for a successful systemdevelopment is widely recognized. Conflicting requirementsare usually detected in a continuous manner during a system’sdevelopment. In fact, this has led the development of designprocesses toward iterative approaches to achieve high levels ofeffectiveness [2], [11]. Different identification approaches areemployed, however, during a system’s development. While con-flicts between requirements naturally emerge during detaileddesign and testing activities, they must be actively sought dur-ing the early phases. Since cost of repairing defects increasesas a system’s development matures, early identification ofconflicting requirements is therefore of paramount importance

for successfully developing a system [8]. Several approachesand techniques to resolve those conflicts have been proposed.However, literature on identifying such conflicts remains scarceand often vague, particularly in the field of systems engineering.Existing work primarily concerns software systems, but as willbe discussed later here, the results are only partially applicableto systems engineering due to the focus on logical statementsand the isolation from laws of physics and social laws andregulations.

The identification and resolution of conflicting requirementsnot only is of concern in large-scale systems but also can befound 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 requirementsis therefore considered a quality of good sets of requirementsextensively in existing literature [13], [57]–[62].

Conflicting requirements can be defined as those in which“the solution to one requirement prohibits implementing theother” [50]. A more rigorous definition is given in mathematicalform [63] and will be presented in the next section of thispaper. Some authors in the field of software systems havefurther granulated the meaning of conflicting requirements. Forexample, 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 mutuallyexclusive requirements, in which a solution would be certainlyimpossible.

In fact, the concept of conflicting requirements has beenalso categorized in various ways in software systems. A com-prehensive categorization that integrates various dimensions isproposed in [49], as follows:

1) process-level deviation, which indicates inconsistencybetween a process-level rule and a specific process state;

2) instance-level deviation, which indicates inconsistencybetween a product-level requirement and a specific stateof the running system;

3) terminology clash, which indicates that a single real-world concept is given different syntactic names in therequirements specification;

4) designation clash, which indicates that a single syntacticname in the requirements specification designates differ-ent real-world concepts;

5) structure clash, which indicates that a single real-worldconcept is given different structures in the requirementsspecification;

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 moreassertions cannot be fulfilled simultaneously for a givenscenario;

8) competition, which indicates divergence for a singlerequirement;

9) obstruction, which indicates divergence with only oneassertion.



Easterbrook [65] proposes three broad types of conflicts thathave different levels of severity:

1) conflicting interpretations, which indicate that descrip-tions do not match, usually because different perspectivesinterpret things differently;

2) conflicting designs, which indicate when design state-ments get into requirements and they want to reflectdifferent designs, even if the solution is the same;

3) conflicting terminologies, which indicate that the terms inwhich 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 dynamicand functional requirements are not captured in a staticmodel;

2) consistency of views, which indicates overlap betweenuse cases. In this case, they distinguish between con-flict, where the execution of one activity may preventthe execution of another, and dependence, where theyhave sequential constraints, i.e., one activity requires apredecessor.

The term consistency has been also used to refer to alterna-tives that may be inoperable due to the context in which theyhave to operate, in contrast with the term conflict, which is leftto refer to actions that need to be executed simultaneously [66].Using this understanding, four types of inconsistencies and twotypes of conflicts were proposed in [66].Inconsistencies:

1) Unneeded variant. The requirement is not neededbecause it is never used in that context.

2) Unadoptable variant. The requirement is expected tobe used in the context, but the operational mode neveruses it.

3) Incompatible contexts. It cannot be adopted in anycontext where it can be activated.

4) Static contribution. The inconsistency in quality con-texts occurs when the conjunction of a context of onecontribution to a soft goal and a context of a goalmodel variant, in which this contribution exists, isinconsistent.

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 inthe environment.”

Based on our previous work [48], we suggest that suchdistinction between context and environment is not necessarybecause contexts or environments of operation are requirementson their own merit, and therefore, there is no real concep-tual difference between them. Literature in software systemsalso 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, aswell 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, whosefaults are only discovered when it is too late,” i.e., duringoperation [68].

Despite this criticality, the detection and elimination of con-flicts “relies [almost] entirely on the intuition of experiencedmodelers” [67]. This is also a concern expressed in the fieldof 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 theoryhas been proposed to support the identification of conflictsbetween functional requirements by comparing critical pairs ofuse cases [67]. A similar approach based on pairwise compar-isons has been proposed for identifying conflicts between fuzzyor imprecise requirements, i.e., those that are formulated usingnonquantitative terms such as “maximize,” “low,” or “high”[64]. Following this line of thought, pairwise comparisons areused to evaluate potential conflicts between viewpoints: whenviewpoints need to be compared, when there is a need to reasonwith knowledge from several viewpoints, when the originatorsinsist their viewpoints are better, and when a coherent descrip-tion is needed for further progress [65].

However, recognizing that most “techniques consider binaryconflicts 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 maybe 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 fieldof systems engineering, as will be discussed in the following.In software systems, given the need for “formal techniquesand heuristics for identifying n-ary conflicts from specificationsof goals/requirements and from known properties about thedomain” [29] and to identify “implicit (or hidden) inconsis-tencies,” i.e., those on which the conflicts arise “between theconsequences of some requirements, rather than between therequirements themselves” [68], some authors have proposeddifferent methods, which are primarily based on the use ofpropositional logic, that evaluate a set of requirements as awhole. 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 concerningthe same object.

2) If there is a confidentiality goal and an information goalconcerning the same object.

3) If there are two optimize goals interfering on the sameobject’s attribute.

4) If there are several possible instantiations of the samesatisfaction goal among multiple agent instances.

5) If there is an achieve goal with a target condition Q and anavoid goal on a condition S with Q overlapping S, thentwo goals are divergent if it is possible for their respectivepreconditions P and R to hold simultaneously.



TABLE VIOVERVIEW 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], wherewe propose four types of requirements to define any system,i.e., functional requirements, performance requirements, re-source requirements, and interaction requirements, there wouldbe a total of ten types of conflicts between requirements. Soft-ware systems have only addressed one of them. Therefore, wecan affirm that the topic of identifying conflicting requirementsin 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 theactivity under a formal underlying theory that enables precisedefinitions and formal mathematical proofing techniques. Thisresearch is grounded on the theoretical elements on require-ments engineering defined in our recent paper [63] and in theformal System Design Language (SDL) proposed by Wymorein [70]. Conflicting requirements are defined there as those thatseverely reduce the solution space when having to be fulfilledsimultaneously, being mutually exclusive when no solutionexists.

Following this concept, we will explore the conflicts betweenrequirements that reduce the solution space dramatically orresult in an impossible space.

B. Fundamental Flaw in Identifying Conflicts as PairwiseComparisons Between Requirements

As discussed earlier, existing techniques to identify andevaluate conflicts between requirements are based on evaluatingconflict potential between pairs of requirements within a setof requirements. However, we assert in this paper, and math-ematically prove later, that an exhaustive evaluation of conflictsbetween pairs of requirements is not sufficient to determinewhether 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 ormore requirements. It is denoted by rci

rci ∈ FNS(R,C). (1)

Note that FNS(A,B) is “the set of all functions defined overthe 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 therequirement domain into the set of complex numbers, so thatit can accommodate a wide variety of metrics that differenttechniques may use for evaluation.

Theorem 1: Conflicts within a set of requirements cannotbe decomposed as proper subsets of conflicts between pairs ofrequirements, 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 toSDL [70].

Proof: Proof for this theorem is possible through visualrepresentation of sets. Fig. 1 depicts three sets of systems, witheach 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; andset C contains the systems that fulfill requirement C. Inter-section of sets are the result of fulfilling various requirementssimultaneously, as defined in [63]. Therefore, it can be con-cluded that there are no conflicts between the following pairsof 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, andC leads to an empty set. This leads to the conclusion that there isno system that is able to simultaneously fulfill requirements A,B, and C. Consequently, there is a conflict between those threerequirements, which could not be related to conflicts betweenpairs 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 pairsof requirements are fundamentally flawed and techniques thatlook 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 ametric to evaluate the level of exhaustion a technique may offer.This level of exhaustion is given by the size of the requirementsubset, against which each requirement is evaluated for conflictidentification 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 functionis given by the number of requirements within the set ofrequirements 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 analysistechniques described in Section II are considered to be of order 2.

Since the conflict-order metric measures a level of exhaus-tion, it may be used for trading off computational needs orrequired effort against the associated risk level. This capabilityis proposed as future research, and therefore, it is not furtherelaborated in this paper.

IV. APPLICATION: CASES WHERE LACK OF

COMPLETENESS RESULTS IN UNIDENTIFIED CONFLICTS

In the previous section, we have formally demonstratedwhy pairwise comparisons cannot be trusted when identifyingconflicting requirements because of their lack of completenesswhen exhausting all one-to-one relations. Here, we provide twopractical examples that showcase this flaw in practice.

The first case presents a mathematical problem, where eachmathematical statement can be seen as an abstraction of asystem requirement. The case shows how, while solutions existfor permutations of such statements, no solution can be foundwhen all statements are considered simultaneously.

The second case is a notional case study that reflects an earlydesign of a communication system for a satellite against a set ofactual system requirements. The case shows how, while systemscan be built to satisfy any pair of requirements, there is nosystem that can meet all system requirements simultaneously.

Therefore, both cases support the mathematical proof pre-sented in the previous section and showcase how pairwisecomparison methods for conflict identification are not able todetect actual conflicts that will arise when developing a system.

Fig. 2. Solutions to inequalities.

TABLE VIICASE 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 eachmathematical statement can be seen as an abstraction of asystem requirement. The case shows how, while solutions existfor permutations of such statements, no solution can be foundwhen all statements are considered simultaneously.

Consider the following inequalities 7, 8, and 9 and theirvisualizations in Fig. 2 (note that vertical lines represent thesolutions to inequality 7, horizontal lines represent the solutionsto inequality 8, and diagonal lines represent the solutions toinequality 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 todetermine 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 needto be explored. Such pair relationships result in the system ofinequalities 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 bythe areas defined by line crossings, solutions exist for each oneof the three systems of inequalities and, thus, for each pair of“abstracted” requirements. Since solutions exist on each pairand we assume that the reduction in solution space is not con-sidered severe, conflict identification and analysis techniques



TABLE VIIINOTIONAL SYSTEM REQUIREMENTS

that are based on pairwise comparison would determine a lowlevel of conflict for the given example.

As inferred from the assessment, because every system ofinequalities formed by any permutation of two of the inequal-ities presented earlier has a set of valid solutions, the level ofconflict is considered very low, and as a result, existing conflictidentification methods would suggest proceeding with systemdevelopment without signaling a need to challenge existingrequirements or to account for the associated risk.

However, trying to find a solution in the space formed bythe three inequalities [see (10)] yields a significantly differentscenario. Fig. 2 shows that there is no area or even pointthat solves the three inequalities simultaneously. Consequently,although pairwise analyses identified a low level of conflictand, therefore, of development risk, actual execution of thedevelopment activities would face all consequences of tryingto design a system without solution. That is{ y > 2 · x+ 3

y > −2 · x+ 200y < 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 completeinformation on the existence of actual conflicts between re-quirements. Consequently, any method that aims at identify-ing conflicts between requirements should explore the set ofrequirements 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 earlydesign of a communication system for a satellite against a set ofactual system requirements. The case shows that, while systemscan be built to satisfy any pair of requirements, there is nosystem that can meet all system requirements simultaneously.

Satellite communication systems are usually characterizedby two figures of merit. Gain over equivalent noise temperature(G/T ) is used to evaluate the performance of a satellite’sreceiver for uplink communication, and effective isotropic ra-diated power (EIRP) is used to evaluate the performance of asatellite’s transmitter for downlink communication [71]. Thepresent case study addresses an early design of a satellite’stransmitter for a given set of requirements. The set of require-ments is given in Table VIII. Although it is a very basic subsetof what an actual set of requirements would contain, the pro-posed requirements provide the necessary boundary conditionsto support the assertions of the present research. In essence, theproposed requirements consist of one performance requirementand two resource requirements.

TABLE IXPOTENTIAL AMPLIFIERS

TABLE XPOTENTIAL 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 thisarchitecture, 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 theline losses. Assuming a narrow-band system, line losses canbe assumed constant for a given length. For this case study,they are arbitrarily set to −3 dB, and cables are considered tobe massless. Transmitter power consumption Pin is a functionof Pout and the amplifier’s efficiency ηamp, as given in thefollowing equation:

Pout = Pin · ηamp. (12)

A set of 26 notional amplifiers, as listed in Table IX, hasbeen constructed using parametric estimations for mass andefficiency using source data given in [71].

Antenna gain Gt is proportional to the antenna diameter andcan 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 multifactorialnature of antenna efficiency in actual developments, it has beenset to a constant value of 55%. A set of 15 antennas, as listed inTable X, has been constructed using parametric estimation for



TABLE XICASE 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 directrelation between antenna mass and antenna diameter:

Antennamass = π ·(D

2

)2

· 10.25. (14)

Given the preceding assumptions and relations, EIRP canbe computed as a function of consumed power and antennadiameter. 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, wecould anticipate the same results, as in Case 1. Nevertheless, itis worth exploring the effects of conflicting requirements on thesolution space for a notional system.

As previously discussed, conflict identification techniquesthat are based on one-to-one comparisons, which evaluate pairsof requirements to determine their level of tension, wouldexhaust every one-to-one relationship, as listed in Table XI. Itshall be noted that, making use of symmetry, only half of therelationships need to be explored.

A tradespace is filled up with 390 systems, which result fromexhausting every combination of the notional amplifiers andantennas given in Tables IX and X, respectively. Evaluationof potential solutions is performed for each pair defined inTable XI. Figs. 3–5 show the corresponding tradespace forpairs 1, 2, and 3, respectively.

Since solutions exist on each pair and we assume that thereduction in solution space is not considered severe, conflict



identification and analysis techniques that are based on pairwisecomparison would yield the results showed in Table X, where alevel of 1 would reflect no conflict and a level of 5 would reflectextreme conflict resulting in an empty solution space.

As inferred from the assessment, because every pair ofrequirements formed by any permutation of two requirementspresented earlier have a set of valid solutions, the level ofconflict is considered very low, and as a result, existing conflictidentification methods would suggest proceeding with systemdevelopment without signaling a need to challenge existingrequirements or to account for the associated risk.

However, visualizing a tradespace that accounts for the threerequirements simultaneously yields a significantly differentscenario. Fig. 6 displays as a function of EIRP and power con-sumption only systems that fulfill requirement 3, i.e., they fulfillthe mass requirement. Interestingly enough, there is no singlesolution that can actually satisfy the three requirements simul-taneously. Consequently, although pairwise analyses identifieda low level of conflict and, therefore, of development risk,actual execution of the development activities would face allconsequences of trying to design a system without solution.

When solutions that do not fulfill the mass requirement areremoved from the tradespace, then there is no solution that isacceptable.



Fig. 6. Tradespace for all requirements. Systems not compliant to requirement3 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 completeinformation on the existence of actual conflicts between re-quirements. Consequently, any method that aims at identify-ing conflicts between requirements should explore the set ofrequirements 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. Theyare based on comparing the existence of conflicts betweenpairs of requirements within a set of requirements. However,the present research mathematically demonstrates that pairwisecomparisons between requirements, as an approach to identifyconflicts, is fundamentally flawed. As a result, existing tech-niques are not able to exhaustively identify conflicts within aset of requirements, but it is recognized that they may serve thepurpose 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 conflictidentification and analysis technique, the consequences of theineffectiveness of existing methods.

The first case study explores the existence of solutions to asystem of three inequalities versus the existence of solutionsfor any permutation of two inequalities within the system. Theresearch shows that, although solutions exist for every pairsetof inequalities, they do not ensure that a solution exists forthe set of three inequalities. Consequently, existing conflictidentification and analysis techniques were not able to detectthe conflict.

The second case study explores the different alternativesto design a notional satellite communication system against aset of three requirements. While solutions exist for fulfillingany pairset of two requirements, it is shown that there is nosingle implementable solution that is able to fulfill the threerequirements simultaneously. Consequently, existing conflictidentification and analysis techniques were not able to detectthe 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-freeset of requirements. As a result, existing conflict identificationand analysis techniques are fundamentally flawed and cannotbe trusted when evaluating the level of conflict within a setof requirements, which has a direct impact on the chance ofdeveloping a successful system.

The results presented in this paper support the generation ofnew research in the following areas:

1) development of heuristics, principles, or theories thatenable the identification of conflicting requirements inadvance to architectural or design activities;

2) theoretical development of techniques that can exhaus-tively explore the existence of conflicts within a set ofrequirements early in the system lifecycle;

3) development of computational methods that can reducethe required effort to exhaustively explore the existenceof conflicts within a set of requirements.

REFERENCES

[1] W. Brace and K. Thramboulidis, “From requirements to designspecifications—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 andManagement.

[3] J. Weinberg, Quality Software Management. Volume 4 AnticipatingChange. New York, NY, USA: Dorset House, 1997.

[4] K. Lyytinen and T. Hirschheim, “Information systems failures—A surveyand 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 ofsoftware 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 EngineeringHandout. 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 technologytransfer: Obstacles, incentives and improvement agenda,” RequirementsEng., 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, andW. 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 the61st 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 systemsengineering,” presented at the 50th AIAA Aerospace Sciences MeetingIncluding the New Horizons Forum and Aerospace Exposition, Nashville,TN, USA, 2012.

[20] C. A. Mattson and A. Messac, “Pareto frontier based concept selectionunder 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 vehiclesunique 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, “Theimpact 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 planetarymissions: 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 inComplex Systems. Saarbrücken, Germany: VDM Verlag, 2008.

[26] C. J. Leising, R. Wessen, and R. Ellyin, “Spacecraft complexity subfactorsand 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 changepropagation,” 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, “Anindustrial survey of requirements interdependencies in software productrelease 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 modelingrequirements 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, traditionalorganisation,” 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: Methodsand Applications. New York, NY, USA: Springer-Verlag, 1981.

[42] D. Greer, D. Bustard, and T. Sunazaka, “Prioritization of system changesusing 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 anditerative 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 IntelligentRequirement 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 requirementprioritization 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 modifieddesirability-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 requirementsbased on Max-Neef’s model of human needs,” Syst. Eng., vol. 17, to bepublished.

[49] A. van Lamsweerde, R. Darimont, and E. Letier, “Managing conflicts ingoal-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 embeddedsystem 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 specificationsof 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 ofthe 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 moralrequirements,” 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 isassociated 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 atthe 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 Developmentand All Other Systems Engineering Processes. Heildeberg, Germany:Springer-Verlag, 2008.

[63] A. Salado, R. Nilchiani, and D. Verma, “Aspects of a formal theory ofrequirements 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 analyzingimprecise 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 conflictingfunctional requirements in a use case-driven approach,” in Proc. 24rdIEEE ICSE, 2002, pp. 105–115.

[68] V. Gervasi and D. Zowghi, “Reasoning about inconsistencies in naturallanguage requirements,” ACM Trans. Softw. Eng. Methodol., vol. 14,no. 3, pp. 277–330, Jul. 2005.

[69] G. Friedman, Constraint Theory: Multidimensional Mathematical ModelManagement. New York, NY, USA: Springer-Verlag, 2005, ser. FSRInternational 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, in1984. He received the B.Sc. and M.Sc. degrees inelectrical engineering from the Polytechnic Univer-sity of Valencia, Valencia, Spain; the M.Sc. degreein project management and the M.Sc. degree inelectronics engineering from the Polytechnic Univer-sity of Catalonia, Barcelona, Spain; the postgraduateMaster in Space Systems Engineering SPACETECHfrom the Delft University of Technology, Delft, TheNetherlands; 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 andverification of space systems. He is currently acting as a Chief Architect forthe Space Weather project and as a Systems Engineer for the Plato instrument,actively contributing to the improvement of the company’s systems engineeringcapability and leading an initiative to transform it into model centricity. Hewas previously a Satellite Systems Engineer with EADS Astrium GmbH, anElectronics Engineer with SENER-NTE S.A., a Stagiere Electrical SystemsEngineer with the European Space Agency, and an Intern Electronics Engineerwith Delta-Utec SRC. He has been exposed to a wide variety of manned andunmanned space systems and his efforts have contributed to several projects,including Plato, Space Weather (SWE), Environmental Mapping and AnalysisProgram (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 andTechnology Award in 2010; the Stevens Fellowship in 2010; and a TeamGuinness World Record for the longest manmade structure ever deployed inspace, with the YES2 project, in 2009.

Roshanak Nilchiani received the B.Sc. degree inmechanical engineering from the Sharif Universityof Technology, Tehran, Iran, in 1998; the M.S. de-gree in engineering mechanics from the Universityof Nebraska–Lincoln, Lincoln, NE, USA, in 2001;and the Ph.D. degree in aerospace systems fromthe Massachusetts Institute of Technology (MIT),Cambridge, MA, USA, in 2005.

She is currently an Assistant Professor in systemsengineering 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 toStevens, during 2005–2006, she was a Technical Consultant with 4FrontiersCorporation, a pioneer startup space company. From 2002–2005, she was aDoctoral Research Assistant with the Space Systems Policy and ArchitectureResearch Consortium (SEAri Lab), MIT, focusing on decision making anddesign under uncertainty, within the context of space systems. At MIT, she alsoserved as a Mission Analyst Consultant for a mars mission project in 2003. Shehas about 40 journal and conference papers published. Her research has beensupported by the Defense Advanced Research Projects Agency, the Departmentof Defense, and the Department of Homeland Security. Her research focuses oncomputational modeling of complexity and system “ilities” for space systemsand other engineering systems, including the relationship between systemcomplexity, uncertainty, emergence, and risk. The other track of her currentresearch focuses on quantifying, measuring, and embedding resilience andsustainability 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, NewYork Academy of Sciences, and International Council on Systems Engineering(INCOSE). She has been a Reviewer for the IEEE systems journal and WileySystems Engineering Journal.

Education

ugc cse ppr