SYSE.2:1 - Problem frame

Use this pattern when a project has selected an actual System, retained an intended System referent, or bounded another engineering subject, but the proposed concept cannot yet be defended through concrete use. The team may have, for example, an internal block diagram, requirement set, component list, product concept, or preferred technical solution while phrases such as environment, suprasystem, using system, Concept of Operations, use case, scenario, requirement, or user story stand in for several Systems, intended System referents, conditions, relations, and effects. A compatible SYSE.16 use-context account supplies decision-relevant operational structures, neighbours, conditions, and outside changes. A compatible SYSE.17 affected-system account supplies qualified consequence claims and unresolved bearers. Use only result claims compatible with the current decision.

The result is a linked use-and-system concept proposal: bounded claim content that connects a concrete use situation with a candidate System concept and states their main uncertainty. One or more descriptions may carry the claims; no document form is required.

First useful move: link one concrete use claim to one candidate system-concept claim and state their main uncertainty. This is enough to expose a grounded architecture question. Add further content—for example, another use situation, structure, participant, failure, effect, or representation—only when it can change the candidate or its boundary.

If this link is missing, internal elegance can substitute for usefulness. A pump passes a component test but worsens downstream flooding; planning software is installed but cannot support production decisions with the available data; a retrofit design works in an empty building but cannot be realized while the building is occupied.

The payoff is a revisable account that keeps outside use connected to concept content about the selected actual System, retained intended System referent, or other bounded engineering subject. Evidence about use can change that concept content, while architecture and realization findings can change the use, boundary, or affected-System claims.

Use this pattern while a concrete use claim and a candidate System concept still need to be developed together. Use C.30 and C.32 when the current question is grounded architecture and candidate synthesis, A.3.4 when the question is whether one actual bounded change occurred, and the applicable Operations Management pattern for continuing Work. Return to SYSE.1 when evidence changes which System should orient the project.

At the first consequential use of source wording, ask: does this claim connect concept content about the selected actual System, retained intended System referent, or other bounded engineering subject with a concrete use situation, participating or affected Systems, conditions, and outside effects? If yes, name those subjects and relations and use this pattern. A representation—for example, a ConOps, use case, scenario, requirement, user story, diagram, or model—presents some of these claims. Its form establishes neither their truth nor the required form for the proposal.