Requirements
Know the four levels
- Business requirements - why: "Cut quote turnaround from five days to one."
- Stakeholder requirements - who needs what.
- Solution/functional requirements - what the system does.
- Non-functional requirements - how well: performance, security, scalability, availability, usability, licensing and data-volume limits.
Also know user stories (INVEST), acceptance criteria (Given/When/Then), MoSCoW prioritization, the traceability matrix, and Definition of Ready/Done.
Traps
- Unmeasurable adjectives: "user-friendly," "flexible," "fast" - these are non-functional and must be quantified.
- Mixing levels: "the org shall use a picklist" is design; "standardize region values across teams" is the requirement.
- Acceptance criteria written as test steps, or missing the negative/failure case.
- Forgetting non-functional concerns - data volume, governor limits, sharing and security, mobile, integrations, licenses.
- Gold-plating: requirements no stakeholder asked for and no objective traces to.
Rule of thumb
If you cannot write a pass/fail test for it, it is not a requirement yet. Every requirement should trace to a business objective; if it does not, challenge it.
Worked example
"Sales reps need to see all opportunities" sharpens to: As a sales rep, I want to see opportunities on accounts my team owns so I can forecast accurately. Acceptance criteria: Given a rep on Team A, when they open the Opportunity list view, then they see only Team A account opportunities, and the page loads in under three seconds at 50,000 records. Note the story, the criteria, and the non-functional clause.