Skip to main content
< All Topics
Print

Requirements Writing

name: requirements-writing

description: Elicit, document, and validate software requirements — functional specs, user stories, acceptance criteria, and non-functional requirements. Use when starting a new feature or product, reviewing a vague product brief, writing acceptance criteria, or auditing requirements before build begins.

Requirements Writing

Instructions

Transform product ideas into precise, buildable requirements that engineers can act on without ambiguity.

Requirements quality criteria (every requirement must be):

  • Specific: “API response < 2 seconds for 95th percentile" not "the system should be fast"
  • Measurable: includes a testable condition or acceptance criterion
  • Achievable: within the available tech stack and timeline
  • Traceable: linked to a business goal or user need
  • Complete: includes error states, not just the happy path

Functional requirements document structure:


## Functional Requirements
| ID | Requirement | Priority | Notes |
|----|-------------|----------|-------|
| FR-001 | [Specific testable action/behavior] | Must Have / Should Have / Could Have | |

Priority tiers (MoSCoW): Must Have (release blocker), Should Have (high value), Could Have (nice to have), Won’t Have (explicitly out of scope).

Non-functional requirements (always address):

  • Performance: response time thresholds, max concurrent users, storage limits
  • Security: authentication requirements, data sensitivity classification, encryption at rest/in transit
  • Reliability: uptime target, error rate tolerance, recovery time objective
  • Scalability: expected growth, bottleneck points

User story format:

As a [user role], I want [capability] so that [benefit].

Acceptance criteria format (BDD):

Given [context/precondition] When [action/trigger] Then [expected outcome] And [additional outcome if needed]

Elicitation questions (apply to every feature):

  1. Who is the user? (role, technical level, context of use)
  2. What triggers this interaction? (event, data availability, user decision)
  3. What is the desired outcome? (what “done” looks like for the user)
  4. What are the failure modes? (what can go wrong; required behavior for each)
  5. What are the performance constraints? (speed, scale, availability)
  6. What is explicitly out of scope for this version?

Gap and ambiguity log format:

Issue ID Requirement Problem Impact Question to Resolve

Outputs: Requirements specification document (.md), user story set with acceptance criteria, non-functional requirements table, ambiguity/gap log, out-of-scope list.

Table of Contents