Misperceptions of Systems Engineering - 5: Boundaries
This is the fifth in a series of short articles.
Are system boundaries a necessary system element/feature/construct for defining “systems”, even if only conceptual?
In system science it may be the case that the system we are describing has no clear boundaries, and the “system” is defined by the constituent components and their relationships with each other. This is especially true for natural systems where the concept of “purpose” must be imputed by intelligent agents and there may not be clear functions or outputs. For example, the earth’s “solar system” is defined primarily by its constituents (sun, planets, asteroids, comets, and related objects primarily influenced by the solar gravity). Even here, however, there is discussion regarding the conceptual “boundary” of the solar system; that is, the scope of influence of the sun’s gravitational field.
In engineered systems, we typically begin with “purpose”, a measurable output of the system-of-interest that has value to one or more stakeholders. Such an output requires an ability to measure it, which means we must observe it at some location, whether physical or conceptual. This leads directly to a need to define the scope of the system-of-interest: what is inside and what is outside the system. This is necessary especially in development and acquisition activities to ensure agreement among stakeholders (especially acquirer and supplier) regarding what is being developed and delivered. Misunderstandings can lead to programmatic problems (late deliveries, over-budget expenditures, and incorrect output or performance) and dissatisfaction.
Once we can identify “inside” vs. “outside” we are able to describe our boundary as that which demarcates “inside” from “outside”. Such a boundary may be physical, as in many aerospace, transportation, or software products. Or the boundary may be conceptual, as is often the case in organizations where the boundary is not typically defined by the extent of a building, especially for global enterprises and networked organizations. Yet, each of these should still have outputs of value delivered to one or more stakeholders who exist on the Outside of the system.
Having a clear boundary with observable functions and outputs is the basis for verifying and validating any requirements for the system. Otherwise we have no basis for measurement and the related determination of pass/fail with respect to defined criteria, also known as the “requirements”. This also leads to the notion that all valid system functions must be observable at the boundary. And this quest for observability of functions may help identify and define the boundary.
Having a clear boundary with interfaces to the context (for providing inputs to the system and receiving system outputs) also enables us to validate any proposed subsystems which decompose the system. Such subsystems must collectively implement the system interfaces as we define and refine the system architecture. But the system boundary must be defined prior to defining any subsystems; otherwise, we cannot know if such a subsystem is necessary, let alone sufficient with respect to solving the problem at hand.
In summary, effective systems engineering requires the identification of the boundary and related inputs and outputs (deliverables) of a system-of-interest if we are to make progress in engineering such systems to solve problems.
References:
- INCOSE, “Systems Engineering Handbook”, INCOSE-TP-2003-002-04, v. 4 (2015), page 6.
- Carson, Ronald S., “Keeping the Focus During Requirements Analysis”, Proceedings of the International Council on Systems Engineering (INCOSE), 2001 (Melbourne, Victoria, Australia).
- Carson, Ronald S. and Robert A. Noel, “Formalizing Requirements Verification and Validation”, Proceedings of the International Council on Systems Engineering (INCOSE), 2018 (Washington, DC, USA).
+1 I would have used the example of solar system. physics is all about studying what goes in and out (including influence) systems that are only defined by "everything that is not outside of it" and forgettung about the other system (that is outside)
Amazing...i wrote the same thing with you. Please give some comments It is widely be identified by us human that system as a whole is comprised with elements or entities to achieve some purposes by specific conditions. System is an integrated abstract concept which can be applied in any form such as mechanical, software domain or even complex ones as human body, society. If we observe the system behavior, complex system itself has capability to protect itself from being destroyed as survivability and sustainability of life. The reason is very simple, system must be alive and healthy to achieve missions. If we go further study of a system, you will find that normally system includes physical structures as "hardware" (Physical) which shall be stable in operatinal enviorment and "software" (Logical) for control ,communication and command. Inorder to live and implement missions, system needs sustained energy & material input from outside, system needs to perform behaviours for surviving , repairing and maintenance. That provides a reaso for system to make physical interactions with environment and other systems outside( we call enable systems by context). That interaction may be energy transportation showed in the form of heat transferring, material change like electrical chemical reaction or just mechanical force engagement. For energy, material and mechanical Interaction events, they are frequently happened in a physical engagement area what we defined as interfaces. So when we define an Interface existed in system we are intersted, there must be the counter-interface in counter systems. That is the engaged versus interfaces existed outside （ From our intersted system point of view）. In order to perform propoerly according to the environment and systems behavior around, system needs collect information from outside for objects and do analysis.Measured Data or information will be transmitted from sensors or other systems into system internally for further synthesis. Decision made by logically for the purpose of surviaving and operation will be made by system itself, command will be sent, transmitted, stored, and received. That's the reason for soft interface exsisted as data interaction algorithms happend on interaction. We need to understand that interactions happend always among systems and envirement apl ying system thinking, seperation realzied in our mind by missions and purpose we want to achieve. The concept of separation is not really separated to environment or other systems around, interfaces will be defined in the whole system contextual senario. Interface concept can help people to be focused on important things such as SOI( system of interest) and the interactive dependences inside and outside.
Umesh Ketkar and Claire Leon, PhD -- would love to see your thoughts on this article by Ron Carson.
There may be some misunderstanding here between entry points and boundaries, the former is defined with regard to business processes and detailed with users, typically with users stories or use cases; the latter is a functional stereotype defined for system architecture.
The concept of a boundary is so important to SE that it becomes its Achilles heel. As the boundary is defined and agreed upon, everybody starts to defend it, making all interactions happen at the boundary, making the boundary almost impenetrable shell. When it is time to enter the Transition to Operations, the boundary bursts and the outside world rushes in, somethimes with an implosive force. The systems doesn't fit into its environment, and the long struggle insues to make the system useful. Systems Engineers work both inside and outside the boundary. On the inside, they manage multi-disciplinary process of system. creation, on the outside they prepare the environment to receive the system. Frequently, the SE role on the outside is thrust on the Cistomer that may have or may have not requisite abilities and qualifications. It is not nice fate to become "by-default SE". I hope that all inside SEs are aware of their responsibility for their system's environment.