Software Requirements and Analysis
Requirements work is about discovering what a system must do, then expressing it so that everyone - users, developers, testers - reads the same thing. Know the vocabulary: functional requirements (behaviors), non-functional requirements (quality attributes such as performance, security, usability, each ideally measurable), constraints (imposed decisions like mandated platforms), and business rules. Distinguish user requirements (goal statements in user language) from system requirements (detailed, testable specifications). Understand elicitation techniques - interviews, workshops, observation, prototyping, document analysis - and their trade-offs: observation reveals tacit workflow that interviews miss; prototypes surface hidden expectations.
Specification quality matters: unambiguous, complete, consistent, verifiable, traceable, prioritized. Know the difference between verification ("did we build it right?" - conformance to spec) and validation ("did we build the right thing?" - fitness for purpose). Requirements traceability links each requirement forward to design, code, and tests and backward to its source, enabling impact analysis when change arrives.
Traps to watch: questions that conflate a non-functional requirement with a constraint ("must run on Linux" is a constraint, not a performance target); scenarios where a stated solution ("add a dropdown") is offered when the underlying need is the real requirement; and "gold-plating" - adding features no stakeholder requested. Also beware assuming a requirement is testable merely because it is stated; "user-friendly" is not verifiable without a metric.
Rule of thumb: if you cannot write an acceptance test for a requirement, it is not yet a requirement - it is a wish.
Worked example: "The report screen shall be responsive" fails verification. Rewrite as: "The report screen shall render within 2 seconds for 95% of requests at 500 concurrent users." Now it is measurable and testable.