Loading field map
Requirements engineering is the subfield of software engineering concerned with discovering, analyzing, documenting, and maintaining the conditions under which a software system is to be built. Its central question is deceptively simple: What should the software do, and under what constraints? The difficulty lies in the fact that the answer is rarely known in advance, is held by many different people with conflicting interests, changes over time, and is expressed in a language (human intent) that differs fundamentally from the language of implementation (code and data structures).
The stakes are high because requirements errors are the most expensive errors to fix. A misunderstanding discovered during coding might require rework of a single module; the same misunderstanding discovered after deployment can require re-architecting the entire system, retraining users, and migrating data. Consequently, requirements engineering is not a preliminary "nice-to-have" phase but a continuous discipline that runs through the entire software lifecycle, from initial feasibility studies to post-deployment evolution.
The core challenge of requirements engineering is a translation problem. Stakeholders—users, managers, regulators, system operators—have needs, but these needs are typically expressed as desires, complaints, or analogies ("the system should be fast," "it should work like our old paper process but better"). These raw expressions are not requirements; they are inputs to the requirements process.
The discipline distinguishes between several levels of abstraction. A business requirement states an organizational goal ("reduce customer support call volume by 20%"). A user requirement describes a task a user wants to accomplish ("allow customers to track their order status online"). A system requirement is a technical statement of what the software must do ("the system shall display the current shipping status within 2 seconds of a request"). The movement from business to system requirements is not a simple translation; it involves negotiation, discovery, and often the realization that the original desire is not what is actually needed.
A second fundamental distinction is between functional requirements (what the system does: "the system shall calculate interest daily") and non-functional requirements (how well it does it, or constraints on its operation: "the system shall support 1,000 concurrent users," "the system shall comply with GDPR," "the system shall be maintainable"). Non-functional requirements are often more critical and more difficult to specify. A system that meets every functional requirement but is too slow, insecure, or unusable has failed. Yet non-functional requirements are frequently implicit, conflicting, and hard to verify.
A third distinction is between requirements (what is needed) and specifications (a formal or semi-formal description of what will be built). A specification is a design-independent statement of behavior, but it is still a model, not the system itself. The gap between a specification and the implemented system is the province of design and coding; the gap between stakeholder needs and the specification is the province of requirements engineering.
Early software engineering, from the 1950s through the 1970s, treated requirements as a preliminary step. The dominant model was the waterfall lifecycle, in which requirements analysis was the first phase, followed by design, coding, testing, and maintenance. The assumption was that requirements could be fully captured up front, frozen, and then handed off to designers. This worked for well-understood, mathematically oriented systems (e.g., scientific computing, compilers) but failed for business systems, where users did not know what they wanted until they saw something concrete, and where the environment itself changed during development.
The term "requirements engineering" emerged in the late 1970s and 1980s as researchers and practitioners recognized that requirements were not a phase but a problem. Two intellectual currents fed this recognition. First, the structured analysis movement (e.g., data flow diagrams, entity-relationship models) provided graphical notations for representing requirements, but these notations were still static and phase-oriented. Second, the growing use of formal methods in the 1980s—particularly for safety-critical systems—demanded precise, mathematical specifications, leading to notations like Z and VDM. These formal approaches were powerful but required a level of mathematical sophistication that most stakeholders lacked.
The 1990s brought a decisive shift with the rise of agile methods. Agile development rejected the assumption that requirements could be fully known in advance. Instead, it embraced iterative development, continuous customer involvement, and the idea that requirements emerge through use. This was not a rejection of requirements engineering but a redefinition: requirements became a continuous conversation rather than a deliverable document. The agile movement also popularized user stories—short, informal descriptions of a feature from a user's perspective—as a lightweight alternative to heavy requirements documents.
The field is not organized into a single succession of schools but rather into several coexisting traditions, each addressing a different aspect of the problem. These traditions overlap, borrow from each other, and often conflict in practice.
The oldest and most formal approach treats requirements engineering as the production of a precise, complete, and unambiguous specification. Its methods include structured analysis (data flow diagrams, entity-relationship models), formal specification languages (Z, VDM, B), and model-based approaches (UML use cases and activity diagrams). The organizing assumption is that ambiguity is the enemy, and that a well-formed specification can be verified for consistency and completeness before any code is written.
This tradition's strength is rigor. For safety-critical systems (aviation, nuclear power, medical devices), a formal or semi-formal specification is often a regulatory requirement. Its weakness is that completeness and unambiguity are rarely achievable for complex, human-centered systems. Stakeholders cannot articulate all their needs in advance, and even if they could, the specification would be so large as to be unreadable. The specification tradition has therefore evolved toward modeling—creating partial, view-based representations (use case diagrams, state machines, sequence diagrams) that are precise enough to reason about but not so formal as to be inaccessible.
A second tradition focuses on the process of discovering requirements. Its methods include interviews, workshops, focus groups, ethnographic observation, and prototyping. The organizing assumption is that requirements are not "out there" waiting to be collected but are constructed through interaction between analysts and stakeholders. This tradition draws on social science methods and emphasizes the political and organizational context of software development.
The key insight of this tradition is that stakeholders often cannot articulate their needs directly. They may not know what is technically possible, they may have conflicting interests, or they may be so embedded in their current practices that they cannot imagine alternatives. The analyst's job is not to transcribe but to facilitate—to ask probing questions, to surface assumptions, to mediate conflicts. Techniques like joint application design (JAD) and later agile user story workshops are practical expressions of this tradition.
Its weakness is that it can become process-heavy without producing a durable artifact. A workshop that produces a shared understanding but no written record is of limited value. The tradition therefore typically pairs with the specification tradition: elicitation produces raw material, and specification structures it.
The agile tradition, which became dominant in commercial software development from the 2000s onward, is not merely a set of practices but a distinct philosophy of requirements. Its organizing assumption is that requirements are emergent—they cannot be fully known in advance, and the most efficient way to discover them is to build working software in short iterations and let users react to it. The requirements artifact is the product backlog: a prioritized list of user stories, which is continuously refined, re-prioritized, and re-estimated.
This tradition's strength is its responsiveness. It avoids the "big requirements document up front" that often becomes obsolete before it is finished. Its weakness is that it can under-specify non-functional requirements and architectural constraints. A team that only works from user stories may discover too late that the system cannot scale, or that security requirements were never considered. Mature agile practice addresses this through "non-functional requirements as stories" and through architectural spikes, but the tension remains.
The agile tradition also introduced the role of the product owner—a single individual responsible for representing stakeholder interests and prioritizing the backlog. This is a significant departure from the earlier model of a requirements analyst who serves as a neutral intermediary. The product owner is expected to be deeply embedded in the business and to make ongoing trade-off decisions.
A more recent and academically influential approach is goal-oriented requirements engineering (GORE). This tradition treats requirements not as statements of behavior but as goals to be achieved. Methods like KAOS and i provide formal frameworks for modeling goals, their refinement into sub-goals, conflicts between goals, and the assignment of goals to agents (human or software). The organizing assumption is that understanding why a system is needed is as important as understanding what* it should do.
GORE's contribution is to make the reasoning behind requirements explicit. Instead of a flat list of requirements, the analyst produces a goal graph showing how high-level objectives (e.g., "maximize customer satisfaction") decompose into operational requirements (e.g., "reduce response time to under 2 seconds"). This supports conflict analysis (two goals may be mutually incompatible) and traceability (every requirement can be traced back to a goal it serves). Its weakness is its complexity; goal models can become as large and unreadable as formal specifications, and the notation has a steep learning curve.
Contemporary requirements engineering is a hybrid practice. Most real projects combine elements of all four traditions. A typical large project might use agile user stories for day-to-day iteration planning, a lightweight use case model for understanding major user interactions, a goal model for the project's strategic objectives, and a formal specification for safety-critical components. The field's current research agenda reflects this hybridity.
Requirements traceability—the ability to link each requirement to its source, its design, its tests, and its code—remains a central concern. Traceability is essential for impact analysis (what breaks if this requirement changes?), for compliance (proving to a regulator that a requirement was met), and for maintenance. Modern tools support traceability through linked artifacts in issue trackers, model repositories, and test management systems.
Requirements quality is another enduring focus. Researchers and practitioners have developed checklists and metrics for evaluating requirements (e.g., atomicity, testability, unambiguity), but these remain largely manual. Automated quality assessment, using natural language processing to detect vague terms or conflicting statements, is an active research area with growing practical adoption.
Requirements for AI and data-driven systems is a newer frontier. Traditional requirements assume deterministic behavior that can be specified in advance. Machine learning systems, by contrast, have behavior that emerges from training data and cannot be fully specified. The field is grappling with how to write requirements for systems whose behavior is probabilistic, how to specify acceptable performance bounds, and how to handle the ethical and regulatory dimensions of AI. This is not a settled area; it is an open problem.
Requirements in agile and DevOps contexts has shifted the field's center of gravity from documentation to conversation. The modern practitioner is less likely to write a 200-page requirements document and more likely to maintain a living backlog, facilitate backlog refinement sessions, and work with testers to define acceptance criteria. The role has become more collaborative and more continuous, but the underlying discipline—asking the right questions, making trade-offs explicit, and ensuring that what is built is what is needed—remains unchanged.
The field's enduring contribution to software engineering is not any single method or notation but the recognition that the hardest problems in building software are often not technical but epistemic: they concern what can be known, by whom, and when. Requirements engineering is the discipline that takes this epistemic challenge seriously, providing the concepts, techniques, and tools for navigating the gap between human need and machine behavior.