INTRODUCTION AND OVERVIEW

Given that engineers have now been practicing systems engineering for more than 30 years, ideally these notes should begin with a precise and succinct definition of systems engineering. Unfortunately, life is not so simple. Systems engineering still means different things to different people. Chapman, for example, contains a list of 16 different viewpoints for what systems engineering is (or is not). Hence, rather than start out with an exhaustive list of definitions, we set the stage for our systems engineering development by describing the scope and complexity of problems relevant to the end-to-end development of modern engineering systems.

Scope and Objectives

In this course we interested in the end-to-end development -- planning, analysis and design, implementation, operation, retirement -- of complex engineering systems, taking into account engineering and business concerns.

These engineering systems are composed hardware, software and human elements that need to work with an external operational environment. Their development is guided by system requirements, specifications and constraints.

Starting with a thorough understanding of business and engineering needs, our goals for systems engineering are to provide:

1. A balanced and disciplined approach to the total integration of the system building blocks with the surrounding environment.
2. A methodology for systems development that focused on objectives, measurement, and accomplishment.
3. A systematic means to acquire information, and sort out and identify areas for trade-offs in cost, performance, quality ....etc.

Systems engineering procedures need to recognize that complex engineering systems are nearly always multifaceted. Implementation procedures need to be integrated and flexible, reuse previous work where possible, and try to solve problems at a high level of abstraction (a well known technique for enhancing flexibility and productivity of problem solving).

Measures of System Complexity

We use the term "complex" to represent the significant difficulty and magnitude of engineering and business development activities, nearly always requiring a team of engineers, input from multiple disciplines, and use of multiple technologies. We can quantify the difficulty in development through a number of attributes:

The traditional metric of "complexity" captures the intricate intertwining (or interconnectivity) of elements within the system. In a highly connected system, a decisions or action made by one element will affect many other elements in the system) and/or between a system and its external environment. Measures of system complexity also include the extent to which its properties evolve over time, and the extent to which the system behavior is governed by distributed control. See the adjacent table.

System complexity is partly "inherent" and partly "accidental." Inherent system complexity includes factors such as the number of parts and subsystems needed just to get the system to work and, as such, cannot be eliminated. Accidental system complexity is caused by error, or perhaps a lack of insight or understanding of the system characteristics, and poor communication among team members. And as we will soon see, accidental system complexity can often be reduced (or minimized) through good planning, system modeling and analysis techniques, strategies of design that keep the system as simple as possible, and effective communications.

Systems Engineering versus Traditional Engineering

Systems engineering is concerned with "cradle to grave" development. That is, systems planning and analysis, system architecting, design, implementation, maintenance, and eventually, system retirement. Figure 1. shows the relationship of systems engineering to the traditional engineering disciplines, business interests, and services provided by computer hardware and software.

Figure 1. Traditional Engineering versus Systems Engineering

The tall boxes show the typical concerns of the traditional engineering and business disciplines. Traditional approaches to engineering design and development are product-oriented, with engineers focusing their attention on modeling product performance (or functionality), and procedures for manufacturing the product. An engineer's involvement with a product may finish when these details have been resolved. Project managers and business executives spend their time working on financial concerns, marketing opportunities, strategic planning problems, and so forth.

The horizontal box shows how the concerns of systems engineers complement those of the traditional engineering disciplines. Three key aspects are:

1. Life-Cycle Orientation

   The systems engineering view of design and development encompasses the organization, all of the engineering design and manufacturing (including product creation, implementation, testing), plus use of the product after its initial delivery to the customer (i.e., maintenance and support; periodic technological improvements).

2. Support for Team Development

   Systems engineering is a discipline that is concerned with the communication of knowledge among the team participants for the solution of interdisciplinary problems. The communication of knowledge will be accompanied by procedures for the synthesis and integration of multi-disciplinary systems, and coordination of activities across disciplines, and with discipline experts.

   Indeed, a commonly held belief is that the greatest opportunity for effective systems engineering lies at the interfaces between system components -- i.e., how should component interfaces be defined so that they can be easily assembled into a systems having a wide variety of functionality.

3. Systems Analysis and Trade-Off Studies

   From a technical perspective, systems engineers need to conduct analysis and trade-off studies that will ensure the overall system is economic, while also balancing the concerns and needs of individual viewpoints contributing to the system.

   In the early phases of system development, these procedures are facilitated by the careful acquisition and analysis of requirements, and traceability of requirements to the design (a lot more on this later).

Systems engineering activities have the greatest technical and economic influence in the early stages of the development lifecycle. In contrast, the "traditional engineering" disciplines have their greatest influence during the detailed analysis and design phases of system development.

Note. As a benchmarh comparison, a detailed description of systems engineering may be found the the Martin Marietta short course notes, where it is defined as having four components:

1. The transformation of an operational need into a description of system performance, and a preferred system configuration. System engineering uses and iterative process of analysis, synthesis, optimization, definition, design, test, and evaluation.
2. Incorporates related technical parameters and assures compatibility of all physical, functional, and program interfaces in a manner that optimizes the total system definition and design.
3. Integrates performance, productivity, reliability, maintainability, supportability, and other specialties into the overall engineering effort.
4. Supports architecture synthesis and reuse through the use of an iterative, hierarchical object-oriented analysis process.

Systems Engineering Processes

Systems engineering development solutions are characterized by well-defined processes, methodologies and models.

Processes

A process is simply a sequence of activities executed by a human or machine, often with the goal of transforming a set of inputs into outputs. A complete description of a process includes naming of the steps within the process, and use of models of the system in various textual/graphic abstractions.

Systems engineering processes are concerned with the step-by-step development of complex engineering systems, from identification of user needs through to specification of all components and subsystems to be designed. The system may be a product, service, deliverable .....

Therefore, we consider systems engineering to be the composition of two processes:

1. Systems engineering is a technical process to be accomplished.

   The purpose of the technical process is to produce a product. This viewpoint focuses on the needs of individual designs/products.

