A Research on Measuring and Reducing Problem Complexity to Increase System Affordability: From Theory to Practice

Abstract

Requirement engineering is the cornerstone of systems engineering. Numerous large scale engineered systems face schedule delays, cost overruns and performance shortfalls that can be traced back to the requirements they need to fulfill. In fact, previous research has demonstrated strong relationship between requirements and systems affordability. This paper summarizes and puts into context the authors’ novel contributions in three domains of requirements engineering: systems theory, complexity science, and systems methodologies. The authors propose new theorems and their proofs on requirements affecting affordability, propose a new complexity metric at requirement stage that measures the complexity limit of the system at conceptual stage (even before a specific design is determined), and propose two methodologies to elicit excess-free requirement sets and to identify conflicting requirements more effectively. The paper showcases the value of structuring a research in such a manner, i.e. from theory to practice, enabling strengthening the bounds between theorists and practitioners.

Full text

Procedia Computer Science 44 ( 2015 ) 21 – 30
Available online at www.sciencedirect.com
1877-0509 © 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
Peer-review under responsibility of the Stevens Institute of Technology.
doi: 10.1016/j.procs.2015.03.037
ScienceDirect
2015 Conference on Systems Engineering Research
A Research on Measuring and Reducing Problem Complexity to
Increase System Affordability: From Theory to Practice
Alejandro Saladoa
*
, Roshanak Nilchiania
aStevens Institute of Technology, Hoboken NJ 07030, NJ (USA)
Abstract
Requirement engineering is the cornerstone of systems engineering. Numerous large scale engineered systems face
schedule delays, cost overruns and performance shortfalls that can be traced back to the requirements they need to
fulfill. In fact, previous research has demonstrated strong relationship between requirements and systems affordability.
This paper summarizes and puts into context the authors’ novel contributions in three domains of requirements
engineering: systems theory, complexity science, and systems methodologies. The authors propose new theorems and
their proofs on requirements affecting affordability, propose a new complexity metric at requirement stage that
measures the complexity limit of the system at conceptual stage (even before a specific design is determined), and
propose two methodologies to elicit excess-free requirement sets and to identify conflicting requirements more
effectively. The paper showcases the value of structuring a research in such a manner, i.e. from theory to practice,
enabling strengthening the bounds between theorists and practitioners.
© 2015 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of Stevens Institute of Technology.
Keywords: problem complexity; systems theory; systems engineering methods; requirements engineering.
1. Introduction
System affordability is a growing concern in the design and development of civilian, military, and commercial
complex engineered systems [1-3]. Schedule delays, cost overruns, and performance shortfalls are often default
outcomes of such developments. These systems are often expected to respond to thousands of requirements. Yet, some
* Corresponding author. Tel.: +49-176-32131458; fax: +1-201-216-5000.
E-mail address: asaladod@stevens.edu
© 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
Peer-review under responsibility of the Stevens Institute of Technology.

