Chapter 2

Systems Life Cycle and Design Processes

Let us start the chapter with a “rocks and bucket” story. There is a bucket, some big rocks just enough to fill it, some small stones, some sand, and water. Let us first fill the bucket with big rocks. Do we still have space? Yes, so we put the small stones around the big rocks in the bucket. Now is it full? We still have some room for some sand; after putting the sand in, is it full? No, we can still put water in the bucket: now the bucket is full. Now ask yourself: What can you see from this story? Someone might say that you can always have room for smaller things. While this might be true to some extent, for us systems engineers, the point we get from this story is that for us to fit all the things (big rocks, small stones, sand, and water) into the bucket, we have to follow the order in the story. If we put the small things into the bucket first, in the end we will realize that there is no way we can fit all the big rocks into the bucket. This order is analogical to the fundamental philosophy guiding the system engineering process: top-down processing.

The whole idea of systems engineering is the implementation of a top-down process; that is, starting from a problem or a need, it gradually evolves from a design concept to a tangible system that can be used. The key issue in a top-down systems engineering design process is a big-picture perspective; that is, designing the system from a life cycle perspective. Nothing lasts forever; everything has a life span. Just like anything else in the world, an engineered system also has a life cycle. Utilizing the big picture means that we have to consider everything involved in the system life cycle from the very beginning of the system design, doing things right in the beginning, even on issues related to the system’s retirement. They need to be considered in the design phase, as design decisions in the early stages can have a significant impact on the system’s performance later, even on the system’s retirement. One of the most important factors in systems design is change or violation of design needs. It has been found that a large percentage of costs incurred in systems design is due to changes in the later design stages. Although, for any system, it is inevitable that change will occur, since unexpected and random events happen all the time, systems design must have the ability to accommodate such an environment; however, controlling and minimizing those changes can significantly reduce the complexity and cost of the whole design process, as the later the change occurs, the more expensive and difficult to implement it becomes. Having a big picture at the beginning of the design process helps us to keep the design changes at a minimum level. The second issue for systems engineering is that it is process oriented; in other words, the process determines the success of the system. Every system starts with a need and it gradually evolves to its final forms through a structured, well-defined process. There is no guarantee that a good process will lead to a good product, since many unexpected issues will occur during the process; however, a structured process will provide the greatest probability of success for bringing the system into being within its cost and time limits. After many decades of practice and implementation, the systems engineering process has been proven to be the most effective and structured approach for designing systems successfully, especially for large complex systems, and it is believed that it will still be the philosophy used for complex system design in the foreseeable future. In this chapter, we will

• Provide an introduction to systems’ life cycles and describe the major forms of systems at different stages of system life cycles.
• Describe the elements that are involved in the system design process, including system need, requirements, functions, components, prototypes, models, and their relationships with regard to different phases in systems’ life cycles.
• Describe the system engineering process and define the main objectives for each of the phases in the design processes, including the main design activities, major milestone baselines, and product for each of the phases, and the design evaluation approaches applied in each of the phases.
• Review the most common models for the systems design process, including the waterfall model, vee model, and spiral model, and their unique features for different types of systems.

2.1 System Life Cycle

“Life cycle,” according to Webster’s Dictionary, refers to “a series of stages through which something (as an individual, culture, or manufactured product) passes during its lifetime.” Almost everything has a life; even the sun on which our planet Earth relies has a life of approximately 14 billion years, starting from a large cloud of dust and gas 5 billion years ago, to become a giant red star in another 5 billion years, and eventually a black dwarf approaching the end of its life.

The life cycle of an engineering system is a sequence of stages/phases in the life of the system. It is the life span or history of the system, from the need to create the system to the point that the system is retired and removed from service. There are some variations among different people regarding the naming of the systems life cycle; for example, Clark et al. (1986) defined systems life cycles as stages of “planning, definition, design, integration acceptance, delivery product”; Blanchard and Fabrycky (2006) used the terms need identification, conceptual design, preliminary design, detailed design, production and construction, utilization and support, and systems phase-out and disposal. Some of the life cycle definitions, such as the ones from Blanchard and Fabrycky, are more like a design process, expressed from the designer’s perspective. Here I adopt the one from Chapanis (1996), as it concentrates on the system’s status and format at different life cycle stages, rather than focusing solely on the design activities. Before we get into the life cycle description in detail, there are two fundamental characteristics of the systems life cycle that need to be brought to the reader’s attention. Firstly, any system starts from a need; this need determines the system’s concepts. From the concepts, system functions are derived, decomposed, and allocated to the system’s components—hardware or software—all the way to its final configuration: developed, constructed, and delivered. All the different stages of the systems life cycle and different forms of systems are driven by the initial needs. Secondly, from the first characteristics just mentioned, one can easily see that the system evolves from a general form to specific forms. This evolvement is a top-down process, starting with the big picture—the need for the design of the system—with further details added in the various life cycle phases. In the following section, we will describe the major phases in the system life cycle; these life cycle phases summarize a common form for most systems. Despite the fact that different systems have different variations of these forms, the fundamental phases should be similar. Generally speaking, the system life cycle consists of seven major phases: (1) the operational need for the system; (2) system concept; (3) system concept exploration and validation; (4) engineering model development; (5) systems production, deployment and distribution; (6) systems operation and maintenance; and, finally, (7) system phase-out and retirement. We will briefly discuss, in each of the system life cycle phases, what the basic format of the system is, what major questions are being addressed, what information it will include, and what major system outcome is expected for these life cycle phases.

2.1.1 Operational Need

A system starts with a need; a need gives the reason for such a system—that is, why does one need such a system and what is needed—at a very high level. Needs come from customers. There are two basic types of customers involved in systems engineering (these are not exactly the same as the system users; we will talk about system user classes in greater detail in Section 2.2.3). One type is the government agency; for example, the Federal Aviation Administration (FAA) may want a new flight management system (FMS) to be developed, based on the electric flight bag (EFB) devices to integrate four-dimensional (4-D, spatial plus temporal) flight data into the cockpit. Government agencies such as the FAA and Department of Defense (DoD) play an important role in prompting systems engineering, as most of the systems they need are large and complex, and often have a tight budget and schedule. These government systems usually have more strictly defined structures and specifications; for example, for the DoD, a commonly used structure is Department of Defense Architecture Framework (DoDAF): this is a foundational framework for developing and describing systems architecture that ensures a common denominator for communicating, understanding, comparing, and integrating architectures across different organizations for DoD-related systems. DoDAF establishes data element definitions, terminologies, rules, relationships, and a baseline for consistent development of military systems architectures.

The other type of customers are nongovernment customers, either commercial or nonprofit related. Systems or products needed for this type of customer vary a great deal in terms of scope and complexity, and compared to government customers, their needs are usually less structured. For example, a marketing survey found out that U.S. customers need a new type of hybrid vehicle that uses environmentally friendly fuel, and in addition, need to be able to use household electricity to charge the vehicle, due to the rising price of regular gasoline. In areas that lack electricity, there is a need for a solar-powered portable water purification system, to provide drinking water for a certain number of people daily.

Systems needs originate from different sources; for government systems, the needs are usually generated from national strategic decision-making, and documented and distributed by a request for proposal (RFP). RFP is a formal invitation document, distributed to the prospective firms or academic organizations, to describe the needs for the system to be developed, and inviting the qualified organization to propose a systems development plan. Based on the RFP, potential developers will respond with a structured proposal, describing the system in a more technical and operational form, and propose a solution and plan for the system. The successful bidders will be required to develop a detailed work plan—namely, a statement of work (SOW)—to illustrate the technical and managerial aspects of systems development, including the personnel qualifications, efforts, and the major timeline and budget. The detailed information included in the RFP and SOW will be explained in Chapter 3.

For nongovernment customers, the need for a new system or product originates from organizational strategic planning. Strategic planning for a new system or product emerges from a number of sources, including marketing surveys and customer feedback/complaints, changing environments, new technologies and new resources, depletion of old resources, and so on. Unlike government projects, in which a strict documentation format has to be followed, in nongovernment projects, the operational need is developed internally and does not usually have a unified format which must be adhered to. Regardless of what type of systems are developed, one cannot depend solely on customers’ original views as the only source, as these are often vague, incomplete, and too general. That is why one needs to have an operational need. Information from a variety of sources needs to be compiled and translated into one document, describing the system’s intended purpose and functions. The following example illustrates typical operational needs:

1. Introduction: This section gives the background and scope of the systems to be designed/requested.
2. Missions: This section defines the highest level of mission that this design tries to accomplish. Missions may be broken down into specific phases and time periods if required.
3. Technical objectives: This section defines the major functions required for the system to be designed. Major function performance parameters are included for these functions. These functions/parameters may be accompanied by technical performance measures.
4. Constraints: This defines the time/cost restrictions on the project and the major milestones and deliverables required.

A sample technical need document can be seen in Table 2.1.

2.1.2 System Concept

After the operational needs are identified, an integrated systems concept will be developed. This concept is illustrated by a conceptual model. A model is the abstract representation of the real-world object; it focuses on the factors most relevant to the system needs, conveying the important relationships between these factors, and ignores nonrelevant factors. For large complex systems, using appropriate models is of the utmost importance, as there are usually hundreds or thousands of factors involved in the design. For the most part, this book is about the models used in systems engineering. We will explore different types of systems engineering models in Section II. The philosophy of systems engineering can be considered to be model based, as models are an absolute necessity in all aspects of systems engineering design. The conceptual model is the first model that the system evolves from its need. In the conceptual model, systems needs are organized as requirements. Requirements are formal documents that define the system’s intended purposes. From the requirements, operational concepts will then be developed. These depict a complete picture of the systems operations. Operational concepts are commonly written in narrative format; sometimes they are also called operational scenarios. Scenarios tell a complete story of the system’s intended activities, if designed and developed, and how it will be utilized by its operators/users. The following example shows a typical scenario for using an automated teller machine (ATM):

The customer (including walk-up and drive-through customers; they may also be visually and hearing impaired) requests service by pressing the start key or by inserting their debit card. They receive feedback from the ATM that their request was accepted. The ATM system reads the card and requests the PIN. The customer inputs their PIN and the system processes it; if the PIN is correct, the ATM proceeds to the next selection menu. If the PIN is not correct, the ATM provides feedback and goes back to request the PIN again. If this process is repeated three times, then the ATM blocks the card and provides feedback.

To better explain the system scenarios, some other format of the operational profile can also be developed to accompany them, to give a more comprehensive picture of the system concepts. This profile includes a graphical representation of the systems operations spatial profile, a timeline of the operations temporal profile, a chart of user/operator characteristics, and an interaction diagram to illustrate the exchange of information, materials, and energy flow between users, systems, and the environment. We will describe this in depth in Chapter 3, which is about systems requirement analysis.

As an immediate result of systems concepts development via the methods mentioned above, systems evolve to a conceptual functional model. System functions define the purpose of the system and illustrate what actions the system would perform to accomplish its purposes. The concepts of functions are developed to give a complete picture of the system’s intended actions, hierarchically and operationally. It defines what the system should do to accomplish its requirements and to fulfill customer needs. Functional analysis is one of the most important systems analysis methods, as it serves as the first and most critical bridge between customer needs and the system’s technical specification. Functional analysis will be covered in great detail in the systems engineering process sections and in Chapter 4.

2.1.3 Systems Concept Exploration and Validation