2. Systems engineering is an organizational process to be managed.

   Each project development must be controlled and repeatable, and yet flexible enough to accommodate each project's idiosyncrasies. Key tasks include the estimation of human resources, scheduling of work activities, and coordination (i.e., communication and bargaining) among separate enterprises (or groups within an enterprise). Each enterprise/organization will have its own objectives, values, and polices. This viewpoint focuses on the needs of the organization/group.

The technical and management processes serve complimentary purposes. The technical process generates generates "technical outcomes and decisions" needed by the management process. Conversely, the organizational process generates "plans and direction" for the technical process.

Because organizations are setup to support an ensemble of design project developments, typically, organizations place more importance on the "process of creating the product" than details of the product itself. This line of thinking has been around for a while -- as a case in point, Dwight Eisenhower is reported to have said ``The plan is nothing; the planning is everything......''

Methodology

A methodology is simply the implementation of a specific process. Kronloff (Kronloff, 1993) points out that methodologies for systems engineering development should contain: (1) An underlying model; (2) Languages for manipulating the model; (3) Well-defined step-by-step development procedures; and (4) Guidance for applying the method.

Elements of Team-Based Development

Methodologies for the team development of system-level architectures need to support the following activities:

1. Partitioning of the design problem into several levels of abstraction and viewpoints suitable for concurrent development by design teams;

2. Synthesis of good design alternatives from modular components;

3. Integration of the design team efforts into a working system; and

4. Evaluation mechanisms that provide a designer with critical feedback on the feasibility of a system architecture, and make suggestions for design concept enhancement.

The ability to describe system products and processes at an appropriate level of abstraction is essential for these methodologies to work. Over time engineers have learned that in order for the development of systems of ever-increasing size and complexity to remain tractable, methodologies need to be adjusted so that problems can be formulated in a formal way, but at higher and higher levels of abstraction. In this software arena, this this progression is very clear: machine languages, followed by assembly languages, followed by high-level languages, followed by object-oriented languages, ... and so forth. There is a strong need for a counterpart capability that will support the synthesis and integration of systems composed of hardware and software.

Each team is likely to view the system in a way that corresponds to their purpose. Some viewpoints will be discipline specific. Other viewpoints will focus on how the teams work will interface with the work of other teams.

As large organizations move towards a model of global development (e.g., NASA Goddard; BMW; Boeing), the role of managment and oversight of external consultants/manufacturers becomes increasingly important. Striking an appropriate balance in "ensuring control" while not being too intrusive about it can be a delicate proposition. First and foremost, oversight authorities need to make sure each team will deliver a product that can be integrated with the other team developments. If this doesn't occur, then the whole system will fail. Having the ability to model incremental progress and make corrective actions as soon as they are needed can mitigate the opportunity for catastrophic shortcomings. On the other hand, oversight authorities need to give each development team a certain level of autonomy. Development team need to understand what the final deliverables will be and how their work will be used downstream, and then left alone to make lower-level decisions on how the deliverables will be produced.

Data, Information, and Decision Making

Of course, a key element of "end-to-end development" is the data and information needed to support system development processes, describe system products, and to generate, rank, and optimize system design alternatives. Over time systems engineering design and development can be viewed as:

For processes associated with the development of complex systems, flows of information -- best thought of as networks or webs, rather than chains -- must be at the right place at the right time. Also, for these processes to have any chance of assistance through computer automation, we will need formal methods for describing data, information, and decision making.

Most engineers are reasonably familiar with "data" and the formal methods (e.g., data structures, algorithms, and databases) that can be used to represent, store, retrieve, and manipulate data. But what about "information" and "decision making" -- what hope do we have for casting these elements of the problem into a formal framework?

Information

From a technical standpoint, information can be viewed as "a measure of the extent to which a piece of knowledge tells you something which you did not know." (Shanon, 1948). Thus, information represents a change in knowledge:

Now suppose that we are looking at a representation (it could be a collection of symbols, a drawing, ... etc), as shown on the left-hand side of Figure 2.

Figure 2. Models of Interpretation determine the Meaning of a Representation

Whether or not the representation contains information lies in the eye of the beholder -- an appropriate interpretation requires a mapping between notations and what those notations are meant to mean in a human or machine-defined world. If such a mapping exists, then the representation will have meaning because information can be extracted from it.

Figure 3. Data/Knowledge Continuum (adapted from Park et al., 2002)

This, of course, says nothing about the quality of the information that is extracted from a representation, nor the number and types of mappings that might be needed for a proper interpretation. The purpose of Figure 3 is to show that, in practice, a spectrum of interpretation methods are needed to handle the wide range of representations that occur.

On one hand, the left side of the figure shows representations that are dominated by unstructured data (e.g., the web). For the most part, representations of this type need to be interpreted by humans. At the other extreme, representations that have well-known structure and content lend themselves to computer interpretation (and reasoning) of representations, sometimes at high levels of abstraction. Ontology induction is the ability to automatically acquire concepts, evolve ontologies into theories about problem domains, and to link disparate repositories.

For systems engineers, the key benefit in using computers to interpret and reason with large quantities of data is the additional time that is available for the more creative/unstructured aspects of development.

Decision Making

A decision making process is concerned with the systematic evaluation of choices over time, and in a manner that is consistent with the values (tastes) and knowledge (beliefs) of the decision maker (or decision makers). Key ingredients of the problem formulation and solution procedure are as follows (Ravindran, 1987):

1. The decision maker.
2. Alternative courses of action.
3. Events (i.e., scenarios or states of the environment not under control of the decision maker); and
4. Consequences. The consequences are measures of net benefit (gain or loss) received by the decision maker.

Generally speaking, the consequences that result from a decision depend not only on the decision but on the event that occurs. Sometimes the consequenes will be singular. However, for systems engineering, working with the consequences of a decision requires consideration of multiple viewpoints that are possibly in conflict.

Figure 4 adapted from Sterman (Sterman, 1994), and shows the role of information feedback and models of the real world in decision making. Information feedback is the data, information, or behavior we receive/sense about the real world. A model is a belief of basic cause-and-effect relationships underpinning the system operation.

