Requirements Under Uncertainty

The problem of specifying requirements for systems that operate under uncertainty — where the environment, workload, and even the availability of components are not fully known at design time — and of making the requirements themselves adaptive so a self-adaptive system knows what it must always guarantee versus what it may trade off. Because Self-Adaptation exists precisely to handle uncertainty, requirements engineering for self-adaptive systems must express tolerated variation rather than assume a fixed, fully-specified world.

Two influential lines address this. RELAX (Whittle, Sawyer, Bencomo, Cheng & Bruel, 2009) is a requirements language that introduces explicit operators — as early as possible, as close as possible to, eventually, etc. — to mark which requirements may be relaxed and under what environmental uncertainty. Awareness Requirements (Silva Souza, Lapouchnian, Robinson & Mylopoulos, 2011) are meta-level requirements about other requirements — constraints on their runtime success/failure rates — that give the feedback loop explicit, monitorable adaptation triggers. Both connect to utility-based decision-making (see Utility Function): when requirements admit trade-offs, a utility function ranks the alternatives the MAPE-K Plan step chooses among. The SEAMS roadmaps flag requirements under uncertainty as a core open challenge.

In this vault

Backlinks

Linked Pages

Goal Management

(page does not exist)

Runtime Assurance

The provision of continuous, runtime evidence that a self-adaptive system still satisfies its requirements as the system, its environment, and its workload change — replacing (or supplementing) one-shot design-time verification with an incremental, always-on activity. Because self-adaptation defers decisions to runtime precisely to cope with uncertainty, the guarantees must be re-established at runtime too; the SEAMS roadmaps call this perpetual assurance and treat it as the field’s defining challenge.

Runtime assurance is realised through several complementary techniques in this vault: quantitative (probabilistic) verification at runtime (Self-Adaptive Software Needs Quantitative Verification at Runtime), executable verified formal models of the feedback loop (ActivFORMS - Active Formal Models for Self-Adaptation), and control-theoretic guarantees synthesised for the adaptation controller (Automated Design of Self-Adaptive Software with Control-Theoretical Formal Guarantees). All of them keep a runtime model in the MAPE-K knowledge base and re-check goals against it as conditions drift.

In this vault

MAPE-K

The reference control loop of Autonomic Computing and self-adaptive software: an autonomic manager runs a closed feedback loop of Monitor → Analyse → Plan → Execute over a shared Knowledge base, acting on a managed element through sensors (probes/gauges) and effectors.

Monitor — collect and aggregate sensor data from the managed element and its environment.
Analyse — detect when adaptation is needed (symptoms, constraint/SLA violations, drift from goals).
Plan — select a course of action (a strategy/tactic, reconfiguration, or repair).
Execute — enact the plan through effectors on the managed element.
Knowledge — models, policies, goals, and history shared across the four phases (see Models@run.time).

Introduced in The Vision of Autonomic Computing (Kephart & Chess 2003) as the organising abstraction for the self-* properties (self-configuration, self-healing, self-optimisation, self-protection). It is the connective tissue linking architecture-based adaptation (Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure), reference models (Three-Layer Reference Model), and the broader survey landscape (Self-Adaptive Software - Landscape and Research Challenges).

In this vault

Utility Function

A scalar-valued function that maps a system state (or a candidate configuration) to a measure of how good it is against the stakeholders’ objectives, so that competing alternatives can be ranked and the best chosen. In self-adaptive and autonomic systems, utility functions are the standard basis for decision-making in the Plan step of a MAPE-K loop: rather than encoding fixed if-then adaptation rules, the manager evaluates the utility of each reachable configuration (trading off, say, performance against cost and reliability) and adapts toward the one of highest expected utility.

Utility-based control is what lets a system reconcile multiple, possibly conflicting non-functional goals and handle requirements that admit trade-offs. In this vault it underpins the utility-based strategy selection of Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure (its Stitch strategies are chosen by expected utility) and the goal-driven planning of the Three-Layer Reference Model.

In this vault

Self-Adaptation

A system’s capability to modify its own behaviour or structure at runtime in response to internal or environmental change, without external intervention. It is typically implemented as a MAPE-K loop (Monitor-Analyse-Plan-Execute over a Knowledge base), the control abstraction introduced by Autonomic Computing.

In this vault

Software Engineering for Self-Adaptive Systems - A Second Research Roadmap

Software Engineering for Self-Adaptive Systems: A Second Research Roadmap

Reference: de Lemos, R., Giese, H., Müller, H. A., Shaw, M., et al. (2013). Software Engineering for Self-Adaptive Systems: A Second Research Roadmap. In Software Engineering for Self-Adaptive Systems II, LNCS 7475, Springer, pp. 1–32. DOI: 10.1007/978-3-642-35813-5_1. URL

Summary

The second SEAMS roadmap, produced four years after the first, takes stock of the field’s progress and re-sets the agenda around what the community had learned to be the genuinely hard problems. Where the first roadmap partitioned the space, this one is organised around four thematic challenges that had emerged as central: design space (systematically characterising the choices a designer of a self-adaptive system faces), processes (development and lifecycle processes that span design time and runtime), decentralisation of control loops (moving beyond a single MAPE-K loop to multiple, interacting control loops and coordination patterns among them), and practical run-time verification and validation (V&V).

