Requirements Engineering and Analysis
Domain 2 tests how requirements are elicited, written, validated and controlled. Expect to classify a requirement, judge whether a statement is verifiable, and identify which artifact records what.
Classification
- Functional requirements describe what the system does: inputs to outputs, and business rules.
- Non-functional requirements constrain how well it does it. ISO/IEC 25010 groups quality attributes such as performance efficiency, reliability, security, usability, maintainability, portability and compatibility.
- Constraints are imposed decisions (platform, regulation, legacy interface) rather than negotiable needs.
Writing verifiable requirements
A good requirement is singular, unambiguous, feasible, necessary and testable. Replace adjectives with measurable thresholds: instead of 'the system shall be fast', write 'the 95th percentile response time for the report request shall be at most 800 ms with 200 concurrent users on the reference hardware'. User stories follow 'As a role, I want a capability, so that a benefit' and are sized with INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable); acceptance criteria are often written Given/When/Then. Use cases record actor, preconditions, main success scenario, alternate and exception flows, and postconditions. Elicitation techniques include interviews, facilitated workshops, observation of real work, document analysis, surveys and throwaway prototyping.
Worked example
Statement: 'The report screen shall be user-friendly and load quickly.' Reasoning: this hides two requirements (split them), both are unverifiable adjectives, and neither states an actor, load or measurement method. Rewrite as (a) 'When an authenticated clerk opens the monthly report, 95 percent of requests shall render within 2 seconds with up to 200,000 rows in the database', testable by a timed performance test; and (b) 'At least 80 percent of 10 representative clerks shall complete the report task unaided in a usability test', testable by observation. Trace both to test cases in the requirements traceability matrix and place them under change control.
Traps that cost marks
- Reporting an NFR as a design decision; caching is a tactic, 800 ms is the requirement.
- Confusing verification (did we build it right, per spec) with validation (did we build the right thing, per need).
- Accepting 'shall support' with no conditions, scope or measurement.
- Writing acceptance criteria that merely restate the story.
- Treating requirements as frozen; change control with impact analysis and traceability is the expected answer.