22 Alejandro Salado and Roshanak Nilchiani / Procedia Computer Science 44 ( 2015 ) 21 – 30
programs that were bounded by significantly smaller requirements sets, such as the B-52, have proven to be very
successful. This research addresses the following main question: do a set of systems requirements fundamentally affect
the affordability of the resulting expected system? In other words, does the complexity of the problem to be solved
influence system affordability?
An end-to-end research was defined and carried out by the authors, in the sense that underlying theoretical elements
that relate system requirements and system affordability were investigated in order to underpin the development of
effective methods for practitioners to reduce problem complexity. In order to achieve this, the research holistically
addressed three areas of systems engineering: systems theory, complexity science, and systems engineering methods.
In particular, the research aimed at fulfilling the following objectives:
x Define aspects of a formal theory in systems engineering that enables to mathematically prove relationships
between stakeholder needs, system requirements, solution spaces, and system affordability.
x Define a metric that enables early assessment of expected difficulty to develop a system given a set of
requirements, i.e., of the complexity of the problem to be solved.
x Develop systems engineering methods that facilitate eliciting excess-free requirement sets and that enable
identifying conflicting requirements early in the life cycle so that recovery actions can be taken with minimum
impact.
A number of previous publications by the authors of this paper have presented the details of individual elements of
the aforementioned research. The objective of the present paper is to provide context to those elements. Linking theory
and practice results in new insights that are of value for theorists and practitioners. In addition, it showcases the value
of structuring a research in such a manner, i.e. from theory to practice.
2. Literature review
Literature suggests systems theorists and community of practice are profoundly decoupled [4]. In fact,
contemporary industrial surveys inform that the community of practice continues to heavily rely on heuristics and
rules of thumb derived from past experiences [5]. Systems engineering is, or at least should be, constructed on the
pillars of general systems theory [6]. Under this framework, several researchers have contributed to build up a body
of knowledge around the theoretical aspects of systems engineering [7-10]. On its vast majority, such research
addresses the formal description of system behavior, from the interaction of their elementary parts to their behavior
as part of a given environment. In the field of requirements, for example, existing research comprehensively addresses
formal definitions of requirements and their flow-down and allocation to different levels of the system decomposition
[7, 11]. However, a theory that addresses the relationships between stakeholder needs, system requirements, solution
spaces, and system affordability is lacking.
Complexity seems to be a limiting factor through a system’s lifecycle [12-15]. The study of complexity in academia
has primarily addressed three development dimensions [16, 17], which seem to be correlated [16-19], which addresses
properties of a system. In contrast, complexity is often used in an industrial context to refer to the difficulty to develop
a system [12-15]. Yet, research has not addressed in depth how to measure the complexity imposed by a set of
requirements beyond a correlation to project resource need based on qualitative assessments [20].
System requirements, as a result of an elicitation effort, may therefore influence system affordability.
Categorization of requirements is a common practice in systems engineering to support requirement this activity in
aiming at completeness [21]. Yet research has not addressed how different categorization methods influence system
affordability. The majority of existing categorizations of requirements have been traditionally developed following a
designer perspective, by thinking about what needs to be there to completely design a system, or a contractual
perspective, by thinking about what needs to be delivered as part of the contract [7, 22-26]. The designer perspective
facilitates a writing style that provides requirements for the design of the system and not for the system itself, thus
limiting the solution tradespace for the system. The contractual perspective specifies how to procure the system and
thus it changes the scope of requirements. Basically none of those classifications achieves a proper description of what
the system is intended to do and instead they end up consistently increasing the amount of requirements without

23
Alejandro Salado and Roshanak Nilchiani / Procedia Computer Science 44 ( 2015 ) 21 – 30
satisfying any new stakeholder need. Standardization processes led to a status quo that has been simply assumed by
the engineering community.
In addition, the absence of conflicts between requirements or, in a different terminology, the consistency of a set
of requirements, is therefore considered a quality of good sets of requirements extensively in existing literature [27-
30]. Conflicting requirements can be defined as those in which “the solution to one requirement prohibits
implementing the other” [31]. Despite this criticality, the detection and elimination of conflicts “relies [almost] entirely
on the intuition of experienced modelers” [32]. The majority of techniques and methodologies used to identify
conflicts are based in pairwise comparisons [32-34]. However, some authors in software systems have already
criticized pairwise comparison methods based on the fact that there may be requirements that are not conflicting
pairwise, but are conflicting when the three are considered simultaneously [35, 36]. Unfortunately, these concerns
persist today in the field of systems engineering. In software systems, some authors have proposed different methods,
primarily based on the use of propositional logic, that evaluate a set of requirements as a whole [32, 37, 38]. However,
more types of requirements need to be addressed in systems engineering, as described earlier. Software systems have
only addressed one of them. Therefore, we can affirm that the topic of identifying conflicting requirements in systems
engineering remains largely unexplored.
3. Research design and methodology
An iterative four-task research methodology was adopted, where findings from one task triggered activities in a
previous one for refinement or to complement literature investigation: Problem Statement and Hypothesis
Development, Concept Development, Detailed Solution and Proof of Application, and Research Validation. The
research encompassed two major efforts that were interrelated. The first part of the research used theory building to
create a theory for requirements engineering aiming at understanding their effects on system affordability. The theory
was then either mathematically proved or applied to a variety of case studies to check if it matched reality. The
selection of this research methodology was considered suitable because the proposed hypotheses in this research were
of a general nature and not related to findings in a particular project or program. The second part of the research
consisted in developing methods that facilitated reducing potential negative effects of some requirements engineering
practices on system affordability. These methods were developed informed by the results of the formal theory and the
literature review. Their effectiveness was tested by comparative analysis to current practices. Quantitative and
qualitative research methods were used at different phases of the research effort.
4. Contributions, Results and findings
4.1. Systems theory
The content of this section has been extracted from [39-41].
This research contributes with some aspects of a formal theory of requirements engineering that address the
relationships between stakeholder needs, requirements, and solution spaces. Using Wymore’s System Design
Language [7] with some modifications as formal language, which is built on set and function theory, a set of formal
definitions was elaborated to enable rigorous mathematical developments. The proposed work in this research
conceptually precedes Wymore’s work, thus it is consistent and compatible with his earlier constructs. Then, theorems
and corollaries that address how stakeholder needs, requirements, solution spaces, and system affordability relate to
each other were presented and formally proven. Finally, the theorems and corollaries informed the need to numerically
explore specific dependencies between requirements and required design effort to find affordable solutions.
Four theorems are considered of most relevance for the purpose of this research:
x The amount of system requirements and the size of the solution space are negatively associated and the function
that relates them is monotonic.
x The amount of conflicting requirements and the size of the solution space are negatively associated and the
function that relates them is monotonic.