Systems concepts, represented by system functional models, need to be further explored in terms of their validity to the system requirements. System concepts are explored and validated by translating the conceptual functional model to the allocated components model. A component allocation model is built to verify that, firstly, the conceptual model is feasible to be implemented by systems components, including hardware, software, and human operators. It is a two-way process, in the sense that the conceptual model needs to be adjusted to make the physical allocation feasible, taking into consideration the availability of the current and emerging technology; on the other hand, the functional model serves as the basis for the selection of the components, as there are many candidates for these, with a large variety of suppliers, manufacturers, and different models involved. The decision-making process for the translation from conceptual model to physical models is iterative and requires a careful consideration of all the requirements and their parameters. That brings us to the second verification in this phase, which is that systems requirements are verified by the physical models. You might have seen, on several occasions, that we have used the words verification and validation; you might wonder whether these two words are the same? If not, what is the difference? In the systems engineering context, “verification” and “validation” are related to each other but do not convey exactly the same meaning. The verification process is to make sure the systems requirements are being met at different phases in the system life cycle; that is, the systems requirements are translated, carried over, implemented, and materialized throughout the system life cycle. Systems requirements are traced through this translation, and the design models are verified against the requirements parameters by using reviews and tests at different stages; sometimes, users are also involved in the tests and reviews. Validation is similar to system demonstration or evaluation: it is to make sure the design outcome is what users want, and that we are designing the correct systems. So, briefly summarizing the two terms, verification means doing things right, following the systems engineering process and structure, while validation is to make sure we are making the right thing, providing the correct outcome for the users’ needs. These two activities go hand in hand, and are closely related to each other; without a good verification plan and process, there will be no valid system to be designed.

In the systems exploration and validation phase, systems evolve from the conceptual model to the physical allocation model, represented by the system allocation baseline (Type B system specification). The allocation baseline answers the question of who will perform what function at what cost. One has to keep in mind that the process is iterative; the allocation models of the systems are reviewed, and usually systems users are involved in this review process.

The allocation model usually includes the following items:

• Systems requirements for subsystems and components, refined and quantitative technical performance measures for functions, including the input, output, and constraining factors for each function
• Functional package and assembly lists, including systems components lists and preliminary configurations for the components
• User systems interaction requirements
• Design data, validation and evaluation documentation, including the faulty tree analysis (FTA) and failure mode and effect criticality analysis (FMECA), human factors tasks analysis, and computer-aided design data

2.1.4 Engineering Model Development

Based on validated system concepts, functional models, and allocation baseline, the actual components are procured and assembled. This is the point at which all the components are integrated together and, for the first time, the system is in its intended form, not only functionally but also in its physical configuration. To obtain a complete and detailed system configuration, the systems specification is translated from what (functions) and who (allocations) to how and how much. Details of systems components are specified, including the systems component/assembly specifications, what materials are involved, and how to assemble them together. The system evolves from the functional allocation baseline (Type B specification) to the product baseline (Type C specification), material baseline (Type D specification), and process baseline (Type E specification). There are various types of documents involved in the engineering model, based on different types of systems. Generally speaking, the model usually consists of the part list, material lists, blueprints, computer-aided design data (such as AutoCAD and CATIA design drawings), and specifications for the interfaces between components. Since this is the first time that the all the components are integrated in their actual design forms, the system will be tested iteratively to verify that the derived physical models meet the system requirements. These tests, usually conducted formally with users and stakeholders involved, are intended to identify the last-minute problems before the system is produced, distributed, and deployed. Necessary changes are made to the models if any mismatches between the physical models and system requirements are found, trade-off analyses are carried out to balance out different options, and changes are monitored and strictly controlled in order not to cause any major time delay and cost increase. Minimizing changes is one of the most important objectives for systems engineering. But, due to the complexity of system design, changes are often inevitable. Systems engineering tries to identify and address the changes as early as possible, which is why traceability plays an important role in the life cycle. Different system formats are interconnected, and the evolvement of different models from one version to another is supposed to be requirement driven, to minimize any deviation from the right track. We will talk about change management in the detailed design phase later in this chapter. Here, it is important to point out that managing changes efficiently is an essential aspect of the development of physical system models.

2.1.5 System Production, Distribution, and Deployment

After the physical system model has been built, tested, and finalized, the system will move to the next life cycle phase, which is full-scale production, distribution, and deployment. The system is in its final format, and is transferred to the production assembly line to start formal mass production. At this stage, the system is produced, possibly in multiple copies. All the components are specified, either produced separately if they are specially designed for the system, or procured if using standard commercial off-the-shelf (COTS) items. These components are delivered to the production site, assembled, and then distributed via retail outlets to customers. A final production of the system may involve hundreds or thousands of suppliers, depending on the level of complexity of the system. The supply chain plays an important role at this stage, as greater cost may be incurred in distribution and deployment than in the production/assembly itself. Much of the system’s assembly work may be outsourced internationally; for example, to take advantage of cheap labor and materials locally. For instance, the cost of labor and materials of many U.S.-designed systems in third-world countries, such as China, is less than 10% of the total cost of the system. As a matter of fact, the majority of the cost is incurred in system distribution and deployment, in addition to the cost of research and development. The system has now evolved from its models to the final realization of its designed format, together with its supplemental materials including manuals and training services; it is delivered to customers and installed for operations.

2.1.6 System Operations and Maintenance

After the system has been produced, assembled, and delivered to the customer, it will be in fully operational mode for the period of time designed, providing functions to users and operators. Users and operators are usually the same group of people; the difference between these two lies in the complexity of the system itself. If the system is fairly simple in nature, the term users, that is, the user–equipment combination, is employed; if the system is very large and complex, the term operators is used instead. System users and operators essentially represent the same type of user class; namely, the end customer of the system. There are also other classes of systems user; systems maintainer is one of the classes. Although highly reliable systems are desired, systems do fail sometimes, requiring maintenance activities to be carried out. At this stage of the system life cycle, the emphasis is on customer service and support of the system; since the design of the system has been finalized, no further design changes are possible. However, follow-up tests and evaluations of systems are still necessary to identify any problems within operations and maintenance; these test results, together with feedback from customers, serve as a guide for any engineering changes that may be made for the subsequent version or next generation of the system. Emerging problems are addressed and fixed immediately, especially those pertaining to user safety and hazards. Faulty systems are fixed, recalled, or replaced to minimize the impact from these issues. At this stage of the system life cycle, operation, maintenance, and evaluation efforts are carried out continuously, until the system is ready to be retired.

2.1.7 System Phase-Out and Retirement

There are many reasons for system retirement; the majority of these are incompatibility with emerging technology, discontinuation of supply of materials, changes to legislation and regulations, new trends in customer demand, and so on. At the system retirement stage, the system is often characterized by a reduction in the number of customers, increasing numbers of system problems, high costs, and difficulty of maintenance. System functions are terminated and the system is disassembled to the level of its components; the system is disposed of. The natural resources from which the system is built are limited, so it is unlikely that the system will be completely discarded and wasted; it is desirable to retrieve materials from retired systems as far as possible, to save the cost of the materials, and more importantly, to reduce the amount of waste to the environment. Sustainable development or green engineering is one of the most important types of development, depending on the different kinds of components. There may be different end uses for the components: reuse, remanufacturing, or recycling. Reuse is the highest level at which a system is preserved—usually a nonfaulty system—to keep it at a degraded function level to prolong its life cycle (one can think of this as a semiretirement phase). For example, older computer systems may not be fast enough for laboratory scientific computation purposes, but since they are still functional, they may be donated to charity for educational purposes in schools and offices. Remanufacturing (also known as closed-loop recycling, or sometimes called refurbishing) implies a series of activities to put a retired system back into use in its complete form, by repairing or replacing faulty parts, to become operational again. Recycling is a process that retrieves useful raw materials, to reduce waste and the cost of procuring similar fresh new materials. It is believed to benefit the environment by reducing pollution and saving the energy consumption of obtaining new materials. Although a common practice for a long time, it did not catch people’s attention until the twentieth century; as an outcome of the industrial revolution, productivity has increased tremendously, as has demand for materials. With more human-made systems, the by-products, waste, and pollution from the production process has influenced our natural environment, which has caused many problems for human health and quality of life. Sustainable development and green engineering of systems have become more and more important for assessing their effectiveness. With more customer awareness and globalization of system development, green engineering has become an essential part of system competitiveness. The life cycle consideration of system design enables designers to take systems retirement into account in the early phases of the design process—assembling it in a way which will simplify its disassembly—to facilitate the system being phased out and retired, to impact the environment at a minimum level, and meanwhile save internal costs and energy.

Where the system is retired only partially, its materials will be recycled or reused for the next generation of the system and some of the concepts will be carried over to the next generation, as part of the requirements for the new system; at that time another life cycle will begin.

2.2 Systems Engineering Processes

2.2.1 Definition of Systems Engineering Process

Parallel to the system life cycle, there are a series of activities that bring systems into being; this series of activities is called systems engineering processes, or more specifically, system design processes. According to INCOSE.org, the systems engineering process is comprised of seven typical tasks: “State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re-evaluate. These functions can be summarized with the acronym SIMILAR: State, Investigate, Model, Integrate, Launch, Assess and Re-evaluate” or SIMILAR.

Chapanis (1996) also defined systems design as a seven-step process in his process model: “Requirement Analysis, Systems Design, Hardware and Software Design, Hardware and Software Development, Systems Integration, Installation/Transition & Training, and Maintenance & Operation”; the three strands of development hardware, software, and users are woven together into one integrated system. Blanchard and Fabrycky (2006) defined the systems design and life cycle as a process with two major steps, the acquisition phase and the utilization phase; the acquisition phase consists of conceptual design, preliminary design, detailed design and development, and production and construction; the utilization phase consists of product use, phase-out, and disposal. There are many other variations of the processes. Despite the different names for the various phases, they all share the same characteristics, which can be summarized as follows:

1. The system engineering process is requirement driven. Systems design starts with identification of the need; the need is the problem statement that the system is designed to address. Once this need is identified, system requirements are derived and these requirements are tailored throughout the system design processes, from the beginning to the end of the whole process, from concept exploration until the system is retired. ‘Requirement driven’ is the key element for the system engineering process; requirements are the guide for the design.
2. Systems design follows a general-to-specific evolvement process. The top-down systems’ requirement-driven features imply that systems evolve from general requirements to specific functions and components; this process is to ensure the system is designed in an effective and efficient way, by having a big picture first to guide one through the process. Through test and evaluation, the requirements are traced, confirmed, and translated to detailed design specifications.
3. System design activities are iterative in nature; there is no clear cut between design activities and the system design process is by no means a linear manner. In any design process, one can expect the cycle of design-verification-modification to iterate many times until the design outcomes are validated and approved. Chapanis (1996) also calls this a 3D process: define-develop-deploy; Blanchard and Fabrycky (2006) used the circle of analysis-synthesis-evaluation to illustrate this iterative process.

Generally speaking, systems engineering design is an iterative, top-down, and need/requirement-driven process, to gradually translate the high-level general system needs and requirements to specific technical system parameters, so that the system can be developed, assembled, installed, and delivered for operations, in a well-managed, tightly controlled, cost-efficient manner, and within cost limitations. We adopt the terms by Blanchard and Fabrycky (2006) for the major design activities for the process: conceptual design, preliminary design, detailed design, systems development and construction, systems operations, and maintenance.

2.2.2 Basic Concepts and Terminologies for Design Process

Before we get into the details of the system design processes, it is necessary to define some of the terms for readers to understand the material hereafter, as these terms are general in systems engineering and they will be used quite frequently throughout the book. Also, we have listed a comparison of these terms with those being used in some systems engineering management tools; for example, CORE. Since we will be using CORE to illustrate the examples, we are comparing the CORE terminology with general systems terminology definitions, for readers to better understand those examples.

