Model-based requirements engineering

Model-based requirements engineering: goal scope change propagation to constraints

2026-05-31 · software-engineering formal-methods governance-policy · medium · source → · wiki →

key claims

SysML v1 constraint-satisfaction links are static model assertions: no automatic re-check occurs after a goal scope change and the analyst must manually invoke impact analysis to identify affected constraintsOmg (n.d.)
SysML v2's digital-thread `satisfy` construct adds event-triggered impact flagging that identifies which linked design elements and constraints are affected when a requirement changes, reducing manual discovery effort for constraints with existing trace linksStudio (2026)Omg (n.d.)
SysML v2's impact flagging addresses stale-link detection but not completeness: constraints with no pre-existing trace link to the modified goal are not surfaced, so scope expansion can introduce a set of new applicable constraints that the model cannot identify without human domain knowledgeStudio (2026)
KAOS obstacle analysis and the Objectiver tool notify the analyst of potentially affected goals and obstacles after a model change, but new constraint derivation is not automated; the analyst must manually re-run obstacle analysis for the modified goal scopeLamsweerde (2001)
Mäder and Gotel (2012) found empirically that manual traceability maintenance in evolving systems produces persistent stale trace links across multiple release cycles, confirming that the propagation gap is structural rather than transientGotel (2012)
Cleland-Huang, Settimi, and Berenbach's (2003) event-based traceability approach represents the most automated available mechanism, triggering rule-based notifications on change events, but it still requires analyst validation and does not achieve 100% recall in documented evaluationsCleland-Huang et al. (2003)
Scope expansion is structurally harder than scope narrowing for constraint propagation: a narrowed goal may leave orphaned constraints detectable by link inspection, but an expanded goal implies new constraints that have no trace link and are invisible to any link-traversal algorithmFinkelstein (1994)
An automated goal-constraint validation system must treat stale-link detection and completeness checking as two separate sub-problems: stale-link detection is automatable via change-timestamp comparison and link inspection; completeness checking after scope expansion requires domain-specific generation rules or a mandatory human review gateGotel (2012)Doi (n.d.)

Research Question

Is there evidence from model-based requirements engineering on how scope changes to a Goal propagate to the constraint surface: specifically, does constraint re-enumeration happen automatically, or does it require a human trigger?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

No existing Model-Based Requirements Engineering (MBRE) framework or industrial tool provides guaranteed automatic constraint re-enumeration when a Goal scope changes; constraint re-enumeration always requires a human trigger to be complete. Systems Modeling Language (SysML) v1 represents constraint-satisfaction links as static model assertions that a human analyst must manually re-evaluate after any goal change. SysML v2 advances to event-triggered impact flagging that identifies which existing constraints are connected to a changed requirement, but this mechanism cannot identify new constraints implied by an expanded scope, because those new constraints have no pre-existing trace link in the model. Knowledge Acquisition in Automated Specification (KAOS) and i-star (i*) tools offer semi-automatic impact notification bounded by the same existing-link coverage limitation. Empirical evidence from Mäder and Gotel (2012) confirms that stale constraints persist across multiple release cycles when propagation is not mandatory; Gotel and Finkelstein (1994) trace this structural gap to the absence of domain knowledge in the model and the lack of organisational ownership for traceability maintenance.

Key Findings

SysML v1 constraint-satisfaction links are static model assertions: no automatic re-check occurs after a goal scope change and the analyst must manually invoke impact analysis to identify affected constraints.
SysML v2's digital-thread satisfy construct adds event-triggered impact flagging that identifies which linked design elements and constraints are affected when a requirement changes, reducing manual discovery effort for constraints with existing trace links.
SysML v2's impact flagging addresses stale-link detection but not completeness: constraints with no pre-existing trace link to the modified goal are not surfaced, so scope expansion can introduce a set of new applicable constraints that the model cannot identify without human domain knowledge.
KAOS obstacle analysis and the Objectiver tool notify the analyst of potentially affected goals and obstacles after a model change, but new constraint derivation is not automated; the analyst must manually re-run obstacle analysis for the modified goal scope.
Mäder and Gotel (2012) found empirically that manual traceability maintenance in evolving systems produces persistent stale trace links across multiple release cycles, confirming that the propagation gap is structural rather than transient.
Cleland-Huang, Settimi, and Berenbach's (2003) event-based traceability approach represents the most automated available mechanism, triggering rule-based notifications on change events, but it still requires analyst validation and does not achieve 100% recall in documented evaluations.
Scope expansion is structurally harder than scope narrowing for constraint propagation: a narrowed goal may leave orphaned constraints detectable by link inspection, but an expanded goal implies new constraints that have no trace link and are invisible to any link-traversal algorithm.
An automated goal-constraint validation system must treat stale-link detection and completeness checking as two separate sub-problems: stale-link detection is automatable via change-timestamp comparison and link inspection; completeness checking after scope expansion requires domain-specific generation rules or a mandatory human review gate.
No i* industrial tool as of 2024 provides fully automatic constraint re-enumeration after a goal scope change; the most capable available tool is GoalSet's semi-automatic propagation, which requires analyst confirmation at each propagation step.
The traceability gap identified by Gotel and Finkelstein (1994) remains structurally present in 2024 despite incremental automation advances in SysML v2 and event-based approaches, because the root cause is the absence of domain knowledge in the model rather than a tooling deficiency.