24 Alejandro Salado and Roshanak Nilchiani / Procedia Computer Science 44 ( 2015 ) 21 – 30
Fig. 1. (a) research methodology; (b) research methods.
x The size of the solution space and the difficulty to find compliant solutions are negatively associated and the
function that relates them is monotonic.
x The size of the solution space and the difficulty to find affordable solutions are negatively associated and the
function that relates them is monotonic.
The result of linking these four theorems is categorical: the more requirements that need to fulfilled, the more
difficult is to achieve system affordability. A key aspect is that this finding does not only result from the increased
requirements management effort, but from an actual reduction in the amount of systems that would possess such
attribute.
The formal mathematical prove for those theorem was found of great importance for the scientific field of systems
engineering and its actual practice. To start with, subjective notions or heuristics can now be substituted with formal
science, thus providing agreement across the community about how requirements and system affordability are actually
related. In addition, and maybe even more important for practitioners, these mathematical findings enable calculating
how adding excess requirements need to be compensated with design effort for achieving equivalent levels of
probability of finding affordable solutions.
4.2. Complexity science
The content of this section have been extracted from [42-44].

25
Alejandro Salado and Roshanak Nilchiani / Procedia Computer Science 44 ( 2015 ) 21 – 30
Fig. 2. Relative increase in probability of finding an affordable solutions under different initial conditions [41] .
Table 1. Solution space reduction as a function of system requirements (Notional).
Decay rate (k)
Size of the solution space as a function of number of requirements (R)
R = 10
R = 100
R = 500
R = 1000
R = 5000
-0.10
3.68299
4.54295
1.93278
3.72256
7.1282
-1.00
4.54295
3.72256
7.1282
0
0
Results from the theoretical developments led into defining the concept of problem complexity, as the difficulty to
solve a given problem, e.g., to design a system given a set of requirements. Its importance is better understood when
studying its effects on the overall complexity of a system. In order to achieve that, an analytical framework that enables
comparing the effects of different types of complexity on an overall system complexity was developed. Such capability
opens a door to a wholly new way of investigating system complexity, as the effects of different types or entities of
complexity can be evaluated together.
The proposed framework consists of two major elements: the complexity types or entities that contribute to the
overall complexity and the underlying mathematical definition that adds them up together. In order to make different
types of complexity comparable, a common complexity measure was selected: joint entropy. As a result, problem
complexity actually sets the minimum boundary to the level of complexity that could be achieved. This has significant
implications to system development. Basically, effectiveness of efforts to reduce system complexity through
architectural activities or contractual negotiations will always be limited on a first instance by the set of requirements
that need to be fulfilled. Consequently, and having into account that requirement definition usually occurs at the initial
stages of system development, identification of requirements that significantly contribute to problem complexity is of
capital importance to ensure limited system complexity as system development evolves.
Using COSYSMO as a basis [20], problem complexity was defined as a function of the amount of requirements a
system is expected to fulfill and the level of conflict between them.
ܥ݌ൌܭή൭෍ܽ݅ήݎ݂݅
݊
݅ൌͳ ൱ܧήቌෑܾ݆ܪ݆
݉
݆ൌͳ ቍܦ
(1)
K is a calibration factor that allows problem complexity to be adjusted to accurately reflect an organization’s business performance. The first term
represents the size of the requirement set, i.e., how many functional requirements rf the system has to fulfill. They are weighted (a) to reflect
inherent difficulty of requirements and adjusted for economies of scale (0 < E < 1). The last term represents complexity modifiers, which are defined
by the amounts of conflicts (H) and their relative contribution to problem complexity (b). Their combined effect is then adjusted for economies of
scale (0 < D < 1).
Evolution according to economies of scale in contrast to diseconomies of scale traditionally seen in other
complexity measures was informed by the theoretical results of the previous research step, which showed evolution
of the solution space according to the equation of growth in general systems theory [45].
Number of design iterations
Relative size of the s olution space
2 4 6 8 10
1.1
1.15
1.2
1.25
1.3
1.35
1.4
1.45
1.5
Relative increase p(aff ordable solutions)
10
15
20
25
30
35
40
45
Number of design iterations
Relative size of the s olution space
2 4 6 8 10
1.1
1.15
1.2
1.25
1.3
1.35
1.4
1.45
1.5
Relative increase of p(af fordable solutions)
10
15
20
25
30
35
40
45

