SYSE.6:0 - Use This When

Use this pattern when an engineering project has several architecture candidates, yet local design choices are accumulating without one recoverable decision about the project-shaping structures of the engineered System. Use it also when an earlier architecture decision still appears in a record, but changed conditions—for example, use, integration, configuration, evidence, or operation—may have made its accepted losses and open refinements stale.

The intended result is an engineering architecture decision that selects one option, fixes the project-shaping constraints, and states when to reconsider it. In FPF this is an ArchitectureDecisionRelation@Project supplied by C.32.PAD, not a second decision kind. In this Systems Engineering specialization, the decision uses the required engineering content recorded below: each candidate’s use, functional organization, bearers, interfaces, realization, integration, affected-System consequences, and evidence. The decision names the selected option, explicit constraints, and results needed by later engineering Work.

First move. Name the architecture question, the decision subject, and the smallest project-shaping structure choice that two current candidates answer differently. When the choice requires authority, cite the separate authority relation; an assignment or architecture record does not supply it.

This pattern begins after candidate development and ends with a decision plus conditions for reconsideration. Use C.32 and SYSE.5 to develop the candidates, SYSE.7 to maintain architecture descriptions, C.32.PAD directly when no Systems Engineering specialization changes the choice, and SYSE.4 to qualify the decision or identify the basis it still lacks. Release approval and evidence that the intended architecture now obtains remain separate decisions and claims.