A Guide to the Systems Engineering Body of Knowledge (SEBoK)

by Rob Leibrandt

Purpose

A comprehensive guide will provide a singular resource for understanding the extent of the practice of Systems Engineering for a spectrum of purposes. These purposes may include accomplished systems engineers seeking more in-depth information in a particular area of the discipline or just in time performance support or other engineering disciplines performing systems engineering tasks. Just as likely the interested neophyte or potential consumer of systems engineering services may wish to learn more about the discipline. It is critical for this guide to be both simplistic and comprehensive. The tools to accomplish this layering do exist and will be applied to intermediate and long-term evolutions of this guide.

The structure of the SEBoK Guide is intended to foster inclusion rather than strictly defining what is and is not systems engineering. It would be very difficult and not entirely productive to reach consensus on a single process due simply to the diversity of the applications and the varying complexity of the systems to which the discipline is applied.

Context

What is/isn’t the SEBoK Guide?

The SEBoK Guide is INCOSE’s attempt to provide a service for its members as well as service to non-members. You will find this guide helpful in understanding not only systems engineering, but also the roles that INCOSE and its members play in promoting the discipline of systems engineering.

We have organized the guide to allow both discrete fact-finding on an aspect of systems engineering and broad inquiry. This guide is a holistic approach to the study and application of systems engineering and is not a “cookbook” that prescribes how systems engineering must be accomplished.

What is unique about the SEBoK Guide?

This guide seeks to define systems engineering broadly, in terms of its concepts, processes, skills required and capability. In addition, this guide provides substantial linkage to related works. Through the use of this guide you can:

· Gain an understanding of the overall and specific aspects of systems engineering

· Investigate the discipline from a functional, product or process perspective

· Comprehend the integrative nature of systems engineering through linkage to related disciplines and where applicable their bodies of knowledge

· Access available articles, papers, member authored texts and distance learning products

· Study existing standards and developing standards

· Interact with authors, members and leadership through discussion groups and forums

When is the SEBoK guide useful?

This is highly dependent on the user impetus. The following categories of users/uses are provided for illustration.

Possible User Types	Possible Uses
Novice	Explore the discipline Determine applicability
Licensing or Certification	Determination of professional standards
Services Acquirer	Source selection Evaluation of sources and techniques Services evaluation
Practitioner	Expansion of knowledge Specific problem solving Identification and evaluation of sources and techniques
Academician	Referencing Curriculum/course development Expansion of knowledge
Learner	Expansion of knowledge Accomplishment of corporate or certification requirements Verification of derived knowledge

Doesn’t this knowledge already exist?

The supporting body of work referenced in the guide is referred to as the “systems engineering body of knowledge”. The processes, lessons learned, products and standards have been developed since the 1930s. The guide does not create extensive new work, however it does provide organization and context for the information.

I. Systems Engineering Fundamentals

by Terry Bayhill, Phil Brown, Dennis Buede, James Martin

Systems Engineering, like other engineering disciplines, is concerned with putting scientific knowledge to practical uses. SE is a knowledge creating process set in motion by a customer or sponsor defining an objective to be achieved, for example, flying a man to the moon. Output from the process is multilevel, highly precise, and highly consistent information characterizing the objective system.

Definition of a system

A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected (Rechtin, 2000). While the designers of a system typically address the purpose of the system that they are trying to achieve during the design phase, the purpose of the system (that is delivered) is what the system does (POSIWID).

Systems Engineering

Systems Engineering is a holistic, product oriented engineering discipline whose responsibility is to create and execute an interdisciplinary process to ensure that customer and stakeholder needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system’s life cycle.

The role of science is to determine “what is” by determining the “laws” of science through the development of theoretical hypotheses and experimentation. All engineering is concerned with the application of knowledge and concepts from science and mathematics. Traditional engineering design of components uses scientific principles to create solutions to a specification or “what can be”. Systems engineering plays the interface between component engineering (the people in search of physical solutions) and society (the people with a need). These systems engineers work with both groups to determine “what should be” or the set of requirements for the solution to the need.

Science determines what
IS…

Component engineering determines what
CAN BE…

Systems engineering determines what
SHOULD BE.

Systems engineering brings two elements to a development project that are not usually present. First, systems engineering brings a disciplined focus on the end product, to include:

(a) Its enabling products, and

(b) Its internal and external operational environment (i.e., a system view).

The end product, of course, is the thing that performs the system mission. The enabling products are what enable the developer to produce, test, deploy, install, operate and support the end product. The operational environment involves the interactions that cross the system boundary.

Second, systems engineering brings a consistent vision of stakeholders’ expectations independent of daily project demands (i.e., the system’s purpose or mission).

With this notion of engineering integration discussed above, it may appear that there is an inherent conflict between systems engineering and project management. In practice, this conflict often leads to confusion over roles and responsibilities and, as a result, the project suffers in terms of low morale, lower productivity, and inferior quality product.

In reality there should be no conflict. There is a need for both project management and systems engineering on development projects. The project manager should focus on the acquisition of resources (people, tools, facilities, funds, etc.) and protection of these resources from competing projects. He acts as the chief spokesman to upper management as to the importance and criticality of the project and how it fits into the overall strategic intent of the enterprise.

The systems engineer, on the other hand, is responsible for the efficient and effective use of these resources (working closely with the program manager), in addition to making sure the system meets the needs and expectations of stakeholders. Roughly speaking:

Project Management ensures that the trains run on time…

Systems Engineering ensures that the trains run at all.

Primer on Systems Engineering Activities

One perspective is that this process consists of the following seven tasks: State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re-evaluate. These functions are captured in the acronym SIMILAR: State, Investigate, Model, Integrate, Launch, Assess and Re-evaluate. The SIMILAR process is diagrammed in Figure 1. The linearity of the functions depicted does Not represent sequential performance of the tasks. Functions are performed in parallel and repetitively, as better information on the objective system becomes available in any task area.

Figure 1. The Systems Engineering Process

from A. T. Bahill and B. Gissing, Re-evaluating systems engineering concepts using systems thinking, IEEE Transaction on Systems, Man and Cybernetics, Part C: Applications and Reviews, 28(4), 516-527, 1998.

State the Problem

The problem statement starts with a description of the top-level functions that the system must perform: this might be in the form of a vision, mission statement and mission requirements, a set of scenarios for how the system will be used and how it interacts with other systems or a description of the deficiency that must be ameliorated. Most mandatory and preference requirements should be traceable to this problem statement. Acceptable systems must satisfy all mandatory requirements. The preference requirements are traded-off to find the preferred alternatives. The problem statement should be in terms of what must be done, not how to do it. Inputs come from end users, operators, maintainers, suppliers, acquirers, owners, regulatory agencies, victims, sponsors, manufacturers and other stakeholders. The output problem statement should express customer requirements as characteristics (quality, quantity and timing) of these outputs. There are also system-wide requirements such as availability. These requirements can be composed in words or as a model.

Investigate Alternatives

Alternative solutions are created and are evaluated based on performance, schedule, and cost figures of merit. No single solution is likely to be the best across all the figures of merit. Multi-criteria decision-aiding techniques are available to help discover the preferred alternatives. This analysis should be repeated, as better data becomes available. For example, figures of merit should be computed initially based on estimates by the engineering design team. As the project evolves, models should be constructed and evaluated; simulation data should be collected and analyzed, and prototypes should be built and measured. Finally, tests should be run on the real system. Alternatives should be judged for compliance of capability against requirements. For the design of complex systems, alternative designs reduce project risk. Investigating innovative alternatives helps clarify the problem statement.

Model the Systems

Models will be developed for most alternate designs of the product system. The model for the preferred alternative will be expanded and used to help manage the system throughout its entire life cycle. Many types of system models are used, such as physical analogs, analytic equations, state machines, block diagrams, functional flow diagrams, object-oriented models, computer simulations and mental models.

Systems Engineering is responsible for creating (developing) a product and also processes for producing, deploying, training, refining, and retiring it. So, models should also be constructed for each of these processes. Development process models allow us, for example, to study scheduling changes, create dynamic PERT charts and perform sensitivity analyses to show the effects of delaying or accelerating certain subprojects. Running the process models reveals bottlenecks and fragmented activities, reduces cost and exposes duplication of effort. Product models help explain the system. These models are also used in tradeoff studies and risk management.

As previously stated, the Systems Engineering Process is not sequential. It is parallel and iterative. The complex interrelationship between creating and improving models throughout the process of developing and selecting alternatives is a good example of the dynamic nature of the systems engineering process.