26 Alejandro Salado and Roshanak Nilchiani / Procedia Computer Science 44 ( 2015 ) 21 – 30
Heuristics to identify conflicting requirements were defined by a combination of literature review and interviews
with thirteen subject matter experts. Questions were aimed at eliciting experiences instead of at seeking agreement
with propositions. Such open ended questions were considered more effective because they did not impose significant
biases.
x A conflict may exist when two or more requirements oblige the system to operate in two or more phases of
matter.
x A conflict may exist when two or more requirements oblige the system to compete for the same resource.
x A conflict may exist when two or more requirements oblige the system to satisfy opposing directions in laws of
physics.
x A conflict may exist when two or more requirements oblige the system to satisfy logical contradictions.
x A conflict may exist when two or more requirements oblige the system to satisfy opposing directions in laws of
society.
The proposed metric was calibrated with a regression factor higher than 58% by five subject matter experts that
assessed estimated effort to develop various system variants that had embedded conflicts they were not informed of.
All calibration activities showed economies of scales with respect to the amount of functional requirements to be
fulfilled and the amount of existing conflicting requirements. This result was in line with previous theoretical
developments and propositions in this research. Consequently, such a closed loop provided a good indication on the
suitability of the proposed metric. Finally, most of the coefficients remained highly consistent throughout all
calibration attempts, except for the calibration factor. Therefore, this was also seen as indicative of suitability of the
proposed metric.
4.3. Systems engineering methods
Literature review and the proposed problem complexity metric informed us for the need for two problem
complexity reduction methods: a method that facilitates eliciting less excess requirements and a method that facilitates
effective identification of conflicting requirements before initiating architectural and design activities.
A. Eliciting less constraints
The content of this section has been extracted from [46, 47].
The present research proposed a system-centric categorization of requirements based on the concept of partition in
set theory that achieves several objectives: (1) completely define a system, (2) identify requirements that are not
applicable to the system, and (3) identify constraints that do not support satisfaction of stakeholder needs. The method
is inspired by Max-Neef’s classification of human needs [48] as a model to categorize requirements:
x Functional requirements (Do): what the system does in essence, or in other words what it accepts and what it
delivers.
x Performance requirements (Being): how well the system does it, which includes performance related to functions
the system performs or characteristics of the system on its own, such as –ilities.
x Resource requirements (Have): what the system uses to transform what it accepts in what it delivers.
x Interaction requirements (Interact): where the system does it, which includes any type of operation during its
life-cycle.
Effectiveness of the proposed method to elicit less excess requirements was tested in a factorial experiment with
practicing systems engineers. Both groups were tasked to write sets of requirements that satisfy the given sets of need,
one set of requirements for each problem statement. The control group was tasked to use the categorization method
used in the European space industry [23]. The experiment group was tasked to use the categorization method proposed
in this research. Inferential statistics were used to support hypotheses validation.
24 subjects participated in the experiment. The non-parametric Mann-Whitney U test was employed. A significance
of α= 0.05 and confidence level of 95% were set. When null hypotheses were rejected, medians were used to determine

