The document that’s supposed to say what to build — in practice, usually incomplete, ambiguous, or wrong in some way that only becomes visible once someone starts building.
Requirements engineering — the academic name for the discipline of writing specs well — is treated in software-engineering research as one of the hardest and most consequential parts of the whole development process, not a bureaucratic formality that precedes the “real” work of coding. Most costly software failures trace back to a requirements problem — the spec described the wrong thing, or an ambiguous thing — rather than a coding error executing a correct spec badly.
That’s the detail easy to miss in “AI can write clean code from specs”: the hard, judgment-heavy part was often writing the spec accurately in the first place, not the code that followed from it.
🔗 Related Concepts
Source: Nuseibeh, B. & Easterbrook, S. “Requirements engineering,” ACM (ICSE ‘00 track), 2000.