Figure 4. Two-loop Feedback for Decision Making

Two loops of information feedback can be combined with a mental model to generate an adaptive system for learning about the structure and behavior of the real world systems, selecting decision rules, and making decisions. The inner feedback loop represents situations where information sensed from the real world affects the decision making process, but for some reason (perhaps oversight), is not accounted for in the mental model. In either case, with each iteration of the looping structure, hopefully we move the system under development/observation closer to our goals.

Systems engineers must make decisions at all stages of the systems life cycle, and those decisions must be based on the information available at that time. Impediments to clear-cut decision making include unknown structure of the real world, dynamic complexity, time delays, and the inability to conduct controlled experiments on the system itself. Decision making will be further restricted when the project participants cannot infer dynamics from cognitive maps. In other words, a systems engineer may have mountains of information, but not be able to deduce the relevant cause-and-effect relationships required for a systematic improvement to the system.

It is important to keep in mind that decisions: (1) involve commitments to resources, and (2) often place constraints on the design alternatives that are possible. When a decision is made alternatives may be eliminated from the space of potential design solutions. Decisions may also involve commitments to economic, work, schedule and quality resoucres.....and so forth.

Because systems engineers are primarily concerned with the development of new and innovative systems that may have stringent performance requirements we need to investigate: (1) the features of these systems that will define their structure and behavior, and (2) metrics that will define system performance.

A smart (or intelligent) engineering system is one that is capable of performing a wide array of responses relating to the system's goals or functions. The nature and extent of the behavior space determines the degree of intelligence (Kim, 1990).

From a social point of view, definitions of intelligence are a sensitive topic. However, there would seem to be at least three factors that contribute to what we deem as the phenomenon of intelligence. They are: (a) the ability to acquire and store knowledge, (b) experience, and (c) creativity.

The left-hand side of Figure 4. shows a three-dimensional space of the so-called intelligence components. From the viewpoint of intelligent design, intelligence manifests itself through the goals, objectives and function of developing a physical object. Some of these functions will be directly related to the product, and others will describe the processes (e.g., learning, communication) that empower an organization and its employees to develop the product. Intelligence can be viewed as a finite volume in the three-dimensional space, that will acts as a resource/catalyst in the transformation of design requirements and specifications into a design product. Often these systems will also need to sense, and adapt to external environments that change with time.

The fundamental problem of understanding intelligence is not the identification of a few powerful techniques, but rather the question of how to represent large amounts of knowledge in a manner that permits effective use and interaction (Goldstein and Pappart, 1977). According to Kim (Kim, 1990), at least five factors are needed to represent knowledge in an intelligent/smart system. The factors are as follows:

1. Space

   As shown in Figure 4, intelligent behavior manifests itself in some finite volume of a multi-dimensional space. The range of responses the system may have in (a) converting design design requirements/specifications into a product, and (b) adapting to changes in an external environment, are bounded by the perimeter of the volume. In some cases, the boundary of the volume may be imprecisely defined.

2. Structure

   The structure of an intelligent system captures the relationship among the components of the system (e.g., network, layers). The system organization will define the communication among components.

3. Time

   An intelligent system often defies entropy by becoming more ordered with time. Intelligent systems must respond to time-dependent changes in an external environment (e.g., regulatory processes in a chemical refinery), and its own internal dependency to decay over time (e.g., health monitoring of highway bridge structures; spacecraft suitable for missions into deep space).

   Time also plays a key role in the trade-off of finite resources, the scheduling of process resources, and decisions over maintenance versus performance (now versus later). In markets such as VLSI components and software packages, minimizing time-to-market can be a crucial part of obtaining a market share.

4. Process

   Processes consist of sequences of events and actions, which may be classified by their level of initiative. One extreme of initiative occurs when the system initiates all types of interaction with its external environment. A passive process, on the other hand, will wait until it is activated by an externally generated activity.

   For a set of processes to be useful they must be coordinated with the physical mechanisms that define the system being developed. In manufacturing, for example, the process of drilling and moulding a mechanical component/part should be related to the geometry of the part being produced. Similarly, in control systems, the output of a process should be monitored to ensure the system's performance objectives are met.

5. Efficiency

   Figure 5. shows trade-off curves in multi-dimensional design space. For a fixed system performance, an increase in one design factor can compensate for a decrease in another factor -- see the left-hand side of Figure 6.

   
   Figure 6. Trade-off Curves in Multi-Dimensional Design Space

   So-called intelligent systems have a model that describes the relationships among the components of the system. When changes in the design factors can be coordinated in an ordered way (e.g., factors 1 and 2 both increase or decrease), performance of the system can be enhanced -- as shown on the right-hand of Figure 5.

And like traditional engineering design, the design of an intelligent/smart system nearly always involves trade-offs among conflicting attributes in 2 or more dimensions. Trade-offs can occur in many ways -- serial versus parallel operation of processes; space versus time; hardware versus software; computation versus storage.

Traditional engineering design processes evolve from a set of stated requirements for a given system through:

The design process generally begins with a high-level visualization of what is required, and extends through the architecture development, test, and evaluation of a prototype model. Typically, the result of design is a specification for a product that can be directly produced or constructed from specifications, a set of drawings, and supporting documents.

The end-to-end development of complex engineering systems requires completion of (at least) four stages:

Figure 7. End-to-end Development Processes

The key activities are as follows:

1. Requirements Engineering

   Requirements engineering involves the translation of a customer's business needs (i.e., what will the system do?) into a complete set of system requirements. Tasks include stakeholder analysis, definition of the domain vocabulary, identification of system goals, developing scenarios for system usage, and so forth....

   Unless systems engineers capture their requirements and specifications of behavior and structure in a precise and executable language, their requirements and specifications will remain ambiguous and error prone (Oliver, pg. 25).

   The importance of a good conceptual design cannot be overemphasized. As systems become more complicated, there is an increased risk of failure due to poor requirements analysis and ill-conceived design specifications. Requirements analysis includes factors like: written requirements, development of a prototype user interface, and involvement and correspondence with end-users. Design specifications include factors such as properly specified data structures and algorithms, design documents and design reviews.

