SYSE.27:4 - Solution
SYSE.27:4.1 - Recover the consumed behavior
Identify the actual users and versions in use, including infrequent consumers and retained templates that may run later. Read the requests and results they rely on: meaning, units, defaults, supported limits, error behavior, configuration and relevant timing conditions. Names and type signatures alone may hide the consequential contract.
Separate internal implementation choices from observable behavior. Identify which observations would distinguish a compatible implementation change from a changed promise. When use evidence is incomplete, retain that uncertainty rather than declare that no consumer exists.
Clarify who owns the interface, who may contribute, who can accept the technical change and who can authorize its actual use. Use existing assignments when they suffice. If the contribution relation or assignment is missing, use the exact OCE.4 or OCE.6 result; do not appoint an owner by adding a name to a template.
SYSE.27:4.2 - Compare the change forms
| Possible form | When it can supply the needed result | Burden or limit to examine |
|---|---|---|
| Internal implementation change | The consumed behavior remains within its existing promise. | Show that the relevant effects are preserved, not merely that requests still parse. |
| Compatible extension | New use can be added without changing supported old use. | Check old defaults, limits, failure behavior and the cost of the extension. |
| Adapter | A bounded translation can preserve the old use while a different interface operates behind it. | State losses, unsupported values, extra failure points and maintenance. |
| Explicit versioned break | The new result cannot honestly preserve the old promise. | Name affected consumers, coexistence and the migration/recovery question. |
| Refusal or outside route | The contribution is not justified or cannot be supported under the current conditions. | Give an actionable reason and a legitimate alternative or missing-premise return. |
A version label communicates a choice; it does not establish compatibility. Compare the actual cases and consequences before selecting the label or mechanism. Do not promise an adapter if lost information or changed physical effects would prevent the existing consumer from obtaining the promised result.
SYSE.27:4.3 - Make contribution possible at the supported boundary
State what a contributor may change and what remains controlled by the provider. Supply a reproducible way to exercise the interaction, examples of supported old and new use, relevant acceptance checks, and enough failure information for a contributor to repair a rejected proposal.
Make dependencies explicit: a contribution may require a toolchain, resource, permission or domain Method not yet supplied. Preserve the distinction between a technically valid proposal, an accepted contribution and a deployed provision. A contribution test should not expose release credentials or unrestricted provider access.
Choose a maintained extension point only where independently changing use justifies it. A small parameter or documented composition may be enough; an open-ended plugin system can cost more to secure, qualify and support than the variants it enables.
SYSE.27:4.4 - Exercise effects on consumers
Run or construct the selected compatibility cases against the old and proposed behavior. Include a representative normal request, defaults or omitted input, a supported limit, a failure and a legitimate unsupported need. Add cases only where their result can change acceptance.
Use the intended result consumer to interpret the outputs. A request that is syntactically accepted but receives a different unit, deadline or configuration is not compatible merely because the interface returns success.
For a physical connection, a fit test may establish only fit. Load, alignment, measurement and safe-operation claims retain their own qualification. For software, a contract test supports its exercised conditions, not all interoperability or application correctness.
SYSE.27:4.5 - Decide support and the next change increment
Return the selected form, affected use, relevant test result or gap, and the actual maintenance/support arrangement. Make rejection useful: distinguish an implementation defect from an unsupported requirement or missing authority.
When users must move, carry the defined old/new behavior and affected consumers to SYSE.29. When an independent provider controls a needed change or commitment, use SYSE.18; a common schema cannot substitute for that decision. Revisit the interface from actual failures and contribution burden rather than from the number of extensions accepted.