ArticlePDF Available

Abstract and Figures

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.
Content may be subject to copyright.
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 = 5000
-0.10
3.68299
4.54295
1.93278
7.1282
-1.00
4.54295
3.72256
7.1282
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-Neefs 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.
... The mathematical model in this context will be the intellectual core of the process. Because of the specifics of mathematical models for difficult-to-formalize processes, it is correct to use a simulation management interval dynamic model with distributed parameters [6]. ...
Article
Full-text available
Nowadays, Russia has the longest heating network system in Europe (about 125 000 km in total). Given the constant growth in the volume of construction space, the length will constantly increase. Consequently, there is a request to increase the level of reliability of heat supply networks. It is possible to satisfy the request only by increasing the volume and quality of comprehensive diagnostics of heat supply networks with simultaneous reduction of time costs. This is possible only if a new generation of measurement and computing complex (MCC) is developed for the diagnosis of heat supply networks. The team of authors examines the features of the information environment in heat supply networks, separately noting the possibility of switching the flow from single-phase to multi-phase and back. The paper proposes to consider a solution to a problem that arises when trying to visualize physical and mathematical models of thermodynamic processes of single-phase flows using MATLAB. It consists in the fact that the desired physical and mathematical model should describe the thermodynamic processes of a single-phase flow, but taking into account that this flow moves in the external heat supply network. The possibility of using the MATLAB functional environment for developing a model based on visually oriented programming is considered in detail, which allows us to lay the foundations for further forecasting the development of the heat supply system.
... Effective decision-making is paramount for managing products over their lifecycle, but we undertook this study because decision-making for lifecycle management and integrated engineering change remains an underresearched area (MacCarthy and Pasley, 2020). Further, every decision made in design becomes a constraint on the lifecycle, whereas the solution space can never be increased after the decision is made (Salado and Nilchiani, 2015;Salado, Nilchiani, and Verma, 2016). The only way to increase the solution space is to change the decision. ...
Article
Full-text available
Engineering change is a significant cost for projects. While avoiding and mitigating the risk of change is ideal, mistakes and improvements are recognised as more is learned about the decisions made in a design. This paper presents a feasibility and performance analysis of automating engineering change requests to demonstrate the promise for increasing speed, efficiency, and effectiveness of product-lifecycle-wide engineering-change-requests. A comparatively simple case is examined to mimic the reduced set of alterable aspects of a typical change request and to highlight the need of appropriate search algorithms as brute force methods are prohibitively resource intensive. Although such cases may seem trivial for human agents, with the volume of expected change requests in a typical facility, the potential opportunity gain by eliminating or reducing the amount of human effort in low-level changes accumulate into significant returns for the industry on time and money. Herein, the genetic algorithm is selected to demonstrate feasibility with its broad scope of applicability and low barriers to deployment. Future refinement of this or other sophisticated algorithms leveraging the nature of the standard representations and qualities of alterable design features could produce tools with strong implications for process efficiency and industry competitiveness in its projects execution.
... Before researchers can formulate effective strategies to manage and control the complexity involved in adopting any new technologies, the types of key characteristics that make the technology complex must be understood (Xia and Lee 2005). However, while there are research studies on the complexities of IS development and implementation within organisations, scant studies investigate factors that might be used to assess the complexity of cloud computing within organizations' information systems (IS) (Salado and Nilchiani 2015). ...
Article
Full-text available
This research paper assesses complexity in cloud computing adoption, using the context of the local government sector in Australia. The research utilized both cloud computing adoption literature and an Information Systems Complexity Framework to propose a complexity assessment model for cloud computing adoption. A mixed method approach was used in this research. Firstly, we conducted 21 indepth interviews with IT managers in the local governments in Australia to obtain their insights into the complexity of cloud computing adoption. Secondly, a quantitative method is used in which 480 IT staff from 47 local governments responded to an online survey to validate the proposed assessment model. The findings indicate that structural complexity of an organization (i.e., knowledge management), structural complexity of technology (i.e., technology interoperability, and data processing capability), dynamic complexity of an organization (i.e., business operations), and dynamic complexity of technology (i.e., systems integration, IT infrastructure update, and customization resources) are critical complexity aspects to be considered during cloud computing adoption. These findings provide important implications for both researchers and managers that are trying to understand the complexities involved in cloud computing adoption.
... Careful decision making is needed in standards devel-opment to minimize over constraining the product lifecycle by forcing industry to provide explicit definitions of all information early in the lifecycle. Every decision made early in the product lifecycle becomes a constraint on the later phases of the lifecycle [20,21]. For example, if design places specific characteristic requirements in a product definition in a way that forces a certain manufacturing process, then manufacturing is restricted to that single type of process capability. ...
Conference Paper
Full-text available
ASME has published a new standard (ASME Y14.47) on model-based definition (MBD) organization practices. It is part of ASME's series of standards on engineering product definition and related documentation practices. ASME Y14.47 introduces novel MBD-element classifications, which are based on industrial recommended practices in organizing and managing three-dimensional geometric models and related information of products. Such classifications form the technical basis for developing information models (e.g., as XML schema definitions) to enable interoperability among engineering information systems in model-based enterprises (MBEs). This paper provides an exposition of these classifications, while emphasizing the need and use of such standardized classifications in modern MBEs.
... The systems engineering community has recently focused on understanding what the theory of systems engineering might be and on contributing to develop it further [1][2][3][4][5][6]. Past research efforts focused on mathematically describing systems and systems engineering [7,8], while current research explores the intersection of theories in diverse domains to further advancing the field of systems engineering [5]. ...
Conference Paper
A part of the systems engineering and engineering design community has voiced a need to measure the goodness of systems engineering and engineering design methods or approaches. Such measurements could enable assessing the merits of novel approaches and methods and, ultimately, compare the situations and contexts in which one of them would be preferred over the other ones. Notwithstanding the complexity of such endeavor, this paper presents an elemental decomposition of systems engineering that can be used for characterizing systems engineering methods or approaches. The proposed model builds on understanding systems engineering as the application of strategies to realize systems. The proposed elemental decomposition consists of four elements, which represent the potential effects that any systems engineering activity may have on the system development: set an order on the solution space, change the content of the design space, shape beliefs on the order of the solution space, and shape beliefs on the solution space. Such characterization could eventually be useful to compare the structure and behavior of different systems engineering methods.
... The field of systems engineering has experienced a recent push for unveiling its scientific foundations. [1][2][3][4][5] Past research efforts focused on mathematically describing systems and systems engineering, 6,7 while current research explores the intersection of theories in diverse domains to further advance the field of systems engineering. 8 Both efforts have contributed with foundations that have seeded the development of promising systems engineering methods, 6,7,[9][10][11] have identified fundamental flaws in some of the existing systems engineering methods, [12][13][14] and have provided mathematical frameworks or results that enable moving the practice from heuristic-based to theorybased. ...
Article
The field of systems engineering has recently experienced a new push for unveiling its scientific foundations and using them to inform better practice. The majority of the research effort towards a theory of systems engineering has concentrated on the early phases of the system's lifecycle, especially in the areas of problem formulation and system architecture and design. However, and despite their importance for system success, the design of verification strategies has received little attention. Current work is of procedural nature, providing guidance instead of enabling computation, or is specific to a particular verification case. As a result, the definition of verification strategies in practice continues to be driven by heuristics and best practices. This has shown to be suboptimal. In order to fill in this gap, this paper contributes to the theory of systems engineering with a mathematical model of verification strategies. The mathematical model is generic, capturing verification comprehensively, and enables computation. First, a descriptive case is presented to facilitate understanding how the mathematical model relates to practice. Second, a quantitative case is presented to justify the need of the model.
... Smith [15] proposes a proactive approach that uses quantitative techniques to predict the performance of software early in design to identify viable options and eliminate unsatisfactory ones before implementation begins. Salado & Nilchiani, [16] 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). Christopher & Chandra, [17] propose a multi-criteria Fuzzy Based approach that is able to estimate the software complexity early which in turn predicts the Software Requirement Stability during the software development life cycle. ...
Conference Paper
The introduction of e-Government enabled services has resulted in the public- sector wide integration of different software applications, often scaled up to a national level. Out of observation, the way these initiatives are handled differs in the way software-development projects are managed in the private sector. The anticipated value of these projects tends to differ significantly in the long run. We have particularly picked interest in the health sector in which e-Health initiatives have been defined. We aim at understanding how value proliferation can be understood and quantified from the onset on such large-scale projects using requirement engineering techniques. In this work we infer that effective planning of large scale ICT initiatives, such as e-Health, should be long term driven so as to ensure effective sector management. Novel approaches in this realm should strive at linking strategy, measurement and operational decisions from the onset. In here we examine what has been done, key opportunities, challenges and gaps that can be addressed by the research community. In bridging these gaps, we propose an agenda by formulating key research questions which both the industry and academia can address as future direction to align this view.
Article
Distributed production paradigms have grown in discrete manufacturing as discrete products are increasingly made by global, distributed networks. Challenges faced by discrete manufacturing, such as increased globalization, market volatility, workforce shortages, and mass personalization have necessitated scalable solutions that improve the agility of production systems. These challenges have driven the need for better collaboration and coordination in production via improved integration of production systems across the product lifecycle. This paper describes key industry use cases to motivate the research and development needed for distributed production in discrete manufacturing. The technological challenges that have hindered distributed production in discrete manufacturing are presented as is a state-of-the-art review of the standards and technologies that have been developed to overcome these challenges. Based on this review, future research directions are described to address the needs of industry and achieve the goals of distributed production in discrete manufacturing.
Conference Paper
Full-text available
Design and verification are conceived in current practice and research as two sequential decisions or optimization efforts. In the first one, a design is optimized (or chosen) by maximizing the expected value to a set of stakeholders, which is a function of its characteristics, and the preferences of the stakeholders. In the second one, a verification strategy is optimized (or chosen) for the selected design by maximizing its own expected value, which is a function of the development uncertainty it reduces, the cost and time it requires, its effects on the system's characteristics, and the risk preferences of the stakeholders. This paper asserts that because verification activities modify the uncertainty associated to the characteristics of a system and consume its development resources, they actually influence the expected value of the system. Consequently, this paper proposes that design and verification decisions should be taken concurrently instead of sequentially in order to increase the expected value a system; pushing thus further the notion that verification should inform the design of a system with respect to embedding elements that enable and ease verification. Contributing to the scientific foundations of systems engineering, the paper mathematically proves that optimizing a verification strategy for a pre-optimized, baseline design can yield suboptimal results, in terms of system expected value, when compared against that obtained by concurrently optimizing design and verification. Using value-driven design as an underlying framework, the implications of this analytical finding are then showcased by a comparative analysis in which a notional system design and its verification strategy are selected on the premises of current practice and of the proposed integrative approach.
Article
Full-text available
Some researchers have suggested that scientific foundations expressed in a mathematical form are needed to thrust the success of systems engineering as a discipline on its own merit. In order to contribute the development of such systems science, this paper investigates from a foundational standpoint the relationships between stakeholder needs, system requirements, and sets of systems. Various theorems and corollaries are proposed and mathematically proven. The theoretical elements are presented as a foundation for the development of a science for requirements engineering. The proposed foundations are finally tested to mathematically describe, in a rigorous and precise manner, qualities of good requirements, which are otherwise traditionally defined using vague narrative. By showcasing practical examples of the theoretical aspects, the paper is intended to serve as a bridge between practitioners and theorists.
Article
Full-text available
This paper discusses a new computational framework for requirements-driven automated design synthesis that allows design changes to be accepted seamlessly from multiple stakeholders and the computer software itself. The framework, based on declarative-variational mathematical underpinnings, supports the systematic design process by using requirements as a basis for coordinating designer and computer efforts. We define a design knowledge representation based on the design exemplar that enables mapping a large set of real-world design requirements to a computer-interpretable form. A new generic high-level algorithm that can apply requirements (exemplars) simultaneously is proposed. As opposed to conventional rule-based production systems, which enforce design requirements one at a time, this new algorithm is able to detect incompatibilities between requirements by applying the requirements simultaneously.
Conference Paper
Full-text available
Conventional approaches to system design use requirements as boundary conditions against which the design activity occurs. Decisions at a given level of the architecture decomposition can result in the flowing down of conflicting requirements, which are easy to fulfill in isolation but extremely difficult when dealt with simultaneously. Designing against such sets of requirements considerably limits system affordability. Identification of such conflicts is usually performed in industry by subject matter experts. Such evaluations are primarily driven by experience. As a result, effectiveness in identifying conflicting requirements is strongly dependent on the person making the assessment. We propose in this paper a set of heuristics that supports identification of conflicting requirements by providing direction and focus in the identification effort. The heuristics have been derived from a combination of literature review and experience from practitioners. In particular, a set of practitioners was interviewed orally and through a questionnaire in order to abstract and generalize their individual experiences.
Book
Requirements Management has proven itself to be an enormous potential for the optimization of development projects throughout the last few years. Especially in the climate of an increasingly competitive market Requirements Management helps in carrying out developments faster, cheaper and with a higher quality. This book focuses on the interfaces of Requirements Management to the other disciplines of Systems Engineering, for example Project Management, Change Management and Configuration and Version Management. To this end, an introduction into Requirements Management and Requirements Development is given, along with a short sketch of Systems Engineering, and especially the necessary inputs and resulting outputs of Requirements Management are explained. Using these flows of information it is shown how Requirements Management can support and optimize the other project disciplines and how very important therefore a functioning Requirements Management is for all areas of development. © 2008 Springer-Verlag Berlin Heidelberg. All rights are reserved.
Article
Problem formulation lays at the heart of systems engineering. While an over-constrained solution space may yield no satisficing solution affordably, properly defined solution spaces may enable developing solutions with high levels of affordability. Therefore, effective requirement elicitation from stakeholder needs is key to achieve a proper definition of the problem to be solved. Categorizing requirements according to predefined taxonomies is an inherent part of this activity and they are as diverse as engineering industries are. Conventional approaches, which use a designer-perspective, a contractual perspective, or a combination of both, facilitate the generation of excess facilitate the generation of excess requirements during requirements elicitation due to promoted design biases and overlaps between the different categories. In order to mitigate those problems, orthogonal, system-centric categorization methods have been proposed as a potential solution. Yet, research has not measured the influence of any type of requirement taxonomy on the effectiveness in defining solution spaces of maximum size, i.e., without excess requirements with respect to a given set of stakeholder needs. In order to fill in this gap, this paper presents the results of a factorial experiment involving systems engineering practitioners that compares the effectiveness in eliciting less excess requirements of an orthogonal, system-centric categorization method versus traditional ones.
Book
The Engineering Design of Systems, Second Edition compiles a wealth of information from diverse sources to provide a unique, one-stop reference to current methods for systems engineering. It takes a model-based approach to key systems engineering design activities and introduces methods and models used in the real world. Features new to this edition include: The addition of Systems Modeling Language (SysML) to several of the chapters, as well as the introduction of new terminology Additional material on partitioning functions and components More descriptive material on usage scenarios based on literature from use case development Updated homework assignments. The software product CORE (from Vitech Corporation) is used to generate the traditional SE figures and the software product MagicDraw UML with SysML plugins (from No Magic, Inc.) is used for the SysML figures. This book is designed to be an introductory reference and textbook for professionals and students in systems engineering. It is also useful in related courses in engineering programs that emphasize design methods and models.
Article
8th Annual Conference on Systems Engineering Research (CSER) presentation