• Requirements: A requirement is a single formal statement containing shall to define a need that a system must provide or perform. It has the following syntax: system (or subsystem or component) + shall + verb + noun (i.e., provide a specific function) + (applicable parameters to which this requirement pertains) + (applicable environmental or contextual information for the requirement). For example, “the portable water purification system shall be able to purify at least two gallons of water per minute.”
• Functions: A function is a specific action or activity that a system does or provides; it is a meaningful purpose for which the system is developed or designed. Since it is an action, a function usually contains a verb. The common syntax for a function is verb + noun. It is easy to confuse functions with tasks; especially for novice designers, it is a common mistake that user tasks are sometimes defined as functions. For instance, in ATM systems, “deposit cash,” “deposit check,” and “transfer funds” are all ATM functions; but “insert debit card” and “key in passcode” are user tasks, not functions. One has to keep in mind that tasks support functions; any user task should relate to one or more system functions—in other words, without a function, there are no tasks. That is why functional analysis of the system usually comes before task analysis. Information on functional analysis and tasks analysis will be given in greater detail in Chapter 4.
• Components: Components are what constitute the system; they are the elements of system construction. A system may have different kinds of components. Generally speaking, system components consist of three basic types: physical components—the hardware to build the system; electrical and computer software components—the software of the system—namely, the programs and codes that control and regulate system operations; and lastly, human components, sometimes called livewire. Humans can be important components for some systems; their interaction with hardware and software are essential for the carrying out of the system functions. There are different levels of human involvement in systems; we will be describing the user classes in Section 2.2.3.
• Input/Output: As the dynamic entities of the system, system components need input to perform their functions; and since components are connected to each other, some components may, in the meantime, also generate output to some other components; these inputs/outputs may be materials, energy, information, or actions.
• Baseline: In systems engineering, a baseline is a basis for evaluation; it is a reference point for system design to be evaluated. At certain stages of systems design, to verify that the design meets the system requirements, one needs to conduct tests and evaluations to make sure the design is on the right track; these are conducted on the intermediate results of the design, which are referred to as baselines. For example, after function analysis, the functional baseline (also called Type A specification) is developed, which contains the functional models of the system. When functions are analyzed and allocated to components to perform the functions, the allocation baseline (also called Type B specification) is derived. When the design progresses to more detailed information, the production configuration (product baseline, or Type C specification), the manufacturing and assembly process (process baseline, or Type D specification), and the material baseline (Type E specification) are developed; the system can be built in its final form and verified/validated against the requirements. To some extent, system design is a process of translating user needs to requirements, and then different specifications/baselines of the system can be constructed/developed. The information pertaining to design baselines will be visited again in greater detail in Section 2.3.

Table 2.2 compares some of the basic terms that are used in CORE with general systems engineering terminology. We list the two sets of basic terms side by side so readers can have a clear understanding of the terms utilized in CORE, and use the correct terms in their applications.

Figure 2.1 illustrates the relationship between CORE concepts; these relationships can be easily established within the “relationship” tab in CORE. A more detailed description of the application of CORE in the systems engineering process is included in subsequent chapters (Chapters 3 and 4). We wish to provide an overall view first in this chapter.

2.2.3 Systems User Classes

Not only are humans an inherent part of the system, human components also play a vital role in the success of the system mission. Throughout the system life cycle, there are different kinds of human involvement in the system at different levels. It is difficult to provide a clear-cut classification of the different human roles in system development and operations; especially for a system with high complexity, it is not uncommon to have multiple tiers of human users related to every aspect of system design and utilization. Roughly speaking, there are basically three levels of user involvement within the context of systems engineering:

1. System users/operators: Also sometimes called customers, system users can be further divided into two categories, direct end users and indirect users. The term end users is easy to understand; these are the people that interact with the system directly. Chapanis (1996) also argued that different names should be used for this category; users refers to small-scale systems, such as a tool, consumer product, or equipment—for example, a micro-computer system user; for large complex systems, such as military aircraft systems or unmanned aerial vehicle ground control systems, people whose use these type of systems are called operators. Besides end users/operators, there are also people who do not directly interact with the system; however, their opinion will impact the end users so much that they cannot be neglected—for example, family members of end users, or managers or supervisors of operators. These indirect users play a significant role in influencing users’/operators’ decisions and behaviors; their needs constitute a major part of the system requirements.
2. System maintainers/supporters: Another group of humans involved in the system design and life cycle are those who maintain and support the system. The system has reliability, but sometimes it might fail; this implies that the system needs to be maintained and supported, both from a preventive and a corrective perspective. The system’s life cycle cost and operational effectiveness also include maintenance efficiencies. This, in turn, requires that the system design also needs to consider the system maintainers’ requirements. As part of the system requirements, the system design should also make maintenance activities easier and more efficient, including indication of the problem area for easy identification of the failure, ease of accessibility for faulty components, standardized tools, equipment and components used in the design to facilitate the maintenance, and so forth. Design requirements for system maintainers’ needs should be considered and specified in the early design phase, as they also have a major impact on the system configuration in later stages.
3. System designers: These are the third class of human involved in system design and include the systems engineering team members and related system management personnel/administrators. System designers are those who bring the system into being; the system design’s focus for this group of users is the documentation of the design. In other words, how does one manage a systems engineering project so that coordination and communication among team members are smooth? For a system with a high level of complexity, there are easily hundreds, even thousands, of people involved in the design, and communications are often not synchronized, as the team members may be distributed all over the world. Traditional, paper-based documentation may not be sufficient to handle the high volume of data. The design should follow a unified standard. Systems engineering is itself about the structure of the design; it is about following procedures to make sure things are done correctly from the beginning. Current systems engineering projects are usually managed by computerized software to provide real-time coordination, prompt responses, and efficient communication, strictly controlling changes and precisely tracing design efforts. It will also provide some basic analysis modules to analyze the data. For example, Microsoft Office, CORE (VitechCorp), and DOORS (IBM) are among the most popular commercial systems engineering management software available.

2.3 Systems Engineering Design Processes

The systems engineering design process can be thought of as a translation process or transformation process. It translates system needs into well-structured systems requirements, and through systems modeling, analysis and synthesis, transforms the general requirements to quantitative system specifications and parameters, so that the system evolves from general concepts to a concrete design configuration. The system can then be easily produced or constructed. This process is to make sure the translation of general system needs to specific system configurations are controlled and kept on track, while at an optimum level of design efficiency. The design process for most systems are quite similar, generally speaking; the design process (or system acquisition process) consists of stages of conceptual design, preliminary design, detailed design, and production/construction. The basic methodology involved in the design process can be summarized in three words: analysis, synthesis, and evaluation (Blanchard and Fabrycky 2006). System analysis studies the needs, the environment, system functions/structure, and the proposed solutions to the design problem; and selects the optimum design concept. The concept is continuously evaluated and verified; the validated design concept is implemented by integrating and balancing the other factors from the system environments. This process is iterated at different levels at different design phases. The design progresses as the cycle of analysis-synthesis-evaluation evolves to a more detailed level.

The actual process involved and implementation of design might vary from one system to another, depending on the nature, type, and complexity involved in that specific system, but the fundamental principle underpinning all the designs are essentially the same, which are top down and systems requirements driven. Here, we present a rather general framework of the systems engineering design process, illustrating the purpose of each stage, main design functions achieved, major design activities performed, commonly used design approaches, design products/data outputs, and major design reviews/evaluations conducted.

2.3.1 Conceptual Design

Conceptual design is the first step in the systems engineering design process, yet it is the most important step for the overall process. In the conceptual design phase, the focus is on requirement analysis and elaboration. In the conceptual design stage, the problem statements of the system are defined as requirements. As the sources for requirements, system needs are collected and captured, then analyzed and compiled into one comprehensive requirements document. System operational requirements are defined in the requirements document; this document provides a rationale for the system design, explaining why the design is necessary. For a design to be carried out, not only must it be necessary, but it also needs to be feasible. Based on the systems requirements, systems design concepts are explored, in conjunction with system feasibility analysis. The design concepts are realized by the output of the conceptual design, the functional model of the system. Functional models are evaluated and the first formal design specification, the functional baseline, is generated.

In the conceptual design stage, the major design activities include

• Identify system users and system needs; this could be a new need or one to correct a deficiency of a current system. Translate user needs into a formal definition of system requirements.
• Conduct feasibility analysis to identify the technical, social, environmental, and economic issues for the system design approach; work out a feasible course of action plan for system design processes.
• Develop system operational requirements that describe the system functions and their contextual information. These requirements should include the normal system functions as well as the system maintenance and support concepts for the normal functions. Technical performance measures (TPMs) for these functions are also defined for these functions at the system level.
• Accomplish a system-level functional analysis, defining the hierarchical structure of the functions and the operational relationships between the functions.
• Perform a system-level analysis and trade-off studies, using a number of systems analysis techniques and models.
• Produce the Type A specification of the system, which is the functional baseline, documenting the results for the above activities.
• Conduct the conceptual design review.

Through the above steps, the system needs are translated into a set of operational requirements, containing the information necessary for the designers beginning to explore design concepts, in terms of what functions the system will provide. These requirements also contain quantitative parameters, enabling the design to be verified against the requirements.

2.3.1.1 Identification of Needs

A system starts with a need, a desire, or a want. In the system life cycle section earlier in this chapter, we have introduced the first very life cycle format of the system as the system need. This need could be a new function, a new product or an improvement of an existing product based on current system deficiencies. Usually, system needs come directly from customers, through interaction with them, including customer feedback and market surveys. Commonly used methods for this include questionnaires, interviews, observations, critical incidents, and accident studies. The needs could also result from strategic mission planning for government customers (such as DoD and FAA system acquisition). Depending on the different sources, needs may originate in different formats; some are narrative, some are graphical. It is the designer’s responsibility to integrate the different formats of the needs together to compile a unified system need document. This need document serves as a system design mission statement and a starting point for requirement analysis and elaboration, defining the overall mission and objectives for the system to be designed. If necessary, a need analysis is often conducted to define the problem statement thoroughly and completely. There is no general template or approach to follow to perform the need analysis; its goal is to define what the system should provide, not how it is constructed. According to Blanchard and Fabrycky (2006), a need analysis should provide general answers for the following questions (but not limited to these):

• What is required of the system in functional terms?
• What functions must the system perform?
• What are the “primary” and “secondary” functions?
• What must be done to alleviate the foreseen deficiency?
• When must the functions be performed?
• When must the system be constructed and delivered?
• What is the planned system life cycle?
• What is estimated system life cycle cost?
• Where is the system intended to be used?
• What frequency is the system intended to be used?

Answers to the above questions give us a big overall picture of what needs to be done, not how it is done. We must make sure we do not over-specify the needs by adding details of design solutions. It is not uncommon for designers to have initial personal thoughts on the system needs, especially those designers who are very familiar with similar, existing systems. For example, some designers might have a preference toward a certain type of technology or components; those designers may select such technology or components without exploring other possibilities. One has to keep in mind that having a solution without going through the formal design process is often premature, distorted, and biased by personal experience. Focusing on one preferred solution to the design problem may miss other options that could bring better benefits to the design. Systems engineering is about following the correct process to do things right at the beginning. Of all the philosophies of design, as we have pointed out when looking at the system life cycle, grasping the big picture is the most important one. Having a completely and clearly defined system need is often the first foundation for system success, which has not been emphasized very much historically; rather, people believe they can always “design it now, fix it later,” which has been proven to lead to many changes to design in the later stages, causing unnecessary delay and more cost.

2.3.1.2 Feasibility Analysis

Once the system needs are determined, before starting the design process, it is necessary to conduct a feasibility analysis to point out the direction of the general design approach. Feasibility analysis provides an answer to the questions “Is it beneficial to design the system?” and “Can we do it?” As part of the strategic planning for the system design, feasibility analysis provides information on the strengths and weaknesses of the organization. By looking at the potential market and customer groups, considering environmental factors, access to necessary resources, workforce readiness, and current/emerging technology, we can objectively and rationally assess the possibility of success if the design project is carried out. The commonly used criteria in assessing the system design feasibility are the cost involved and the value obtained from the design, which includes the monetary return as well as the sustainable development and growth opportunities for the organization.

