Difference between revisions of "Systems Engineering Overview"
Line 13: | Line 13: | ||
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. | 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. | ||
+ | |||
+ | [[File:Scope_SystemBoundaries.png|frame|500px|center|'''Figure 1. System Boundaries of Engineered Systems, Social Systems, and Natural Systems.''' (SEBoK Original)]] | ||
+ | |||
+ | The nature of and relationships between these system domains is discussed in [[Systems|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 [[Systems Engineering and Management|Part 3, Systems Engineering and Management]], and [[Applications of Systems Engineering|Part 4, Applications of Systems Engineering]] is on how to create or change an ES to fulfill the goals of stakeholders within these wider system contexts. The knowledge in [[Enabling Systems Engineering|Part 5, Enabling Systems Engineering]] and [[Systems Engineering and Other Disciplines|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 2011) 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. | ||
+ | |||
+ | [[File:Scope_BoundariesSE_PM_SM.png|thumb|600px|center|'''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 2011) 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: | ||
+ | |||
+ | <blockquote>''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 2011, modified) </blockquote> | ||
+ | |||
+ | [[Systems Engineering and Management|Part 3, Systems Engineering and Management]], elaborates on the definition above to flesh out the scope of SE more fully. | ||
− | |||
==References== | ==References== |
Revision as of 19:14, 28 August 2012
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.
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 ES 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 2011) 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.
Traditional definitions of SE have emphasized sequential performance of SE activities, e.g., “documenting requirements, then proceeding with design synthesis …”. (INCOSE 2011) 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 2011, modified)
Part 3, Systems Engineering and Management, elaborates on the definition above to flesh out the scope of SE more fully.
References
Works Cited
None.
Primary References
None.
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