27
Alejandro Salado and Roshanak Nilchiani / Procedia Computer Science 44 ( 2015 ) 21 – 30
the direction of the difference between both groups. Results showed that the experiment group performed significantly
better than the control group in terms of eliciting less excess requirements. Furthermore, results indicated that the
proposed categorization method does not negatively affect completeness of the requirement set. Finally, additional
correlation analyses indicated that uncontrolled dependent variables were not factors in the result. The test achieved a
statistical power higher than 97%, thus providing high level of confidence on the results. Consequently, the results of
the factorial experiment proved that the proposed requirements categorization method significantly improves
effectiveness in not eliciting excess requirements with respect to existing ones, while maintaining a similar level of
completeness.
Table 2. Experiment results [47].
Measure of effectiveness
Significance
Decision
Control
group
Test
group
Test group
(full)
Better
performer
1H0. Both groups elicit the same
amount of constraints
Mean
0.001
Reject
27%
4%
2%
Test group
Median
26%
5%
0%
Test group
2H0. Both groups elicit the same
amount of inapplicable requirements
Mean
0.025
Reject
16%
5%
Test group
Median
18%
1%
Test group
3H0. Both groups elicit the same
amount of net requirements
Mean
0.804
Fail to
reject
25
29
Equivalent
B. Conflicting requirements identification methods
The content of this section has been extracted from [49, 50].
The proposed method to identify conflicting requirements, the Tension Matrix, is built on three pillars: (1)
Heuristics to identify conflicting heuristics, aiming at reducing completeness uncertainty, (2) Targeted modeling, and
(3) Elemental decomposition, a concept that proposes that the effect of every requirement on the system, or the effect
of a system in fulfilling a requirement can be decomposed in a set of elemental attributes that can be linked together
through simple relational models. The matrix is formed by combining the proposed categorization method in [46] and
the set of heuristics defined in [44]. Examples of elemental attributes for laws of physics could include temperature,
power dissipation, velocity, or mass. Examples of elemental attributes for laws of society could include freedom,
selfishness, selflessness, or God’s mandates. These sets are not fixed and should be tailored according to the nature of
the requirement set and the system of interest.
Table 3. Schematic view of the proposed Tension Matrix [50].
Reqs.
Resources
Phases of matter
Elemental decomposition
Laws of physics
Laws of society
Logical
r7
r8
r9
S
L
G
V
T
P
v
L1
L2
L3
F
r1
X
↑
r2
X
↑
↓
r3
X
P
r4
↓
r5
X
↑
↓
↑
r6
X
↑
R
r7
r8
↓
r9
I
r10
X
r11
X
↓
↓
r12
X
Legend: F, functional requirements; P, performance requirements; R, resource requirements; I, interaction requirements; S, solid; L, liquid; G,
gas; V: vacuum; T, temperature; P: power; v, velocity; L1, L2, L3, notional laws.
Effectiveness of the method was validated with a case study on which a combination of retrospective assessment
with a prospective analysis was employed [51]. The case study used the FireSat satellite as basis [52]. Existence of
conflicting requirements was determined by populating a solution space with potential satellites that could satisfy
those requirements. The satellite model was built on the basis of publicly available satellite cost models [52]. Changes

