SYSE.23:1 - Problem Frame

An engineered System does not become easier to evolve in isolation. A replaceable module may still require a fixture the factory lacks. A configurable product family may outrun test and evidence reuse. A simulation platform may generate variants that manufacturing cannot build or service. A flexible Method may depend on skills, permissions, or data that the assigned Agents do not have. Conversely, a costly redesign of the project system-of-interest may add little when the actual bottleneck is a slow builder or unavailable test service.

Evolvability is therefore an entry word, not a ready-made scalar or one universal quality bearer. An architecture-characteristic claim concerns an identified selected structure of a System, family relation, platform, or Method. A capability claim concerns a named holder and target Work under stated conditions. Lead time, rework, defects, and consumed effort may be results or resources of bounded change Work. A claim about the joint arrangement of the project system-of-interest and builders identifies its participating Systems, Methods, Agents, and relations. A claim that one architecture change caused or contributed to a Work result needs its own support. These claims may be compared, but they do not become the same kind.

The structures also differ. The project system-of-interest and a builder System can each have genuine constructive part–whole levels. Actual family members can participate in a membership structure. A component- level change can create a simultaneous whole-System or family-level conflict. Those are genuine level claims only when the part–whole or membership relation, scale, and horizon are stated. A dependency between the project system-of-interest and builder arrangement, a provider relation, or a platform service is non-holonic unless another relation establishes otherwise. Build-the-builder Work that precedes testing of the project system-of-interest is temporal Work order, not a level.