Generally speaking, there are three interrelated types of feasibility that need to be taken into account—technical feasibility, economic feasibility, and operational feasibility. Technical feasibility refers to the practicality of a specific technical approach for the proposed system and the availability of technical resources, including the readiness and maturity of current and emerging technology. Since the design takes time to complete, designers are often required to look at the current technology available, and predict the technology that will emerge in the near future. Certainly, there are risks involved, since any future prediction has some degree of uncertainty. No one would have expected that HD-DVD technology for high definition video media would cease to be adopted when it first came on the market. There are occasions when decision makers need to choose the right track for the design approach by specifying what technology would be adopted in the design. Designers should be familiar with the cutting edge technology of the development of similar systems, and grasp the pulse of the technology developed in the field. Compatibility and flexibility are two key factors for technology selection. The story of Wang Laboratories is a good example of and lesson about not conforming to common technology and standards. As another example, as a trend for mobile devices, the 4G network has become more sophisticated and affordable; many designs of mobile devices will consider this technology as a possible solution for certain network systems applications. When computer-aided software engineering (CASE) technology was first introduced in the mid-1980s, many organizations thought it was impractical for them to adopt it, due to the limited availability of the technical expertise to use it. Nowadays, although adopted slowly, object-oriented programming for software systems has become a universal standard. One has to keep in mind that the selection of applicable technology is done in conjunction with system needs; as a matter of fact, the need should drive the technology selection, not vice versa.

Operational feasibility measures how well the proposed system solves the problems, and takes advantage of the opportunities identified during needs definition and how they satisfy the requirements identified in the requirements analysis phase. In other words, operational feasibility tells us how well the system will work in or fit in the current environment, given the current status of the designing organization. Historically, it was found that operational feasibility is often overlooked or taken for granted. Typically, for operational feasibility analysis, if a new system is being proposed, we need to answer the following questions: How does this system work well with the existing operational system? Is there any resistance to the new system from the end users? How does the system fulfill customer needs? Are the operational characteristics of the system compatible with the current existing management style? What are the potential pros and cons of the system’s operational efficiency? Do we have the necessary resources to design such a system, including facility support, management support, capacity/capability of the organization, resource readiness, workforce skills/training, and so on? For example, before building a diversion route for an urban freeway system, designers first assess the operational feasibility by conducting capacity analysis at critical intersections of the arterial route. Using simulations at different times of day and traffic conditions, the critical demand volumes that can be handled by the new system are computed, and different diversion strategies are compared to find the optimal solution for the new system structure. Operational feasibility is conducted prior to system design to make sure that the system can be designed in a timely manner with the minimum possibility of failure.

Economic feasibility, also called cost-benefit analysis (CBA), measures the cost-effectiveness of the proposed system. Economic analysis is a systematic process to compare the costs and the benefits of the system over its intended life span, to see if the benefits outweigh the costs. As a basic requirement for the design project to be economically feasible, the cost-benefit analysis is expected to show positive net benefit over cost. Economic feasibility is considered the most important decision factor for the system design project, as the ultimate goal of a business organization is to make a profit; the system design project is considered as a capital investment, and treated in the same way as other financial investments. A general approach involved in economic analysis includes the following steps: identifying the stakeholders; identifying the cost factors; selecting measures for all the cost factors and elements; predicting the monetary outcome of the costs and benefits over the life cycle time period; applying the appropriate model to integrate all the values from different time periods into one common basis of measure; comparing the costs and benefits; calculating the net benefit of the system; and performing sensitivity analysis to make the comparison more robust. This process is rather general; with different types of systems and different levels of complexity, it may vary accordingly. There are two primary types of costs that are almost every system will incur within its life cycle: system development cost and system operation/maintenance cost. The system development cost occurs in the early phases of the system life cycle; it is more of an initial one-time cost. The operation/maintenance cost is an ongoing cost that is incurred throughout the system life cycle until the system is retired. There are further categorizations within each type, depending on the nature of the system, which can be broken down into several levels. Two things need to be pointed out here: Firstly, since this is only the system planning stage, most of the cost factors and estimates are based on the analytical model and empirical data prediction; we cannot expect the figure to be precisely accurate at the beginning. As a matter of fact, it is expected that the cost estimate will be modified and revised when more design data is available, and the estimate will be more realistic in the later design stages; in system economic analysis, a commonly used approach for estimating cost is the activity-based approach. Based on the source of the cost, which is believed to be relevant to certain activities, mapping the amount of effort for each design and operation activity is believed to provide a basis for cost estimation. The cost concept will be further elaborated on in greater detail in Chapter 9. Secondly, as you have probably also realized, most of the cost estimates are in different time periods. As we all know that time puts a value on money (a dollar at the present time is worth more than a dollar in the future—think about the interest paid on the student loan you have), it is imperative to consider time in the formula of the cost-benefit analysis; all the cost and benefit values need to be converted to a common basis—either the current (present) value or a future value, or evenly distributed annually (such as the mortgage payment equivalent amount on a borrowed principal payment). The subject of studying the time value of money and its related models is called engineering economy; we will review this subject in detail in Chapter 9. The benefits involved in the system design are primarily tangible benefits, such as projected gross profit from the sales of the systems. This type of benefit can be easily understood and may usually be objectively predicted as a dollar value; however, there are also benefits that are not easily quantified or visualized—we call this type intangible benefits, such as increased environmental friendliness, increased customer loyalty, better quality, better service to the community, better employee job satisfaction, better moral values and ethics, and so on. These benefits are difficult to measure objectively. However, it is believed that the intangible benefits of the system can significantly impact the economic feasibility of the system, thus cannot be ignored.

Besides the three feasibility criteria of system analysis, there is another source of feasibility criteria that need to be taken into account in system development: these are legislation, regulations, standards, and codes, which can also be called legal feasibility. There are many regulations and standards developed at the federal, state, or even international level to regulate system engineering development. There are two major types of standards that are related to systems engineering: safety standards and performance standards. These standards include federal and military standards such as MIL-STD-1472D, Human Engineering Design Criteria for Military Systems, OSHA (Occupational Safety and Health Administration) standards for safety; and International Standards, such as ISO (International Organization for Standardization) 9000 (Quality Management Standard). Although some standards are concerned with safety issues, they cannot be ignored in the design and the consequences of not complying with the standards can have a significant impact to system effectiveness, even to the extent of involvement in a product liability lawsuit. For example, ISO has the following requirement for quality management systems:

The organization shall establish, document, implement and maintain a quality management system and continually improve its effectiveness in accordance with the requirements of this International Standard. (ISO 2008)

When applying the appropriate standard, we have to keep in mind that standards have many limitations that need to be taken into account for the design. As Chapanis (1996) pointed out, standards provide general and minimum requirements for the system, as they are prepared by external agencies; to achieve consensus, they have to be high level and general, as clearly seen from the above ISO example. To implement this requirement, further refinement is definitely needed. Many standards are not precise enough to be used directly; for example, wording such as “simple to use and communicate” means different things for different systems, so system designers have to tailor the relevant standards to the particular system specification, to make the relevant standards applicable to the system to be designed.

2.3.1.3 System Planning

After the proposed system has been shown to be feasible, the corresponding systems engineering program is developed through system planning. This is achieved by preparation of a system engineering management plan (SEMP). According to INCOSE (2012), the SEMP is

the top-level plan for managing the systems engineering effort. The SEMP defines how the project will be organized, structured, and conducted, and how the total engineering process will be controlled to provide a product that satisfies customer requirements. A SEMP should be prepared early in the project, submitted to the customer (or to management for in-house projects), and used in technical management for the study and development periods of the project, or the equivalent in commercial practice. The format of the SEMP can be tailored to fit project, customer, or company standards.

A typical SEMP document includes the following outline:

• Title, cover page, table of contents, scope.
• Applicable document.
  • This section includes all the documents that initiate the system, including the RFP, relevant standards, codes, and government/nongovernment documentation related to this project.
• Systems engineering process.
  • This section conveys how the organization performs systems engineering efforts, and should include the organization’s systems engineering policies and procedures, which contain the organizational responsibilities and authority for systems engineering activities and control of subcontracted activities, define the tasks in the systems engineering master schedule (SEMS) and the milestones of the systems engineering detail schedule (SEDS). These tasks and milestones encompass the following activities.
    • System engineering process planning.
    • Requirement analysis.
    • Functional analysis.
    • Synthesis.
    • Systems analysis and control, including trade studies, cost analysis, risk analysis, configuration analysis, interface and data management, TPMs, review and evaluation efforts.
• Transitional critical technologies.
  • Describes the key technologies (current and emerging) that the system will be using and their associated risks for systems development. Provides criteria for selecting technologies and transitioning these technologies.
• Integration of the systems engineering efforts.
  • Describes how the various systems design efforts will be integrated and how interdisciplinary teaming will be implemented to involve appropriate disciplines and expertise in a coordinated systems engineering effort. Tasks include team organization, technology verifications, process proofing, manufacturing of engineering test articles, development testing and evaluation, implementation of software designs for system end items, sustaining development/problem solution support, and other implementation tasks.
• Additional systems engineering activities.
  • Includes other areas not specified in previous sections but essential for customer understanding of the proposed systems engineering effort. These activities include long lead items, engineering tools, design to cost, value engineering, system integration plans, compatibility with supporting activities, and other plans and controls.
• Systems engineering scheduling.
• Systems engineering process metrics.
  • Including the cost and performance metrics and process control measures.
• Role of reviews and audits.
• Notes and appendix.

Chapter 10 will review SEMP in greater detail. For a more detailed elaboration, template, and example, readers can refer to INCOSE (2012), which can be downloaded free of charge by INCOSE members from www.incose.org.

2.3.1.4 Requirement Analysis

A system starts with a need, as we have stated before; system needs come from different sources, with a majority of needs coming directly from customers. Although system design is need driven, these high-level needs often come in different formats; and, moreover, are too general and vague to be implemented directly. System needs must be further refined and analyzed, transformed from an informal format to well-defined system design requirements. A requirement is a formal statement about the intended system that specifies what the system should do, identifying a capability, characteristic, or quality factor of a system to have values for system users. Generally speaking, a system requirement should have the following format (syntax):

A system (or subsystem or components, depending on the levels of requirements) shall + verb + object (noun) + (target performance metric) + (requirement-related context or environment conditions). Note, here, that the word “shall” is being used in the sentence and carries a very specific meaning: it indicates the sentence is a requirement statement—that this requirement is mandatory and must be followed. There are occasions that “will,” “must,” “should,” or even “may” are used. “Will” and “must” statements signify the mandatory condition that surround the requirements; “should” and “may” statements are less restrictive—usually they are used for nonmandatory or optional requirements. A “should” statement is a little stronger than a “may” statement; sometimes the reason that “should” is used is because it is considered by the design team as important but not yet determined to be mandatory or difficult to verify. A “may” statement is considered as optional, as recommended by research or previous findings, not a contractually binding requirement. Here are some examples of the different requirement formats:

Shall statement: The new display shall present the required time of arrival (RTA) status upon request by the pilot.

Should statement: The new display should be two-dimensional in an exocentric format.

May statement: The new display may make it possible for the pilot to select the color of their choice.

System requirements analysis is the most critical design activity in the conceptual design stage; it translates the various formats of the system needs from different sources into well-structured system operational requirements, eliminating ambiguity, resolving conflicts, and documenting requirements so that they can be followed, traced, and verified. Although they vary with different types of systems at different complexity levels, system operational requirements should at least address the following issues (Blanchard and Fabrycky 2006):

