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

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: [email protected]

© 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.

http://crossmark.crossref.org/dialog/?doi=10.1016/j.procs.2015.03.037&domain=pdf

http://crossmark.crossref.org/dialog/?doi=10.1016/j.procs.2015.03.037&domain=pdf

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:

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.

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.

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


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:

The amount of system requirements and the size of the solution space are negatively associated and the function that relates them is monotonic.

The amount of conflicting requirements and the size of the solution space are negatively associated and the function that relates them is monotonic.


Fig. 1. (a) research methodology; (b) research methods.

The size of the solution space and the difficulty to find compliant solutions are negatively associated and the function that relates them is monotonic.

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].


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

Rel

ativ

e si

ze o

f th

e so

lutio

n sp

ace

2 4 6 8 101.1

1.15

1.2

1.25

1.3

1.35

1.4

1.45

1.5

Rel

ativ

e in

crea

se p

(aff

orda

ble

solu

tions

)

10

15

20

25

30

35

40

45

Number of design iterations

Rel

ativ

e si

ze o

f th

e so

lutio

n sp

ace

2 4 6 8 101.1

1.15

1.2

1.25

1.3

1.35

1.4

1.45

1.5

Rel

ativ

e in

crea

se o

f p(

affo

rdab

le s

olut

ions

)

10

15

20

25

30

35

40

45


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.

A conflict may exist when two or more requirements oblige the system to operate in two or more phases of matter.

A conflict may exist when two or more requirements oblige the system to compete for the same resource. A conflict may exist when two or more requirements oblige the system to satisfy opposing directions in laws of

physics. A conflict may exist when two or more requirements oblige the system to satisfy logical contradictions. 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:

Functional requirements (Do): what the system does in essence, or in other words what it accepts and what it delivers.

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.

Resource requirements (Have): what the system uses to transform what it accepts in what it delivers. 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


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


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:

The aspects of a mathematical theory of requirements engineering have been validated for discrete open systems. Some aspects of the mathematical theory of requirements engineering are bounded to finite sets of systems,

where compliant and affordable solutions are uniformly distributed. 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 106

0.5

0.52

0.54

0.56

0.58

0.6

0.62

0.64

0.66

0.68

Cost (k$)

Util

ity


Results of the effectiveness to elicit constraints of the proposed categorization method primarily address the space industry.

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.


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. Samuel, & 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 solution 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.

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

Documents

Transcript of A Research on Measuring and Reducing Problem Complexity to Increase System Affordability: From...