28 Alejandro Salado and Roshanak Nilchiani / Procedia Computer Science 44 ( 2015 ) 21 – 30
in sizes of the solution spaces due to requirements removal, as well as their effect on the location of the Pareto front,
dictated the actual level of conflicts between them. Two methods were employed to identify conflicting requirements.
The first method, which reflects industry practice, employed a simple prioritization model that assigned difficulty
levels to the different requirements. Heritage data or simple analyses were used as basis to assign the different levels.
The second method was the proposed conflicting requirements identification method, which employed the proposed
Problem Complexity metric as a performance indicator for identifying driving conflicts. Comparative analysis was
performed between the two methods. The first tradespace reflects the solutions that fulfill the original set of
requirements, after relaxation suggested with Benchmark (blue points and dotted line). The second tradespace reflects
the solutions that fulfill the requirements after the conflicts identified with the tension matrix were removed (red and
blue points and solid line). The results confirmed the proposed Tension Matrix and the concept of elemental
decomposition provide higher levels of effectiveness to identify conflicting requirements before initiating architectural
or design activities.
Fig. 3. Effect of removing conflicting requirements in the Pareto front [50].
5. Discussion and conclusions
5.1. Strengths of the research
The uniqueness of this research lays on the definition of the solution space as a driver for system affordability
instead of on its actual exploration. The present research closes the loop between stakeholder needs, system
requirements, solution spaces, and system affordability. In addition, it provides an end-to-end contribution, in the
sense that it begins with a theoretical development, which results in a system metric, and which informs the
development of two actual and tested methods to influence such a metric. Therefore, the research has contributed to
both the body of knowledge of systems engineering and to its practice. The proposed methods are in fact readily usable
by the practicing community. Furthermore, the results of the present research have been generalized to discrete
requirements, fuzzy requirements, and continuous requirements or value functions.
5.2. Limitations
The results of the research summarized in this paper are bounded by the following major limitations:
x The aspects of a mathematical theory of requirements engineering have been validated for discrete open systems.
x Some aspects of the mathematical theory of requirements engineering are bounded to finite sets of systems,
where compliant and affordable solutions are uniformly distributed.
x Since it is impossible to formally demonstrate completeness of a set of requirements, validation of the
requirements categorization method only provides indications on whether completeness is negatively affected or
not.
1.5 1. 55 1.6 1. 65 1.7 1. 75 1.8
x 10
6
0.5
0.52
0.54
0.56
0.58
0.6
0.62
0.64
0.66
0.68
Cost (k $)
Utility