• Defining system mission: Identify the primary and secondary missions of the system; namely, what is the overall system objective? What are the main functions that system is intended to provide? Usually a set of operational scenarios (narrative or graphical) are defined to help elaborate the mission profile.
• Defining system stakeholder: Identify the major user classes for the system, together with their main characteristics, including demographic information and skill/training levels for each class.
• Defining system performance and physical parameters: These are the operational characteristics of the system’s intended function; for example, how well the system performs under certain operational scenarios. These parameters include system deployment and distribution characteristics, describing how the system is deployed geographically.
• Defining system life cycle and utilization requirements: What is the intended life span for the system? How is the system utilized (i.e., hours per day, days per week, months per year)? This is closely related to system performance parameters, such as system reliability and maintainability measures, as they are both functions with time and utilization frequencies.
• Defining the system effectiveness factors: The system’s main technical and economic effectiveness factors are defined at the conceptual design stage; these include life cycle cost, system availability, mean time between maintenance (MTBM), logistic support, failure rate (λ), system operators’ and maintainers’ skill levels, and so on. Generally speaking, given the system is operational, how efficient and effective is it?
• Defining the environmental factors: These are the environmental conditions for the system’s operations and maintenance, including physical environmental conditions (i.e., location, temperature, humidity, etc.), as well as the possible environmental impact from the system. This is essential for system sustainable development, because, during the system life cycle, the system constantly interacts with its ambient environment, especially the natural environment that humans rely on. Environmental friendliness is one of the most important factors for the system’s long-term success; this is true even for the system’s retirement and recycling of materials. This factor needs to be addressed in the very early stages of system design.

The results of the requirement analysis lead to the preparation of system requirement documents. They define, refine, and record a set of complete, accurate, nonambiguous system requirements, usually in an operational hierarchical structure, based on the different levels of system addressing, managed by database-like model-based systems engineering (MBSE) software (such as DOORS and CORE), and made easily accessible to all designers at appropriate levels. Chapter 3 will explain the procedures for refining high-level requirements into lower-level requirements in greater detail. The purpose of refining requirements into different levels is to avoid ambiguity, provide a clear structure of traceability, and manage the requirements easily.

2.3.1.5 Functional Analysis at the Systems Level

Once the requirements have been captured and organized, the question to be addressed is what functions the system needs to have to fulfill these requirements. This question is answered by conducting functional analysis at the system level. Functional analysis is an important activity for system design besides requirement analysis, as it is the first step in describing what the system should do. A system function, according to INCOSE, is a unique action or activity that must be performed by the system to achieve a desired outcome. For a product, it is the desired system behavior. A function can be accomplished by “one or more system elements comprised of equipment (hardware), software, firmware, facilities, personnel, and procedural data (INCOSE 2012).” Many people tend to confuse functions with tasks; in the context of systems engineering, they are different yet interrelated with each other. A function is an action performed by systems that may or may not involve system users. For example, for an ATM system for banks, “deposit,” “withdraw cash from checking account,” “check account balance” are instances of system functions; tasks, on the other hand, are activities that system users carry out to support certain functions to be performed. We highlight support here to illustrate the relationship between functions and tasks; that is, functions come first, then tasks. Tasks are supporting or triggering functions; without functions to perform, there will be no task to act on. For the same example of an ATM, “insert debit card,” “key in PIN,” and “select amount” are all user tasks; these tasks are necessary for the function “withdraw cash from checking account” to be accomplished. Keeping in mind this precedence of functions over tasks, we can easily understand the relationship of these two analyses, and conduct the right analysis at the right time.

A function is an action of the system; it emphasizes the action by using an appropriate verb in the short phrase, such as the “withdraw cash from checking account” function for an ATM system or the “transport passengers to desired floor” function for an elevator system. Knowing this characteristic of functions helps us to identify necessary functions from the narrative of system operational scenarios; that is, highlighting the verbs is a good start when building the functional model. The method for identifying systems functions, their hierarchical structure, and operational sequences is called functional analysis, which is explained in greater detail in Chapter 4 of this book. A typical functional analysis results is illustrated in the following functional list and the associated Figure 2.2 and Figure 2.3.

ATM functions list

0 Perform ATM functions

1.0 Verify account information

2.0 Deposit funds

2.1 Deposit cash

2.2 Deposit checks

2.3 Print deposit receipt

3.0 Withdraw cash

3.1 Withdraw from checking account

3.2 Withdraw from saving account

3.3 Print withdrawal receipt

4.0 Transfer funds

5.0 Check account balance

5.1 Check checking account

5.2 Check saving account

5.3 Print account information

The output of functional analysis is the functional model or functional baseline. A functional baseline defines what functions the system should perform and the operational structures of these functions, not how the functions are accomplished. It is imperative to keep in mind not to rush into hardware and software solutions at an early stage of the design; in other words, not to over-specify the design in the early stages. Systems engineering is a philosophy of a requirement-driven, top-down process. Design takes a step at a time, and gradually evolves to the final form of the system. In this way, we can ensure that most parts of the design space are explored and the big picture of the design is always considered to achieve an optimal system design solution. Rushing into the detailed system components without properly following the process could cause immature decisions to be made early, causing unnecessary changes in the later design stages.

One essential immediate output from requirement analysis and functional analysis is the identification of the major system parameters and their quantitative target value. The system generally speaking, the system performance Y is a function of two types of variables or parameters: Y = f(Xi, Xd). Xi represents design-independent parameters and Xd design-dependent parameters.

• Design-independent parameters (DIPs) are those attributes or variables external to the system design, but influencing the system performance. The design cannot alter the DIP values, but has to take them into consideration. DIPs usually define the environmental conditions for and constraints of systems operations, such as the labor rate, resources costs, demand rate, service rate, customer preferences, interest rate, regional electricity voltage/frequency, and so on. These external factors directly influence the design decisions and system effectiveness. They are independent to the systems design decisions.
• Design-dependent parameters (DDPs) are the attributes/variables that are inherent in the system design; these are the variables that designers can decide on and alter to achieve optimal system performance. Examples of DDPs include system mean time between failure (MTBF), system life cycle cost, output power capacity, acceleration, velocity, weight, dimensions, color, size, and so on. These variables have unique values for the system being designed; in other words, they are dependent on the system itself.
• Technical performance measure (TPMs): these refer to the quantitative values for DDPs. For example, system MTBF of 3000 h, weight less than 40 lb, and so on. These values define the system effectiveness objectives, often included in the system requirements. Quantitative values make it possible for these requirements to be verified.

For requirement analysis and functional analysis, not only are the requirements described in narrative format, but also the objectives pertaining to them need to be stated in a quantitative format, as readers will see later in Chapter 3. TPMs facilitate the efforts of system tests and evaluation. For every requirement and function, a quantitative TPM makes it easier for verification of that requirement. A requirement of “system shall start within six seconds when turned on” is easier to verify than a requirement with vague objectives, such as “system shall be easy to use.”

2.3.1.6 System Specification Type A

The results from the design activities described above, including the need identification, system feasibility analysis, requirement analysis, and system function analysis, are integrated and compiled into one major document for the conceptual design stage, system specification, or Type A specification or A specs. It specifies the system functional models from the highest level, so is called the system functional baseline.

A typical Type A specification includes the following information:

• System general description, including system mission, scope, and applicable documents.
• System requirements analysis results, including the system-level requirements and their refined sublevel requirements. Requirements may be categorized into different classes, depending on the nature of the system; usually, they include system operational requirements, maintenance requirements, system effectiveness factors (such as reliability, maintainability, human factors and usability, system cost-benefit profile, safety and security, etc.); system design and construction considerations (hardware and software technology, data management, CAD/CAM).
• Functional structure of the system, including major functions definitions and hierarchical structure at system level; functional model represented by functional flow block diagram; major maintenance functions and their relationship with the system operational functions.
• Other design considerations and constraints, including system logistics and support concepts; test and evaluation plan; major system milestones for system life cycle.

As the first system configuration baseline, the system specification (Type A) defines the technical, performance, operational, and support characteristics for the system as an entity at the highest level. It includes the allocation of requirements to system functions, and it defines the functions and their relationships (i.e., system decomposition structure and operational flow structure). The information derived from the feasibility analysis, operational requirements, maintenance concept, and functional analysis is included in the Type A specification. It describes design requirements in terms of the whats (i.e., the functions that the system is designed to perform and the associated metrics, TPMs).

2.3.1.7 Conceptual Design Review and Evaluation

As stated at the beginning of Section 2.3, the basic methodology involved in the system design process can be summarized in three words: analysis, synthesis, and evaluation. In each of the system design stages, before proceeding to the next stage, intermediate design results are reviewed, tested, and evaluated, to verify that the design is following the right track. These reviews, tests, and evaluations serve as a control point, or decision point, to make sure the design is correct in terms of following the system’s operational needs. Systems engineering tries to do things correctly at the beginning; no matter how well the design is laid out and controlled, it is inevitable that any design will have unexpected changes and deviations from the original path, due to a number of reasons, such as changes to requirements, new technology, miscommunication, or lack of in-depth understanding of the design, to name a few. Testing and evaluation is critical in system design, as it serves as a checkpoint to identify the mismatch between the design and the needs; thus, problems may be fixed before it is too late to do so. Throughout the system life cycle and design processes, testing and evaluation are conducted continuously and iteratively, at different levels of detail. The testing and evaluation includes an informal daily check of the work accomplished and a formal test conducted at certain milestones of the system design.

At the end of the conceptual design stage, formal reviews and evaluations are conducted, with representatives from stakeholders (i.e., system users and customers) and designers involved, to determine

• Whether or not the system needs are well understood by all parties
• Whether or not the operational requirements are sufficiently developed for the design
• Whether or not the functional models are complete and reflect the concepts of the system operational requirements

Also called the system requirement review, the conceptual design review uses a variety of techniques and methods, depending on the nature of the system, to gather feedback from stakeholders. For example, in software design, focus groups, questionnaires, and surveys are often utilized by the conceptual design review, while a product design review might use models such as simulations, mock-ups, and trade studies analysis as the basis for evaluation. At the conceptual design stage, since the system only exists conceptually, the review is usually more high level, abstract, analytical, and qualitative in nature. Its purpose is to obtain approval for the system functional model and make sure that there is a correct functional model that reflects exactly what users need of the system, to start the implementation and allocation of the functions to components (the hows) in the next stage.

2.3.2 Preliminary Design

The preliminary design extends the results from the conceptual design stage to more detailed levels; namely, the subsystem level and component level. The purpose of the preliminary design is to demonstrate that the design concepts are indeed valid in the sense that they can be implemented through systems components, including hardware and software. Design concepts are further explored, with information about component implementation, translating the what aspects of the system (systems functions) to how the system requirements are actually fulfilled (function allocations to components).

Generally speaking, the major activities in preliminary design include the following:

• Performing the functional analysis at the subsystem and component levels; taking the functional baseline developed from the conceptual stage, the system-level functions are further decomposed into the subsystem-level functions as well as the operational structure of these systems.
• Developing the specifications for the subsystem and components; this includes components’ TPMs, product specification, and processes/materials related to the procuring or producing of these components; preparing preliminary configurations for system physical models, including the interaction between components, and between humans and the system.
• Documenting the design results using engineering design tools and software, including the design data, drawings, and prototype.
• Performing trade-off analysis for the system configuration; optimizing system performance by applying appropriate decision-making models.
• Conducting the system design review to verify that the preliminary design results conform to system requirements.

At the preliminary design stage, what functions the system should provide is further investigated. Based on the system concepts developed, systems functions are decomposed to subsystem level; to configure the components to achieve these functions, the question of how the system functions are accomplished is first addressed. In other words, the system functional model is translated into system operational models and physical models. These models are instances for the application of model-based systems engineering (MBSE) philosophy.

