Engineering Disciplines Other than Systems Engineering
Engineering disciplines are mostly component-oriented and value-neutral in their intellectual content (Boehm and Jain 2006). Their underlying laws and equations, such as Ohm’s Law, Hooke’s Law, Newton’s Laws, Maxwell’s equations, the Navier-Stokes equations, Knuth’s compendia of sorting and searching algorithms, and Fitts’s Law of human movement, pertain to performance in a system of interest. They do not address how that performance contributes to the value propositions of stakeholders.
In contrast, SE is more holistic than component-oriented, and more stakeholder value-oriented than value-neutral performance-oriented in its intellectual content. Realizing successful systems requires reasoning with stakeholders about the relative value of alternative realizations, and about the organization of components and people into a system that satisfies the often-conflicting value propositions of stakeholders. Stakeholders who are critical to the system’s success include funders, owners, users, operators, maintainers, manufacturers, and safety and pollution regulators.
In some disciplines, the engineer evaluates and integrates design elements into a system that satisfies proxies of value. The wider the scope of the system of interest, the broader the set of SE skills the engineer needs.
For example, an aeronautical engineer might integrate mechanical, electrical, fluid, combustion-chemical, software, and cockpit design elements into a system that satisfies proxies of value like flight range, payload capacity, fuel consumption, maneuverability, and cost of production and maintenance. In so doing, the engineer operates partly as a systems engineer. The system of interest is the aircraft itself and the engineer applies aircraft-domain expertise.
However, the same engineer could participate in the engineering of passenger services, airport configurations, baggage handling, and local surface transportation options. All of these contribute to the value propositions of success-critical stakeholders. The systems of interest are wider, and the engineer needs broader SE knowledge, skills, and abilities to operate as a systems engineer.
The aircraft-domain expertise remains needed for effective engineering of the wider systems. As discussed in (Guest 1991), most good systems engineers are “T-shaped” people, with both a working knowledge of wider-system considerations, and a deep expertise in a relevant domain, such as aeronautical, manufacturing, software, or human factors engineering.
Engineering disciplines that are intertwined with SE include software engineering (SwE), human factors engineering, and industrial engineering. Software engineering (SwE) and SE are not just allied disciplines, they are intimately intertwined (Boehm 1994).
Most functionality of commercial and government systems is now implemented in software, and software plays a prominent or dominant role in differentiating competing systems in the marketplace. Software is usually prominent in modern systems architectures and is often the “glue” for integrating complex system components.
The scope of SwE includes both software SE and software construction, but does not include hardware SE. Thus neither SwE nor SE is a subset of the other. For a definition of the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK), which is published by the Institute of Electrical and Electronics Engineers (IEEE) (Abran et al. 2004) and is currently under revision.
Human factors engineering, from micro-ergonomics to macro-ergonomics, is intertwined with SE (Booher 2003; Pew-Mavor 2007).
Industrial engineering overlaps significantly with SE in the industrial domain, but also includes manufacturing and other implementation activities outside of SE.
Finally, to field a successful system, a systems engineer may need to know one or more of the many specialty fields in engineering, e.g., security, safety, reliability, availability, and maintainability engineering. Most of these are considered professional disciplines in their own right and many have their own bodies of knowledge. For explanations of how these disciplines relate to SE, overviews of what most systems engineers need to know about them, and references within their bodies of knowledge.
Non-Engineering Disciplines
SE is intimately intertwined with two non-technical disciplines: technical management (TM), and procurement and acquisition (also known as acquisition and procurement).
Technical management often falls within the purview of a systems engineer. Many SE textbooks, competency models, and university programs include material about TM. TM is a specialization of project management (PM). SE and PM have significant common content in TM, but neither is a subset of the other. For a definition of the relationship between the SEBoK and the Guide to the Project Management Body of Knowledge, which is published by the Project Management Institute (PMI) (PMI 2008).
Procurement and acquisition practitioners draw upon SE to determine the scope and overall requirements of the system to be procured or acquired. They then prepare requests for proposals and statements of work, determine evaluation criteria, and design source selection processes. Once a leading source is selected, they decide upon contracting options that encompass payments, reviews, audits, incentive fees, acceptance criteria, procedures, and the nature of deliverables. Finally, they monitor progress with respect to plans (including those for SE), and negotiate and execute changes and corrective actions. Many of these activities amount to specialty disciplines within procurement and acquisition.