Methods
Requirements Engineering
Turning what people ask for into statements precise enough to build and test against, and specific enough that stakeholders can disagree with them before code is written.
Part of Digital Strategy & Discovery
Requirements Engineering is the work of eliciting, clarifying and recording what a system must do, precisely enough that two people reading the same requirement would build the same thing.
Where it fits
An ambiguous requirement tends to surface late, in testing or in production, when someone says the system does not do what they meant. A requirement written specifically enough lets a stakeholder disagree with it early, while the change is still cheap.
Precise here means testable. "The system must be fast" cannot be checked, while "search results return within two seconds for 95% of requests at 500 concurrent users" can be measured. It also means recording the unhappy path: what happens when a field is missing, an upstream service is down, or two users edit the same record. Many defects and change requests come from those cases.
Its limits
Understanding improves during a project, so requirements need revisiting, with each change recorded and agreed. Very detailed specifications written all at once take time and go out of date quickly.
How we use it
We write acceptance criteria that testers can use directly and spell out permissions and error cases. For a sales CRM we designed for GMM Music Publishing International, the deliverables included user flows, a permission matrix and an API specification.
Related
Solution Architecture, Enterprise Software Development, Software Testing & QA