29
Alejandro Salado and Roshanak Nilchiani / Procedia Computer Science 44 ( 2015 ) 21 – 30
x Results of the effectiveness to elicit constraints of the proposed categorization method primarily address the
space industry.
x Calibration of problem complexity has been performed against a set of subjective difficulty assessments.
5.3. Implications for practice and research
This research contributes to the body of knowledge of systems engineering and to its state of the art in three areas:
systems theory, complexity science, and systems engineering methods.
First, a set of definitions, theorems, and corollaries formally proves how stakeholder needs, system requirements,
solution spaces, and system affordability are related. As a result, several heuristics, opinions, or engineering feelings
that are widely spread in the systems engineering community, have been mathematically proven in this research
enabling them to become laws of systems engineering. In addition, the mathematical formulations have enabled
exploring the amount of rework cycles that are needed to compensate for adding unnecessary requirements to a
requirement set for achieving similar levels of probability of finding affordable solutions. This work extends previous
work by Wayne Wymore. In addition, it puts emphasis on the practical implications of each definition, theorem, and
corollary to serve as a bridge between theorists and practitioners.
Second, the concept of problem complexity and an analytical framework to sum up different types of complexities
have been developed. Problem complexity measures the level of difficulty to develop a system as a function of the set
of requirements it is expected to fulfill. This metric enables anticipating expected development complexity of a system
before initiating architectural or design activities. In addition, the analytical framework for joining different types of
complexities mathematically proves that a set of requirements imposes the lowest limit of complexity a system can
achieve before its development. Therefore, the metric enables sensitivity analysis on each requirement, which
facilitates unprecedented effective requirement negotiation before committing to particular features, performances, or
design options, without requiring effort investment on architecture and design. The proposed problem complexity
metric has been tested against different system variants and calibrated with subject matter experts.
Third, two methods to reduce problem complexity during requirements elicitation have been developed. The first
method, inspired in Max-Neef’s model of human needs, facilitates the identification of constraints that limit the
solution space without supporting the satisfaction of new needs. A test field with practitioners has proven that the
method reduces excess requirements in the form of constraints from 26% to 0% (medians). The second method, based
on the concept of elementary decomposition, facilitates the identification of conflicting requirements and enables
challenging decisions at higher levels of the architecture for conflict removal. Its effectiveness has been demonstrated
by comparing how tradespaces and Pareto fronts change after removing conflicting requirements with respect to an
industry benchmark.
References
1. Winter U. Automobil-Industrie: “Krise dauert bis 2010”. http://www.rponline.de/wirtschaft/news/Krise-dauert-bis-2010_aid_639188.html.
Accessed Dec 17th 2009.
2. Government Accountability Office (GAO). Defense Acquisitions: Assessments of Major Weapons Programs; 20011.
3. Bitten R, Emmons D, Bordi F, Scolese C. Explanation of Change (EoC) Study: Approach and Findings. IEEE Aerospace Conf 2013.
4. Shell T. System function implementation and behavioral modeling: a systems theoretic approach. Syst Eng 2001:4:58-75.
5. Sheard SA, Mostashari A. Principles of complex systems for systems engineering. Syst Eng 2009:12:295-311.
6. Klir G. An approach to general systems theory. New York: Van Nostrand Reinhold, 1969.
7. Wymore AW. Model-based systems engineering. Boca Raton, FL: CRC Press, 1993.
8. Bahill AT, Dean FF. What is systems engineering? A consensus of senior systems engineers. 6th Annual INCOSE International Symposium,
Boston, MA, 1996.
9. Friedman G. Constraint Theory: Multidimensional Mathematical Model Management. Springer, 2005.
10. Warfield JN, Hill JD. A unified systems engineering concept (Bd. Monograph 1). Columbus: Batelle Memorial Institute, 1972.
11. Thompson KR. "General system" defined for predictive technologies of A-GSBT (Axiomatic-General Systems Behavioral Theory). Scientific
Inquiry, 2006:7:1-11.
12. Maier M. Dimensions of complexity other than 'complexity'. Symposium on Complext Systems Engineering. Santa Monica, CA, 2007.
13. Filippazzo G. Complexity based cost estimating relationships for space systems. IEEE Aerospace Conference. Big Sky, MT, 2004.
14. Leising CJ, Wessen R, Ellyin R. Spacefract complexity subfactors and implications on future cost growth. IEEE Aerospace Conference. Big
Sky, MT, 2013.