The roadmap’s sharpest emphasis is on assurance: it argues that self-adaptive systems demand a continuous supply of evidence that requirements are still met as the system and its environment change, shifting V&V from a design-time gate to a runtime, incremental activity. It highlights the need to reason explicitly about the uncertainty that motivates adaptation, to make control loops (and their interactions) explicit architectural entities, and to develop perpetual assurance techniques — including quantitative and formal methods applied at runtime — that keep pace with adaptation. It is the standard “state of the field, part II” reference for engineering and assuring self-adaptive software.

Key Ideas

Four thematic challenges: design space, processes (design-time + runtime), decentralised control loops, and practical run-time V&V.
Decentralised control: self-adaptive systems increasingly need multiple interacting MAPE-K loops with explicit coordination, not one central loop.
Perpetual / runtime assurance: continuous, incremental evidence that goals still hold, replacing one-shot design-time verification.
Uncertainty is first-class: adaptation exists to handle it, so it must be modelled and reasoned about explicitly across the lifecycle.
Positions runtime quantitative verification and formal runtime models as key enabling techniques for assurance.

Connections

Conceptual Contribution

Claim: Four years on, the hard core of engineering self-adaptive systems is decentralised control, lifecycle processes spanning design/runtime, and — above all — continuous runtime assurance under uncertainty.
Mechanism: Reorganise the agenda around design space, processes, decentralisation of control loops, and practical run-time V&V; treat uncertainty as first-class and pursue perpetual assurance via runtime quantitative/formal verification.
Concepts introduced/used: Runtime Assurance, MAPE-K, Requirements Under Uncertainty, Feedback Loop, Runtime Quantitative Verification
Stance: roadmap / community agenda
Relates to: The sequel to Software Engineering for Self-Adaptive Systems - A Research Roadmap; its assurance emphasis is realised in Self-Adaptive Software Needs Quantitative Verification at Runtime and ActivFORMS - Active Formal Models for Self-Adaptation, and its decentralised-control theme extends the single loop of The Vision of Autonomic Computing.

Software Engineering for Self-Adaptive Systems: A Research Roadmap

Reference: Cheng, B. H. C., de Lemos, R., Giese, H., Inverardi, P., Magee, J., et al. (2009). Software Engineering for Self-Adaptive Systems: A Research Roadmap. In Software Engineering for Self-Adaptive Systems, LNCS 5525, Springer, pp. 1–26. DOI: 10.1007/978-3-642-02161-9_1. URL

Summary

This roadmap — the outcome of a Dagstuhl seminar bringing together the self-adaptive-systems community — is the first attempt to organise self-adaptation as a software-engineering discipline rather than a collection of point techniques. It frames self-adaptation as the response to increasing scale, dynamism, and uncertainty in operating environments, where systems must adjust at runtime with reduced human intervention, and argues that the classic engineering activities (requirements, design, verification, process) all need to be rethought when much of the decision-making is deferred to runtime.

Its most-cited contribution is a set of four views that partition the research agenda: modelling dimensions (a vocabulary for classifying self-adaptive systems — e.g. what is adapted, when, why, and how), requirements (specifying adaptation goals and tolerated uncertainty, including languages that “relax” requirements), engineering (making the feedback loop a first-class design element and reusing control-loop architectures such as MAPE-K), and assurance (providing runtime evidence, verification, and validation that adaptation preserves goals). The paper repeatedly emphasises the feedback loop as the architectural centre of gravity — echoing control engineering — and lays out open challenges that framed the field for a decade.

Key Ideas

Reframes self-adaptation as a software-engineering problem: requirements, design, assurance, and process must all account for runtime decision-making under uncertainty.
Four research views: modelling dimensions, requirements, engineering, and assurance.
Modelling dimensions give a shared classification vocabulary (goals, change, mechanisms, effects) for comparing self-adaptive systems.
Makes the feedback loop / MAPE-K control loop a first-class, visible design element rather than buried logic.
Names assurance (continuous, runtime evidence that goals still hold) as a defining open challenge.

Connections

Conceptual Contribution

Claim: Self-adaptation should be treated as a first-class software-engineering discipline; its distinctive challenges — deferring decisions to runtime under uncertainty — reshape requirements, design, assurance, and process.
Mechanism: Partition the agenda into four views (modelling dimensions, requirements, engineering, assurance), elevate the feedback/MAPE-K loop to an explicit architectural element, and demand continuous runtime assurance rather than one-off design-time verification.
Concepts introduced/used: Feedback Loop, MAPE-K, Runtime Assurance, Requirements Under Uncertainty, Adaptation Dimensions
Stance: roadmap / community agenda
Relates to: The first of the two SEAMS roadmaps; its successor Software Engineering for Self-Adaptive Systems - A Second Research Roadmap deepens the assurance and control agenda. Complements the taxonomy of Self-Adaptive Software - Landscape and Research Challenges and the feedback-loop treatment of Engineering Self-Adaptive Systems through Feedback Loops.

Requirements Under Uncertainty

In this vault

Related

Backlinks