Defining Business Requirements and the Solution
This domain turns findings into a precise statement of what must be delivered. Candidates must know the requirements hierarchy: business requirements (why, at organisational level), stakeholder requirements (what users need), and solution requirements split into functional (what the system does) and non-functional (how well - performance, security, usability, availability). Understand requirements quality: unambiguous, testable, traceable, complete, consistent, and prioritised (e.g. MoSCoW). Know traceability from business need through requirement to solution component, and the role of the requirements document or backlog. Also grasp business rules (constraints on behaviour) and the difference between a requirement and a solution design decision.
Traps
Questions often present a non-functional requirement dressed as functional ('the system must respond within two seconds' is non-functional). Another trap is accepting a requirement that is untestable ('user-friendly') without a measurable criterion. Beware confusing requirements with design: 'use a dropdown' is a design choice, not a requirement. Also watch for missing prioritisation - not everything can be 'must have'.
Rule of thumb
If you cannot write a test for it, it is not yet a requirement. Rewrite until it is measurable.
Worked example
'Users need fast access to customer records' becomes: 'A user can retrieve a customer record by name or ID in under two seconds for 95% of searches at peak load' - testable, and clearly non-functional in part.