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 an engineered system, a natural system, a social system, or 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”.
Some special meanings or terms reflect the historical evolution of SE. “Systems architecting” was introduced in (Rechtin 1991) to embody the idea that better systems resulted from concurrently rather than sequentially addressing a system’s operational concept, requirements, structure, plans, and economics. “Soft SE” was introduced in (Checkland 1981) to express the criticality of human factors in SE. In both cases, the emphases that these terms imply are now accepted as integral to SE.
Since the province of SE is 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 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. For more on SE see Part 3.
Scope of Systems Engineering within the Systems Domain
While considering all classes of systems, SE focuses on the domain of the engineered systems (ES). Sociotechnical systems are treated as a special form of engineered system. The differences and commonalities in scope of the three overall categories of systems — engineered, natural, and social — are depicted in Figure 2 below. (The figure is one of many possible versions of a Venn diagram where the underlined headings are always "natural systems", "engineered systems", and "social systems", while the bullet points listing instances of systems within and across those categories, could change with each new version.)
This picture provides a convenient tool for understanding the scope of an engineered system. For example, power generation and distribution systems are purely ESs which include software and human operators as well as hardware. Water and power safety legislation comes from the political processes of a legislature, which is a social system. The resulting water and power safety assurance and safety governance systems are sociotechnical systems whose participants work in both engineered systems and social systems.
The nature of and relationships between these system domains is discussed in Part 2, which considers the general nature and purpose of systems and how these ideas are used to ensure a better ES. Part 2 covers:
- Systems thinking – a way of understanding complex situations by looking at them as combinations of systems
- Systems science – a collection of disciplines that have created useful knowledge by applying systems thinking and the scientific method to different aspects of the system domains
- Systems approach – a way of tackling real-world problems which uses the tools of system science to enable systems to be engineered and used.
One must understand both natural and sociotechnical systems to identify and scope the engineering of system problems or opportunities. This scoping largely determines whether engineered systems achieve their goals, without adverse impact on other outcomes, when those systems are deployed in the real world.
The primary focus of 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.
Again, 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