System Dynamics Applications / 1 / 1.6

1.6 A SYSTEMS ENGINEERING APPROACH TO MODEL REQUIREMENTS AND MODEL BUILDING

There is considerable evidence that, from the viewpoint of cognitive capacity, we are poorly equipped to deal with complex problems (Diehl and Sterman, 1995; Dörner, 1980; Forrester, 1971; Kleinmuntz, 1985; 1993; Mosekilde and Larson, 1988; Mosekilde, et, al., 1990; Paich and Sterman, 1993; Sterman, 1989a; 1989b; 1989c; 1994; 2002 and Sweeney and Sterman, 2000). Where we might encounter large amounts of detail, we need tools and techniques to manage that detail. Tools such as databases and spreadsheets are widely used and we are generally familiar with these. It is a different story, however, when it comes to problems where we might encounter the additional aspect of dynamic complexity. That is, dynamic complexity in problems is characterised by feedback, delay and resultant counter-intuitive system response. We need specialised tools and techniques to help us build models which create for us the best possible opportunities to understand these complex, dynamic problems.

The approach taken in this book involves taking a systems view and deals with the problem at various levels of aggregation, recognising the nature of complex problems. It utilises systems thinking and systems engineering tools and techniques to support the development of models which together will significantly improve both diagnosis and understanding.

In ‘Managing Complex Technical Projects: A Systems Engineering Approach’, Faulconbridge and Ryan (2002) explain the essentials of systems engineering. In this book we examine how to address complex dynamic problems using system dynamics tools applied through the systems engineering discipline. Systems engineering is an interdisciplinary, comprehensive approach to solving complex problems and satisfying stakeholder requirements. System dynamics modelling supported by the tools and techniques of the systems engineering discipline provide a highly effective approach. Integrating the systems engineering approach into a methodology for building system dynamics models for analysis of complex problems provides a number of benefits. The approach integrates:

• Requirements analysis. The complete and accurate definition of the systemic problem, often a human activity system, demands primary focus on clear and unambiguous statements of requirements for a model of that systemic problem. A human activity system is a notional purposive system which expresses some purposeful human activity, activity which could in principle be found in the real world. Such systems are notional in the sense that they are not descriptions of actual real-world activity (which is an exceptionally complex phenomenon) but are intellectual constructs; they are ideal types for use in a debate about possible changes which might be introduced into a real-world problem situation. Defining requirements starts with a simple statement of need, which is translated into a large number of statements of requirement that form the basis for the structural and physical designs of models, which will be used for analysis of the specific parts of a physical system or human activity system under study. These translations must be managed by a rigorous process that guarantees that all relevant requirements are included (and all irrelevant requirements are excluded). The initially unstructured problem situation is translated through to precise definitions of the system and its behaviour. These definitions are critical for many reasons including being the basis for model design, development and verification (testing against requirements). To facilitate the analysis of human activity systems, we develop a series of root definitions of the relevant parts of the human activity system. A root definition is a concise, tightly constructed definition of a human activity system which states what the system is; what it does is then elaborated in a conceptual model which is built on the basis of the definition. Every element in the definition must be reflected in the model derived from it. A well-formulated root definition will make explicit each of the CATWOE elements identified by Checkland (1981; 1990; 1993) and Checkland and Scholes (1999). A completely general root definition embodying CATWOE might take the following form: A (…O…)-owned system which, under the following environmental constraints which it takes as given: (…E…), transforms this input (…) into this output (…) by means of the following major activities among others: (…T…), the transformation being carried out by these actors (…A…) and directly affecting the following beneficiaries and/or victims (…C…). The world-image which makes the transformation meaningful contains at least the following elements among others: (…W…). Examples can also be found in Rosenhead (1989) and Wilson (1990; 2002).
• Requirements management. Once requirements have been collected, the systems engineering process then focuses on the management of those requirements from the highest level of aggregation right down to the lowest. It is appropriate to define requirements in terms of a model at the highest level, a sector at the intermediate level and a module at the lowest level. Modules contain elements such as stocks (levels or accumulators), rates (flows), auxiliary variables, physical flows, and information links (the latter two often forming feedback loops). To collect and build specifications of modelling requirements involves activities of elicitation, analysis, definition, and validation. Requirements engineering ensures that a rigorous approach is taken to the collection of a complete set of unambiguous requirements from the stakeholders in each of their perspectives (even though at some stage these will be combined into a single view represented by the model, or set of connected models).
• Requirements traceability. Through being able to trace requirements back to stakeholders and through every stage of consideration of a complex problem, it is possible to assure that all requirements can be traced forward and can be accounted for in the design of the model at any stage of its development. Similarly, any individual design decision affecting the model of the system or the system itself must be able to be justified by being associated with at least one higher-level requirement (backward traceability). Further, any aspect of the model being used to analyse the design, and the design itself, that cannot be traced back to a higher-level requirement is likely to result in redundant or unnecessary work. Traceability also supports processes that lead to implementation of changes to the structure of the systemic problem under examination. Support for requirements traceability is a feature of the top-down systems engineering approach that provides a mechanism by which it can be guaranteed that requirements can be satisfied at any stage. A bottom-up approach cannot provide the same guarantee.