Requirements & Elicitation
Requirements are why a systems analyst exists. A mistake here is costlier than any other: an unmeasurable or ambiguous requirement drags rework through analysis, development, and testing. So requirements are gathered methodically, checked against criteria, and carried through a lifecycle to verified delivery.
The traps, named up front: functional get confused with non-functional, "unambiguity" is swapped for length, a non-functional requirement is left with no measurable target, and the analyst themselves is reduced to either a tester or a "wish forwarder". The full map is in the layers below.
Topic map
- The systems-analyst role — the bridge between business and development and who they interact with.
- Requirement types — business, functional, non-functional, and user requirements.
- Non-functional requirements — system qualities (availability, performance, security) and their measurability.
- Elicitation techniques — interviews, questionnaires, document analysis, and internal vs external customer.
- Requirement quality criteria — unambiguity, completeness, verifiability, traceability.
- The requirement lifecycle — from business need through analysis and delivery to verification, with traceability.
Common traps
| Mistake | Consequence |
|---|---|
| Confusing functional (what it does) and non-functional (how well) | System qualities get lost and no one owns them |
| Stating an NFR with no measurable target | The requirement cannot be verified and acceptance is impossible |
| Treating business requirements as low-level detail | The project's scope and justification are lost |
| Confusing unambiguity with length | A long but ambiguous requirement breaks the build |
| Believing a requirement cannot be tested | Errors surface only in code, late and expensive |
| Reducing the analyst's role to a tester or "forwarder" | Analysis, decomposition, and task-setting vanish |
Interview relevance
This is the core of a systems-analyst interview. It checks not memorized lists but the ability to tell a quality from a function, make a requirement measurable, and carry it through the lifecycle. A candidate who answers "which NFRs did you set" with measurable targets ("availability 99.9%", "response < 200 ms") is immediately ahead of one who says "fast and reliable".
Typical checks:
- The requirement types and the functional vs non-functional difference.
- The quality criteria (unambiguity, verifiability, traceability).
- Elicitation techniques and the internal vs external customer difference.
- The requirement lifecycle and that requirements are themselves tested, not just the code.
Common wrong answer: "requirements cannot be tested — only the code is". In fact requirements are checked in layers: the analyst against quality criteria, the team for shared understanding, and QA against scenarios derived from the requirements.