2. Systems Architecting

   The system architecture is the fundamental and unifying system structure defined in terms of elements, interfaces, processes, constraints and behaviors. System architecting is the set of activities that define, maintain, improve and certify proper implementation of system architectures.

   Architecture development needs to ensure system-wide characteristics (mission effectiveness, interoperability, etc) are achieved across the detailed design and deployment phases of systems that are build in conformance with the architecture. Consequently, architectural models must be capable of providing insight into the logical, behavioral, and performance aspects of the proposed system.

   

   Figure 8. Technical Process for System Architecting

   Figure 8 summarizes the key inputs, outputs and technical processes and activities needed for architecture development. Starting with "customer requirements" and "needs analysis" results, systems architecting is an iterative process involving the following tasks:

   • Requirements Analysis

     Determine the intended use, scope and characteristics of the architecture (i.e., what questions will the architecture answer?; what is the system boundary?; what system characteristics are needed to answer the questions that need to be answered?).

   • Functional Analysis

     Identify the purposes or functions that the system will support.

   • System Synthesis

     System synthesis is concerned with the generation of (good) design alternatives. Synthesis is a translation process where a behavioral description is translated into descriptions of system architectural/structure. This involves identification of the components, modules or subsystems that can provide the needed functionality, along with mechanisms for component connectivity. Each component or module involved in the synthesis is in turn defined by its own lower-level behavioral description. Synthesis adds an additions level of detail that provides detail for the next lower level of detailed design.

     Synthesis is particularly important for systems that are quite unlike their predecessors. Instead of extrapolating established designs and technologies, engineers need to return to first principles, rethink established ideas, and identify potential problems (e.g., incompatible interfaces) downstream in the development. The required skills are creativity, common sense, and an ability to apply heuristics to new situations.

   The purposes of the system architecture are to provide:

   1. A comprehensive specification for the subsequent design and construction phases.
   2. A means of communication between project participants.
   3. A means of reducing risks of project failure by identifying problems and trading off various alternative solutions early in the project life cycle.
   4. A means for estimating cost, reliability and performance of the system under development.

   A good system architecture is logically correct, functionally achievable, unambiguous, complete (i.e., the functions should satisfy the needs of the user as completely as possible) and open-ended (i.e., its functions should allow for use in other ways than envisioned in the design). The architectural representation should be independent of choice of technology and process (i.e., sequence of activities). This gives an experienced designer freedom to design a process that matches their experience in successful projects and processes.

3. Systems Design

   The actual system design involves specialization of the system architecture and addition of all of the details so the system can be built. In other words, system design is concerned with "how will the system work?" (i.e., engineers design the hardware and software that will implement top system-level specifications.)

   The challenging problem at this stage is proper allocation of resources to hardware and software -- if the wrong allocation is made, then performance of final system may be suboptimal. System design tasks include the evaluation of alternative architectures (and sometimes prototypes), decomposition of functions into sub-functions, allocation of sub-functions to physical components. These tasks will be guided by cost and technology considerations.

   Every aspect of the detailed design should be documented with drawings and written descriptions, which will be passed onto the manufacturing/construction processes. Often the result of the detailed design is tested and verified components ready for integration into the system.

4. Systems Integration.

   Components and subsystems are assembled together. The assembly should follow the integration plan worked out during the system design phase, and verified to work.

   Production and/or construction problems can take a variety of forms. For example, (1) the production of a multiple quantity of like items (mass production), (2) the production of small quantities of a wide variety of different items (a job-shop type of operation), and (3) the construction of a single item, such as a large structure of some type. In production/construction operations material and personnel resources must be combined in such a manner as to provide the necessary product-system output in an effective and efficient

5. Optimization and Trade-Off Analysis.

   After it has been established that the system works properly, it is necessary to test that the system performs just like (or hopefully better) than the requirements of the system-design specification. System performance may be improved through the use of optimization methods.

6. System Validation and Verification.

   The terms system validation and verification refer to two basic concerns, ``are we building the right product'' and ``are we building the product right?'' Satisfactory answers to both questions are a prerequisite to customer acceptance.

   Validation and verification concerns are a prerequisite to customer acceptance, and the last overall system check before the system is sent to manufacturing.

Systems will become operational once these six steps have been completed and may be followed by periods of maintenance (expensive!) planning for upgrades (e.g., Window95, Windows 98, Windows 2000) and disposal (e.g., KingDome in Seattle).

Architecture versus Design

In real-world applications, the boundary between system architecture and system design is not well defined. Considerable overlap may exist. This observation is particularly relevant for object-oriented analysis and design because the abstractions of both are viewed in terms of the application rather than the underlying technology-dependent implementation. Moreover, in object-oriented design, the logical design may be inseparable from object-oriented analysis.

System architects arrange subsystems and components so that the proposed system will fulfill the customers needs. Additional detail is added through decomposition of subsystems/components in to constituent parts. An architect is needed only if the system is unprecedented and complex. An architect is not needed is a similar working system already exists and/or the system is very simple and can be constructed directly by a contractor.

It has been estimated that 90% of the function attributes, 80% of the schedule related information, 70% of the quality attributes and 60% of the manufacturing costs will be fixed once a systems requirements specification is complete.

Architectural Specifications and Frameworks

The output from front-end systems engineering is a set of specifications which must be logically correct, functionally achievable, and unambiguous. Systems are developed by teams of engineers - team members must be able to understand one-another's work. The adopted specifications must be relevant to all parties and disciplines involved in the development -- this will require the use of models customized to discipline-specific annotations, views and tools.

Definition of Architecture Framework.

An architecture framework provides common definition, data and references, and describes a set of products providing views of the system architecture.

    ----------------------------------------------------------------------------
    Architectural Framework/Views        Subsequent Design Activities
    ----------------------------------------------------------------------------
    What must be produced?     ----->    Product.  Choice of technologies that
                                         will implement the system architecture.
    And how?                   ----->    Process.  Sequence of activities needed
                                         to prod.ce and test the product.
    ----------------------------------------------------------------------------

