Goal Modeling¶
Goal modeling represents intended outcomes and their relations so stakeholders can examine refinements, dependencies, responsibilities, and system alternatives.
Core Idea¶
Goal modeling makes intended outcomes explicit and relates them in a model so stakeholders can ask why a system is proposed, how a high-level objective might be met, and which actors or alternatives matter. Its common structure is a represented goal plus interpretable intentional links. A KAOS refinement graph and an i* actor model both do this, but their node and link rules differ. A goal model supports requirements reasoning; the diagram alone neither proves that the proposed system meets its goals nor automatically turns every node into a requirement.[1][2]
In van Lamsweerde's BART train-control case, the model relates SafeTransport to more specific safety conditions before considering responsibility assignments. In Yu's meeting-scheduling case, an i* model exposes the initiator's and participants' interests and compares an existing routine with a proposed computer-supported arrangement. These are unlike settings for the same practice of representing and reasoning about intended outcomes.[1][2]
Structural Signature¶
Signature: intended objective + explicit modeling medium + intentional relation + situated actors or responsibilities when relevant + interpretation toward alternatives or requirements.
- Intended objective. A goal describes a desired condition, such as safe train transport or arranging an agreeable meeting. Without one, a diagram of tasks or components is not a goal model.[1][2]
- Explicit medium. Nodes and links make selected objectives and relationships inspectable. The medium can be a KAOS goal graph or an i* strategic dependency and rationale model; neither notation's whole grammar is universal.[1][2]
- Intentional relation. A link connects a goal to a proposed refinement, means, alternative, contribution, or dependency under the chosen notation. A disconnected list of wishes cannot do this relational work.[1][2]
- Actor or responsibility context. KAOS later assigns refined goals to software or environment agents. Yu's i* model records dependencies among a meeting initiator, participants, and, in the proposed configuration, a computer scheduler. An initial goal graph need not already contain completed assignments.[1][2]
- Reasoning output. The interpreted links make possible means, assignments, or requirement candidates discussable. This is a use of the model, not a promise that its proposed means have been implemented or succeeded.[1][2]
What It Is Not¶
A bare list of objectives is not yet goal modeling: it lacks represented relations. A task-flow diagram with no intended outcome likewise records activity without saying what the activity is meant to achieve. Nor is a Goal Structuring Notation assurance case interchangeable with this practice: a claim supported by strategies and evidence asks how a safety assertion is justified, while the cases here model stakeholder objectives and alternative means. The shared word “goal” does not make their links equivalent.[1][2]
KAOS AND/OR refinement and terminal single-agent allocation are not required of every goal model. Conversely, i* softgoals, actor dependencies, and contribution links cannot simply be read into van Lamsweerde's BART graph. A model can guide inquiry without proving satisfaction or yielding requirements by a mechanical reading of arrows.[1][2]
Scope of Application¶
The scope here is goal-oriented requirements reasoning: people build a model of desired outcomes and selected relations to explore requirements, responsibilities, or system alternatives. Van Lamsweerde's 2001 account develops KAOS refinement and a train-control case; Yu's 1997 paper develops i* strategic dependency and rationale modeling around meeting scheduling. They are evidence of two full positive settings, not evidence that every project uses either exact notation.[1][2]
The cited BART graph is a requirements analysis, not a report that the pictured graph by itself established operational train safety. Yu's Figure 3 depicts the routine before considering a computer scheduler; Figure 4 depicts a proposed computer-supported configuration. Neither figure reports that such a scheduler was deployed or achieved quick scheduling. Model contribution signs and refinements express structured reasoning subject to later validation.[1][2]
Clarity¶
Read a goal model by first identifying the desired condition, then the semantics of each link. In the KAOS account, AND subgoals jointly support a parent and OR refinements present alternatives; van Lamsweerde distinguishes eventual software requirements from expectations about environment agents after assignment. Those interpretations depend on the KAOS method and its refinement conditions.[1]
In Yu's i* account, dependencies identify what one actor seeks from another, while strategic-rationale links record means, task decomposition, and contributions to quality softgoals. “Quick” or “low effort” is a criterion for comparing arrangements, not evidence that an arrangement is quick or low effort in operation. Reading the link type prevents a proposed means from being mistaken for a verified result.[2]
Manages Complexity¶
A large requirement discussion can lose the relation between an objective and its proposed means. Goal modeling keeps a traceable structure: an upper goal can be linked to narrower conditions, candidate operations, agents, or alternatives. In the BART case, SafeTransport connects to train-entry, inter-train-distance, and segment-speed conditions. The representation makes those links reviewable while leaving the proof and allocation steps to the method's further analysis.[1]
The meeting example manages a different complexity: the initiator, participants, and a possible scheduler do not have identical interests or tasks. Yu's two rationale figures let the reader compare the current scheduling routine with a proposed delegated arrangement and consider quick scheduling, effort, convenience, and user friendliness. The comparison makes questions visible; it does not resolve all of them by drawing the graph.[2]
Abstract Reasoning¶
For a proposed instance, ask five questions. What intended outcome is represented? Which medium records it? What do the links mean in that notation? Whose responsibility or dependency is at issue? Which alternatives or requirements does the interpretation open for examination? Remove the represented goals or all interpretable relations and the distinctive practice collapses into unlinked statements. Remove actor allocation and some early goal models remain valid, but allocation claims cannot yet be made.[1][2]
The inference runs from a specified relation under a method to a question or candidate, not straight from a drawn edge to real-world success. KAOS refinement can require checking that subgoals adequately support a parent. Yu's proposed scheduler can be compared with the existing routine through modeled contributions to softgoals. The two procedures share intentional modeling while retaining different evidentiary demands.[1][2]
Knowledge Transfer¶
The reusable move is to externalize objectives and their relations before choosing a system design. It transfers from train control to meeting scheduling because each has desired outcomes, possible means, and human or technical responsibilities. The concrete goal vocabulary, link semantics, and acceptance tests must be re-established for the new setting; importing a KAOS AND edge into an i* model would change what the second source actually says.[1][2]
This practice presupposes the live Representation Prime: a target of intended goals is mapped into a selected medium with relations that can be read back. Goal modeling is the activity of constructing and interpreting that medium for requirements inquiry, not simply the finished representation object. Other uses of representation exist without goals, so the relation is strict.
Examples¶
KAOS BART train-control goals¶
Van Lamsweerde's preliminary BART goal graph places SafeTransport among higher objectives and links it to safety conditions including avoiding a train entering a closed gate, maintaining adequate distance between trains, and maintaining a track-segment speed limit. Further refinement and responsibility analysis ask which software or environment agents can satisfy the narrower goals. A terminal software-agent goal may become a requirement; a terminal environment-agent goal is treated as an assumption or expectation under the author's account. The graph is a model for analysis, not itself evidence that BART trains met those conditions.[1]
Mapped back: intended objective → SafeTransport and related safety outcomes; medium → KAOS BART goal graph; intentional relation → goal refinements among transport and narrower safety conditions; actor context → later train-control and environment-agent assignments, not an assertion that each preliminary node already has an owner; reasoning output → candidate requirements and expectations after refinement and allocation.[1]
i* meeting-scheduling alternatives¶
Yu models a meeting initiator and participants whose activities must yield an agreeable meeting time. The strategic-rationale model in Figure 3 describes the routine before a computer scheduler is considered: the initiator gathers availability, finds a suitable date, proposes it, and obtains agreement. Figure 4 then examines a proposed computer-supported configuration, including the task FindAgreeableDateUsingScheduler. Contributions to softgoals such as quick scheduling, low effort, and user friendliness help compare possible arrangements; they are qualitative model judgments, not outcome measurements from a deployed scheduler.[2]
Mapped back: intended objective → arranging an agreeable meeting; medium → i* strategic dependency and rationale models; intentional relation → existing means and task decompositions in Figure 3 versus proposed scheduler means and softgoal contributions in Figure 4; actor context → initiator and participants in the original routine, with a proposed scheduler actor added in the computer-supported model; reasoning output → a comparison of who might schedule and how alternatives may serve stakeholder interests.[2]
Structural Tensions¶
The two papers do not establish a single intrinsic tradeoff of goal modeling. They do show questions a model must leave open: whether a refinement is adequate, whether an agent can discharge an assigned goal, and whether a proposed means serves several stakeholder interests. The BART graph requires method-specific refinement and assignment checks; the meeting model compares qualitative contributions and alternatives. These are boundary and validation questions, not a claim that every model contains the same cost-versus-safety conflict.[1][2]
Structural–Framed Character¶
This is a human-guided modeling practice. Evaluative weight: the goals and softgoals encode what stakeholders seek, but the model's existence does not prove those aims are met. Human-practice dependence: modelers select goals, link types, and possible means; stakeholders interpret the results. Institutional origin: neither a legal mandate nor a particular vendor defines the identity, though requirements projects supply its setting. Vocabulary travel: “goal,” “dependency,” and “refinement” travel, but their link semantics depend on the chosen method. Import versus recognition: a new model must be read through its stated notation rather than relabeled KAOS or i. *Portable skeleton:** representing a target in an explicit medium is assigned to live Representation; a wider Prime for intentional modeling would need independent cross-domain evidence. Its character: inspectable reasoning about intended system outcomes and alternatives, bounded by framework-specific links.[1][2]
Structural Core vs. Domain Accent¶
The core comprises intended goals, an explicit model, interpretable relations, and a use of those relations to discuss means or responsibilities. Live Representation supplies the target-to-medium mapping that this practice presupposes. KAOS AND/OR refinements, single-agent terminal assignment, i* actor dependencies, softgoals, and contribution signs are domain and framework accents: useful in their respective sources, but not required together in every goal model.[1][2]
The named identity remains domain-specific to requirements reasoning because both positive instances organize intended system or organizational outcomes toward requirements choices. The evidence does not establish independent cross-domain instances of this exact method. A more general intentional-modeling Prime would therefore be a future admission question rather than a conclusion drawn from these two papers.
Instantiates / Related Primes¶
This entry presupposes Representation.
The staged graph records a strict composition/presupposes edge to Representation. An intentional-goal model cannot exist without mapping selected goals and relations into an inspectable medium; the practice itself is not merely a representation artifact. Representation has many instances that do not model goals. Requirements Analysis is a nearby broader practice, while Goal Structuring Notation organizes assurance claims and evidence; neither is asserted as a strict parent on these sources. No edge makes every requirements conversation a goal model.
Relationships to Other Abstractions¶
Current abstraction Goal Modeling Domain-specific
Parents (1) — more general patterns this builds on
-
Goal Modeling presupposes Representation Prime
Goal modeling requires a mapping of intended objectives and relations into an inspectable model.Every admitted goal-modeling practice encodes target objectives and their selected intentional relations in a structured medium under a stated notation. Without that target-to-model mapping it is goal discussion, not goal modeling. The practice constructs and interprets the representation; it is not itself a representation object. Representation occurs independently in many other settings.
Hierarchy path (1) — routes to 1 parentless root
- Goal Modeling → Representation → Abstraction
Neighborhood in Abstraction Space¶
Goal Modeling sits in a sparse region of the domain-specific corpus (95th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2551 abstractions)
Nearest neighbors
- Event Correlation — 0.79
- Cradle-to-Cradle Design — 0.78
- Transmediation — 0.78
- Protocol Stack — 0.77
- Rational Choice Model — 0.77
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
A list of stakeholder wishes without modeled relations; a task flow that says what happens but not which outcome it serves; a GSN claim-evidence argument; or a finished software implementation. Yu's proposed computer scheduler is a model alternative, not a reported deployed intervention. In the BART case, a preliminary refinement is not automatically an assigned, verified requirement. These exclusions prevent notation-specific arrows and imagined outcomes from being silently promoted to universal facts.[1][2]
References¶
[1] Axel van Lamsweerde, Goal-Oriented Requirements Engineering, A Guided Tour, invited mini-tutorial in Proceedings of the 5th IEEE International Symposium on Requirements Engineering (RE'01, 2001), pp. 249–263; original title-page punctuation is “Goal-Oriented Requirements Engineering: A Guided Tour.” See §§2–3 for goals/refinement and §6, Fig. 1 for the BART graph and responsibility analysis. The author-hosted PDF is the consulted full text. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v
[2] Eric S. K. Yu, Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering, Proceedings of the Third IEEE International Symposium on Requirements Engineering (RE'97, 1997), doi:10.1109/ISRE.1997.566873, §§2.1–2.4, Figs. 1–4. Figure 3 models the pre-computer routine; Figure 4 models a proposed computer-supported configuration. The author-hosted PDF is the consulted full text. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v