Software Requirements
What to know
Requirements engineering spans elicitation (interviews, workshops, observation, prototyping), analysis and negotiation, specification, and validation. Distinguish functional requirements (what the system does) from non-functional requirements (quality attributes: performance, security, usability, availability) and from constraints (fixed technology, regulations, budgets). A good requirement is unambiguous, verifiable, consistent, and traceable. User stories capture need in a lightweight form; use cases describe actor-goal interactions; SRS documents (IEEE-style structure) formalize scope, interfaces, and acceptance criteria.
Traps in questions
- Non-functional vs constraint: "must run on the client's existing Oracle database" is a design constraint, not a quality attribute, even though it reads like a technical statement.
- Requirement vs design: wording that names a solution ("the system shall use a red-black tree") is a design decision smuggled into a requirement.
- Traceability direction: forward traceability links requirements to design/code/tests; backward links tests and code to their source requirement. Questions often swap these.
- Prioritization schemes: MoSCoW (Must/Should/Could/Won't) is about scope negotiation, not risk; avoid confusing it with risk-based ordering.
- Ambiguous verbs: "fast", "user-friendly", "robust" are unverifiable unless quantified with a measurable criterion.
Rule of thumb
If you cannot write a test that passes or fails against a stated requirement, it is not yet a requirement. Rewrite "the system shall respond quickly" as "95% of search requests shall return within 2 seconds under a load of 200 concurrent users."
Worked example
A stakeholder says: "The app must be secure and use our SSO provider." Split it: the SSO provider is a constraint (fixed integration); "secure" becomes verifiable NFRs such as "all sessions expire after 15 minutes of inactivity" and "passwords are never stored in plaintext." Each fragment gets an ID for traceability.