SYSE.1:4 - Solution

SYSE.1:4.1 - State the current project decision

Begin with the project whose coordination is current. State:

1. what change or later use this project is meant to enable;
2. which plan or decision needs a shared project-system designation now; and
3. which subject is presently proposed as the System to be changed or brought about.

Keep related projects separate. A manufacturer’s planning-improvement project, a software vendor’s product project, and an integration provider’s deployment project may use the same software and evidence without making the same project-system choice. A programme or portfolio may coordinate shared matters—for example, priority, resources, investment, risk, or evidence—without thereby becoming a composite acting System.

SYSE.1:4.2 - Recover the direct subject before forcing a System choice

Use A.15.6 when project, process, or case wording hides whether the current subject is performed Work, a reusable Method, a selected structure, a transformation-flow structure, a changed referent, or another claim. If that direct subject answers the decision, stop this pattern use and keep the subject under its own FPF pattern.

When the decision does need a System, distinguish two cases:

• For an actual System, use A.1.SCR when recognition is unresolved. Its constructive criterion supplies the tested System identity and boundary used in the comparison.
• For a System that does not yet exist, keep the intended referent in the current plan, decision, or description. Do not describe it as an already acting System.

Recognition and project designation remain different claims. Recognizing an actual System does not select it for the project; selecting an intended referent does not make it physically present.

SYSE.1:4.3 - Generate and criticize materially different referents

Generate alternatives from the working situation. After the direct-subject exit in §4.2, retain a candidate referent for the project system-of-interest only when it is one of two things:

1. an actual System, with A.1.SCR recognition when that recognition is decision-relevant; or
2. an intended referent for a System not yet present, kept as a designator in plan, decision, or description content rather than described as an already acting System.

Examples include an actual product System, tool System, engineering platform, operating System, provider System, containing System, or organization System, and the intended referent of any such possible-future System. A provider arrangement or organization qualifies only when that whole is an admitted actual System or such an intended referent. A subject changed by a tool, a collection, Work, Method, capability, state, description, or another holon remains the direct subject or a related structure unless it satisfies the same System condition. The examples are non-exhaustive. Retain only candidates that would change a later decision.

For each candidate, compare the claims that matter now:

• the outside use or change the candidate is expected to support;
• the project boundary and the relation to related projects;
• the participating and affected Systems;
• the boundary, interaction, constituent, containment, ownership, authority, or other direct relations that actually change the choice;
• the important characteristics, constraints, feasibility branches, evidence, and uncertainty; and
• the assumption or observation that would defeat the candidate.

Treat familiar project facts—payment, delivery, ownership, enterprise boundary, a diagram, the transformer that performs realization Work, or the subject visibly changed by a tool—as evidence about candidates or project boundaries. Choose the project system-of-interest through the project’s stated use and decision.

Retain several candidates when later learning can change their order or when different candidates preserve valuable options. Let the current decision, available resources, and named stop determine the candidate count and comparison effort. Stop when the current choice is good enough to ask the next consequential question and its reopening evidence is named.

SYSE.1:4.4 - Record the smallest useful choice account

The cheap first result contains only:

Project-system choice account:
  current project and decision:
  selected actual System or intended referent:
  current use or change reason:
  main unresolved assumption:
  reopen condition:

Use any readable form for this content. Add further content—for example, comparison grounds, candidate alternatives, boundary and participation claims, affected Systems, authority, realization, or evidence—only when it changes the current choice or a downstream use.

Stop when the project can ask a concrete use-and-system concept question about the named referent for the stated reason. The resulting account supplies that referent, reason, boundary question, alternatives, and reopen condition to SYSE.2.

SYSE.1:4.5 - Reopen the choice from the answer that failed

Reopen the account when one of these changes the comparison:

• observed or expected use crosses the assumed boundary;
• authority or permission makes the intended change unavailable;
• an architecture candidate moves important functioning to another System;
• no feasible realization branch supports the selected referent;
• operating or assurance evidence defeats the reason for the choice; or
• a related project is separated, combined, or reoriented in a way that changes the current project decision.

Return to the smallest failed claim. A changed use assumption may require SYSE.2 before the project focus changes. A failed bearer or architecture candidate may return through C.30 or C.32. Reopen SYSE.1 only when the evidence changes which System should orient this project or where the project boundary lies.