SYSE.5:4 - Solution

Develop several functional organizations and materially different bearer-and-interface proposals together. Enter at the claim that blocks the current decision, keep the outside effect and use visible, and iterate between functional and constructive accounts. Make every allocation, interface condition, conflict, evidence limit, and decision-relevant consequence explicit. Use C.32 for the general multi-structure candidate palette; apply the Systems Engineering content below to make that palette usable for realization, integration, procurement, assurance, and continuing change.

SYSE.5:4.1 - Perform the Move

1. Bind the engineering decision. Name the actual System or intended-system designator selected as the project system-of-interest, decision question, use situation, required outside effect or observed failure, configuration or variant, operating envelope, horizon, and protected characteristics. Use SYSE.2 candidates and unresolved use–System mismatches when they are current and compatible; otherwise use a qualified direct source or record the missing result.
2. Restore the blocking function-like claims. For each material contribution, use A.6.F to state the predicate, possible bearer, receiving whole or effect, conditions, and claim status. Begin from outside use, an observed internal failure, a candidate construction, or a feasibility result as the current question requires.
3. Develop several functional organizations. Vary how interactions and contributions could combine to produce the required outside effect. Include decision-relevant situations—for example, operating, degraded, maintenance, recovery, or consequential foreseeable use—when they can change the decision. A tree is optional; other selected structures may represent, for example, flows, feedback, cooperation, shared contributions, or mode-dependent relations.
4. Generate materially different bearer arrangements. Start with actual or intended Systems that might carry the contributions. For each arrangement, state how each candidate System would be obtained and operated— for example, by using an available System, procuring or realizing one, relying on provider Work, or combining software and physical Systems. Record shared resources and changes to supporting Systems as dependencies unless they themselves carry a contribution. Vary decision-relevant structures—for example, physical principle, distribution, placement, redundancy, containment, control boundary, or interface grammar. State separately whether an actual System exists, whether it is procurable, what realization or provider Work is needed, and which candidate claim still lacks support.
5. Write many-to-many proposed allocations. Associate functional contribution claims and candidate bearers explicitly. Permit several bearers for one contribution, several contributions for one bearer, and different allocations by mode, use, configuration, place, or effectivity. Treat weak cues—for example, co-location, matching names, diagram overlap, product kind, ownership, or system-role assignment—only as possible evidence for a separately stated claim.
6. Develop interface and placement conditions. For every material interaction, state the boundary and participants. Add the conditions that matter to the decision—for example, exchanged quantity or signal, units, geometry, protocol states, timing, capacity, environment, error handling, configuration, and effectivity. Identify the physical realization or missing realization separately from the interface specification. Add decision-relevant constraints—for example, placement, access, assembly, maintenance, supply, or resource constraints—when they change feasibility.
7. Challenge intended and unintended interaction. Test the proposed arrangement against relevant cases—for example, loads, failures, swaps, reversals, stale configuration, unavailable resources, human or machine misuse, and external change. For consequential wrong use, compare candidate changes—for example, to geometry, keying, protocol, control, detection, containment, or operation. Test evidence supports a mitigation claim only for the tested interaction and conditions.
8. Check realization and integration dependencies. Identify each dependency needed to make and join the bearers—for example, a System, Method, capability, resource, service, assembly Work, configuration episteme, or specialist result. Record each dependency with its own kind and relation to the proposal. Distinguish a missing catalogue item from a missing physical principle and from a missing project capability. When a recursive realization dependency is current, use SYSE.3 to develop it; do not hide it in a module name.
9. Compare engineering consequences. For each proposal, state predicted gains, losses, and unknowns for the current decision. Compare proposals for the engineering concerns that matter, such as performance, energy, safety, security, fault containment, latency, placement, service access, manufacture, assembly, integration, supply, cost, configuration, changeability, evidence burden, and affected-System consequences. Express each comparison through a characteristic with an explicit subject, conditions, Scale, and comparison frame. Bring in specialist Methods for the actual physics and risks.
10. Examine a representative slice. Use available evidence that supports the present claim under the needed representative conditions. When further challenge Work could change the decision, use C.11.DUA and the applicable C.11 or specialist experimental-design Method to decide whether to obtain it, comparing its attainable contribution with the whole burden. For selected Work, choose the Method suited to the claim—for example, computation or simulation, prototype-building and testing, or a physical trial. Identify each performed Work whose result is relied on, the Agent that performed it, and the observations produced. A model, simulation result, or trial observation remains an input to later claim assessment; its form alone does not establish feasibility of the whole proposal.
11. State the decision use and local stop. Record which alternatives remain usable, were revised, combined, or rejected; record the reasons, protected losses, and smallest unresolved dependency. When an architecture decision is current, use this account as an input to the Work governed by SYSE.6. When no admitted bearer can satisfy a sound contribution, choose explicitly among another bearer, a changed functional organization, new realization or supporting-System capability, bounded exploratory Work, or stopping the current proposal. Pause only the commitment whose basis is missing.

This numbered list is a learning and presentation unfolding governed by A.22.CGUS, not a WorkPlan or a temporal account of performed Work. It keeps the reasoning questions together without requiring Work to follow the displayed order. Functional reasoning, construction search, specialist analysis, realization, integration, trial, and concept revision can overlap and recur. The logical dependency of one claim on another does not imply that all Work producing the first result finishes before Work on the second begins.

SYSE.5:4.2 - Record the Result

The account can use several linked representations. Each representation names the functional organization, constructive organization, or engineered System it describes, and the account states the correspondence among those subjects.

SYSE.5:4.3 - What Changes in Practice

Engineers stop asking which named component implements each box and start asking which materially different arrangements can produce the required outside effect under the actual use conditions. They no longer treat functional names as purchase items or procurement specifications. Interface standards become inspectable specifications and evidence questions. Failed feasibility changes the smallest affected functional or bearer claim instead of silently collapsing the candidate set or restarting the whole project.