Requirements Engineering for Complex Adaptive Systems - CiteSeerX

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

Requirements Engineering for Complex Adaptive Systems: Principles vs. Rules George A. Polacek 1 and Dinesh Verma, Ph.D.2 1

Stevens Institute of Technology, USA, [email protected] Stevens Institute of Technology, USA, [email protected]

2

Abstract Systems engineering has always been concerned with the development of complex systems. Today’s complexity is reflected in our interest in new classes of systems such as systems-of-systems, socio-technical systems and enterprises, which can display characteristics associated with complex adaptive systems. One such characteristic is the uncertainty that comes in part from the large number of potential interactions that can exist within the system and between the system and its reference environment. Uncertainty is especially a concern in the foundational activity of requirements engineering where the primary objective is to provide an unambiguous basis for developing and evaluating solutions. It has been suggested that obtaining specific, desirable outcomes from the systems engineering process will not be possible for complex adaptive systems. Instead, our efforts should focus on guiding an evolving system towards acceptable “outcome spaces”. This paper extends this argument to the development of requirements for complex adaptive systems. First, it presents a discussion on the scalability of the structures used to organize and relate requirements that are traditionally rules-oriented, i.e. that prescribe specific actions or outcomes. It then explores the concept of principles-based requirements as a means to guide the evolutionary development of complex adaptive systems. Related research and potential research questions are also included. Key words - Requirements, Complexity, Principles, Uncertainty, Interaction objectives. The regulators strive to provide accurate and consistent information and promote fairness in the market 1 Introduction (or at least to prevent fraud). The public companies wish to increase their profitability and to present themselves in the 1.1 Motivation best light to investors and lawmakers. In a speech delivered on November 20, 2006, former U.S. Treasury Secretary Henry Paulson made the following The interesting item for the systems engineering statement: community is the paradox that the less specific approach is presented as producing the more desirable outcome. This is “A number of foreign markets have developed excellent contrary to the traditional view that what a system “shall” standards and protocols. In some parts of the world, do must be complete, consistent, unambiguous, verifiable, particularly Europe, public companies adhere to the etc., which can lead to the undesirable characteristics International Financial Reporting Standards – an Secretary Paulson ascribes to rules-based systems: rigidity accounting system that differs from ours. and an overly process-centric approach to their development. Would a principles-based approach provide One important feature of the IFRS accounting system is some benefit to the engineering of certain classes of that it is principles-based, rather than rules-based. By systems? If so, what might it look like? "principles-based," I mean that the system is organized around a relatively small number of ideas or concepts that provide a framework for thinking about specific issues. The advantage of a principles-based system is that it is flexible and sensible in dealing with new or special situations. A rules-based system typically gives more specific guidance than a principles-based system, but it can be too rigid and may lead to a "tick-the-box" approach.” [17] The statement describes how two similar complex adaptive systems produce different emergent system properties due to the different ways that goals are set and interactions are constrained. The systems are similar in that they consist of two basic types of agents; the government regulators and public company representatives. They are also similar in that each group of agents works towards the same overall

The intent of this paper is to present a problem statement, use Secretary Paulson’s address to contribute towards a definition of principles in the context of this problem, and offer several research questions for future work. Before discussing rules-based vs. principles-based approaches, a brief overview of the complex adaptive systems model and some guiding descriptions of rules and principles are provided. 1.2 Overview of Complex Adaptive Systems Complex adaptive systems consist of autonomous components or agents that interact locally within a given environment in the pursuit of their individual goals. The aggregate of these interactions produce complex large scale behaviors and properties that can be sensed by the agents Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) and may influence their actions. The net result is an emergent, self-organizing global structure that is based on a dynamic cycle of individual agent decisions and feedback based on their combined actions. No higher level entity controls or guides these systems. This model is shown in Figure 1. The small circles at the bottom represent the agents and the small arrows between them depict their interactions. The three upward pointing arrows above the agents represent the aggregate interactions that produce an emergent structure. The two downward pointing arrows represent the influence of the emergent structure on the agents. Complex adaptive systems have been studied for many years in the physical and social sciences but have only received limited attention within the systems engineering community [3][4][13][20][21][6].

