Introduction
Requirements Engineering (RE) is the disciplined, systematic process of discovering, analysing, documenting, validating and managing what a software system must do and the constraints under which it must operate — before and while it is built. In one line: RE answers the questions "What should the system do?" and "Under what conditions?" — deliberately before deciding how it will be built (which is design).
Why it matters for your exam (BCS, Bank IT, and IT-officer posts): RE is one of the most heavily-tested areas of Software Engineering because it is where most real-world project failures begin. Classic industry studies (Standish CHAOS, and Boehm's cost-of-change data) repeatedly show that requirement defects are the single largest cause of project failure, and that a defect is far cheaper to fix in the requirements phase than after release. Examiners love this topic because it links definitions (FR vs NFR, verification vs validation), a named process, elicitation techniques, the SRS document (IEEE 830), and the economics of fixing bugs.
Learning objectives
By the end of this lesson you will be able to:
- Define requirement, requirements engineering, and stakeholder, and explain why RE is done first.
- Distinguish functional vs non-functional requirements, and user vs system requirements, with examples.
- Describe the RE process: elicitation, analysis, specification, validation, and management.
- Name and compare elicitation techniques (interviews, workshops/JAD, prototyping, observation, questionnaires, use cases).
- Explain the structure and purpose of an SRS (Software Requirements Specification) and the IEEE 830 quality attributes of a good requirement.
- Perform requirements validation and requirements traceability, and handle change/creep.
- Solve exam-style numeric problems on the cost-of-change / cost-of-fixing-a-defect economics of RE.