Requirements Engineering

Requirements engineering is the disciplined effort to discover, describe, check, prioritize, and manage what a system must do and the conditions it must satisfy.

From the software crisis to requirements engineering

During the 1960s, software projects were becoming large enough that informal programming practices no longer worked reliably. Projects ran late, exceeded their budgets, produced unreliable systems, or delivered software that did not meet its intended purpose. The 1968 NATO conference on software engineering helped establish software engineering as a distinct discipline. It did not solve the software crisis, but it drew wide attention to the need for disciplined development. In particular, teams had to compare a system against a specification, and that specification had to describe what the system was supposed to accomplish.

Over the following decades, researchers and practitioners developed methods for describing systems more carefully. Teams studied how to elicit requirements from stakeholders, analyze conflicts and constraints, write requirements specifications, validate them, and manage changes. By the 1990s, requirements engineering had become a named subject in its own right. Books such as Ian Sommerville and Pete Sawyer’s Requirements Engineering: A Good Practice Guide (1997) and Gerald Kotonya and Ian Sommerville’s Requirements Engineering: Processes and Techniques (1998) taught requirements elicitation, analysis, specification, validation, and management as connected activities rather than as a single document-writing task. IEEE 830-1998 also gave teams a widely recognized structure for software requirements specifications.

From documents to conversations

In the early 2000s, software development teams began to question the value of large, formal requirements documents. The 2001 Agile Manifesto emphasized working software and customer collaboration over comprehensive documentation and contract negotiation. Requirements therefore became more incremental and conversational. Teams used product backlogs, user stories, acceptance criteria, examples, prototypes, and frequent discussions to decide what to build next. The form changed, but the underlying questions remained the same: Who needs what behavior? Under what conditions? How will we know that the system provides it? What should the team do when two legitimate requests conflict?

Standards continued to treat requirements as a lifecycle activity rather than a one-time planning phase. ISO/IEC/IEEE 29148, whose 2018 edition is still an active standard, describes requirements engineering and management across the life of a system. Requirements may change when stakeholders discover missing needs, resolve conflicts, or get evidence from prototypes and use. They still need to be discovered, stated, checked, prioritized, and kept consistent with the system being built.

Back to documents with AI agents

AI coding agents change how quickly a team can move from a request to an implementation. An agent can generate code, tests, database changes, configuration, and documentation in response to a description of the desired behavior. That changes the cost of implementation. It does not transfer responsibility for deciding what the software should do.

Suppose someone asks an agent to “make publishing easy for authors and editors.” The agent can produce a plausible workflow, but the request leaves important decisions open. Can an author publish directly? Must an editor review every post? Can an author edit a submitted post? What happens when an editor returns it? Which roles may perform each action? Different answers produce different systems, and an agent may choose one without realizing that the choice conflicts with the university’s policy.

The faster the agent produces software, the faster it can carry an unstated assumption through many files and behaviors. A human team may have noticed the uncertainty while discussing a requirement because implementation took time. An agent can produce a working demo before anyone notices the uncertainty. The code may run, the tests may pass, and the system may still implement the wrong behavior.

That is why documenting requirements up front is important again. The requirements specification becomes more important when agents write software. We need clear requirements to direct the agent, acceptance criteria to check its result, and explicit decisions to prevent it from filling important gaps on its own. We also need people who understand the users, constraints, and consequences well enough to judge whether the generated system is correct.

This does not mean returning to massive documents or trying to specify every line before development begins. It means keeping the essential agreement documented: the behavior the system must provide, the conditions that govern it, the quality attributes it must have, the constraints it must respect, the priorities that shape its scope, and the evidence that will show whether the system meets the requirements.

Requirements engineering remains the starting point for software development, even when AI agents can implement software quickly. The responsibility to decide what a system should do, and to recognize when the result does not meet that intention, remains with the people building and using it.

System design in the age of AI

This chapter began by defining system design as the work of deciding how a system will meet its requirements. That responsibility is becoming more important as AI agents make implementation faster. The reason is not that AI will permanently stop at “lower-level” coding while people keep every “higher-level” task. That division is too simple, and the boundary keeps moving. AI can already propose designs, compare alternatives, and modify code across an entire project, and it will get better at those tasks over time.

The reason design remains important is that it is the work of making choices that have consequences. A system’s behavior, cost, and maintainability depend on those choices.

If human engineers remain accountable for a system’s behavior, they must audit and approve the design decisions that lead to that behavior. That means they must understand the design, its trade-offs, and its consequences. Someone must still decide which behavior to support, which trade-offs to accept, which risks are tolerable, and whether the resulting system fits the people and organization that will use it. AI can help with those decisions, but it does not remove the responsibility for them.

AI still has some way to go before it can make all those decisions for us and leave us with only the liability for the consequences. A 2025 study of practitioners using AI for software development found that requirements were usually too abstract to send directly to a coding model. Developers first decomposed them into programming tasks and added design decisions and architectural constraints. Another study of experienced developers using coding agents found that they planned before implementation, validated the agents’ output, and preferred agents for well-described tasks rather than for complex, poorly specified work.