achieved through the thinking and decisions of the people involved in the interactions. There is some level of trust in the people to know or be able to determine an appropriate set of actions that will lead to the desired outcome. For a rules-based system, he notes that it is prescriptive and gives more specific guidance relative to a principles-based system. The intent appears to be that rules specify the actions to be taken for a given set of circumstances, similar to an IF-THEN programming statement. This essentially eliminates the decision-making by the people involved once they determine the applicable rule(s) for the circumstances. An intrinsic assumption is that we can reliably predict that the prescribed actions will produce the desired outcome. Table 1 summarizes and compares these basic characteristics according to the general areas of quantity, content and purpose. Table 1 – Characteristics of Principles vs. Rules Principles-based Rules-based Framework Framework Quantity Relatively smaller Relatively larger number of principles number of rules Content Ideas and concepts Specific guidance Purpose Guide thinking Prescribe actions

Figure 1 - Model of a Complex Adaptive System [14]. The basic properties of a complex adaptive system include aggregation, nonlinearity due to the number and types of interactions taking place, flows of resources within the system, and diversity in the components that perform similar functions [11]. These basic properties combine to create characteristics such as unexpected emergent behavior from aggregate interactions, sensitivity to different initial conditions, and small fluctuations causing rapid changes between many possible stable states. 1.3 Descriptions of Principles and Rules Secretary Paulson provides a very brief description of what constitutes principles-based and rules-based frameworks in his address. For a principles-based system, he mentions several key characteristics. A principles-based framework will have a relatively smaller number of elements or statements compared to a rules-based framework. The statements represent ideas and concepts, and are intended to guide the thinking of decision-makers. These characteristics can be generalized as quantity, content and purpose. The core idea behind these characteristics appears to be that principles specify a desired outcome, which is Loughborough University – 20th - 23rd April 2009

Within the context of the complex adaptive system model, a rules-based framework would prescribe the actions that an agent should take when interacting with another agent or with the environment. This greatly constraints the agents’ autonomy and can lead to the rigidity that Secretary Paulson cites. Many rules would be required to account for each type of interaction and the environmental conditions under which it might take place. In contrast, a principlesbased framework would map to the desired outcomes or goals that each agent or group of agents pursues as opposed to specifying their actions. The autonomy of the agents is preserved, leading to greater adaptability to unforeseen circumstances. Fewer principles are required because their number is not a function of the many possible paths that can lead to or inhibit reaching each goal. 2

Requirements Organization and Scalability

2.1 Limits on Traditional Requirements Hierarchies Requirements have traditionally been organized in directed trees, where requirements at one level are linked to their origins in the next higher level. Limits on scaling such structures can come from several sources that roughly follow a breakdown of complexity into contributions from the number of components, the number of relations, and the interests, capabilities and notions/perceptions of people [9]. In terms of size, scalability can be inhibited by the cognitive limits of people to comprehend and work with increasing numbers [15] and their ability to communicate effectively across larger and larger teams [5]. This description of complexity has been referred to as “detail complexity” [19].

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) In terms of interactions, there can be an inability to contain requirements interaction (relationships of dependency or influence as opposed to traceability) as the structure grows [18]. This has been called “dynamic complexity” [19] and as it increases, the methods of modularization and hierarchy that allow people to work with larger amounts of information [23] will be less effective in keeping the apparent system complexity below our limited cognitive ability. This calls into question our continued ability to overcome the effects of non-ideal requirements and recognize the increasing dependencies between them. A report on Ultra-Large Scale Systems by the Software Engineering Institute, Carnegie Mellon University highlighted the role and limits of humans in requirements engineering by stating: “Determining or discovering the requirements is also the software engineering activity that is the most domain specific, the least capable of being automated and formalized, and the least scalable. ULS systems will make these problems worse because of the scope of application domains that exceed the limits of human intellectual capabilities, the complexity and fragmentation of socio-economic processes and organizations that are highly decentralized and autonomous, and the sheer complexity of the problems being addressed.” [16] In terms of people, the choices they make and the expectations they have within their businesses and markets can limit scalability. There are practical limits on the resources available to build correct and complete requirements trees for larger and larger systems and choices must be made on how to allocate these resources. A highly dynamic marketplace can impose additional limits by creating more pressure to reduce costs and by increasing the pace of requirements changes. Reducing costs can lead to even fewer resources to perform a growing amount of work. Larger requirements structures and growing interactions make it more difficult and error-prone to incorporate changes at such a high pace. These limitations to the scalability of requirements structures are significant challenges for the types of complex systems that systems engineers have dealt with for decades. But systems engineers have been successful, at least to some extent, by controlling changes, limiting interactions, and coordinating the efforts of large teams when interactions are recognized. 2.2 The Implications of Complex Adaptive Systems The defining characteristics of complex adaptive systems may not just limit the scalability of requirements structures. They could conflict with the basic hierarchical structure that enables scalability. In particular, the large number and variety of interactions within a complex adaptive system are a major source of its emergent properties and its ability to adapt to environmental changes. An approach that limits these interactions would then limit the adaptive capabilities.

