Most software projects fail not on technology but on requirements: unclear, contradictory, incomplete or recognised too late. Requirements engineering is the discipline that tackles this risk systematically. It is needed in traditional and agile approaches alike, just in different forms.
The four activities
Elicit: gain requirements from interviews, workshops, observation, documents and existing systems, involving the right stakeholders. Document: in a form the people involved understand, from natural language through models to user stories. Validate: check that requirements are correct, complete, consistent and feasible before building. Manage: changes, priorities, versions and traceability to tests across the whole lifecycle.
Types of requirements
Functional requirements describe what the system should do. Quality requirements describe how well: performance, security, availability, usability, maintainability. Constraints describe non-negotiable givens, such as laws, data residency or prescribed technologies. Quality requirements and constraints are the most often forgotten, and they cause the most expensive surprises.
Traditional and agile
In traditional approaches a comprehensive document is produced early, such as a requirements or functional specification, which serves as the basis for tender and acceptance. In agile approaches requirements are refined step by step, and the backlog replaces the document. Both need the same skills. In public tenders and projects under HERMES the two worlds often meet: a binding requirements catalogue for procurement, agile refinement in delivery.
The IREB CPRE standard
With the Certified Professional for Requirements Engineering (CPRE), the International Requirements Engineering Board (IREB) defines a widespread body of knowledge with a common terminology. It is not a process model but a shared vocabulary and set of methods. Leutrim Miftaraj, founder of Innopulse, is certified at IREB CPRE Foundation Level and works as a business analyst on mandates at Swiss institutions according to this standard.
Signs of good requirements engineering
Every requirement has a source and a priority, is unambiguous and verifiable. Acceptance criteria are fixed before building. Contradictions are resolved, not postponed. And there is a defined path for changes that makes the impact on effort and schedule visible. Where this discipline is missing, external project management with business analysis helps.