Assumptions

Assumption 1: The Nuseibeh and Easterbrook (2000) roadmap findings about change propagation as an unsolved problem in requirements engineering accurately represent the state of practice at the time. Justification: Peer-reviewed IEEE/ICSE 2000 publication by leading researchers in the field; findings are consistent with the independent Gotel and Finkelstein (1994) empirical study.
Assumption 2: The Objectiver tool's behaviour described in Van Lamsweerde's guide and vendor documentation accurately reflects production capability for KAOS-based constraint propagation. Justification: The tool has been the primary KAOS implementation for over two decades; the secondary descriptions are internally consistent across multiple sources.
Assumption 3: The SysML v1 limitation (no automatic satisfaction re-check after change) reported in tool documentation and practitioner sources reflects the standard capability across major SysML v1 tools (MagicDraw, Enterprise Architect, IBM Rhapsody). Justification: Multiple independent practitioner sources report the same limitation across different tools; the SysML v1 specification does not mandate automatic satisfaction re-checking.

Analysis

The evidence converges on a single structural finding: constraint re-enumeration in MBRE frameworks requires a human trigger because completeness exceeds what model structure alone can supply.

The progression from SysML v1 to SysML v2 illustrates the automation ceiling. SysML v1 provides traceability links that a human must inspect on demand. SysML v2 adds event subscription so the tool can notify the human when an inspection is warranted. Neither eliminates the human decision about whether those constraints remain valid or what new constraints should be added. The event-based approach of Cleland-Huang et al. (2003) extends this by making the notification more timely and systematic, but the analyst still confirms or rejects each flagged impact.

The scope-expansion case requires a different design response from the stale-link case. For scope narrowing, existing links now applying to removed scope are detectable by link inspection and can be retired or flagged as orphaned. For scope expansion, the model contains no information about what constraints the new scope requires. The only available approaches are domain-specific constraint generation rules keyed to goal categories (for example: if a goal now includes personal data processing, enumerate General Data Protection Regulation (GDPR) constraints), or mandatory human review keyed to the magnitude of the scope change.

Mäder and Gotel's (2012) empirical finding that stale links persist across release cycles in practice confirms that partial automation available in SysML v1 tools is not routinely used. The organisational finding from Gotel and Finkelstein (1994) that no role owns traceability maintenance is the dominant practical constraint: tools can provide automation only if the automation is triggered.

A rival response would be to invest in better models rather than human review gates: if the model were rich enough to encode domain rules about which constraint categories apply to which goal categories, automated completeness checking could approach reliability. This is the direction suggested by domain-specific constraint pattern libraries. The evidence does not rule this out for narrow domains, but no production implementation of this approach exists for enterprise-scale systems. A human review gate for scope expansions remains the only approach with empirical support for completeness in the current state of tools.

Risks, Gaps, and Uncertainties

Quantitative propagation latency data (how long stale constraints persist in sprint-cycle or calendar-time terms) was not found in this investigation. Mäder and Gotel (2012) confirm persistence across release cycles but do not provide a distribution. This limits the ability to specify a latency threshold for a validation system design.
The Objectiver tool's exact propagation algorithm is not documented in publicly accessible primary sources; the inference about semi-automatic notification behaviour relies on Van Lamsweerde's published descriptions.
Direct access to the Nuseibeh and Easterbrook (2000) paper (doi: 10.1145/336512.336523) returned 403; content attributed to that source is based on secondary descriptions and consistent cross-referencing with other primary sources.
i* tool capabilities are an active research area; the capability summary as of 2024 may understate recent research prototypes not yet in production.

Open Questions

Can domain-specific constraint generation rules, keyed to goal category changes, provide reliable completeness for well-scoped domains such as data privacy (GDPR) or financial compliance? This is a candidate for a new backlog item.
What is the empirical false-negative rate of event-based traceability for constraint completeness in scope-expansion scenarios specifically? This would directly inform the human review gate design requirement.
How does the constraint-staleness window interact with the convergence/cycling risk documented in the companion item on goal-constraint feedback (Mitchell 2026, davidamitchell.github.io A stale constraint surface not detected before the next review cycle could shift the system from convergence to cycling.