The traditional approach to requirements engineering includes the pursuit of ‘ideal’ requirements that are complete, unambiguous, testable, etc. These ideals enable the creation of well-defined requirements hierarchies. For complex adaptive systems, it would appear that pursuing these ideal qualities could create requirements that limit the actions and decisions of the agents to those that are specific and can be foreseen, i.e. those that have characteristics similar to a rules-based framework. The many potential interactions within a complex adaptive system also inhibit our ability to predict the effects of our engineering efforts, as reflected in the following statement. “Engineering relies on confident prediction of an outcome but many characteristics including nonlinearity, multiple stable states and sensitivity to conditions make confident prediction difficult. We have not reached the point where we can use these properties as engineering tools.” [4] For requirements engineering, uncertainty and unpredictability limit the detail and level of specificity that can reliably be attained. This puts a limit on the depth of the requirements hierarchy. Such a limit can result in assumptions and uninformed design decisions at lower levels of implementation that can change the intended outcome at the system level [3]. The traditional approach of generating additional levels of requirements to address growing complexity may also be counterproductive if the conditions under which these requirements will hold cannot be reliably stated. Alternatively, if the system state and initial conditions under which a requirement holds are not known, all of the possible system states and initial conditions for that requirement must be accounted for. This creates a multiplier effect for each requirement, further increasing the strain on our cognitive abilities. Thus it appears that for complex adaptive systems we cannot reliably scale up the requirements structure to overcome complexity, and we risk failing to achieve the desired outcome at the system level if we work from limited requirements. 3 Exploring a Principles-Based Approach This paper proposes a working hypothesis that principles, in some form, may be useful in guiding the thinking and decision making necessary for engineering when the uncertainty and dynamics inherent in complex adaptive systems limits the effectiveness of classical requirement engineering. Secretary Paulson’s address provides several ideas on what form a principles-based approach might have. The first idea is that principles should be strategic in nature, focusing on longer-term objectives. Secretary Paulson stated that in the U.S. regulatory structure “…we have added multiple regulators to respond to the issues of the day. Our regulatory system has adapted to the changing market by expanding, but perhaps not always by focusing on the broader objective of regulatory efficiency.” He goes

Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) on to suggest that we can achieve this objective by using rules that “are rooted in principles which will stand the test of time”. Thus, rules and principles can be linked together to address both short-term issues and long-term objectives. The second idea is that principles can promote coordination within a complex adaptive system. In the address Secretary Paulson described the U.S. regulatory structure as consisting of multiple, uncoordinated regulators at the State and Federal level that produce “…an ever-expanding rulebook in which multiple regulators impose rule upon rule upon rule. Unless we carefully consider the cost/benefit tradeoff implicit in these rules, there is a danger of creating a thicket of regulation that impedes competitiveness.” Principles could provide a broad coordination mechanism by capturing certain cost/benefit tradeoffs in a similar way that the agile software development community has used four simple ‘we value x over y’ statements to guide the many implementations of their processes [1]. The third idea is that principles should focus on the outcome instead of on a process that has an expected outcome, as shown in this quote from the address. “Our rules-based regulatory system is prescriptive, and leads to a greater focus on compliance with specific rules. We should move toward a structure that gives regulators more flexibility to work with entities on compliance within the spirit of regulatory principles.” Thus, principles should adhere to the ideal requirements characteristic of being implementation-free. Note that this quote also suggests a cooperative environment between the regulators and the regulated, where both sides continually work together to resolve ambiguities and learn from each other’s experiences. Such an environment may be a key element in having success with a principles-based approach. Table 2 adds these ideas to the basic characteristics presented in Table 1. The long-term vs. short-term view and outcome vs. process view are included under the Content heading. The idea of influencing a group to provide coordination is included under the Purpose heading. Table 2 - Characteristics of Principles vs. Rules (Expanded) Principles-based Rules-based Framework Framework Quantity • Relatively • Relatively larger smaller number number of rules of principles Content • Ideas and • Specific guidance concepts • Short-term focus • Long-term focus • State processes • State outcomes Purpose • Guide thinking of • Prescribe actions individuals of individuals • Provide group • Provide group coordination coordination through influence through authority Loughborough University – 20th - 23rd April 2009

