Why this matters
Functional requirements describe what a system must do. As a Business Analyst, you turn stakeholder intent into clear, testable behaviors so engineers build the right thing the first time.
- Translate goals into user stories, use cases, and acceptance criteria.
- Prevent rework by making behavior unambiguous and testable.
- Align business rules, data, and workflows across teams.
- Enable QA to verify the solution and stakeholders to sign off with confidence.
Real tasks you’ll face
- Define acceptance criteria for checkout rules (e.g., free shipping thresholds).
- Describe data entry validations for onboarding forms.
- Capture workflow steps for approvals and error handling.
- Document integration triggers and expected payloads.
Concept explained simply
Think of a functional requirement as a contract for behavior. If someone performs an action or a condition is true, the system responds predictably.
What counts as functional requirements
- User capabilities (create, read, update, delete).
- Business rules and calculations (discounts, eligibility).
- Workflow transitions (submit, approve, reject, escalate).
- Integrations and events (send to CRM when X occurs).
- Notifications and conditional messages.
- Permissions-based behavior (what a role can do).
Mental model: Recipe cards. Each card says: ingredients (inputs), steps (triggers/actions), and the dish (output). If you follow the card, you always get the same dish.
Quality checklist for a good functional requirement
- Atomic: expresses a single behavior.
- Unambiguous: one clear meaning.
- Testable: measurable acceptance criteria.
- Feasible: can be built and verified.
- Consistent: doesn’t conflict with other rules.
- Traceable: linked to a business need.
- Prioritized: value and risk are considered.
Scope boundaries (quick self-check)
- In scope: what the system does (behavior, data transformations).
- Out of scope here: performance, security levels, UX look-and-feel (these are non-functional and design aspects).
Ways to express functional requirements
- User stories with acceptance criteria: As a [role], I want [capability], so that [benefit].
Acceptance criteria often in Given-When-Then (GWT) format. - Use cases: Actors, preconditions, main flow, alternate/exception flows, postconditions.
- Business rules: If-then statements; decision tables for complex combinations.
- Data rules: Required fields, formats, allowed values, uniqueness.
Tip: Keep story small and testable
Split by data subset, by path (happy vs. edge), or by rule segment (one discount rule at a time).
Worked examples
Example 1 — Free shipping rule
Poor: "Apply free shipping for big orders."
Improved:
- Rule: If the cart subtotal (before tax) is greater than or equal to 50.00 in the shopper’s currency, the system offers a Free Shipping option.
- Exclusions: Digital-only carts are excluded.
Acceptance tests (GWT)
- Given a cart subtotal of 49.99, when the user goes to shipping, then Free Shipping is not shown.
- Given a cart subtotal of 50.00 with at least one physical item, when the user goes to shipping, then Free Shipping is shown.
- Given a cart of only digital items totaling 120.00, when the user goes to shipping, then Free Shipping is not shown.
Example 2 — Password reset flow
Poor: "Users can reset passwords easily."
Improved use case snippet:
- Actor: Registered user
- Precondition: Email exists and account is active.
- Main flow: User requests reset; system sends one-time link valid for 30 minutes; user sets a new password.
- Exceptions: Invalid email, expired link, rate limit after 5 requests/hour.
Acceptance tests (GWT)
- Given a valid email, when reset is requested, then an email with a 30-minute link is sent.
- Given 5 reset requests within an hour, when another is requested, then the request is blocked and an informative message is shown.
- Given an expired link, when the user visits it, then the system shows error and offers to request a new link.
Example 3 — Report filtering
Poor: "Reports should be filterable by date."
Improved:
- Capability: User can filter the Sales report by a date range where start date is on or before end date.
- Defaults: Pre-fill with last 30 calendar days.
- Validation: Reject ranges over 366 days with an explanatory message.
Acceptance tests (GWT)
- Given start=2024-01-01 and end=2024-01-31, when the user runs the report, then only rows in that range are shown.
- Given start=2024-02-01 and end=2024-01-31, when the user runs the report, then validation error is displayed.
- Given a range longer than 366 days, when run, then an error message is shown and no data is fetched.
A lightweight process to elicit and validate
1. Prepare
Actors, goals, and key scenarios. Bring sample data and known rules.
Actors, goals, and key scenarios. Bring sample data and known rules.
2. Facilitate discovery
Walk through scenarios, draw simple flows, and capture decisions. Ask: "What should happen if X?"
Walk through scenarios, draw simple flows, and capture decisions. Ask: "What should happen if X?"
3. Capture drafts
Write stories/use cases and sketch acceptance criteria live. Keep them atomic.
Write stories/use cases and sketch acceptance criteria live. Keep them atomic.
4. Make it testable
Convert to Given-When-Then or decision tables. Add negative paths.
Convert to Given-When-Then or decision tables. Add negative paths.
5. Quality check
Run the checklist below; fix ambiguity and split oversized items.
Run the checklist below; fix ambiguity and split oversized items.
6. Validate
Review with stakeholders and QA; walk through examples and edge cases.
Review with stakeholders and QA; walk through examples and edge cases.
7. Baseline
Prioritize, version, and note dependencies for change control.
Prioritize, version, and note dependencies for change control.
Quick quality checklist
- One behavior per requirement.
- Inputs, triggers, and outputs are explicit.
- Edge cases and exceptions exist.
- Acceptance criteria are objective and verifiable.
- Consistent with related rules and data definitions.
Common mistakes and self-checks
- Mixing non-functional items like "fast" or "modern UI" into functional rules. Self-check: If you remove the UI, does the behavior still hold?
- Vague verbs: avoid "should" or "can". Use "system displays", "system calculates", "system rejects".
- Designing screens instead of behavior. Focus on triggers, inputs, outputs, and rules.
- Missing negative/exception paths. Always ask "What if the input is invalid, missing, or duplicated?"
- Overstuffed requirements. Split by path, data subset, or rule fragment.
- No acceptance criteria. Add GWT or decision tables for every behavior.
Self-review mini checklist
- Is it unambiguous and testable?
- Do we have at least one negative test?
- Can QA verify it without guessing?
- Is the business rule source known?
Exercises
Everyone can do the exercises and the quick test. If you sign in, your progress will be saved.
Exercise 1 — Rewrite vague requirements into testable ones
You are documenting a meal delivery app. Rewrite the following into precise, testable functional requirements with acceptance criteria:
- "Offer free delivery for loyal customers."
- "Users can schedule deliveries easily."
- "Block suspicious orders."
What to include
- Each requirement should be atomic and unambiguous.
- Include 2–3 Given-When-Then tests per requirement, covering at least one negative case.
- State any constraints (thresholds, time windows, limits).
Exercise 2 — Use case with alternate paths
Create a brief use case for "Customer returns an item" for an e-commerce system:
- Actor(s), preconditions, main success flow.
- At least two alternate/exception flows (e.g., past return window, damaged item).
- 3–5 acceptance tests in GWT.
Exercise submission checklist
- Behavior, not design, is described.
- Inputs, triggers, outputs are explicit.
- Negative paths included.
- Acceptance criteria are objective.
Practical projects
- Micro-inventory: Define functional requirements for adding/removing stock, reorder thresholds, and backorder rules. Include decision tables for thresholds.
- Event registration: Specify rules for capacity, waitlisting, cancellations, and notifications. Provide GWT tests.
- Simple CRM integration: Document triggers to send new leads to a CRM and expected field mappings; include retry/duplicate handling.
Who this is for, prerequisites, and learning path
Who this is for
- Aspiring and junior Business Analysts.
- Cross-functional team members who write or review requirements (QA, PM, dev leads).
Prerequisites
- Basic understanding of stakeholders, goals, and scope.
- Familiarity with user stories or use cases is helpful but not required.
Learning path
- Start: Functional vs. non-functional requirements and quality criteria.
- Next: Writing acceptance criteria (GWT) and decision tables.
- Then: Use cases with alternate/exception flows.
- Practice: Apply to your domain; run stakeholder reviews.
Next steps
- Apply the checklist to one of your current tasks this week.
- Pair with QA to craft tests for a tricky rule.
- Create a decision table for a complex eligibility rule and validate it with a stakeholder.
Mini challenge
Write one atomic, testable requirement for: "Send an alert when inventory for a SKU falls below the reorder point" and add two GWT tests (one for below threshold, one for above). Keep it unambiguous and measurable.