In developing an architectural specification, one should provide sufficient information to assure that components/sub-systems will fit into the architecture, while simultaneously trying not to over-specify the architecture and overly constraining the designers.

Ideally, the architectural representation to be independent of choice of technology and process (i.e., sequence of activities). This gives an experienced designer freedom to design a process that matches their experience in successful projects and processes.

But perhaps the key motivation to requiring an architecture specification (as opposed to a single system) is the issue of system evolution. Systems today are being designed in a more modular form, with individual subsystems being upgraded on different schedules as needs and the technology base change. There is a growing need to define the common, or time invariant aspect of the evolving system that takes into account the likely risks and uncertainties associated with the external environment (and estimation of the system itself), control factors such as architectural requirements, required functions, and the need to economize through reuse of components/modules and sub-systems.

From an economic standpoint, the development of engineering systems is affected by:

Commitment of Funds versus Funds Spent.

Economic constraints limit the people, money, and tools resources which can be used during the requirements engineering process. It is not always true that by allocating more resources, a better design will be obtained. It is true, however, that if available resources fall below a certain limit, then the output of the design process will be of an inferior quality. Careful planning is of paramount importance, and the following figure shows the relationship between funds committed and fund expended at various stages in a typical product life cycle.

Points to note are as follows:

• Decisions made early in the product life cycle require little expenditure, but commit the largest proportion of project funds.

• Decisions made early in the life cycle have the largest opportunity for leading to significant cost savings. Conversely, decisions make in the latter stages of a product life cycle will have little bearing on project cost (most of the money has already been spent!).

Economic Constraints. Economic constraints limit the people, money, and tools resources which can be used during the requirements engineering process. It is not always true that by allocating more resources, a better design will be obtained. It is true, however, that if available resources fall below a certain limit, then the output of the design process will be of an inferior quality.

Design Changes during the Product Life-Cycle