3.1 Agility Principles and Frameworks The uncertainty and dynamic nature present in complex adaptive systems can quickly push a traditional systems engineering approach towards a reactionary stance similar to the ‘issue of the day’ regulatory mentality stated by Secretary Paulson. The evolving missions and objectives within complex adaptive systems create an environment where an adaptive approach to requirements engineering is more effective than rigid, up-front rules. Hence, this context should benefit not just from using principles, but from using principles that support agility. Examples of existing agility-oriented frameworks include the RRS framework, the Design for Changeability principles, and the principles behind the Agile Manifesto. RRS Framework [8] – This framework provides 10 characteristics that are commonly found in agile systems. It organizes these characteristics according to the 3 subcategories of Reusable, Reconfigurable and Scalable (RRS) as shown in Table 3. Table 3 – RRS Framework Reusable Encapsulated Modularity (Self-Contained Units) Modules are distinct, separable, self-sufficient units cooperating toward a shared common purpose. Plug Compatibility - Modules share defined interaction and interface standards; are easily inserted or removed. Facilitated Reuse - Modules are reusable/replicable; responsibilities for ready re-use/replication and for management, maintenance, and upgrade of component inventory is specifically designated. Reconfigurable Flat Interaction - Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. Deferred Commitment - Module relationships are transient when possible; decisions and fixed bindings are postponed until immediately necessary; relationships are scheduled and bound in real-time. Distributed Control and Information - Modules are directed by objective rather than method; decisions are made at point of maximum knowledge; information is associated locally, accessible globally, and freely disseminated. Self-Organization - Module relationships are selfdetermined; component interaction is self-adjusting or negotiated. Scalable Evolving Standards (Framework) - Frameworks standardize inter-module communication and interaction; define module compatibility; and have responsibilities designated for evolution and compatibility. Redundancy and Diversity - Duplicate modules are employed to provide capacity right-sizing options and fail-soft tolerance; and diversity among similar modules employing different methods is exploited. Elastic Capacity - Module populations may be increased and decreased widely within the existing framework.

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)

Secretary Paulson highlights the use of three of these principles: Flat Interaction, Distributed Control & Information, and Evolving Standards. Flat interaction is encouraged through the creation of a collaborative environment where regulators and public companies can work together and learn from each other. Distributed control is demonstrated in the ability of the regulators and public companies to resolve issues and unusual situations without the need to consult central authorities. The principle of evolving standards is seen in another section of the press release where Secretary Paulson describes the efforts of U.S. and E.U. regulators to evolve their different accounting and reporting standards towards a common system. Design for Changeability Principles [10] – This framework describes a set of principles that enable the incorporation of changeability into system architectures according to four different aspects: robustness, flexibility, agility and adaptability. The principles are divided into two sub-sets; 3 basic principles that enable all 4 aspects of changeability and 6 extending principles that only enable selected aspects (see Table 4). Most of these principles overlap with those in the RRS Framework and relate to Secretary Paulson’s address in the same way.

Extending

Basic

