Loading field map
Every software project begins with a question that is deceptively simple: what should we build? Answering that question reliably has proven one of the hardest problems in software engineering. The cost of getting it wrong is enormous—systems that meet their specification but fail to solve the real problem, or that satisfy one stakeholder while alienating another. Requirements engineering (RE) is the subfield that grapples with this challenge. Its history is a series of attempts to tame the ambiguity, incompleteness, and conflict inherent in human needs, each framework proposing a different discipline for moving from vague desires to actionable specifications. The central tension running through all of them is between precision and flexibility: how do we capture requirements rigorously enough to guide construction, yet remain open to learning and change?
The earliest systematic approach to requirements was Structured Requirements Analysis, dominant from the 1970s through the mid-1980s. Emerging from the broader structured programming movement, it treated requirements as something to be discovered through disciplined decomposition. Analysts built data-flow diagrams, entity-relationship models, and state-transition diagrams to represent what a system must do. The method assumed that with enough analytical rigor, a complete and consistent specification could be produced before any code was written. Its strength was bringing order to chaotic early projects; its weakness was that it offered no way to verify that the model actually matched what stakeholders needed.
Formal Requirements Specification arose in the 1980s as a direct challenge to the perceived imprecision of structured analysis. Where structured methods used informal diagrams and natural language, formal specification employed mathematical notation—Z, VDM, or CSP—to define system behavior unambiguously. Proponents argued that only a formal specification could be proved correct and that ambiguity was the root cause of requirements failures. Formal methods did not replace structured analysis so much as coexist with it in a competitive relationship: structured analysis remained more accessible to practitioners, while formal specification found a home in safety-critical and security-sensitive domains where the cost of ambiguity was unacceptable. Over time, formal specification narrowed in scope, retreating from general-purpose use to specialized niches where its rigor was essential and its overhead tolerable.
By the late 1980s, a different critique was emerging. Even a perfectly precise specification could be wrong if it captured the wrong thing. Goal-Oriented Requirements Engineering shifted the focus from what the system should do to why it should do it. Frameworks such as KAOS and i* modeled requirements as goals that stakeholders wanted to achieve, along with the rationales and trade-offs that connected high-level objectives to low-level system functions. This made requirements traceability possible: a designer could ask why a particular feature existed and follow the chain back to a stakeholder goal. Goal orientation also enabled systematic conflict analysis—when two goals pulled in opposite directions, the framework made the tension visible and negotiable. It did not abandon precision; instead, it absorbed the formal tradition's concern for rigor while adding a layer of human rationale that structured analysis had ignored.
Around the same time, Problem Frames offered a complementary shift. Instead of starting with a solution specification, Michael Jackson's Problem Frames asked analysts to first understand the problem context: the physical world in which the software would operate. A problem frame described a recurring class of software problem—such as controlling a device or providing information about a domain—along with the phenomena and constraints that defined it. By classifying the problem before designing the solution, Problem Frames made explicit the assumptions about the environment that structured analysis often left implicit. The approach never achieved the industrial adoption of goal-oriented methods, but it influenced later work on domain analysis and requirements patterns, and it remains active in research as a tool for clarifying the boundary between the machine and the world.
The 1990s brought a recognition that no single model could capture all relevant aspects of a system. Scenario-Based Requirements Engineering addressed this by centering requirements on concrete narratives of use. Use cases, popularized by Ivar Jacobson and later absorbed into the Unified Modeling Language (UML), described how actors interacted with a system to achieve specific goals. Scenarios made requirements tangible for stakeholders who struggled with abstract models, and they became the backbone of many industrial RE practices. The approach did not replace goal-oriented or structured methods; rather, it coexisted with them as a complementary technique. Scenarios were particularly effective for elicitation and validation, while goal models remained better suited for analysis and traceability.
Viewpoint-Oriented Requirements Engineering tackled a different dimension of multiplicity: the fact that different stakeholders see the same system differently. Frameworks such as VORD and PREview proposed that requirements should be organized by viewpoint, with each viewpoint representing a particular stakeholder's perspective. Conflicts between viewpoints were not bugs to be eliminated but features to be managed through negotiation and reconciliation. Viewpoint-oriented methods were influential in research and in domains like air traffic control, where multiple authorities had legitimate but conflicting requirements. Their practical adoption was uneven, however, because managing the proliferation of viewpoints and their interrelationships added significant complexity to the RE process—a cost that many projects were unwilling to bear.
The turn of the millennium brought a fundamental challenge to the entire premise of upfront requirements engineering. Agile Requirements Engineering rejected the idea that requirements could or should be fully specified before development began. Instead, it treated requirements as emergent: discovered through iterative cycles of development, feedback, and adaptation. User stories replaced detailed specifications; face-to-face conversation replaced written documents; and the backlog replaced the requirements document. Agile RE did not solve the problems that earlier frameworks had addressed—it declared those problems secondary to the greater risk of building the wrong thing because the world had changed. This was not a refinement of prior approaches but a direct confrontation. Where structured analysis and formal specification sought to eliminate ambiguity, agile RE embraced it as a natural consequence of learning. Where goal-oriented and viewpoint-oriented methods provided sophisticated tools for analysis, agile RE prioritized speed and responsiveness over analytical depth.
Agile RE became dominant in commercial practice, particularly for web and mobile applications where requirements changed rapidly and the cost of delay was high. Its dominance was not total, however. Safety-critical systems, large-scale infrastructure, and regulated industries continued to rely on the precision-oriented frameworks that agile had challenged. The result was a landscape of living disagreement: agile practitioners argued that upfront specification was wasteful and dangerous; traditional RE researchers countered that agile methods scaled poorly and left critical requirements implicit.
Today, no single framework has won. The leading approaches—Goal-Oriented RE, Scenario-Based RE, and Agile RE—coexist in a state of pragmatic pluralism, each best suited to different project contexts. Goal-oriented methods excel when requirements traceability and conflict analysis are paramount, as in safety-critical or compliance-heavy domains. Scenario-based techniques remain the default for elicitation and communication in many organizations, often combined with agile practices. Agile RE dominates in fast-moving commercial environments where learning speed matters more than completeness.
What the leading frameworks agree on is that requirements engineering is fundamentally about managing uncertainty and conflict. They disagree on how to do it: whether through upfront analysis and formalization, through iterative discovery and feedback, or through a hybrid that selects tools based on project risk. The practical consequence is that modern RE practitioners rarely commit to a single framework. They borrow from multiple traditions—writing user stories for features, goal models for rationale, scenarios for validation, and formal specifications for critical subsystems—assembling a bespoke process that matches the specific pressures of their project. This pluralism is not a sign of failure but of maturity: the subfield has learned that no single answer fits every question.
The enduring tension between precision and flexibility remains unresolved, and it probably should be. Requirements engineering is not a problem to be solved but a practice to be cultivated, one that requires judgment, negotiation, and the willingness to adapt. The frameworks described here are tools for that practice, each illuminating a different facet of the challenge. Understanding their history—their competitions, absorptions, and specializations—gives the student not a recipe but a repertoire.