Loading field map
Requirements engineering is the subfield of systems engineering concerned with discovering, analyzing, documenting, and maintaining the needs and constraints that a system must satisfy. Its central subject is not the system itself—its architecture, components, or code—but the description of what the system is supposed to do and why. The field exists because the gap between what stakeholders want and what engineers build is the most common and most expensive source of system failure. A system that perfectly implements the wrong requirements is not a partial success; it is a total loss.
The stakes are correspondingly high. Requirements errors discovered after a system is deployed can cost orders of magnitude more to correct than errors found during initial elicitation. In safety-critical domains—aviation, medical devices, nuclear power, autonomous vehicles—a flawed requirement can lead directly to loss of life. In commercial software, vague or shifting requirements are a primary driver of schedule overruns and abandoned projects. Requirements engineering is therefore not a bureaucratic preamble to design; it is the discipline that defines the problem before resources are committed to a solution.
The fundamental difficulty of requirements engineering is that human needs do not arrive in the form of engineering specifications. Stakeholders speak in terms of desires, fears, examples, and complaints. They may not know what is technically possible, may disagree among themselves, or may assume that obvious context will be understood. The requirements engineer must transform this raw material into a set of statements that are unambiguous enough to guide design, testable enough to verify compliance, and complete enough that no critical expectation is left implicit.
This transformation involves several distinct activities, though in practice they interleave and iterate. Elicitation is the process of gathering information from stakeholders: interviewing users, observing work practices, analyzing existing systems, studying regulations, and facilitating workshops. Analysis is the work of resolving conflicts, detecting omissions, assessing feasibility, and prioritizing. Specification is the act of writing the requirements down in a form that is precise and reviewable. Validation checks that the specified requirements actually reflect what stakeholders need, often through reviews, prototypes, or simulations. Management covers the inevitable changes: tracking versions, assessing the impact of proposed modifications, and maintaining traceability from a requirement back to its source and forward to its implementation and tests.
A central distinction runs through all of these activities: the difference between the problem and the solution. A requirement should state what the system must achieve, not how it should achieve it. "The system shall allow a user to book a seat on a flight" is a requirement; "The system shall use a relational database with a web front end" is a design decision. The discipline insists on this separation because premature solution choices constrain the design space and often embed unexamined assumptions. In practice, the line is not always clean—some constraints, such as "must operate on existing hardware," are legitimate requirements—but the principle remains a central organizing idea.
Requirements engineering emerged as a recognized discipline only in the late twentieth century, but its concerns have deeper roots. Large engineering projects have always needed some form of specification. The pyramids, Roman aqueducts, and medieval cathedrals all required explicit descriptions of what was to be built, though these were often embodied in drawings, models, and craft tradition rather than written requirements documents. The modern field's direct ancestors are the systems engineering practices developed for large military and aerospace programs in the mid-twentieth century. These programs faced the problem of coordinating thousands of engineers across many organizations, and they responded with formal documentation hierarchies: system-level specifications, subsystem specifications, and component specifications, each flowing down from the level above.
The term "requirements engineering" itself came into use in the 1970s and 1980s, primarily within software engineering. The software crisis of the 1960s and 1970s—large projects delivered late, over budget, and full of defects—focused attention on the early phases of development. Researchers and practitioners began to argue that the problem was not just coding but understanding what to build. The field drew on earlier work in systems analysis, operations research, and management science, but it developed its own identity around the specific challenges of specifying software-intensive systems.
A significant early influence was the structured analysis movement, which proposed graphical notations such as data flow diagrams to model what a system does. These methods treated requirements as something to be discovered by analyzing the flow of data through an organization. A rival tradition, object-oriented analysis, emerged in the 1980s and 1990s, modeling the world in terms of objects with attributes and behaviors. These were not merely different notations; they embodied different assumptions about how to decompose a problem and what aspects of reality were most important to capture.
The field is not organized into a single sequence of schools that replaced one another. Rather, several approaches have coexisted, each addressing a different facet of the problem, and their relationships are marked by both borrowing and unresolved tension.
The oldest and still dominant approach treats requirements engineering as the production of a requirements specification document. This document is the contract between the customer and the developer, the baseline against which design and testing are measured. The approach emphasizes precision, completeness, and formality. Requirements are written as structured statements—often "shall" statements—each with a unique identifier, a priority, and a source. The document is reviewed, approved, and placed under configuration management.
The strengths of this approach are its rigor and its fit with large, contractual projects. It provides a clear basis for cost estimation, project planning, and acceptance testing. Its weaknesses are equally clear. The document becomes a frozen artifact, while stakeholder needs evolve. The emphasis on writing requirements can displace the harder work of understanding the problem. And the format encourages a focus on individual statements rather than on the coherence of the whole. Critics have long noted that a specification can be internally consistent and individually testable while still being fundamentally wrong about what users need.
A second tradition focuses less on the document and more on the process by which requirements are discovered. This approach emerged from the observation that requirements are not waiting to be collected but are constructed through interaction. Stakeholders often do not know what they want until they see something concrete to react to. The process approach therefore emphasizes iteration, prototyping, and continuous feedback. It is closely associated with agile software development, which explicitly de-emphasizes upfront specification in favor of working software as the primary measure of progress.
The process approach addresses a real failure of the specification-driven approach: its assumption that requirements can be fully known before design begins. But it has its own limits. It works best for projects where stakeholders are available, the problem is explorable, and the cost of change is low. For large, distributed, safety-critical systems, an entirely process-driven approach is impractical. The two approaches are often presented as opposites, but in practice many organizations combine them: using iterative discovery for uncertain aspects of the problem while maintaining a formal specification for contractual and safety obligations.
A third tradition holds that the central activity of requirements engineering is not writing statements but building models. A model is an abstract representation of some aspect of the problem: the entities involved, their relationships, the states a system can occupy, the events that trigger transitions, or the goals that motivate the system's existence. Modeling approaches differ in what they choose to represent and in their notation, but they share a conviction that requirements are better understood through structure than through prose.
The earliest modeling approaches were functional: data flow diagrams showed how inputs were transformed into outputs. Later approaches added data modeling, state modeling, and goal modeling. Goal-oriented requirements engineering, which became influential in the 1990s, treats requirements as refinements of high-level goals. A goal such as "maximize passenger safety" is decomposed into subgoals, each assigned to an agent—a human, a software component, or a hardware device. This approach makes explicit the reasoning that connects high-level intentions to specific requirements, and it provides a basis for detecting conflicts between goals.
The modeling approach's strength is its ability to expose structure and relationships that prose hides. Its weakness is that models are abstractions, and abstraction means omission. A model that captures the logical structure of a problem may miss its political, social, or emotional dimensions. Moreover, models require interpretation; two analysts can build different models of the same problem, and there is no guarantee that either captures what stakeholders actually need.
A fourth tradition, more recent and more diffuse, focuses on the human and organizational context of requirements. This approach draws on ethnography, psychology, and communication theory. It argues that the central difficulty of requirements engineering is not technical but social: stakeholders have different backgrounds, different vocabularies, different power positions, and different unstated assumptions. The requirements engineer is not an analyst extracting information but a facilitator constructing shared understanding.
This tradition has contributed techniques such as contextual inquiry, in which the analyst observes users in their actual work environment rather than interviewing them in a conference room; participatory design, in which stakeholders are actively involved in designing the system; and various workshop and negotiation techniques for resolving conflicts. Its influence has been real but diffuse; it has not produced a unified method, and its insights are often absorbed into other approaches as "good practices" rather than as a distinct paradigm.
The present state of requirements engineering is best understood as a set of enduring tensions rather than a settled consensus. The tension between upfront specification and iterative discovery remains unresolved and is likely to remain so, because the right balance depends on the project. The tension between natural language and formal notation persists: natural language is flexible and accessible but ambiguous; formal notation is precise but requires training and can be incomprehensible to stakeholders. The tension between completeness and cost is fundamental: discovering every requirement is impossible, and the effort spent seeking completeness has diminishing returns.
Several trends have shaped the field's recent development without resolving these tensions. The rise of model-based systems engineering has pushed requirements into digital models that can be simulated and analyzed, rather than static documents. The growth of safety and security standards has made traceability—the ability to link each requirement to its source and to its verification—a legal and regulatory necessity in many domains. The increasing complexity of systems-of-systems, where multiple independent systems must interoperate, has made requirements engineering a problem of coordination across organizational boundaries as much as technical specification.
A persistent challenge is the field's relationship to artificial intelligence. Machine learning systems do not have requirements in the traditional sense; they have training data, objectives, and evaluation metrics. Whether these can be treated as requirements, and how to specify behavior that is learned rather than programmed, is an open question. Some researchers argue that the field must develop new forms of specification for learning systems; others argue that the traditional concepts still apply, but to the system's goals and constraints rather than to its internal logic.
The field's enduring contribution is not any particular method or notation but a stance: the insistence that building the right thing is as important as building the thing right. Requirements engineering is the discipline that keeps that insistence operational. It provides the concepts—stakeholder, goal, constraint, traceability, validation—that allow engineers to ask, before committing resources, what problem they are actually solving and how they will know when they have solved it. The methods will continue to evolve, but the questions at the field's core are permanent features of engineering practice.