Table 4 – Design for Changeability Principles Ideality/Simplicity – reducing system complexity Independence – minimizing the impact of changing design parameters Modularity/Encapsulation - minimizing the coupling among modules while maximizing the cohesion within modules Integrability – compatibility, interoperability, open or common/consistent interfaces Autonomy – objects are capable of providing basic functionality necessary to ensure their independence from the embedding systems Scalability – units are independent from scale or self-similar/fractals Non-Hierarchical Integration – units linked across the total system, with no respect to any type of modularity or encapsulation Decentralization – distribution of control, information, resources, attributes, and properties within the system architecture Redundancy – enables capacity, functionality, and performance options as well as fault-tolerance Agile Manifesto Principles [2] - The 12 principles behind the Agile Manifesto are another example of how principles can be used to guide the thinking about, and the development of, a particular kind of complex adaptive system; a self-organizing software development team. The principles are: •

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• • • • • • • • • • •

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is faceto-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Again, several of these principles are seen in Secretary Paulson’s comments, specifically the emphasis on business people and regulators working together, trusting them to get the job done, using regulatory efficiency (the equivalent of working software) as the primary measure of progress, and reflecting on how to become more effective (learning from each other). In terms of the previously described characteristics for principles-based systems, we can see that these example sets consist of small numbers of principles that describe ideas and concepts instead of giving specific guidance for a given situation. It is evident that they are intended to guide the thinking of the people that make decisions as opposed to directing the actions of these people. To apply this approach does not mean to replace existing requirements with broad principles. The principles can be used as a form of “design rules” for the requirements. For example, the need for modularity and standards in an agile system are promoted by the RRS Framework and Design for Changeability principles that were presented earlier. Thus, the requirements for interfaces within a system that is to be “agile” should comply with these principles and systems engineers should resist the temptation to create unique but higher performing interfaces. Another example is the expectation for a large software-intensive system to be heavily modified over its lifetime. Principles may be established to emphasize maintainability over operator usability, which may guide the decomposition of requirements when trade-offs are required. These principles can also serve to fill in the gaps when Loughborough University – 20th - 23rd April 2009

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) requirements lack sufficient detail or when going beyond a set of minimal requirements. It is possible to lose the system perspective at lower levels of decomposition, leaving the engineers to integrate separate and independent requirements statements together in their minds [3]. Requirements principles can serve to guide their thinking. 3.2 Principles Can Lead to Rules Earlier in the press release, Secretary Paulson quotes former Treasury Secretary Bob Rubin to stress the need for a balanced view of risk by noting society’s apparent imbalance: “Our society seems to have an increased tendency to want to eliminate or minimize risk, instead of making cost/benefit judgments on risk reduction in order to achieve optimal balances.” [17] This tendency to be risk adverse could be viewed as an unstated, higher level principle that counteracts the principle of seeking an optimal balance between cost and benefit. For example, a cost/benefit judgment may result in accepting a risk. If the risk becomes an issue, society’s risk adverse bias may create a desire to prevent any reoccurrence of that problem. This can shift the balance away from the optimal cost/benefit point and limit future cost/benefit judgments. An illustration of this, using a Limits-to-Growth system archetype [19] is shown in Figure 2. Such unstated principles may promote an overly process-centric approach to developing complex systems or at least inhibit creating the type of culture needed to foster principles-based development.

on an early definition of what constitutes success. One can take the view that this understanding of systems engineering contributed to a principle of risk minimization instead of risk management in order to eliminate variation, improve predictability and promote optimization. The principle of risk minimization may not be expressly stated in an explicit policy, but it may still exist in practice leading people to prefer mitigation strategies such as risk avoidance, transfer and elimination instead of risk reduction and tracking. For example, the U.S. Department of Defense Risk Management Guide does not distinguish between risk handling strategies and promotes balance between the risk managed by the Government and the Contractor [7]. Yet a study of motivation and cognitive biases in risk management suggests that avoidance of uncertainty is one human bias that impacts the effectiveness of risk management [22]. 4 Potential Research Questions Several sets of research questions can be drawn from this examination of Secretary Paulson’s address on principles vs. rules. They will be used to guide future research by the authors. •

•

• Figure 2 - Limits to Growth Archetype for Principles-based Development This same risk adverse tendency may exist within the systems engineering community. Consider the description of systems engineering from the International Council on Systems Engineering, which emphasizes up-front definition of requirements and a sequential process. “Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:” [12] This process-centric approach organizes the activities to produce a stable, predictable and efficient outcome based Loughborough University – 20th - 23rd April 2009

•

The relationship between agent interactions and requirements interactions. What is the relationship between the interactions that take place within a complex adaptive system and the interaction between the requirements for such a system? Must requirements interactions exist for a complex adaptive system? Does limiting the interactions between requirements limit the capabilities of a complex adaptive system? Differentiation of principles from rules. Can the characteristics derived from Secretary Paulson’s address be validated? What other characteristics differentiate principles from rules? What is the appropriate scale or level of detail for principles as opposed to rules? A descriptive approach - current use of principles. Are principles being used, formally or informally, in the engineering of complex adaptive systems? If so, what are the characteristics of these principles? Is there commonality across these systems or across some other factor? How useful are they? Towards a prescriptive framework for principles. What should a principles-based framework consist of? What ideal characteristics would principles have? How would they be derived and stated? What would their relationship to requirements be?

5 Summary and Conclusions We presented several characteristics of principles-based and rules-based systems, as described in an address by Secretary Paulson, and compared them using a simple evaluation framework consisting of quantity, content and purpose.