30 Alejandro Salado and Roshanak Nilchiani / Procedia Computer Science 44 ( 2015 ) 21 – 30
15. Young LZ, Farr JV, Valerdi R. The role of complexities in systems engineering cost estimating processes. Conference on Systems Engineering
Research (CSER), Hoboken, NJ, 2010.
16. Weber C. What is 'Complexity'? In A. Sa muel, & W. Lewis (Hrsg.), ICED 05: 15th International Conference on Engineering Design:
Engineering Design and the Global Economy. Barton, ACT: Engineers Australia, 2005.
17. Lindemann U, Maurer M, Braun T. Structural Complexity Management - An Approach for the Field of Product Design. Heidelberg: Springer
Verlag Berlin, 2009.
18. Conway ME. How do Committees Invent? Datamation 1968:14:28-31.
19. Kreimeyer M. Aggregate views to manage complex dependency models. International Journal of Product Development 2011:14:144-164.
20. Valerdi R. The Constructive Systems Engineering Cost Model (COSYSMO): Quantifying the costs of systems engineering effort in complex
systems. Saarbrücken, Germany: VDM Verlag, 2008.
21. Buede DM. The engineering design of systems: Models and methods. 2nd Ed. Wiley; 2009.
22. NASA. Systems engineering handbook. 2007.
23. ECSS. Space Engineering - Technical Requirements Specification. European Cooperation for Space Standardization, 2009.
24. Bapat V, Bettig B, Summers J. Requirements-driven design computations in next-generation CAD. International Conference on Engineering
Design. Paris, France, 2007.
25. Gilb T. Towards the engineering of requirements. Requirements Engineering, 1997:5:165-169.
26. Ward J, Shefelbine S, Clarkson PJ. Requirements capture for medical device design. International Conference on Engineering Design,
Stockholm, Sweden, 2003.
27. INCOSE. Guide for writing requirements. The International Council of Systems Engineering, 2012.
28. IEEE. Institute of Electrical and Electronics Engineers, Recommended practice for software requirements specification. New York: IEEE,
1993.
29. Kasser JE. Applying total quality management to systems engineering. Boston, MA: Artech House, 1995.
30. Hood C, Widermann S, Fichtinger S, Pautz U. Requirements management, the interfaces between requirements development and all other
systems engineering processes. Heidelberg: Springer-Verlag, 2008.
31. Robertson S, Robertson J. Mastering the requirements engineering process. Getting requirements right. 3rd ed. Addison-Wesley, 2012.
32. Hausmann JH, Heckel R, Taentzer G. Detection of conflicting functional requirements in a use case-driven approach. 24th IEEE International
Conference on Software Engineering ICSE, 2002.
33. Liu XF, Yen J. An analytic framework for specifying and analyzing imprecise requirements. ICSE-18, 1996.
34. Easterbrook S. Resolving requirements conflicts with computer-supported negotiation. Requirements engineering: social and technical issues,
1994:1:41-65.
35. Gervasi V, Zowghi D. Reasoning about inconsistencies in natural language requirements. ACM Transactions on Software Engineering and
Methodology 2005:14:277-330.
36. Eben KG, Lindemann U. Structural analysis of requirements - Interpretation of structural criterions. International Dependency and Structure
Modelling Conference DSM10. Cambridge, UK, 2010.
37. van Lamsweerde A, Darimont R, Letier E. Managing conflicts in goal-driven requirements engineering. IEEE Transactions on Software
Engineering 1998:24:908-926.
38. Ali R, Dalpiaz F, Giorgini P. Reasoning with contextual requirements: Detecting inconsistency and conflicts. Information and Software
Technology 2013:55:35-57.
39. Salado A, Nilchiani R, Verma D. A Contribution to the Scientific Foundations of Systems Engineering: Solutions Spaces and Requirements.
Submitted/unpublished, 2014.
40. Salado A, Nilchiani R. A Contribution to the Scientific Foundations of Systems Engineering: How the Solution Space Influences System
Compliance and Affordability. Submitted/unpublished, 2015.
41. Salado A, Nilchiani R. Increasing the probability of developing affordable systems by maximizing and adapting the solutio n space. Procedia
Computer Science 2014:28:547-554.
42. Salado A, Nilchiani R. The concept of problem complexity. Procedia Computer Science 2014:28:537-546.
43. Salado A, Nilchiani R. Toward Measuring Problem Complexity in Systems Engineering. Submitted/unpublished, 2015.
44. Salado A, Nilchiani R. A set of heuristics to support early identification of conflicting requirements. Submitted/unpublished, 2014.
45. von Bertalanffy L. General Systems Theory - Foundations, development, applications. New York, NY: George Braziller, Inc., 1969.
46. Salado A, Nilchiani R. A categorization model of requirements based on May-Neef’s model of human needs. Syst Eng 2014:17:348-360.
47. Salado A, Nilchiani R. Reducing excess requirements through orthogonal categorizations: Results of a factorial experiment.
Submitted/unpublished.
48. Max-Neef M. Human Scale Development: Concept Application and Further Reflections. Apex Pr, 1989.
49. Salado A, Nilchiani R. The concept of order of conflict in requirements engineering. IEEE Systems Journal, in press, 2014.
50. Salado A, Nilchiani R. The Tension Matrix and the concept of elemental decomposition: Improving identification of conflicting requirements.
Submitted/unpublished, 2014.
51. Friedman G, Sage AP. Case studies of systems engineering and management in systems acquisition. Syst. Eng. 2004:7.
52. Wertz JR, Larson WJ. Space mission analysis and design. 3rd ed. Microcosm, 1999.