BA Specification Writing
BRD vs. FRD, functional requirements, NFRs, measurable criteria, and stakeholder analysis
Business Analyst writing essentials
- BRD: what the business needs — problem, goals, stakeholders, success metrics — not how to build it
- Functional requirement: "The system shall…" + specific actor + action + success path + error handling
- NFR: performance, security, scalability — always measurable: "50K concurrent users, p99 < 500ms"
- Shall/should/may: shall = mandatory; should = recommended; may = optional
- Stakeholder analysis: role + what they own + how they use it + what is out of scope
Question 0 of 5
What is the primary purpose of a Business Requirements Document (BRD) written by a Business Analyst?
What the business needs — problem, goals, stakeholders, metrics — not how to build it. BRD vs. other documents:
- BRD: business need — "The business needs to reduce customer churn by 15% in 12 months"
- FRD (Functional Requirements Document): what the system must do — "The system shall send an automated email 3 days before subscription expiry"
- Technical Spec: how to build it — "Email will be sent by the notification-service using the SendGrid API"
Which functional requirement is written most correctly?
"Shall" + specific actor + specific action + specific outcome + error handling. Functional requirement language:
- "shall" = mandatory requirement (the system MUST do this)
- "should" = recommended but not mandatory
- "may" = optional
- ✅ Specific actor: "registered user"
- ✅ Specific action: "authenticate using email and password"
- ✅ Success path: "redirect to dashboard"
- ✅ Failure path: exact error message specified
- ✅ Security note: not revealing which field failed (prevents enumeration attacks)
What is the difference between a functional requirement and a non-functional requirement (NFR)?
Functional = what the system does; NFR = how well it does it. NFR categories with examples:
- Performance: "The search API shall return results within 300ms at the 95th percentile under 1,000 concurrent users"
- Security: "All passwords shall be hashed using bcrypt with a minimum cost factor of 12"
- Scalability: "The system shall support 10,000 concurrent users with no degradation in response time"
- Availability: "The system shall have 99.9% uptime (maximum 8.7 hours downtime per year)"
- Usability: "A new user shall be able to complete registration without external assistance in under 3 minutes"
A BA writes: "The system should handle a large number of users." How should this be rewritten?
Specific number + metric + threshold. How to write measurable NFRs:
- ❌ Vague: "a large number of users" — what is large? 100? 10,000? 10M?
- ✅ Specific: "50,000 concurrent active sessions" — testable in a load test
- ❌ Vague: "fast" — what is fast?
- ✅ Specific: "under 500ms at the 99th percentile" — p99 latency SLO
Which stakeholder analysis statement is most useful in a BRD?
Role + what they own + how they use the system + what is out of scope. Stakeholder analysis elements:
- Who: "Customer Success team" — a real team, not "users"
- What they own: "retention metrics" — the business metric they're responsible for
- How they use it: "daily to identify at-risk accounts" — frequency and use case
- Impact of requirements: their priorities should shape the feature priorities
- Excluded stakeholders: "Sales team — out of scope" — prevents scope creep from stakeholders who show up mid-project claiming their needs weren't considered