Figure 10 shows design changes versus time in the product life-cycle (this diagram is adapted from Chapman, (Chapman, 1992).

Figure 10. Design Changes in Product Life-Cycle

The curve labeled traditional design is based on actual data taken from a U.S. automobile manufacturer. The curve labeled concurrent design, is for a Japanese counterpart. Generally speaking the cost of design changes increases as one proceeds through the product life-cycle. Even though the number of design changes early in the product life-cycle for concurrent design may be larger than at any point in the life-cycle for traditional design, design changes in concurrent design are relatively inexpensive and easy to make. If properly executed, a well controlled concurrent design process will give the customer a higher quality product at reduced costs.

Cost of Design Changes in the Product Life Cycle

The need for systems/concurrent engineering versus traditional engineering is motivated in part by economics. We observe:

1. Analysis and design errors are the most numerous.
2. Most analysis and design errors are not found by the developer.
3. Errors in system performance are a major source of user dissatisfaction.

Observation 2 is particularly troubling because an error detected by the developer is, generally speaking, also the cheapest to fix.

Table 3. shows the results of a study by Hewlett-Packard to quantify the relative costs, in terms of money and/or time, of correcting design errors. From an economic point-of-view, the last thing a manufacturer wants is discovery of a fatal error in the engineering system by a customer !! Similar results are reported by IBM.

The Ford Pinto manufactured in the 1970's is one of the best known examples of a catastrophe resulting from incorrect design decisions based on false early assumptions. In the car design, the position of the fuel tank mounting bolts was based on the assumption ``there will be no rear impact collisions.'' After this assumption proved to be false, the Ford Motor Company, by its own estimates spent $100 million on recalled services and litigation (Gause, 1989).

Relative Life Cycle Costs

Figure 11 shows the relative life-cycle costs for a variety of engineering domains. The key message is as follows -- look at where the costs are, and then focus on parts where savings can be made.

Figure 11. Relative Life Cycle Costs

Specific points to note are as follows:

1. Projects in the aerospace/defense sector typically have extensive requirements development. Software projects, on the other hand, may be based on a short requirements document. The industry works under a model of incremental development, and relies on customer feedback to guide further work.

2. Civil Infrastructure systems development requires methodologies for building, monitoring, evaluating, repairing, replacing, and financing public and private buildings, transportation systems, waste management facilities, and so forth. A key problem in the design of one-of-a-kind projects that are often expected to have a service lifetime of several decades is that they soon become technically obsolescent. A single facility is a good example of a small scale system; a series of highway bridges in a transportation network is a good example of large scale infrastructure. In most cases, provision for disposal of the system is not part of the initial development budget.

Our systems engineering drivers are the economic, technical, market and management factors pushing the need for improvements to the discipline of systems engineering.

Technical Factors

From an technical standpoint, the development of modern engineering systems is challenged by:

1. Increasing Prevelance of Information-Centric Systems.

   As we move from industrial- to information-age systems, hardware dominated systems are being replaced by large and complex systems containing combinations of hardware and software. In many cases the software isn't even visible to the outside users (i.e., increased use of so-called ubiquitous computing). Balancing the selection of hardware and software for the implementation of these systems is becoming progressively more difficult and common, and requires a new way of thinking.

   For the development of information-age systems, the execution of these goals will require:

   1. Methods that Deal with Scientific, Technical and Business Data in a Consistent Way

      We want to do everything using computers and information abstractions, from conception, to design, to parts selection, to manufacturing, to operations and retirement. Work is needed to abstract multiple disciplines to properly annotated information representations....this allows for communication among disciplines via multiple contextual views and much better management of the overall process.

   2. Synthesis of Systems from Modular Components

      Not only in aerospace, defense and large government projects, but in all commercial designs and operations. Delay choices of technology and details of implementation until near very end of development process. Systems Integration is the key.

   3. Support for Team Development

      Improve communication among team members by promoting "information-based" design, operation and management of systems/products.

   Example. A good example the trend from simple to complex systems is the gradual replacement of industrial-age systems (e.g., machine, assembly line) with information-age systems (e.g., smart weapons, Boeing 777 has 6 million parts). Simply speaking the characteristics of each domain are as follows:

   Industrial-Age Systems	Information-Age Systems
   Small	Large
   Simple	Complex
   Linear	Nonlinear
   System of Components	System of Systems

   Table 4. Characteristics of Industrial- and Information-Age Systems

   Whereas industrial-age systems tend to be the invention of a single individual (e.g., automobile, telephone), information-age systems tend to be the invention of teams (e.g., Intel products, Microsoft products). Teamwork requires communication.

2. Knowledge Gap.

   The adjacent figurte replicates Figure 11 and shows how funds committed and funds expended vary throughout the lifecycle of a typical project.

   
   Figure 12. Knowledge Gap in Systems Development

   The so-called "knowledge gap" is the distance between the percentage of funds committed and our knowledge of the system at a particular stage in the lifecycle. It seems desirable that if we are about to make a series of decisions that will commit 75% of the project funds, then these decisions should be based on a proportional amount of project knowledge. This goal is easily achieved in projects that are routine because many similar projects have already been completed, and most of the potential difficulties are already known. For new product development, however, the gap will be greatest during the conceptual stages of design. Part of the problem can be solved with a thorough gathering and analysis of requirements -- once this information is in hand, one still needs to make the best decision possible.

   The second dashed line in Figure 12 shows the ease with which design changes can be made. The good news is that even though our knowledge of a system is incomplete in the beginning, changes are cheap to make. The bad news is that once key decisions have been fixed in place, large sums of money are committed for the remainder of the project. Hence the quality of decision making in the early stages of the product lifecycle is of utmost importance. In addition to use of better methods for requirements gathering and analysis, use of engineering models (to learn about system behavior), and formal decision making and optimization techniques (for guidance on the best way to change a system for potential improvements) can mitigate potential problems. Use of systems engineering tools can extend the periods within the lifecycle with which changes are easy to make.

   Note. See comments in Oliver, pg. 6-7 -- The gap is the void between the needs expressed in informal, natural language and component specifications described in multiple engineering notations. Systems engineers need to remove the ambiguity and inconsistencies between what has been written/expressed informally and what they know will work.

3. Poor Support for Distributed Development and Decentralized Control

   Example. Mission to Planet Earth (MTPE) is an international initiative aimed at the advancement of scientific knowledge of the Earth and its environment. There are 13 participating nations, including Canada, China, France, UK, Germany, Japan, Brazil, Australia, and the US. The single most important goal of MTPE is understanding (and eventually predicting/modeling) natural and human-induced global climate change. MTPE is motivated by the prospect of accelerated environmental change in the next century -- these changes include climate change, rising sea levels, deforestation, and acid rain. Because these climatic adjustments will have a profound impact on many nations, it is important that we develop a detailed scientific understanding of the spatial and temporal nature (i.e geographical extent and rates) of atmospheric, oceanic, and terrestrial phenomena. The long-term hope is that improved scientific understanding will allow for impact studies of environmental phenomena, a consensus of international communities, and policy actions evident by the creation of new laws, regulation, and investment strategies.

   NASA has already identified principal scientific investigators from 13 nations who will have full access to data collected under the umbrella of MTPE. When EOS is fully operational, hundreds of science products will be generated by approximately 10,000 researchers and graduate students (Austin, 1994). Who's in charge?

4. Lack of Tools to Counter Rapidly Diminishing "Ease of Change"

   Systems engineering development processes can be very large, detailed, and complex. Some potentially "good design solutions" may remain unexplored. Not every decision will be correct.

   The dashed line in Figure 12 shows that as one works through steps in the life-cycle development process, the "ease of change" with which incorrect decisions can be corrected rapidly diminishes.

   This problem can be mitigated, in part, by trying to solve problems at a high-level of abstraction -- this strategy minimizes the effort (and cost) associated with making decisions, thereby increasing the resources available to explore more design options. With the appropriate data and information abstractions in place, there is also a need for system-level design tools that can assist systems engineers in the exploration and high-level evaluation of design options.

5. Data Analysis Gap

   When it is fully operational, NASA's multi-satellite Earth Observing System (EOS) will collect, process, and generate somewhere between 2-3 terabytes of information/data per day for 15 to 20 years. The result will be a database containing 2-3 petabytes (1 petabyte = 10^(15) bytes).

   To put these volumes of data in perspective, in 1990 the total amount of information archived by NASA for all missions was about 8 terabytes -- this is 2.7% of what is expected yearly from the EOS Data and Information System (EOSDIS) (David, 1995). Making NASA's vision a reality will require that some obstacles be overcome. A basic problem that exists today is that NASA is collecting and storing more information than it can process using traditional means. The consequences of this information abundance have been succinctly depicted by Campbell (Campbell, 1995), and are shown in Figure 13.

   
   Figure 13. The Data Analysis Gap

   The so-called ``data analysis gap'' is due to the positive difference and the ability of current scientific staff to analyze the data. Simply working harder is not the answer because there will never be enough scientists and statisticians to meet the data demand. New analytical methods and computer-based information systems tools are needed by both the science and non-science communities for the automated -- or partially automated -- recording, storage, processing, classification, and on-line dissemination of data/information. Automated processing reduces costs, and enables science and non-science users to focus on their domain of interest, rather than infrastructure building ~\cite{campbell95}.

6. Need for Flawlees Production

   The adjacent figure shows that on the average, U.S. companies incur approximately 66,800 defects per million opportunities, leading to a loss of 15\% of sales due to poor quality.

   
   Figure 14. Cost incurred by Poor Quality

   A few companies have acquired a world-wide reputation for high quality products (e.g., Motorola, Honda, Texas Instruments) by reducing defects in their design and production processes to the point of a few hundred per million opportunities.

   In addition to being an important market differentiator, the benefits of near flawless operations include enhanced customer satisfaction, reduced overhead in production costs, and fewer lost sales. Many companies are therefore re-engineering their operations to take advantage of these benefits.

   Example. Nowadays, General Electric incurs approximately 35,000 defects per million opportunities, a little better than the U.S. industry average. A major company initiative known as six-sigma is currently underway to reduce the rate of defects by a factor of 10,000. Moving GE to this new mode of operations is expected to save the corporation billions of dollars per year.

Marketing and Management Factors

From a marketing and management standpoint, the development of modern engineering systems is challenged by:

1. Fast Time to Market Critical.

   For many products, fast time-to-market is a critical element of success because it maximizes market opportunity,

2. Vague Mission

   Believe it or not, large projects are sometimes conducted in the absense of a well-defined mission.

   Example. The June 1996 issue of Scientific American features NASA's Space Station (Beardsley, 1996). Staff writer for Scientific American, Tim Beardsley, writes ``the $27-billion international space station will not do many of the jobs once conceived for it. Industrial interest in it has ebbed. Uncertainties in Russia's commitment jeopardize its mission. Next year NASA will start building it anyway.''

3. Support for Extended Project Duration

   Most U.S. companies operate on a product life-cycle of perhaps 1 to 2 years. For those projects having a duration of more than a decade, long-term management of requirements, and changes to personnel and budgets become a significant challenge. A fourth important ingredient is the ease with which a project can easily incorporate new technology.

   Example. A pivotal component in the US Global Change Research Program is NASA's Mission to Planet Earth Project (MTPE). MTPE will employ space and ground-based measurement systems for the monitoring of planet Earth on a global scale over a 15 year lifetime.

4. Ability to deal with Changing Requirements

   Details coming soon ..... read and insert material from ENSE 621 notes.

A central question in the development of engineering systems is: ``Can a satisfactory functional design (what to do?) be realized by an available technical solution (how to do it?) for an acceptable price (who to do it?).'' Unfortunately, too often the answer is no! System deliveries are often behind schedule and over cost. Sometimes these systems will fail to meet the customers requirements, and are so unreliable that constant maintenance is needed. Poorly structured systems are difficult to enhance and maintain.

Projects fail for many reasons. The following findings are based on observations of 17 projects in the manufacturing, telecommunications, consumer electronics, and aerospace industries with budgets in the range $4.5 - 17.0 million. Difficulties in systems engineering projects are most likely to occur from:

1. Thin Spread of Application Domain Knowledge

   A thin spread of application domain knowledge means that systems are often developed without a thorough understanding of the relevant principles, characteristics and domain behavior. The associated "accidental" complexity can be minimized (in part) with appropriate domain-specific analyses.

2. Fluctuating and Conflicting requirements

   As the saying goes, the only constant in life is change. Systems engineering methodologies and procedures need to be flexible enought to handle fluctuating and conflicting requirements.

3. Communication and Coordination breakdowns

   Communication and coordination breakdowns are a fact of life. People and machines may not be able to communicate because the speak different languages, have different areas of expertise, have different definintions for the same term, and sometimes, cannot describe their thoughts in a manner that is precise and succinct. Points to note are as follows:

   1. Tools cannot be relied upon to overcome team and organizational problems.
   2. Writing code is not the problem -- understanding the problem is.
   3. Education of people is often neglected.
   4. Sometimes there are many customers in a project -- this can lead to fluctuating requirements.
   5. Often customers will not understand cost and trade-offs.
   6. Contractors may be forced to assume requirements?
   7. Programmers/designers often add functionality that is not needed.
   8. Projects sometime feel the absence of ``a mission.''

In an effort to avoid pitfalls of this type, and remain economically competitive, an organization may find itself addressing the following issues:

1. Can a better design process be designed? Better usually means improved quality, reduced life-cycle costs, and shorter development times.
2. What information is needed and when so that concurrent design of products and processes can proceed rapidly and with confidence?
3. What design tools are needed to support those parts of what designers do that is truly difficult? Do these tools even exist?
4. What questions would the tools answer, and what information would they need?
5. What cultural, human, and organizational changes are needed to make the ``better design process'' work?

The systems approach to problem solving aims to minimize the possibility of these shortcomings (and result in a design that balances the best interests of the system as a whole) by providing a systematic means of attacking problems in the engineering of complex systems.

The adjacent figure is a high-level flow diagram of activities we will consider in assessing whether a systems engineering problem is suitable for automation. The two most important stages in the models-to-tools pathway are (a) understanding the problem, and (b) simplifying the problem.

Step 1: Understanding the Problem

Here is a list of things to keep in mind when trying to understand what makes a system work (Kronlof 1993; Thome 1993):

1. View the System Whole as more than its Parts.

   The systems approach should support different points of view (e.g., human factor, economic, performance and maintenance requirements), and pay careful attention to interactions among different parts of the system. Making rational decisions involving trade-offs among competing criteria necessities formal analytical techniques for systems analysis and design.

   A system is often characterized by the nature of its interfaces, the relationships among interfaces (e.g., hierarchy, network, layered), and the traffic across them.

   Optimization of the system should occur as a whole, rather than simply at the part level.

2. Recognize that Complex Systems are Multifaceted.

   Most systems engineering problems need to be attacked from multiple views (or perspectives) and with varying levels of detail.

   Recognize that complex systems are often a composition of entities (e.g., information, hardware, software, materials etc..).

   Most systems may have emergent properties -- for example, in chemical processing plant, two chemical components may react to form a new component.

3. Follow an Integrated, Flexible, but Controlled Process.

   Be prepared to adjust the ordering of steps in sequence, selection, concurrencies and iteration to suit the specific engineering product. Trade-off analysis may be needed for systems whose performance goals, specifications, and requirements are conflicting.

   Problem solving procedures should consider design alternatives. Appropriate representations (i.e., models and their views) and notations should be used for each step of the system's development. Try to use networks instead of simple cause-and-effect chains.

4. Try to Solve Problems at a High Level of Abstraction.

   Problem solving procedures should employ abstractions as a means of controlling complexity, and work at the conceptual level for as long as possible (before making technology-specific decisions).

Step 2: Simplifying the Problem

The need for problem simplification is due in part to the limitations of today's computer programming languages. Before software can be written to support a systems engineering process, the process itself must be simplified to the point where it can be described unambiguously using a relatively simple language.

Strategies for simplifying a problem include a careful analysis of the system ``as is,'' the elimination of non-value added steps, and the use of theories and methods that will help us understand how these activities come together. Kronloff (Kronlof, 1993) points out that the methods should contain:

1. An Underlying Model.

   The underlying model refers to the ensemble of objects (or data types or data structures) represented, manipulated, and analyzed by the method.

   Modeling is a key element of systems engineering that helps to close the gap between "what is needed" and "how the system will work." Models represent systems through a variety of viewpoints, and analytical and visual formalisms (e.g., technical drawings; sequence and collaboration diagrams).

2. A Language.

   The language is the notation for the systems model, and acts as the user interface to the underlying model. It is a set of expressions that is capable of describing the objects in the model, and how the objects can be manipulated and analyzed. Carefully designed languages provide physical independence (or decoupling) from the underlying storage mechanisms/databases.

   The term language includes its syntax and semantics, where the syntax can take several forms (i.e., textual, graphical, or tabular). We would like the syntax to be provided in a more-or-less formal fashion, such as a Backus-Naur-Form (BNF) grammar. Semantics refer to the meaning of the symbols and expressions in a language. As such, the semantics of a language can provide support for the definition of objects known to the engineer (e.g., design constraints and specifications), the representation and manipulation of models (e.g., model synthesis and reduction), and logical decision making (e.g., truth evaluation, reasoning, and control).

   Because no single person could possibly understand every aspect of the design, a general understanding of the system will be spread across a team. Languages are needed to describe:

   1. The system functionality, including performance, concurrencies, communications.....
   2. The system architecture, including components of the system, attributes (properties of the components), and relationships (links among components).
   3. The effective communication of information among the project stake-holders, including the team developers, customers and end-users.

   Of course if the communication among the team members is poor, then the overall understanding of the system will also be poor.

3. Defined Steps (and Ordering of these Steps).

   While the language and underlying model are related to the product (or result) of the method, the defined steps refer to the activities performed by the user of the method. These activities/processes can include:

   • Transformations of the model, including representations of manufacturing processes.
   • Generation of simulation models etc...
   • Strategies for exploration of the design space, performance evaluation and trade-off analysis of design alternatives, and understanding the sensitivity of a system design to technology selection.

   Nearly all systems methods will support iteration, a good measure of the complexity of the systems being developed.

4. Guidance for Applying the Method.

   Guidance typically takes the form of collections of literature, guides, technical manuals, and so forth. It can include linkages to: computer technologies, standards for product and design process representation, and other engineering and business disciplines.

Step 3: To Automate or not to Automate?

It does not follow that just because a system has been understood and simplified, automation will be needed to improve system efficiency and reduce system costs.

One possibility, as pointed out by Baudoin et al. ~\cite{baudoin96}, is that a new simpler manual process might be sufficient to achieve the desired system improvements.

We do not mean to be glum -- projects that are wildly successful tend to be based on well established systems engineering mechanisms. They include:

1. Well-defined Processes for Systems Development.

   Everyone on the development team needs to know what they are supposed to be doing, why, and when it's due! Systems processes should be flexible enough to accomodate changes in development objectives and to account for risks in an appropriate way.

2. Effective Use of Systems Modeling Techniques.

   Systems modeling techniques are needed to understand the system behavior and system structure, to organize the development activities, and to carryout appropriate optimization and tradeoff studies.

3. Effective Communication and Coordination of Activities.

   This point speaks for itself!

Key Technical Areas

Our plans are to advance the capability of systems engineering practices by focusing on a handful of key technical areas:

1. Object modeling of systems using the Unified Modeling Language (UML) and automation of model-based system behavior simulation.

2. Semi-formal and formal languages for the representation of system requirements, system specifications, and allocation flowdown in heterogeneous (from the physical layer perspective) hierarchies.

3. Object-relational databases and multiple views (engineering and others) of system data.

4. Quantitative procedures for trade-off analysis when (mixed) Boolean and numeric variables are present.

5. Validation and verification by quantitative treatment of tolerances and convex analysis.

1. Austin M., Using EOSDIS for Education: Vision, Reality and Recommendations, Hughes Applied Information Systems Technical Report 194--00126, February, 1994.
2. Beardsley, "Science in the Sky", Scienfic American, pp. 64-70, June, 1996.
3. Campbell W.J., Intelligent Information Fusion and Management Prototype Application to EOSDIS, February 1995. Presentation to Hughes Applied Information Systems, Landover, MD.
4. David L., Keeping Earth fit for Life, Vol. 262, Aerospace, pp. 22-41, March 1995.
5. Gause D.C., Weinberg G.M., Exploring Requirements: Quality before Design, Dorset House Publishing, New York, New York, 1989.
6. Kronloff K., Method Integration: Concepts and Case Studies, John-Wiley and Sons, 1993.
7. Oliver D.W., Kelliher T.P., and Keegan Jr. J.G., Engineering Complex Systems : With Models and Objects , McGraw Hill, 1997.
8. Park J. (editor), Hunting S. (technical editor), XML Topic Maps: Creating and Using Topic Maps for the Web , Addison-Wesley, 2002.
9. Schultz A.P., Clausing D.P., Fricke E., Negele H., "Development and Integration of Winning Technologies as a key to Competitive Advantage," Systems Engineering, Vol. 3, No. 4., 2000.
10. Sterman J.D., Learning In and About Complex Systems, System Dynamics Review , 1994.
11. Thome B., "Systems Engineering: Principles and Practices of Computer-Based Systems Engineering," John-Wiley and Sons, 1993.

Developed in February 2001 by Mark Austin
Copyright © 2001-2002, Mark Austin. All rights reserved. These notes may not be reproduced without expressed written permission of Mark Austin.