F.0.2:5.1 - Systems Engineering use and system concept
A Systems Engineering DPF author must decide what a practitioner should do when a proposed system concept is internally attractive but its connection to outside use is unclear. The author compares a proposed outside-before-inside instruction with the receiving ontology and an external systems-engineering account:
| Input to the comparison | Claim used in this comparison | Role and limit |
|---|---|---|
| Proposed outside-before-inside instruction | Begin with the system’s behavior in its operating environment and only then work inward toward alternative constructions. These linked descriptions remain revisable. | Authoring proposal to test and refine. |
FPF 8, patterns A.14, A.6.F, and C.2.1 | Parthood, function or effect claims, function bearing, and the identity of a claim-bearing episteme are separate questions with their own conditions. | Receiving-ontology boundary. |
SEBoK v2.14, Applying the Systems Approach, permanent revision 78074, 18 May 2026, Application Principles | Apply activities concurrently with attention to their dependencies. Iterate between needs and candidate solutions. | Comparison for dependency-aware concurrent and iterative work; the sequence is tailored to the problem situation. |
A lexical crosswalk that maps both using system and containing system to one parent system entry erases the use-versus-parthood distinction. The author can then no longer compare changing the project system’s construction with changing how an external system uses it.
The comparison concerns priority within an iterative process. Starting from an internal construction can narrow the alternatives before the outside behavior and operating conditions are known. Begin with the outside-use question. Once the information needed for a particular design question is explicit, explore construction and feasibility while refining the use account; leave a dependent construction choice open while its decisive use conditions remain unknown.
The author records the provisional synthesis branch at local locator SE-CS-USE-01 with this claim: “For one Systems Engineering concept decision, first establish the proposed outside behavior, operating conditions and system-of-interest sufficiently to compare internal constructions. Develop and test candidate constructions against that use; refine both accounts as new information arrives, and reopen the use, boundary or construction when realization evidence defeats it. State the subjects and direct relations that change the decision.” This retains the proposal’s outside-before-inside priority, reconciled with dependency-aware concurrent and iterative work.
Replay the clock choice. A team begins comparing gear arrangements for a clock. In this constructed case, asking where and how the clock will be used reveals a requirement for millisecond timing beside a rocket engine, with vibration and 30 g acceleration. The next result is an explicit timing-and-environment use hypothesis; the team compares and tests constructions against it before selecting one. Timing accuracy and vibration resistance can be investigated in parallel once their required operating conditions are stated. If feasibility evidence defeats the proposed clock use, revise that use or the system concept and compare again.
A key/lock case changes another premise: investigating the intended change from a locked to an unlocked door shifts the system-of-interest from the key to the lock, with the key treated as a subsystem in that decomposition. Recover the selected boundary before comparing mechanical, electronic or biometric realizations. The retained function stays visible while the construction alternatives change.
In this worked case, the later Systems Engineering DPF content decision cites SE-CS-USE-01 with this source edition and records used as proposed. The applied use-and-system-concept move stays in the Systems Engineering DPF; general claim, parthood and function-bearing rules stay in FPF. Reopen SE-CS-USE-01 when a source changes the linked action or boundary, a counterexample shows that the proposal cannot guide the decision, or the receiving decision changes its intended use.