SYSE.2:4 - Solution · fpf.tools

SYSE.2:4 - Solution

SYSE.2:4.1 - Start with one decision-changing use situation

Take the selected actual System or intended System referent and current reason from the project-system choice account, or state the bounded engineering subject when no project-system choice is needed. If that choice is needed but no compatible SYSE.1 account is available for the same subject and decision, use a qualified direct source for the focus claim or record the missing project-focus result and stop only the linked claim it blocks. For an actual System, describe an actual or possible-future situation in which it participates. For a not-yet-present referent, keep the intended participation in modal plan, decision, or description content; do not assert an actual System or participation relation before identity inception. State:

the subject that relies on, uses, changes, or is affected by the proposal;
the direct relation by which that subject enters the use;
the condition or change expected;
the outside effect that matters to the current decision; and
the uncertainty that could change the concept.

Name the relying subject under its admitted kind; a person and a System are only two possible kinds. State the direct relation by which it enters the use—for example, reliance, participation, performed Work, or affectedness. Include affected Systems or intended System referents whenever their qualified consequence claims can change the decision; participation in or ownership of the designated System is not required.

SYSE.2:4.2 - Name the subjects and direct relations hidden by environment language

Start from compatible current SYSE.16 and SYSE.17 results for the same subject, configuration, use, horizon, and decision. If either result is unavailable, recover only the subjects and direct relations needed for the first linked claim. Use SYSE.16 when the decision needs several operational structures or a co-change boundary, and SYSE.17 when it needs active discovery of consequence-bearing Systems. A neighbouring System may matter, for example, through constructive parthood, placement, interface, interaction, causal participation, use, transformation, collection membership, assignment, ownership, permission, authority, or affectedness. State only relations that are current and apply the FPF pattern that defines or constrains each claim.

Use A.1.SCR when the System status of a proposed participant or containing whole is unresolved. Use A.22 when the current question selects an organization among independently identified constituents and obtaining relations for a named use. Keep several non-nested structures when one decomposition would hide a relevant claim—for example, an interaction, control relation, affected System, or source-return condition.

Authority constrains who may change a System; it does not draw the System boundary. Ownership can matter to a decision without establishing containment. A containing whole matters when its actual or proposed proper-part relations and whole-level consequences change the use or concept. Distinguish supported actual relations from proposed relations and qualified predictions; a future whole need not already exist for its proposed arrangement to affect the concept.

SYSE.2:4.3 - Develop the use claim and candidate system concept together

Write one outside-facing use claim and one inside-facing concept claim:

Linked use-and-system concept proposal:
  concrete use claim:
  candidate system-concept claim:
  main uncertainty:
  architecture question exposed:
  reopen condition:

Use any readable form for this content. The use claim names participating or affected Systems, conditions, expected transformations or behavior, and outside effects only as far as the current decision needs. The system-concept claim names what the proposed concept needs—for example, a boundary, functioning, interface, resource, constraint, or placement—while leaving full architecture selection open.

Use A.6.F when function-like wording carries a claim. Name the required functioning and its proposed bearer. Any remaining question—for example, about function, capability, Method, Work, module, interface, evidence, or architecture—stays under the pattern that defines or constrains it. Use A.6.M only when an actual module or interface claim is current. If no feasible bearer can support required functioning, revise the concept or use claim before admitting an architecture candidate.

Use A.3.4 for an actual observed transformation only after the continuing subject, boundaries, before/during/after facts, and continuity rule are available. A required, intended, or simulated transformation remains modal claim content; its description does not establish that the change occurred.

A functional or transformation-flow description of relevant environment structure can support the linked proposal by showing selected functioning or flow relations for a named use. The proposal also states which use situation matters, which Systems participate or are affected, which outside effect changes the decision, which candidate System concept is being considered, and what remains uncertain. Model only the environment structure needed by those claims.

SYSE.2:4.4 - Compare changes on either side of the boundary

Develop alternatives when changing a different subject would change the engineering answer. Compare, for example:

an actual or proposed change to the designated System;
a change to an external System or operating arrangement;
a changed interface, placement, or resource relation; or
coordinated changes on several sides.

Use a compatible SYSE.8 provider-arrangement account when its supported provider-arrangement claims or design constraints change the use, candidate System or intended referent, boundary, interfaces, realization needs, or evidence. Consume only the compatible claims named for this use. Without a compatible current SYSE.8 account, use a qualified direct source for the needed provider-arrangement claim or record the missing result and stop only the linked claim it blocks. Either account may need revision when a shared claim changes; that dependency does not prescribe the order of engineering Work. Obtain other decision-changing results from the specialist practice that owns them—for example, organization change, Operations Management, Platform Engineering, Governance, safety, security, ethics, law, or finance. Keep each result claim linked to the use or concept claim that consumes it.

For example, when source material names a product-service system, digital twin, digital thread, MBSE, PDM, PLM, eXperience platform, or Multi-D arrangement, recover the actual contribution before using the umbrella term. A concrete contribution—for example, a maintained model, configuration relation, simulation, observation return, integration capability, or change decision—can enter the linked proposal through its direct claim. The umbrella name alone does not decide whether this pattern, architecturing, realization, assurance, or a specialist practice is the next use.

SYSE.2:4.5 - Expand only when another claim can change the candidate

The cheap first result is one linked use claim, one candidate concept claim, and their main uncertainty. Expand when further content—for example, another use situation, load, failure, participant, affected System, harm, benefit, or representation—could change the candidate. Add only the relevant:

environment structures and obtaining relations;
transformations, interactions, conditions, and effects;
functioning, interface, placement, resource, and constraint claims;
correspondence between a representation and the represented claims;
alternatives, assumptions, evidence limits, and specialist returns.

If source words such as operational system, system in operation, operations, or operational flow are current, distinguish two questions. Use this pattern for a System’s participation in use and the concept that supports it. Use Operations Management when the difficulty is managing continuing Work, queues, policies, or flows. An operational adjective does not settle that choice.

SYSE.2:4.6 - Stop at a grounded architecture question and reopen from failed support

Stop when the current use claim and candidate concept expose a grounded architecture question and their main uncertainty. The linked proposal supplies required functioning, operating conditions, outside effects, decision-relevant environment structures, assumptions, and evidence limits to C.30 and C.32.

Use C.30.ASV only when a structural description and its adequacy for a selected architecture use are current. Do not open a full view or architecture-description apparatus merely because a sketch helped the discussion.

Reopen the smallest linked claim when:

the use claim and concept claim no longer support each other;
a candidate architecture lacks a feasible bearer or hides a harmful effect;
realization evidence defeats an interface, resource, placement, or capability assumption;
operating observation changes a condition or effect; or
a specialist result changes permission, feasibility, harm, value, or the participating Work arrangement.

Return to SYSE.1 only when the failed claim changes which System should orient the project or where the project boundary lies.