Difference between revisions of "Scope of the SEBoK"

From SEBoK
Jump to navigation Jump to search
Line 28: Line 28:
 
Again, a convenient way to define the scope of SE within the ES domain is to develop a Venn diagram showing the relations among SE, Systems Development, and Project/Systems Management.  Here also, activities outside the SE boundary are still important SE environment considerations, such as analyzing alternative methods for production, testing, and operations.  Note that Software Engineering also includes the software parts of Systems Development.  It is not a subset of Systems Engineering.  
 
Again, a convenient way to define the scope of SE within the ES domain is to develop a Venn diagram showing the relations among SE, Systems Development, and Project/Systems Management.  Here also, activities outside the SE boundary are still important SE environment considerations, such as analyzing alternative methods for production, testing, and operations.  Note that Software Engineering also includes the software parts of Systems Development.  It is not a subset of Systems Engineering.  
  
[[File:Scope_BoundariesSE_PM_SM.png|750px|frame|center|System Boundaries of Systems Engineering, Systems Development, and Project/Systems Management (Figure Developed for BKCASE)]]
+
[[File:Scope_BoundariesSE_PM_SM.png|500px|frame|center|System Boundaries of Systems Engineering, Systems Development, and Project/Systems Management (Figure Developed for BKCASE)]]
  
 
Previous INCOSE elaborated definitions of SE have emphasized sequential performance of SE activities (…documenting requirements, then proceeding with design synthesis…).  For the SEBoK, we have emphasized the inevitable intertwining of system requirements definition and system design in the following revised definition of SE:
 
Previous INCOSE elaborated definitions of SE have emphasized sequential performance of SE activities (…documenting requirements, then proceeding with design synthesis…).  For the SEBoK, we have emphasized the inevitable intertwining of system requirements definition and system design in the following revised definition of SE:

Revision as of 19:41, 25 July 2011

The scope of SE and the SEBoK does not include all classes of systems. It focuses on the domain of Engineered Systems. A convenient way to define the scope of SE and the SEBoK is to relate Engineered Systems to the two other main systems domains, Natural Systems and Social Systems, as shown in the figure below.

System Boundaries of Engineered Systems, Social Systems, and Natural Systems (Figure Developed for BKCASE)

For Engineered Systems (ES) and Social Systems (SS), the best way to define the domain scope is to identify the types of systems for which they have authority to commit and manage resources for system creation and sustainment, and responsibility for the results. Purely technical systems such as bridges, electric autos, and power generation and distribution systems are exclusively in the ES domain, while purely human systems such as legislatures, conservation foundations, and the United Nations (UN) Security Council are exclusively in the SS domain. Systems that exist naturally such as the real number system, the solar system, and watersheds are exclusively in the Natural Systems (NS) domain. They are called systems, but exist outside of human control.

Systems common to both the SS and ES domains such as water and power management and safety governance systems, and water and power safety assurance systems, are often called sociotechnical systems. The behavior of systems common to the ES and NS domains such as dams and flood control systems is determined both by the nature of the dam and flood control system construction and by the nature of the water supply occurring naturally within the watershed. Systems such as the watershed that are outside the ES domain boundary are still important to the ES domain, but as part of its environment. As a resulting definition,

An Engineered System (ES) is a technical or sociotechnical aggregation of physical, informational, and human elements that exhibit emergent properties not exhibited by the individual elements. Its characteristics include being created by and for people; having a purpose, with multiple views; satisfying key stakeholders’ value propositions; having a life cycle and evolution dynamics; having a boundary and an external environment; and being a part of a system-of-interest hierarchy.

Counterpart definitions of Natural Systems, Social Systems, and Systems are:

A Natural System (NS) is a system whose elements, boundary, and relationships exist independently of human control. Examples: the real number system, the solar system, planetary atmosphere circulation systems.

A Social System (SS) is a system that includes humans as elements.

A Sociotechnical System is a system that is both an engineered system and a social system.

A system is a set of system elements within a system boundary defined by a set of membership criteria, and a set of relationships satisfied by the elements within the boundary.

Scope of Systems Engineering (SE) within the ES Domain.

However, the scope of SE does not include the entire ES domain. Activities such as system construction, manufacturing, and their funding and management are similarly part of the SE environment, but (other than the management of the SE function) not a part of SE. As is reflected in the International Council on Systems Engineering (INCOSE) top-level definition of systems engineering (INCOSE 2010):

An interdisciplinary approach and means to enable the realization of successful systems,

SE can enable the realization of successful systems, but cannot ensure a successful realization if the systems’ funding, development, and manufacturing are poorly managed and executed.

Again, a convenient way to define the scope of SE within the ES domain is to develop a Venn diagram showing the relations among SE, Systems Development, and Project/Systems Management. Here also, activities outside the SE boundary are still important SE environment considerations, such as analyzing alternative methods for production, testing, and operations. Note that Software Engineering also includes the software parts of Systems Development. It is not a subset of Systems Engineering.

System Boundaries of Systems Engineering, Systems Development, and Project/Systems Management (Figure Developed for BKCASE)

Previous INCOSE elaborated definitions of SE have emphasized sequential performance of SE activities (…documenting requirements, then proceeding with design synthesis…). For the SEBoK, we have emphasized 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:

  • Performance and Mission Effectiveness
  • Verification and Validation
  • Development and Production
  • Training and Support
  • Operations and Maintenance
  • Disposal
  • Life Cycle Cost and Schedule

Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured system definition process that covers concept definition to production to operation for each evolutionary increment. Systems engineering considers both the business and the technical needs of all key stakeholders with the goal of providing a quality system that satisfactorily addresses the full set of stakeholder needs.

Part 2 of the SEBoK, Systems, elaborates on the definitions above and offers additional definitions and elaborations, providing further context for the rest of the SEBoK.

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.

Additional References

All additional references should be listed in alphabetical order.

INCOSE. 2010. INCOSE systems engineering handbook, version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.


Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->