MBSE is a formalized application of models to design systems, defining system requirements, system elements, verification/validation, and relevant design activities, to support structures and communications in systems engineering efforts throughout the system life cycle. MBSE uses structured modeling languages and semantics to define systems elements and their relationships, such as System Modeling Language (SysML). SysML is inspired by Unified Modeling Language (UML), a commonly used object-oriented design language for software engineering.

SysML was developed in 2003, as a dialect (or profile) of the popular UML. It uses part of the UML construct, removing those constructs that are not needed in systems, and also provides an extension of UML modules for unique systems engineering applications.

SysML including the following diagrams:

1. 1.0 Behavior diagram
   1. 1.1 Activity diagram
   2. 1.2 Sequence diagram
   3. 1.3 State machine diagram
   4. 1.4 Use case diagram
2. 2.0 Requirement diagram
3. 3.0 Structure diagram
   1. 3.1 Block definition diagram
   2. 3.2 Internal block diagram
   3. 3.3 Package diagram

Among these diagrams, the requirement diagram is unique to SysML; the other diagrams are either the same as in UML or modified from UML.

An in-depth review of SysML is beyond the scope of this book; please refer to Friedenthal et al.’s (2009) book for a more comprehensive review of the subject.

Using MBSE, systems can be described via different forms of models, depending on the perspective from which a system is studied. Generally speaking, there are three models that are most commonly used for the system description: functional models, operational models, and physical models.

A functional model of the system describes the system functions architecture. It illustrates the hierarchical relationships among systems functions. Figure 2.4 shows an example of system hierarchical structure.

A system operational model describes the systems in terms of the system operations. Similarly to the system functional flow block diagram, it illustrates the system operations from a temporal perspective, describing the systems operations in terms of timeline relationships. Figure 2.5 shows an example of an operational model of an ATM system.

A physical model describes the physical components of the system, including system hardware, software, and the geographical location information for physical model distribution, as well as environmental information for the components (Figure 2.6).

These three models are instances of MBSE design outputs. They describe and define the systems from different perspectives, and we can say that none of the models is 100% complete; they address the system from one particular dimension of the system characteristics. To get a complete picture of the system, we need to integrate all these models together. It is just like an engineering drawing of a 3D object using a partial 2D picture; one can use the side view, top view, and front view together to get a complete picture of the object.

One also needs to keep in mind that certain models depend on others to be developed first. For example, out of all the models, the functional model is developed first before an operational or physical model is developed, as operations depend on functions and physical components are allocated to functions. In the conceptual design stage, the focus is on the system functional analysis; the operational model is developed based on the system-level functional analysis, and it is at the preliminary design stage that the system physical model starts to be addressed; namely, how will the functions be accomplished, by what components? The preliminary design allocates functions to components by conducting further functional analysis at the subsystem and component level.

2.3.2.1 Functional Analysis and Function Allocation

The subsystem functional analysis starts with the functional baseline developed from the conceptual design stage. For each of the main system functions, further functional decomposition is conducted and a lower-level functional flow block diagram (FFBD) is developed. The process is very similar to the FFBD in the conceptual design stage, except that it occurs at the lower level. The detailed FFBD method is illustrated with examples in Chapter 4. During this decomposition process, for each of the system functions not only the operational functional sequence is identified, but also the maintenance functions if the operational function fails. In the FFBD, the operational sequence is for the normal conditions of the function and the maintenance functions are for the error conditions of the main function. Considering the failure mode of the function is essential, measures to deal with the system failure (both corrective maintenance to fix a failure if occurs and preventive measures to postpone the failure occurrence) need to be considered in the early stages, as the implementation of the maintenance functions—such as components selection, interface design, and diagnosis system—can have a huge impact on system success, and later changes and modifications should be avoided, just as in any other function.

During subsystem functional analysis, system requirements and related TPMs are also assigned to the sublevel. For example, a reliability of 99% at system level might require a certain level of component performance to achieve that goal. The system itself is not a single object; its performance objectives, defined in TPMs, are accomplished by the components that constitute the system. Allocation of high-level requirements and TPMs to the lower-level components is a necessity to procure the right components. Unfortunately, there are no standards or template to follow to perform these allocations; this is because:

• Different types of requirements necessitate different types of TPMs; some are easy to measure, such as the cost of the components, size, dimensions, and quantitative engineering parameters. These TPMs usually have direct ways to be calculated; some other TPMs are not that easy to measure, especially those involving qualitative parameters, such as system reliability, supportability, and most of the human factor parameters. Most of these type of TPMs rely on empirical data for verification—sometimes even subjective data.
• Analytical models play a very important role when assigning TPMs for quantitative measurements, such as the faulty tree analysis (FTA) to derive the cause–effect relationship of the failure occurrence probability among components at different levels, or the transition functions to study the system control dynamics. However, the majority of the system parameters have no well-defined analytical model to find the optimal solution. In many cases, since the decomposition maps from one (high-level system function) to many (subsystem-level functions), it is nearly impossible to find a unique solution for the assignment. For example, there may be multiple ways of configuring the components that can all meet the system reliability requirements. To find the most feasible solution, one inevitably has to use the most naïve method, trial-and-error, and multiple criteria have to be combined to narrow down the solution space. In the process of decomposition and allocation, often the bottom-up approach is combined with the top-down process; as the top-down process cannot lead to a unique solution, we do need to search for what is available and determine what our choices are. In the later chapters (Section II of this book), we will discuss the different models and methods that can be applied to allocate high-level requirements to various lower levels. Readers have to keep in mind that a good designer is always versatile and flexible, and must master a wide range of models and techniques; experience with similar systems will help a great deal.

In the preliminary design stage, the functional analysis is carried out at a more in-depth level to help find the correct components. For each of the functions, the detailed information for the function is studied, including the inputs to the function (system requirements for the function, material and information needed for the function), the output of the function (product, information, another format of materials, waste and residuals), its controls and constraints (technical, political, environmental, economic) and its mechanism (human factors, computer resources, facility and utility support, maintenance and support). This analysis is further elaborated on in Chapter 4 in greater detail.

The purpose of functional analysis at the subsystem level is to eventually allocate the system functions to components, so that the system functional model can be translated to the physical model. Theoretically, functions can be decomposed into deeper lower levels, all the way to the nuts-and-bolts level; system designers should know when the functional analysis has arrived at the bottom level to stop further decomposition. Usually, the functional analysis stops at the basic configuration level, that is, at the level at which the configuration items can be obtained, either from a supplier or as COTS items. The internal structure of that item is beyond the scope of system design, as long as the item provides the appropriate outputs that support the system functions. Novice system engineers are often confused about the level of depth needed for preliminary design functional analysis. The rule of thumb is to ask the following question: Is there a need to configure the internal structure of the function? If the answer is yes, then another level of decomposition is probably needed; if the answer is no, the function can be achieved by obtaining an external item—then one has arrived at the bottom level of functional analysis. Of course, during this process, since trade-off studies are necessary to obtain the best approach to fulfill a functional requirement, the process of functional analysis usually involves many rounds of iteration and evaluation to point out the most feasible selection of the system components, including hardware, software, people, facilities data, and the combination thereof.

With functional analysis achieved at the lowest level, the lower-level elements are defined based on the functional requirements and TPMs. Subsequently, similar functions are grouped or partitioned into logical subdivisions or packages; this leads to the identification of the major system assemblies, units, and modules. For example, for all the power consumption units, the power input function items can be grouped together, by having one power supply providing power to all the units. This step is necessary, as we will see later; the system package might put constraints on the numbers and sizes of the components inside the system, so having a lower number of components and providing more common functions per component is always a desirable design approach. Usually, this grouping is also dependent on the available standard COTS items; again, the bottom-up search combined with top-down analysis is necessary for successful allocation.

The results of functional analysis at the subsystem level lead to the development of a second system design baseline, the allocation baseline, also called specification Type B; it is a system development specification that includes the technical requirements for the system components/items (such as items of equipment, assembly, data packages, computer software programs, facilities, support items, and so on). These technical requirements are derived from the original high-level requirements, through the process of analysis, allocation, relevant trade studies, and system modeling. Each of the technical requirements for the items includes the performance, effectiveness, and support characteristics that are required from the system-level requirements and necessary for obtaining the actual items for the system.

Another important aspect of the allocation baseline is that interface or interaction requirements are also included. Based on the system functional analysis and allocation to components, each of the functions’ inputs and outputs are also addressed. Among them is the necessary human input to activate the functions. It is necessary to conduct an operational task analysis (or operational sequence analysis) as the first step to develop requirements for user–system interfaces. As an inherent part of the system requirements, human factors and ergonomics aspects of the system design are considered at the earliest stage once the human user’s role has been identified. Allocation to humans also involves trade studies, as decisions about the allocation can be complex for large systems. Questions to ask include: What is the role of humans within the system functions? What are the advantages and disadvantages of human control versus automated control of particular functions? What is the interaction style between users and the system? What kind of data is involved? What kinds of skills are necessary to operate the system?

The results of the user–system interaction analysis lead to a detailed description of the user–system interface requirements and related components, including input devices, output devices, and the forms of dialogs the interface will contain. We have to keep in mind that, at this stage, the mechanism of implementing the interface is still to be determined. The detailed format of the interaction should evolve together with the other system components, as they are not totally independent of each other.

As part of the interaction design, the working conditions for the user–system interaction should be addressed and described. Some environmental factors such as vibration, heat, and noise may have a serious impact on human performance, thus need to be considered into the design. Human factors engineers and professionals are primarily responsible for working out the design requirements for the user–system interaction and its related environmental conditions.

Based on the design requirements from the user–system interaction and environmental conditions, a statement of personnel requirements should be prepared at the system design level. This statement should include basic information about the system staffing model, including the number of users needed, basic level of skills needed, and training program requirements that are necessary for these skills. These requirements are stated at the system design level and tailored by the details of the design, as the personnel requirements are DDPs, evolving with more details as the system design progresses. It is important to follow the top-down process for these types of requirements as well, because they will change and be modified as system development proceeds in the later stages.

The allocation baseline (Type B specification) breaks the system functions into lower-level functions; thus, the functions can be implemented by system components through an open-architecture configuration structure, providing a foundation through which the subsequent design tasks can be accomplished. Through this baseline, it is ensured that all the subsequent results will follow the original system requirements, providing traceability for design activities. As mentioned earlier, this is the basic design philosophy for systems engineering, in such a way that unnecessary changes can be avoided to a great extent.

2.3.2.2 Design Tools and Analytical Models

A successful systems engineering design is highly dependent on a structured design process, organized documentation, and properly applied models/tools. As the design progresses into the preliminary design phase, and later, the detailed design stage, the level of detail and amount of information increase dramatically; the semantics and interrelationships among different design elements become more complex. Systems designers need to track the relationships, generate different models for evaluation, and manage design changes in a well-controlled and efficient way. This makes utilization of the proper design aids and tools a necessity. After many years of development, CAD hardware and software are now quite mature; the utilization of computer technology in systems engineering has gone far beyond the scope of two-dimensional drawing and graphics design. Nowadays, computer-related technology has become an inherent part of the design; it is hard to imagine a complex systems engineering design project being completed without any computer technology support. The computer technology applied in systems design generally serves two categories of purposes:

Project management and documentation: In this category, the computer serves as a project management tool, enabling designers to develop a database for the design data, document the design elements, establish and provide traceability among different design elements, generate reports and different models, and aid trade-off studies. Commonly used tools include Rational DOORS by IBM and CORE by Vitech Corporation. These tools provide a well-controlled environment for systems design, to efficiently manage and communicate systems design activities. In Chapter 3, we will introduce the application of CORE in system design at a more detailed level.

