Systems Engineering Overview
Systems engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. Successful systems must satisfy the needs of their customers, users and other stakeholders. This article provides an overview SE as discussed in the SEBoK and the relationship between SE and systems (for additional information on this, please see Part 2).
Systems and Systems Engineering
In the broad community, the term system “system,” may mean a collection of technical, natural or social elements, or a combination of all three. This may produce ambiguities at times: for example, does “management” refer to management of the SE process, or management of the system being engineered? As with many special disciplines, SE uses terms in ways that may be unfamiliar outside the discipline. For example, in systems science and therefore SE, “open” means that a system is able to interact with its environment--as opposed to being "closed” to its environment. But in the broader engineering world we would read “open” to mean “non-proprietary” or “publicly agreed upon.” In such cases, the SEBoK tries to avoid misinterpretation by elaborating the alternatives e.g. “system management” or “systems engineering management”.
The SEBoK seeks to position SE within the broader scope of knowledge which considers systems as part of its foundations. To do this without attempting to re-define general systems terminology SEBoK introduces two related definitions specific to SE:
- An Engineered Systems (glossary), is a technical or Sociotechnical systems system which is the subject of an SE life cycle
- An Engineered Systems Context (glossary) centres around an engineered system but also includes its relationships other engineered, social or natural systems in one or more defined environments.
Since the province of SE is an engineered systems, most SE literature assumes this in its terminology. Thus, in an SE discussion, “system architecture” would refer to the architecture of the system being engineered (e.g., a spacecraft) and not the architecture of a natural system outside its boundary (e.g., the solar system). In fact, a spacecraft architecture would cover the wider system context including external factors such as changes in gravity and external air pressure and how these affect the spacecraft's technical and human elements. Thus, the term "system architecture" more properly refers to the engineered system context. The SEBoK tries to be more explicit about this, but may still make these kinds of assumption when referring directly to other SE literature.
An extensive glossary of terms identifies how terms are used in the SEBoK, and shows how their meanings may vary in different contexts. As needed, the glossary includes pointers to articles providing more detail.
For more about the definition of systems, see the article What is a System? in Part 2. The primary focus of SEBoK Part 3: Systems Engineering and Management, and Part 4: Applications of Systems Engineering is on how to create or change an engineered system to fulfill the goals of stakeholders within these wider system contexts. The knowledge in Part 5: Enabling Systems Engineering and Part 6: Systems Engineering and Other Disciplines examines the need for SE itself to be integrated and supported within the human activity systems in which it is performed, and the relationships between SE and other engineering and management disciplines.
Scope of Systems Engineering within the Engineered Systems Domain
The scope of SE does not encompass the entire ES domain. Activities can be part of the SE environment, but other than the specific management of the SE function, not considered to be part of SE. Examples include system construction, manufacturing, funding, and general management. This is reflected in the International Council on Systems Engineering (INCOSE) top-level definition of systems engineering as, “an interdisciplinary approach and means to enable the realization of successful systems.” (INCOSE 2012) Although SE can enable the realization of a successful system, if an activity that is outside the scope of SE, such as manufacturing, is poorly managed and executed, SE cannot ensure a successful realization.
This is a convenient way to define the scope of SE within the ES domain is to develop a Venn diagram. Figure 3 shows the relationship between SE, system implementation, and project/systems management. Activities, such as analyzing alternative methods for production, testing, and operations, are part of SE planning and analysis functions. Such activities as production line equipment ordering and installation, and its use in manufacturing, while still important SE environment considerations, stand outside the SE boundary. Note that as defined in Figure 3, system implementation engineering also includes the software production aspects of system implementation. Software engineering, then, is not considered a subset of SE.
Traditional definitions of SE have emphasized sequential performance of SE activities, e.g., “documenting requirements, then proceeding with design synthesis …”. (INCOSE 2012) The SEBoK authors depart from tradition to emphasize the inevitable intertwining of system requirements definition and system design in the following revised definition of SE:
Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal. (INCOSE 2012, modified)
Part 3: Systems Engineering and Management, elaborates on the definition above to flesh out the scope of SE more fully.
Systems Engineering and Engineered Systems Project Life Cycle Context
Figure 1 summarizes the main agents, activities, and artifacts involved in the life cycle of SE, in the context of a project to create and evolve an ES.
For each primary project life cycle phase, we see activities being performed by primary agents, changing the state of the ES.
- Primary project life cycle phases appear in the leftmost column. They are system definition, system initial operational capability (IOC) development, and system evolution and retirement.
- Primary agents appear in the three inner columns of the top row. They are systems engineers, systems developers, and primary project-external bodies (users, owners, external systems) which constitute the project environment.
- The ES, which appears in the rightmost column, may be a product, a service, and/or an enterprise.
In each row:
- boxes in each inner column show activities being performed by the agent listed in the top row of that column
- the resulting artifacts appears in the rightmost box.
Arrows indicate dependencies: an arrow from box A to box B means that the successful outcome of box B depends on the successful outcome of box A. Two-headed arrows indicate a two-way dependencies: an arrow that points both from box A to box B and from box B to box A means that the successful outcome of each box depends on the successful outcome of the other.
For example, consider how the inevitable changes that arise during system development and evolution are handled:
- One box shows that the system’s users and owners may propose changes.
- The changes must be negotiated with the systems developers, who are shown in a second box.
- The negotiations are mediated by systems engineers, who are shown in a third box in between the first two.
- Since the proposed changes run from left to right and the counter-proposals run from right to left, all three boxes are connected by two-headed arrows. This reflects the two-way dependencies of the negotiation.
An agent-activity-artifact diagram like Figure 1 can be used to capture complex interactions. Taking a more detailed view of the present example demonstrates that:
- The system’s users and owners (stakeholders) propose changes to respond to competitive threats or opportunities, or to adapt to changes imposed by independently evolving external systems, such as Commercial-off-the-Shelf COTS products, cloud services, or supply chain enablers.
- Negotiation among these stakeholders and the system developers follows, mediated by the SEs.
- The role of the SEs is to analyze the relative costs and benefits of alternative change proposals, and synthesize mutually satisfactory solutions.
References
Works Cited
Checkland, P. 1981. Systems Thinking, Systems Practice. Hoboken, NJ, USA: Wiley.
INCOSE. 2012. Systems Engineering Handbook, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.
Rechtin, E. 1991. Systems Architecting. Upper Saddle River, NJ, USA: Prentice Hall.
Primary References
INCOSE. 2012. Systems Engineering Handbook, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.
Additional References
None.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus