Requirements engineering is the part of software engineering concerned with discovering, agreeing on, and recording what a system is supposed to do. It covers eliciting needs from stakeholders, analyzing and reconciling them, specifying them precisely, validating that the specification is correct, and managing changes to requirements over time.
The discipline is formalized in the IEEE Computer Society’s Guide to the Software Engineering Body of Knowledge (SWEBOK), which devotes a full knowledge area to Software Requirements. That knowledge area distinguishes functional from nonfunctional requirements and structures the work into requirements elicitation, analysis, specification, validation, and management - the standard activities that define the field.
Requirements get separate, careful treatment because getting them wrong is among the most expensive mistakes in software. Errors introduced at the requirements stage but caught only during testing or operation force redesign that ripples back through everything built on top of them - the same trap Winston Royce highlighted in his 1970 waterfall paper and that Barry Boehm’s risk-driven and cost-estimation work later quantified.
Because of that leverage, requirements engineering grew into its own subdiscipline with dedicated techniques such as interviews, prototypes, use cases, and formal specifications, and dedicated roles such as the business analyst. Modern iterative and agile methods do not abandon it; they change when and how often requirements are elicited and validated rather than whether the work is done at all.