Software Requirements and Specification
What the domain covers
This domain tests requirements engineering: elicitation, analysis, specification, validation, and management. Expect questions on functional versus non-functional requirements, specification quality characteristics, use cases, user stories with acceptance criteria, and bidirectional traceability.
Core rules
- A requirement should be necessary, unambiguous, complete, consistent, feasible, verifiable, and traceable.
- Separate functional behavior from quality attributes such as performance, security, and usability, and from constraints such as platform or law.
- Write requirements as “shall” statements with measurable acceptance criteria, including trigger, conditions, and thresholds.
- Maintain traceability from stakeholder need to requirement to design, code, and test.
Worked example
Original: “The system shall respond quickly to user searches.” This fails verifiability. Rewrite: “When a user submits a search query of up to 200 characters, the system shall return the first page of results within 2 seconds for 95% of requests under a load of 500 concurrent users.” Reasoning: add trigger, input constraint, metric, percentile, and load condition. The statement becomes testable and negotiable.
Traps
- Treating a design decision as a requirement, such as mandating a specific database product.
- Writing non-functional requirements without a measurement method.
- Confusing user stories with acceptance criteria and omitting negative paths.
- Assuming traceability is optional; it supports impact analysis and verification.
Exam focus
Practice rewriting weak statements, classifying requirements, and spotting missing acceptance criteria.