Engineering design aid and prototyping: This category is very common and seen in almost all kinds of systems design. Tools in this category primarily include prototype tools such as AutoCAD, LabView, CATIA, computer-aided manufacturing (CAM) tools, and modeling/simulation software such as ARENA, ProModel, and FlexSim. The application of these tools will be described throughout Section II of this book.

In the preliminary design phase, since the level of complexity greatly increases as the design evolves from functions to subfunctions and components, CAD tools provide great advantages, just as Blanchard and Fabrycky (2006) pointed out. CAD offers advantages including:

1. Enabling designers to address different alternatives in a relatively short period of time, thus making the evaluation and modification of the design more convenient and efficient.
2. Enabling designers to simulate, visualize, and manipulate the design configuration by providing a three-dimensional prototype at low cost and in a relatively short period of time.
3. Enhancing the changing process of the design, in terms both of time and accuracy of data presentation. A well-defined change procedure can be managed and tracked easily with CAD tools, in conjunction with other tools such as electronic mail and computer office systems.
4. Improving the quality of the design data, in terms of both the volume of the data and its precision/accuracy. With a high quality of data, system analysis and modeling become easier, as does the capability of building large, complex system models.
5. Facilitating communication among design teams and the training of personnel assigned to the project. With a common database, the designers can easily synchronize the design effectively, ensure all design activities are tracked so that everyone is “on the same page” and, moreover, provide a platform for brainstorming, discussion, and training of new personnel, as a design project will usually last years and there is inevitable turnover of designers.

2.3.2.3 Design Reviews

Just as in the conceptual design stage, there are also two types of evaluation at the preliminary design phase. The ongoing informal review and evaluation is conducted on a daily basis, where the designers check their own work, providing technical data and information for the design teams; formal reviews are conducted at the end of the preliminary design stage, to verify that the design results follow the design requirements. Depending on the nature of the system being designed, the type of review and evaluation varies. But, generally speaking, the formal reviews at the preliminary design phase usually include the following:

2.3.2.3.1 System Design Review

This is a formal review usually conducted after a preliminary allocation baseline is completed. The system design review is intended to evaluate how well the system configuration, derived from the allocation baseline, will meet system requirements. This review focuses on the overall system configuration, not the individual components and items. The system design review covers a variety of topics, including system and subsystem functions (including related maintenance functions), function allocations to components, TPMs on subsystems and components, design data and reports (including trade studies results, drawings, part lists, and prototypes), user–system interaction/interface, facilities, environmental conditions, and personnel requirements. A system design review is usually conducted with the involvement of system users to provide feedback on any possible updates and modifications pertaining to the system requirements and configurations.

2.3.2.3.2 Preliminary Design Review

Also called the hardware/software design review, this is usually conducted after a hardware and software components specification is completed, before implementing these components into the design. In the preliminary design, design data related to system hardware and software are reviewed and a variety of test beds are used for the review, usually including the drawings, part lists, trade-off study reports, simulations, mock-ups, and prototypes. Software and hardware performance and the interface between components and users are assessed. The approval of the preliminary design review leads to a design-to systems specification; that is, system components are ready to be procured and system items to be developed, which is the goal for the system detailed design phase.

2.3.3 Detailed Design

With the functional baseline (Type A specification) developed at the conceptual design stage and the allocation baseline (Type B specification) developed at the preliminary design stage, the system configuration is derived in terms of hardware and software components. It is now time to proceed to integrate all the components into a final form of the system; this is the main goal for system detailed design. In the detailed design phase, system engineers will (1) develop design specifications for all the lower-level components and items; (2) develop, procure, and integrate the system components into the final system configuration; (3) conduct a critical system review, identify any possible problems with the system configuration with regard to systems requirements, and control/incorporate changes to the system configuration.

2.3.3.1 Detailed Design Requirements and Specifications

The detailed design starts with the two baselines developed from the previous design stages, the functional baseline (Type A specification) from the conceptual design stage and the allocation baseline (Type B specification). These two baselines are normally at system level, and describe the overall system structure/configuration. At the detailed design stage, all the system components must be finalized, including hardware, software, users, assemblies/packages, system requirements, and specifications, which all need to be further evolved to the lowest level. On the one hand, the analysis process is similar to that of the conceptual design and preliminary design stages; system designers need to iteratively perform the allocation and decomposition analysis, to derive the requirements and related TPMs for the lowest level of components. This is, again, a top-down process; however, since all the components need to be specified and procured or developed in the detailed design stage—and depending on the complexity of the system, the majority of the components most likely need to be procured from external suppliers or using COTS items—it is imperative to understand what is available “out there” before a selection decision can be reached. At the detailed design stage, the top-down process is usually combined with a bottom-up process, to get a complete picture of what is needed and what is available, to obtain the most efficient design solutions.

The analysis of the detailed design will lead to a comprehensive description of the system configuration in terms of system components and operations. With these descriptions, it should be easy to build or install the system with minimum confusion. The detailed design configuration usually consist of the following design baselines:

1. Product baseline (Type C specification): This, according to Blanchard and Fabrycky (2006), describes the technical requirements for any items below the system level, either in inventory internally or that can be procured commercially off the shelf. Type C specifications cover the configuration of the system at the system elements and components level; it comprises the approved system configuration documentation, including the component/part lists, component technical specifications (TPMs), engineering drawings, system prototype models, and integrated design data, which also includes the changes made and the trade-off studies/models for the decisions made for the components.
2. Process baseline (Type D specification): This, according to Blanchard and Fabrycky (2006), describes the technical requirements for the manufacturing or service process performed on any system elements or components to achieve the system functions. It includes the manufacturing processes necessary for system components, such as welding, molding, cutting, bending, and so on, or the service/logistics processes such as material handling, transportation, packaging, and so forth; and any related information processing procedures, including any management information systems and database infrastructure for the design.
3. Material baseline (Type E specification): This describes the technical requirements pertaining to the materials of the system elements/components, including the raw materials, supporting materials (such as paints, glues, and compounds), and any commercially available materials (such as cables and PVC pipes, etc.) that are necessary for the construction of the system components.

These baselines are built on one another, and are derived from the system technical requirements and system analysis, taking into consideration economic factors from the global supply chain, and gradually lead to the realization of the system.

2.3.3.2 CAD Tools and Prototypes in Detailed Design

At the detailed design stage, all the design components have been specified and integrated together. The level of detail and information involved is vast and overwhelming. It is imperative to use computer-aided tools and system project management software to control the design activities and manage all the data involved. The system has evolved to the final form of its physical model; this model needs to be built, verified against the system requirements, and traced against other forms of the system models, including functional and operational models. CAD/CAM tools provide great benefits for detailed design integration and verification; these benefits are similar to those mentioned in Section 2.3.2 (preliminary design phase), providing a well-structured and controlled database and project for implementing the design more effectively. These tools, sometimes combined with system simulation software, enable the design team to create a robust design more efficiently, through quick iterations with different configuration alternatives.

In the detailed design, prototype-based simulation is of importance for validating the design. A prototype is a simulated representation of the system that enables designers and users to visualize, conceptualize, touch and feel, and interact with it to validate the design effectively and efficiently. Prototypes come with different kinds of forms and levels of detail. They range from concept cards, cardboard, hand-sketched flow charts, and storyboards, to near complete complex versions of the system interface or hardware mock-ups. Prototypes are used at all stages of the system design, with different levels of information and different aspects of the system for different purposes. In software interface design, fidelity is used to measure the level of detail included in the prototypes. Fidelity of the prototype refers to the degree of closeness of the prototypes to the system counterparts they represent; the closer to the real system, the higher the fidelity. Fidelity is also used in the aviation training and simulation community to measure the quality of the training devices; it has a similar meaning here as with prototypes, as the training devices are often replicas of the real system; for example, the personal training devices (PTD) to train novice pilots. In the early design stages, such as in the conceptual design stages, since the design is focused on the high-level system operational concepts, the prototypes developed at these stages are often of low fidelity. In other words, they do not look like or feel like the final system, but are in a more abstract format, to capture the most important logical relationships of the system functional structure, as they are cheaper and easier to build, and thus provide advantages for exploring different conceptual design alternatives. In the later design stages, especially when approaching the end of the preliminary design stage and detailed design stage, with all the components configured, the prototypes are closer to the final forms of the systems. At this stage, the focus is on investigating the more detailed low-level aspects of the design, such as the physical dimensions, look and feel, and interaction with users.

In detailed design, high-fidelity prototypes are to be developed to serve as the test bed for validating the system components configuration. Prototypes enable designers from different disciplines to come together to communicate in a very cost-effective and time-efficient way. Some of the values and benefits for the detailed design, according to Blanchard and Fabrycky (2006), include:

1. Provide the designers with opportunities to experiment with different detailed design configuration ideas, including (not limited to) facility layout, interface style, packaging schemes, controls and displays, cables and wires, and so on.
2. Provide different engineers with a test bed to accomplish a more comprehensive review of the system configuration, including system functions and operations, reliability and maintainability, human factors and ergonomics, and support and logistics. Reviews are more open and straightforward, with the possibility of interactions between different problem domains.
3. Provide design engineers with a test bed for conducting user task analysis, including the task sequence, time constraints, and skills requirements, which in turn specify the training requirements for system operators and maintainers.
4. Provide a vehicle for designers to demonstrate their ideas and design approaches during the design review.
5. Provide a good tool for training purposes.
6. Provide a good reference for tools and facility design.
7. Serve as a tool in the later stages for the verification of a modification kit design prior to the finalization of data preparation.

Prototypes play a vital role in almost all kinds of design projects; it is hard to imagine a design being completed without any kind of prototype being developed during the design process. In software engineering, there are designs that evolve primarily with the prototypes, as this is straightforward for the users and easy to demonstrate. For example, the rapid prototyping approach utilized in software development is an iterative and evolutionary design process that primarily uses prototypes as the main tools to convey the design ideas and get users involved in the early stages of the design.

2.3.3.3 Component Selection

The main activities in the detailed design stage are to further meet the top-down system requirements with bottom-up system component selections; sometimes this is called the middle-out approach. Based on the system functional structure and its allocation baseline, components are sought and the system is built. The designer’s job is to select the best way to obtain the components (hardware and software) and integrate them into the system as a whole. With regard to the sources of the components, the selection approach has to be based on system specification and driven by requirements, but generally speaking, the following sequence is usually followed:

1. Use a standard COTS item. COTS items are usually easy to obtain from a number of suppliers. The benefits of using a standardized part is because most suppliers specialize in manufacturing those parts, which usually conform with established government and industrial regulations and specifications, such as FAA or ISO9000/ISO9001. These parts are often produced in large volumes at a relatively low unit price. Using standard parts can significantly reduce the cost and increase the efficiency of system development, and even system maintenance/support. The objective of selecting the right components from COTS is to derive detailed requirements for these components through system design analysis, to pick the appropriate supplier for the parts.
2. Modify an existing COTS item to meet the system requirements. If a COTS item cannot meet the configuration requirements completely, a close form of the item obtained from COTS can be modified. These modifications may include adding a mounting device, adding an adapter cable, or providing a software module. The rule for the modification is that it should be kept to a minimum and be simple and inexpensive, to ensure that no new problems or new requirements are introduced to the system design.
3. Design and develop a unique component for the system. If there is no standard component available and it is not possible to modify a standard part to meet our needs, designing a special unique part is our only option. The manufacturing process and materials used for the part, defined in the Type C, D, and E specifications, need to be based on the systems requirements, and it is desirable to use standard tooling/equipment and assembly parts for ease and economy of the installation, operation, and maintenance.

