According to Pohl, what are the four core activities of requirements engineering, and over what span are they carried out?
Elicit the stakeholders' requirements, document them suitably, validate & verify them, and manage them — and you do all four across the entire life cycle of the system, not just once at the start.
Pohl frames RE as four continuous activities (not sequential phases):
- Elicit — actively draw the requirements out of stakeholders, documents, and existing systems, refining them in greater detail. (They rarely arrive fully formed; you have to dig.)
- Document — record the elicited requirements in a suitable form, using natural language or conceptual models so they can be communicated and checked.
- Validate & verify — confirm the requirements are the right ones and are stated correctly: validation asks "are these what the stakeholders actually want?", verification asks "do they meet the predefined quality criteria (clear, consistent, testable)?"
- Manage — keep the requirements organised, consistent, and up to date as they change, so the different roles can keep using them.
Why "entire life cycle" is the load-bearing phrase: requirements aren't authored once and filed away. They're consulted, challenged, and revised through design, build, test, and evolution. Treating RE as a one-off front-loaded phase is the classic mistake — change management of requirements is part of the job to the very end.
(Some standards, e.g. ISO/IEC/IEEE 29148, phrase the four as Elicitation, Documentation, Validation & Negotiation, and Management — the same skeleton with slightly different labels.)