Requirements are the foundation of every successful project. Yet so many Business Analysts write requirements that confuse developers. The irony? Most mistakes are easy to fix.
Mistake #1: Being Vague
Wrong: “The system should be fast.” Right: “Search results display within 2 seconds.”
Specific requirements leave no room for interpretation. Developers know exactly what to build.
Mistake #2: Mixing Functional and Non-Functional
Don’t combine: “The login button should be blue and allow users to authenticate.”
Separate them: Functional describes what. Non-functional describes how well.
Mistake #3: Assuming Unstated Context
You understand the business. But developers don’t. Write down: Which discount? When applies? Override allowed? Recalculate shipping?
Always include acceptance criteria. Spell out edge cases, exceptions, and assumptions.
Mistake #4: Writing Solutions, Not Problems
Don’t prescribe: “Add a one-page checkout.” State the problem: “Reduce cart abandonment by clarifying checkout and reducing perceived effort.”
Let design and dev propose approaches.
Mistake #5: Ignoring Constraints
Beautiful requirements that ignore technical reality are fiction. Know your constraints: technology limits, regulations, budget, timeline.
“The integration must work with legacy billing (API v2 only)” beats discovering mid-sprint that your approach is impossible.
Mistake #6: Missing Acceptance Criteria
A requirement without acceptance criteria is just a wish. Use this format:
- Given [context], when [user action], then [expected outcome]
- The system should [behavior] under [conditions]
This forces clarity and gives testers a roadmap.
Mistake #7: Only Happy Path Scenarios
Real systems have unhappy paths: payment failures, timeouts, invalid input, permission errors.
Always include: Error states, edge cases, timeout behavior, fallbacks. What happens when the payment gateway fails?
Mistake #8: No Stakeholder Sign-Off
Get agreement before development starts. Use a template: “Is this what we agreed? Gaps? Sign here.”
This takes 30 minutes and saves weeks of rework.
The Bottom Line
Good requirements are specific, testable, and documented. They explain what and why, not how. They account for constraints and edge cases. They’re signed off before work begins.
Check out our free BA templates library for requirement templates and acceptance criteria checklists.
Take Your BA Skills Further
Join 40,000+ business analysts on the platform built for real career growth — courses, 138 podcast episodes, 200+ templates, and 1-on-1 coaching.
No credit card required · Takes ~2 hours · Free forever