7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) We then discussed Secretary Paulson’s comments in the context of engineering complex adaptive systems with inherently evolving missions and objectives. In particular, the issues of unforeseen interactions leading to a more reactive approach and the dynamic nature of both environments were seen as common factors. This led to the conclusion that some of the published principles from agile systems and software development may be applicable. Examples of such principles were provided and related to several corrective activities that the Department of the Treasury is undertaking. These principles can be seen as strategic design rules for creating requirements of a tactical nature or serving to fill the gaps that exist when requirements are insufficient, do not exist or when environmental and system changes make them outdated. Finally, we discussed former Treasury Secretary Bob Rubin’s view that society tends to prefer eliminating or minimizing risk and suggested a similar tendency within the system engineering community. It was hypothesized that such a tendency contributes to adopting an overly processcentric approach to development. This tendency may exist in spite of explicit policy and principles that promote a more balanced approach to risk management. One conclusion here is that principle-based systems, like rulesbased systems, are not guaranteed to produce the desired results and that they need a supportive environment to exist. 6 References [1] Agile Alliance (2001a), “Manifesto for Agile Software Development”, retrieved June 19, 2006, from http://agilemanifesto.org/. [2] Agile Alliance (2001b), “Principles Behind the Agile Manifesto”, retrieved June 19, 2006, from http://agilemanifesto.org/principles.html. [3] Beckerman, L. P. (2000), “Application of Complex Systems Science to Systems Engineering”, Systems Engineering, 3(2), 96-102. [4] Calvano, C. N., & John, P. (2004), “Systems Engineering in an Age of Complexity”, Systems Engineering, 7(1), 25-34. [5] Cockburn, A. (2002), Agile Software Development, Boston: Addison-Wesley. [6] DeRosa, J. K., Grisogono, A.-M., Ryan, A. J., & Norman, D. O. (2008), “A Research Agenda for the Engineering of Complex Systems”, paper presented at the 2nd Annual IEEE Systems Conference, Montreal, Quebec, CAN. [7] DoD. (2006), Risk Management Guide For DOD Acquisition, retrieved September 2, 2008, from http://www.dau.mil/pubs/gdbks/docs/RMG%206Ed%20Au g06.pdf. [8] Dove, R. (2001), Response Ability: The Language, Structure, and Culture of the Agile Enterprise, New York: Wiley. [9] Flood, R. L., & Carson, E. R. (1988), Dealing With Complexity: An Introduction to the Theory and Application of Systems Science, New York: Plenum Press.

[10] Fricke, E., & Schulz, A. P. (2005), “Design for Changeability (DfC): Principles to Enable Changes in Systems Throughout Their Entire Lifecycle”, Systems Engineering, 8(4), 342-359. [11] Holland, J. H. (1995), Hidden Order: How Adaptation Builds Complexity, New York: Basic Books. [12] INCOSE. (2004, June 14, 2004), “What is Systems Engineering?” retrieved September 2, 2008, from http://www.incose.org/practice/whatissystemseng.aspx. [13] Kuras, M. L., & White, B. E. (2005), “Engineering Enterprises Using Complex-System Engineering”, paper presented at the 2005 INCOSE International Symposium, Rochester, NY. [14] Lewin, R. (1992, 1999), Complexity: Life At The Edge Of Chaos, (2nd edition), Chicago: The University of Chicago Press. [15] Miller, G. (1956), “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information” [Electronic Version], The Psychological Review, 63, 81-97, retrieved May 21, 2008 from http://www.musanim.com/miller1956/. [16] Northrop, L., Feiler, P., Gabriel, R. P., Goodenough, J., Linger, R., Longstaff, T., et al. (2006), “Ultra-Large-Scale Systems: The Software Challenge of the Future”, Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. [17] Paulson, H. M. (2006), “Remarks by Treasury Secretary Henry M. Paulson on the Competitiveness of U.S. Capital Markets Economic Club of New York”, retrieved September 1, 2008, from http://www.ustreas.gov/press/releases/hp174.htm. [18] Robinson, W. N., Pawlowski, S. D., & Volkov, V. (2003), “Requirements Interaction Management”, ACM Computing Surveys, 35(2), 132-190. [19] Senge, P. M. (2006), The Fifth Discipline: The Art & Practice of The Learning Organization (1st edition), New York: Doubleday. [20] Sheard, S. A. (2005), “Practical Applications of Complexity Theory for Systems Engineers”, paper presented at the 2005 INCOSE International Symposium, Rochester, NY. [21] Sheard, S. A. (2007), “Principles of Complex Systems for Systems Engineering”, paper presented at the 2007 INCOSE International Symposium, San Diego, CA. [22] Siefert, W. T. (2007). “Cognitive Biases in Risk Management”, M.S. thesis, University of Missouri-Rolla, Rolla, MO. [23] Simon, H. A. (1962). “The Architecture of Complexity”. Proceedings of the American Philosophical Society, 106(6), 467-482.

Loughborough University – 20th - 23rd April 2009