Component selection decisions should be systems requirements driven. The decision-making process usually involves vigorous modeling, simulation, and prototype testing, using systems TPMs as the decision-making criteria. For example, the impact of the selection of components on system functionality performance, economic merits, systems reliability, maintainability, supportability, usability, and even ease of system retirement are all part of the considerations. Just as mentioned above, the selection process is a combined approach, both from the top down and the bottom up; it is systems requirements driven and, meanwhile, involves familiarizing oneself with the available technology and suppliers. Both are essential for the detailed design of the system components.

Another important aspect in detailed design is the implementation of the team effort. Systems engineering requires that all the parties are involved at the early stages of the design, to facilitate communication and stay “on the same page.” It is at the detailed design stage that the integration of all the different disciplines reaches the highest level of complexity. With a tremendous amount of data and information, and many personnel involved (even in different parts of the world), the coordination and management of the design team members are very critical for the efficiency of the design activities. With the proper design aids and computer-aided systems management tools, it is now easier to synchronize all the design activities and data within a central database structure. Another important aspect of teamwork is to deal with the design changes. It is inevitable that some changes will occur at the different stages of the design process, due to changes of customer requirements, changes in technology/resources, and so forth. As mentioned above, systems engineering design has traceability incorporated within the design structure; in other words, every design outcome and decision made is not random, but rational, primarily based on the evolvement of the system requirements through the design process. At the later stages of the design, such as the detailed design stage, a small change in the system specification could cause a significant impact on the whole system. As systems engineers, we always try to identify the causes for changes as early as possible, since the further downstream the changes occur, the more costly they will become. Regarding the required changes, a responsible design engineer or staff member cannot just simply implement the change; a proper procedure has to be followed to minimize the impact on the whole system that has been developed. When incorporating changes, the control process or protocol has to ensure proper traceability from the originating baseline to another, through a formally prepared engineering change proposal (ECP), reviewed by the control change board (CCB). Each change proposal is carefully reviewed in terms of its importance, priority, and impact on the system, TPMs, and life cycle costs. Once approved, the responsible teams then prepare the necessary document, models, tools, and equipment, incorporating the changes into the system configuration. All the data, models, and reports are documented, as well as the communication logs and memos. This procedure is illustrated by Figure 2.7.

2.3.3.4 Detailed Design Review

At the end of the detailed design stage, with all the components selected, it is time to review the final configuration before going into production. The detailed design review is a critical checking point, since it is the final review for the system design phase; sometimes it is also called the critical design review (CDR). The purpose of the critical design review is to formally review all the system components, hardware, and software with the real users, for compliance with all the system specifications. The majority of the design data is expected to be fixed, and the system is evaluated in terms of its functionality, producibility, usability (human factors), reliability, and maintainability. The critical design review usually involves all the stakeholders and the complete set of data, including all the baselines, design drawings, applicable analysis reports and trade studies results, detailed plans on the production, operation, and distribution of the system, and system retirement plans. Human factors professionals need to assess the interaction between the system with the users, in terms of its control and display, dimensions, look and feel, safety features, environment factors, space layouts, training requirements, staffing models, and other human-related factors, under the real operating conditions.

The iterative review, once successful, leads to the approval of the final system configuration, and the system is released to the next phase, full-scale production and distribution.

2.3.4 System Installation and Deployment, Operation, and Maintenance

After the critical design review has approved the final system configuration, the majority of the system design activities have been completed, and it is time for the system to be installed, delivered, or produced. Depending on the type of system, the system may need to be installed at the customer site—for example, building a house—or the system is handed over to a manufacturing facility, the assembly process/mass production starts, and the finished products—such as a new Boeing 787 aircraft or a new iPad—are delivered to customers. At the system installation and deployment phase, system specifications need to be strictly followed and no major changes or modifications are expected. The focus of system installation is on the efficiency and effectiveness of manpower and cost. Supply chain management (SCM) plays a more significant role in the installation process, by defining the optimum procedure and locations for the system components and resources. A similar focus is carried on to the system operations and maintenance phase, which occurs after systems installation and deployment. During the system operations and maintenance stage, systems designers and engineers are primarily concerned about the follow-up evaluation and feedback from the users, to find out how well the system performs at the user’s site and what difficulty users have with the systems. Incidents and accidents need to be documented and investigated, to find their cause and make improvements in the next version of the system. Necessary maintenance and support activities are carried out; for example, recalling faulty components, providing updates/patches, and supporting the system maintenance and warranty activities. These activities are carried out on a continuous basis, possibly until the end of the system life cycle, to provide data for system improvements, materials for training, and, more importantly, for the next version of the system to be more competitive. Techniques that can be used in the system operation and maintenance phase are similar to those in the system design phase, especially in the early conceptual design stage for gathering user needs, such as observation of system operations, surveys and questionnaires, user interviews and focus groups studies, crucial incidents and accidents studies, and related test/evaluation methods. These models will be discussed in more detail in Section II of this book.

2.4 System Engineering Design Process Models

In Section 2.3, we discussed the major steps and milestones of the systems engineering design processes, and provided a basic description and understanding of the activities that are involved in system design. To implement the system design process, it is also important to understand how these different processes and activities are related to one another. In other words, we need to understand the relationships between these activities, how the system evolves from one model to another and the interrelationships between different deliverables. This relationship is captured by systems engineering models. Engineers use these models to provide a management structure to control the efforts that are involved in the system engineering design process. It is a framework to describe the structure of design activities and facilitate communication among team members.

Over the years, many models have been developed for different types of systems and various levels of complexity. It is hard to say which one is better than the others; we do not intend to emphasize any particular ones, but rather provide an overview for the most commonly used models. It is important to keep in mind that all the models are from the same top-down systems design philosophy, yet each has its unique concentration on slightly different aspects. The models described here include the waterfall model, the spiral model, and the vee model.

2.4.1 Waterfall Model

The waterfall model was originally a model for software project development. It has been adopted and widely used for general systems design models due to its simplicity. The key idea of the waterfall model, as its name implies, is that system design systematically progresses from one phase to another, in a downward fashion. The process follows an iterative manner as well; that is, at any phase, the design can go back to its previous phase to adjust the design results based on the feedback received from the review. Figure 2.8 illustrates the structure of a waterfall model.

The first formal description of the waterfall model was presented by Royce (1970). After several years of use, waterfall models received much recognition as well as criticism. As one of the oldest and most popular models used in systems engineering, the waterfall model offers many advantages for managing system design efforts. These advantages include:

1. The model is linear in nature, which makes it simple to understand.
2. A limited amount of resources is needed to implement the model as the model clearly defines efforts and little interaction across stages is needed.
3. The model provides a clear structure for the system design life cycle, making it easy to document; it also provides a clear structure for system intermediate checkpoints and evaluations.

There are also some criticisms of the waterfall model. The main concern is also one of its benefits mentioned above: its simplicity and linear nature. Many believe that it is impossible for any complex design project to follow the waterfall model strictly; it is difficult to finish one phase completely before moving on to the next phase. For large, complex systems, it is not uncommon that users do not know exactly what they want at the beginning of system design. After seeing a number of prototypes, users usually change their requirements or add something new to them. System designers have little control over such changes. If these changes occur later in the waterfall model, the cost incurred could be tremendous and significant delays could result. It is apparent that the waterfall model is not flexible enough to accommodate constant changes, due to its rigid structure and lack of interaction between different phases. This limitation leads researchers to look for more responsive and iterative variations of the waterfall model; the spiral model is one of these variations.

2.4.2 Spiral Model

The spiral model was initially developed for the software development process; it is based on the concept of fast prototyping in the process, combining both the top-down design process from the waterfall model and the bottom-up process from prototype development and evaluation, to quickly address the constant changes and modifications identified from prototype evaluation in the requirements-driven design process. Figure 2.9 illustrates a basic structure for the spiral model.

The spiral model was first proposed by Barry Boehm in 1986. It was found to be beneficial for large, complex system design, especially for information technology (IT)-related projects. The key idea of the spiral model is continuous development through prototyping to manage the risks. Unlike the waterfall model, the system is not completely defined at the beginning, and each of the phases is not completed prior to progressing to the next one; instead, only the most important requirements are addressed, and the detailed requirements are gradually put in place through iterative prototype feedback with user interaction.

The advantage of the spiral model is flexibility. It allows the changes to the design to be implemented at any stage of the design in a relatively quick manner. As the design does not change when completing one phase and moving to the next, but rather is kept open ended during the process, this means that changes may be implemented without impacting the design too significantly. The second benefit of the spiral model is the level of user involvement. Users are involved in the design process by providing feedback on the design prototypes on a continuous basis, thus retaining more control over the direction of the project. With constant interaction, users’ knowledge and understanding of the system requirements will grow as the design progresses, making interaction and communication more effective in the later stages.

The disadvantages of the spiral model are primarily related to its implementation. The model works best for large, complex systems with possibilities to construct prototypes, such as large-scale software engineering projects. It may not be appropriate for small systems that involve little variation to the requirements, since the requirements are not defined rigidly at the beginning of the spiral model, making such systems development less structural. The model also needs extensive skills in risk assessment and management, requires more in-depth modeling and analysis of risks and uncertain factors. Improper assessment of the risks can lead to a significant increase in system costs.

2.4.3 Vee Model

The vee or V-model is another extension of the waterfall model, but instead of strictly following a linear pattern, the design processes are bent upward after the detailed design phase to form a V-shaped process. The vee model establishes a relationship between the phases of system design and its associated phase of verification and validation, which is achieved by testing and evaluation. Figure 2.10 illustrates the vee process model.

The vee model was first developed simultaneously but independently in Germany and the United States. It is now found widely in commercial and defense systems design. On the left-hand side of the V, the system is defined, leading to the system structure and configuration, just as in the early phases of the waterfall model; on the right-hand side of the V, system integration and verification of subsystems and components occur, resulting in operations being verified and validated at the complete system level.

The vee model integrates users and designers by linking the system definition phase and system components verification and validation phases; it focuses on the systems life cycle, just like the waterfall model, but provides a mechanism to quickly address the responsibility between the design and verification; thus, the changes can be implemented more efficiently. Criticisms of the vee model primarily concern the application aspect: it is argued that the model does not address the supporting structure of the design, but focuses on the project rather than the organization, and the concepts of maintainability and supportability of systems are hardly covered. Separate efforts are needed to define these concepts.

It is clear that all the systems design models have their advantages and limitations. When choosing a model in practice, we should keep these advantages and disadvantages in mind. Sometimes it is not uncommon that combinations of different models are used or necessary adaptions are required for the specific needs of the system design. There is no one model that is superior to the others, and designers have to be flexible, making the model serve the design, not vice versa.

2.5 Summary

In this chapter, we have looked at the system life cycle and systems design processes. Systems engineering is a top- down process; it is driven by systems needs and requirements, gradually bringing the system into being via well-defined design phases. It is the only proven method that will efficiently and effectively design a complex system. In this chapter, we introduced the systems life cycle; described the major forms of systems for different system life cycle stages; described the elements that are involved in the system design process, including system need, requirements, functions, components, prototypes, models, and their relationships with regard to different phases of the life cycle; described the system engineering process, defining the main objectives for each of the phases in the design processes, including the main design activities, major milestone baselines, product, and design evaluation approaches applied in each of the phases; and finally, we reviewed the most common models for the systems design process, including the waterfall model, spiral model, and vee model, and their unique features for different types of systems.

Problems

1. What is a life cycle? Describe the general life cycle stages for a system.
2. Describe the waterfall model, spiral model, and vee model, and their unique characteristics.
3. What is a system requirement? What is a function? Give an example of a system function.
4. Describe the system user classes.
5. List the major system design processes and describe the purposes and major output for each of these processes.
6. Describe the system functional model, operational model, and physical model. What is the relationship between these models?
7. Define model-based systems engineering (MBSE).