Requirements analysis (or requirements engineering) is the process of discovering, analyzing, documenting, and validating the conditions and capabilities that a software system must satisfy. It bridges the gap between stakeholder needs and technical system specifications, and is widely recognized as one of the most critical and error-prone phases of software development.

Origins and History

The importance of requirements was recognized early in software engineering history. The NATO Software Engineering Conference in 1968, which coined the term “software engineering,” identified requirements as a primary challenge. Barry Boehm’s research in the 1970s and 1980s demonstrated that requirements errors detected late in development cost 50-200 times more to fix than those caught during requirements analysis. The IEEE 830 standard (1984, revised 1993 and 1998) provided a recommended practice for software requirements specifications (SRS). Michael Jackson’s “Problem Frames” approach (2001) offered an alternative to document-centric methods by focusing on the relationship between the machine and the world it operates in. The agile movement shifted requirements practices from comprehensive upfront documentation toward user stories and continuous refinement, though the underlying analytical activities remain essential regardless of methodology.

Core Activities

Elicitation gathers requirements from stakeholders through interviews, workshops, observation, prototyping, surveys, and document analysis. Analysis examines requirements for completeness, consistency, feasibility, and conflicts, often using modeling techniques (use cases, user stories, data flow diagrams, state machines). Specification documents requirements in a structured format that is understandable by both stakeholders and developers. Validation confirms that the documented requirements accurately reflect stakeholder needs, using techniques such as reviews, walkthroughs, and prototypes. Requirements are classified as functional (what the system must do) and non-functional (quality attributes such as performance, security, usability, and reliability).

Practical Applications

Requirements analysis is performed in every software project, whether through formal SRS documents in regulated industries (medical devices, aviation, defense), user stories and acceptance criteria in agile projects, or lightweight specifications in startups. Poor requirements are consistently identified as a leading cause of project failure in industry surveys.

Sources

  1. IEEE (1998). “IEEE Recommended Practice for Software Requirements Specifications.” IEEE Std 830-1998.
  2. Boehm, B.W. (1981). Software Engineering Economics. Prentice Hall.
  3. Wiegers, K.E. and Beatty, J. (2013). Software Requirements, 3rd ed. Microsoft Press.