Defining Requirements

Defining Requirements

A requirement is a specification of what must be true for a feature to be considered complete and correct. Poor requirements produce features that don't match user needs, don't meet stakeholder expectations, and surprise engineers with edge cases mid-development. Good requirements align everyone on what is being built and why before the first line of code is written.

From Problem to Requirement

The progression: problem statement → solution hypothesis → requirements → acceptance criteria.

Problem statement: "Users abandon the checkout flow at the payment step because they are uncertain whether their card information is secure."

Solution hypothesis: "Displaying security certifications, lock icons, and a brief trust statement near the payment fields will reduce abandonment."

Requirements: "The checkout payment page must display an SSL certificate indicator in the header, a payment security badge adjacent to the card fields, and a one-sentence trust statement below the card number field."

Acceptance criteria: "SSL indicator is visible in the browser address bar. Payment badge displays the provider's logo and reads 'Secured by [Provider]'. Trust statement reads 'Your payment information is encrypted and never stored.' All three elements are present on mobile and desktop. The page loads in under 2 seconds with all trust elements visible."

Product Requirements Documents

PRDs vary in format by company and team, but a complete PRD typically includes:

1. Problem definition — what user problem or business opportunity is being addressed?
2. User context — who specifically has this problem? In what context? With what frequency and severity?
3. Goals — what outcomes should this feature produce? How will we measure success?
4. Non-goals — explicit statement of what is NOT being addressed in this iteration
5. Proposed solution — at a conceptual level (not implementation details)
6. Requirements — what must be true for this feature to be complete
7. Edge cases — unusual but possible scenarios the implementation must handle
8. Non-functional requirements — performance, security, accessibility constraints
9. Dependencies — what else must be true for this to work?
10. Open questions — decisions not yet made, information not yet known

The PRD is a communication tool, not a compliance document. Its purpose is to ensure that everyone building the feature is working toward the same outcome. Length matters less than clarity.

User Stories

User stories express requirements from the user's perspective:

"As a [user type], I want [capability], so that [outcome]."

Examples:

• "As a returning customer, I want my shipping address to be pre-filled, so that I can check out faster."
• "As an admin, I want to export user data as a CSV, so that I can provide reports to our legal team."
• "As a new user, I want to see what the product can do before signing up, so that I can decide if it's right for me."

Good user stories are:

• Independent: can be built and shipped without requiring another story to be complete
• Negotiable: the story describes the goal, not the implementation — the team can discuss how to achieve it
• Valuable: the story delivers value to a user or the business
• Estimable: the team has enough information to estimate the effort
• Small: can be completed in one sprint
• Testable: has specific acceptance criteria

Stories are not task lists. "Build the database schema for user addresses" is a technical task. "As a returning user, I want my shipping address remembered" is a user story.

Writing Acceptance Criteria

Acceptance criteria define "done." They are testable, specific conditions:

Given [precondition], When [action], Then [expected outcome].

Example: "Given a logged-in user with a saved shipping address, When they proceed to checkout, Then their saved address is pre-populated in the shipping form and marked as default."

Good acceptance criteria:

• Are specific enough to be tested manually or automatically
• Cover the happy path AND key edge cases
• Include non-functional conditions ("loads in under 1.5 seconds")
• Are written before implementation begins (forces agreement upfront)

Edge Cases and Non-Functional Requirements

The most expensive bugs are the ones nobody wrote a requirement for.

Common edge cases that requirements miss:

• What happens when the user's internet connection drops mid-process?
• What happens when the user submits the form twice (double-click, slow connection)?
• What happens when the input is empty, or contains special characters, or is 10,000 characters long?
• What happens when the dependent service (payment processor, shipping API) is unavailable?

Non-functional requirements are frequently undocumented because stakeholders assume them. "The page should load fast" is not a requirement. "The page must achieve a First Contentful Paint of under 1.8 seconds on 4G mobile" is.