Integrate

No man is an island. Systems, businesses and people must be integrated so that they interact with one another. Integration means bringing things together so they work as a whole. Interfaces between subsystems must be designed to facilitate the movement of physical items, information and energy. Subsystems should be defined along natural boundaries. Subsystems should be defined to minimize the amount of information, physical items and energy to be exchanged between the subsystems via interfaces. Well-designed subsystems send finished products to other subsystems. Feedback loops around individual subsystems are easier to manage than feedback loops around interconnected subsystems. Processes of co-evolving systems also need to be integrated. The consequence of integration is a system that is built and operated using efficient processes.

Typical products produced by the systems engineering process are a mission statement, a requirements document including verification and validation methods, a description of functions and objects, figures or merit, a test plan, a drawing of system boundaries, an interface control document, a listing of deliverables, models, a sensitivity analysis, a tradeoff study, a risk analysis, a life cycle analysis and a description of the physical architecture. The requirements should be validated (Are we building the right system?) and verified (Are we building the system right?). The system functions should be mapped to the physical components. The mapping of functions to physical components can be one to one or many to one. But if one function is assigned to two or more physical components, then a mistake might have been made and it should be investigated. One valid reason for assigning a function to more than one component would be that the function is preformed by one component in a certain mode and by another component in another mode. Another would be deliberate redundancy to enhance reliability, allowing one portion of the system to take on a function if another portion fails to do so.

Launch the System

Launching the system means using the system to obtain results. This is where the design team learns if the system does what it was intended to do. This phase includes the system engineering of deploying multi-site, multi-cultural systems.

This phase is where the preferred alternative is designed in detail; components are built or bought (Commercial Off-The Shelf - COTS), components are integrated and sub-system elements tested at various levels leading to the certified product. In parallel, the processes necessary for assembling and deploying the system are developed – where necessary - and applied so that the product can be produced and deployed. In addition, training systems (if necessary) must be designed and produced for operators or maintainers.

In designing and producing the product, due consideration is given to its interfaces with operators (humans, who will need to be trained) and other systems with which the product will interface. In some instances, this will cause interfaced systems to co-evolve. The process of designing, developing and producing the system is iterative to accommodate new knowledge developed along the way to be incorporated in an improved system.

Assess Performance

Figures of merit, technical performance measures and metrics are all used to measure performance. Figures of merit are used to quantify requirements in the tradeoff studies. They usually focus on the product. Technical performance measures are used to monitor system performance during the design, development and manufacturing. Metrics (including customer satisfaction comments, productivity, number of problem reports, or whatever one believes is critical to a venture’s success) are used to help manage organization processes.

Measurement is the key. If you cannot measure it, you cannot tell success from failure and therefore cannot control it. If you cannot control it, you cannot improve it. Important resources such as weight, volume, price, communications bandwidth and power consumption should be managed. Each subsystem is allocated a portion of the total budget and the project manger is allocated a reserve. These resource budgets are managed throughout the system life cycle.

Re-evaluate

Re-evaluate is arguably the most important of these functions. Since the first systems developed by the ancient engineers in Egypt, Greece and Rome, improved designs have been the result of feeding back what was learned in testing and using previously developed systems. Feedback is one of the most fundamental engineering tools. Re-evaluation should be a continual process with many parallel loops. Re-evaluate means observing outputs and using this information to modify the system, the inputs, the product or the process. The Systems Engineering process illustrated in Figure 1 clearly shows the distributed nature of the re-evaluate function in the feedback loops. It is not necessary for all these loops be used. The actual loops used are unique to the particular problem being solved.

Variations

Like all processes, good engineering practice dictates that the Systems Engineering processes implemented by an organization should be documented, measurable, stable, of low variability, used consistently throughout an organization, adaptive, and tailorable! This may seem like a contradiction. And perhaps it is. But one size does not fit all. The above description of the Systems Engineering process is one of many that have been formulated. Some are more complex and some are simpler. But all contain elements of the process discussed above.

Important Concepts of Systems Engineering

Throughout this introduction a number of important concepts related to a system have been mentioned. The following concept map highlights the relationships between pairs of these concepts.

The important concepts for systems engineering are shown here: