Systems Engineering Overview

Systems Engineering

Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. Successful systems must satisfy the needs of its customers, users and other stakeholders. Some key elements of systems engineering are highlighted in Figure 1 and include:

• The principles and concepts that characterize a system, where a system is an interacting combination of system elements to accomplish a defined objective(s). The system interacts with its environment that may include other systems, users, and the natural environment. The system elements that compose the system may include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements.
• A systems engineer is a person or role who supports this interdisciplinary approach. In particular, the systems engineer often serves to elicit and translate customer needs into specifications that can be realized by the system development team.
• In order to help realize successful systems, the systems engineer supports a set of life cycle processes beginning early in conceptual design and continuing throughout the life cycle of the system through its manufacture, deployment, use and disposal. The systems engineer must analyze, specify, design, and verify the system to ensure that its functional, interface, performance, physical, and other quality characteristics, and cost are balanced to meet the needs of the system.
• A system engineer helps ensure the elements of the system fit together to accomplish the objectives of the whole, and ultimately satisfy the needs of the customers and other stakeholders who will acquire and use the system.

Figure 1. Key Elements of Systems Engineering. (SEBoK Original)

Systems and Systems Engineering

When we speak of a “system,” we may mean an engineered system, a natural system, a social system, or all three.

Since the province of Systems Engineering (SE) is engineered systems, most SE literature assumes that this is the context. 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).

This may produce ambiguities at times: for example, does “management” refer to management of the SE process, or management of the system being engineered? In such cases, the SEBoK tries to avoid misinterpretation by elaborating the alternatives into “system management” or “systems engineering management.”

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.”

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.

An extensive Glossary 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 systems engineering 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 1 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 engineered systems 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.

Figure 2. System Boundaries of Engineered Systems, Social Systems, and Natural Systems. (SEBoK Original)

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 2 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 2, system implementation engineering also includes the software production aspects of system implementation. Software engineering, then, is not considered a subset of SE.

Figure 2. System Boundaries of Systems Engineering, Systems Implementation, and Project/Systems Management. (SEBoK Original)

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.

References

Works Cited

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.

---

< Previous Article | Parent Article | Next Article >

SEBoK v. 1.9.1 released 30 September 2018

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