Loading field map
Every engineered system begins as a set of needs—sometimes vague, often conflicting, always incomplete. The challenge of moving from those raw stakeholder desires to precise, verifiable specifications is the central problem of requirements engineering. Since the late 1970s, practitioners and researchers have developed a series of frameworks to address this challenge, each responding to the limitations of its predecessors and to the growing complexity of the systems being built. The history of the field is not a story of simple progress but of persistent tensions: between formal precision and communicative accessibility, between upfront analysis and iterative discovery, and between a single specification and multiple stakeholder perspectives.
In 1977, two frameworks emerged that would define the poles of requirements engineering for decades. Formal Requirements Specification drew on mathematical notations—such as Z, VDM, and algebraic specifications—to describe system behavior with unambiguous precision. Its advocates argued that only a formal specification could be subjected to rigorous verification, catching inconsistencies and incompleteness before implementation began. The framework treated requirements as a mathematical object to be proved correct, not merely described.
At the same time, Structured Requirements Analysis took a very different path. Rooted in the structured analysis movement of the 1970s, it used data flow diagrams, entity-relationship models, and structured English to make requirements accessible to stakeholders who were not mathematicians. Where Formal Requirements Specification prioritized rigor, Structured Analysis prioritized communication. Its practitioners believed that a specification that could not be understood by the customer was worthless, no matter how formally correct.
These two frameworks did not replace each other; they established a living disagreement that persists today. Formal methods remain essential in safety-critical domains such as aviation, medical devices, and nuclear control, where an undetected ambiguity can be catastrophic. Structured analysis, meanwhile, became the default approach in many commercial and industrial settings, where stakeholder communication was the primary bottleneck. The tension between them—rigor versus readability—would shape every subsequent framework.
By the mid-1980s, practitioners using Structured Analysis had noticed a recurring blind spot: the technique described what a system should do, but it said little about how users would actually interact with it. Scenario-Based Requirements Engineering, introduced around 1987, addressed this gap by shifting the unit of analysis from abstract functions to concrete sequences of user-system interactions. Use cases, the most famous form of scenario-based specification, described a specific actor achieving a specific goal through a series of steps. This made requirements tangible in a way that data flow diagrams never could. Scenario-based approaches did not reject Structured Analysis; they absorbed it, adding a user-interaction layer on top of the functional decomposition.
Soon after, Viewpoint-Oriented Requirements Engineering (1992) challenged a deeper assumption shared by both Formal Specification and Structured Analysis: that a single, monolithic specification could adequately capture all stakeholder needs. In practice, different stakeholders—end users, operators, maintainers, regulators—had different concerns, different vocabularies, and different criteria for success. Viewpoint-oriented frameworks proposed that requirements should be elicited and represented from multiple perspectives, each with its own partial specification, and that conflicts between viewpoints should be managed explicitly rather than papered over. This was a direct narrowing of the earlier ideal of a single unified specification.
Goal-Oriented Requirements Engineering (1993) extended the viewpoint idea in a different direction. Instead of asking what stakeholders wanted, it asked why they wanted it. Goals provided the rationale behind requirements, allowing analysts to trace why a particular function existed and to explore alternative ways of achieving the same objective. Goal-oriented frameworks such as KAOS and i* introduced concepts like goal refinement, obstacle analysis, and soft goals for non-functional requirements. Where viewpoints addressed the problem of multiple perspectives, goals addressed the problem of missing rationale—the fact that requirements often arrived without any explanation of their purpose.
By the mid-1990s, the field had accumulated a rich set of techniques for eliciting, representing, and analyzing requirements. But Michael Jackson observed that many requirements failures stemmed from a different source: analysts were too quick to assume a particular solution structure before understanding the problem. Problem Frames (1995) provided a taxonomy of recurring problem types—such as required behavior, commanded behavior, information display, and transformation—each with its own characteristic structure and concerns. By classifying a problem into a frame, the analyst could apply known analysis patterns and avoid premature commitment to a specific design. Problem Frames coexisted with Scenario-Based and Goal-Oriented approaches rather than replacing them; it operated at a different level of abstraction, focusing on the shape of the problem rather than the content of stakeholder interactions or goals.
Around the turn of the millennium, two new frameworks began to reshape the field, each responding to the growing scale and dynamism of software-intensive systems.
Model-Based Requirements Engineering (2001) emerged from the broader Model-Based Systems Engineering movement. Instead of representing requirements in separate documents or diagrams, it embedded them in an integrated, executable model that served as the single source of truth. Requirements were no longer static text; they became elements in a model that could be simulated, validated, and traced to design and test artifacts. Model-Based Requirements Engineering absorbed many techniques from earlier frameworks—structured analysis notations, goal models, and formal constraints—but transformed them by making the model the central artifact. This approach proved especially powerful in complex cyber-physical systems such as aerospace and automotive platforms, where requirements must be consistent across hundreds of interacting subsystems.
Agile Requirements Engineering (2003) took the opposite stance. Instead of building a comprehensive model upfront, Agile methods such as Scrum and Extreme Programming treated requirements as a living backlog of user stories that were elaborated incrementally through direct collaboration with customers. The Agile framework challenged the very idea that requirements could or should be fully specified before implementation began. It argued that stakeholders could not know what they wanted until they saw working software, and that the cost of change was not as high as traditional methods assumed. Agile Requirements Engineering selectively incorporated use cases (from Scenario-Based approaches) and goals (from Goal-Oriented approaches), but it rejected the upfront specification ideal shared by Formal, Structured, and Model-Based frameworks.
Today, no single framework dominates the entire field. The most productive practice often combines techniques from multiple frameworks, but the leading approaches have settled into distinct domains.
Agile Requirements Engineering is the default in software-intensive domains—web applications, mobile apps, enterprise software—where requirements are volatile and close customer collaboration is feasible. Its strength is adaptability; its weakness is that it can produce systems with poor architectural coherence or missing non-functional requirements.
Model-Based Requirements Engineering dominates complex cyber-physical systems—aircraft, automobiles, medical devices—where consistency, traceability, and verification are paramount. Its strength is precision and integration; its weakness is the upfront investment required to build and maintain the model.
Formal Requirements Specification remains essential in safety-critical and security-critical contexts, often embedded within a Model-Based framework. Structured Requirements Analysis persists in legacy systems and in organizations that have not transitioned to model-based or agile practices. Scenario-Based, Viewpoint-Oriented, Goal-Oriented, and Problem Frames have been largely absorbed into the toolkits of both Agile and Model-Based practitioners, providing specific techniques for elicitation, rationale capture, and problem structuring.
What the leading frameworks agree on is that requirements engineering is fundamentally about managing uncertainty and conflict. They disagree on when and how to resolve that uncertainty—whether through upfront analysis and formal verification (Model-Based and Formal), through iterative feedback and incremental elaboration (Agile), or through a combination tailored to the specific domain. The field has not converged on a single method, and it probably never will. Instead, it has become a toolkit of frameworks, each suited to different kinds of problems, and the skill of the requirements engineer lies in knowing which tool to apply when.