Requirements

Requirements in Release Cadence capture what your product must do before you start designing or building. They sit between customer feedback and your design documents — turning survey insights into structured, reviewable specifications that your whole team can align on.

Types of Requirements

Release Cadence supports two levels of requirements:

  • Project requirements — Global requirements that apply across the entire project. Use these for non-negotiables like tech stack constraints, performance targets, security standards, and accessibility compliance. They are organized into sections: General, Tech Stack, Performance, Security & Compliance, Accessibility, and Other.
  • Feature requirements — Requirements specific to a single feature. These describe what that feature must do, how it should behave, and what constitutes done. They are created from inside a feature's detail page.

Tip: Project requirements are automatically included in every checkpoint and design document. You don't need to repeat global constraints on every feature requirement.

Requirement Fields

Priority (MoSCoW)

Every requirement has a MoSCoW priority that tells the team how critical it is:

  • Must — Non-negotiable. The feature cannot ship without this.
  • Should — Important, but there is a workaround if it cannot be delivered in this cycle.
  • Could — Desirable but not necessary. Include only if time allows.
  • Won't — Explicitly out of scope for this release. Documents the decision so it doesn't resurface as a surprise.

Type

The type categorizes what kind of constraint the requirement describes:

  • Functional — Describes behavior the system must exhibit ("The user can filter results by date").
  • Non-Functional — Describes quality attributes like performance, reliability, or scalability ("The page must load in under 2 seconds").
  • Constraint — An external limitation the solution must operate within ("Must run on the existing AWS infrastructure").
  • Assumption — A premise the team is taking as true, which should be validated ("We assume users have a modern browser").

Status

Requirements move through three statuses:

  • Draft — Still being refined. Not yet ready to be locked into a checkpoint.
  • Ready for Checkpoint — Reviewed and agreed upon. Will be included in the next checkpoint.
  • Committed — Locked into a checkpoint. The requirement is now part of the immutable record for that design cycle.

Acceptance Criteria

Each requirement can have one or more acceptance criteria written in BDD-style (Behavior-Driven Development) format. Acceptance criteria are the concrete, testable conditions that prove the requirement has been met.

The format is Given / When / Then:

  • Given — The starting state or precondition.
  • When — The action the user or system takes.
  • Then — The expected outcome.

Example:

Given a logged-in user on the features page

When they click "Add Feature" and enter a feature name

Then the new feature appears in the project roadmap

You can also add edge cases to each criterion — for example, what happens when there are no responses, or when the export file would exceed a size limit.

Creating a Requirement

Feature requirement

  1. Open a feature from your project roadmap.
  2. Navigate to the Requirements tab on the feature detail page.
  3. Click Add Requirement.
  4. Enter a title and description.
  5. Set the priority (MoSCoW) and type.
  6. Optionally add acceptance criteria using the Given/When/Then fields.
  7. Save the requirement. It starts in Draft status.

Project requirement

  1. Go to your project's Settings.
  2. Select Project Requirements.
  3. Click Add Requirement in the relevant section (e.g., Performance, Security).
  4. Fill in the fields and save.

Marking a Requirement Ready

When a requirement has been reviewed and agreed on, change its status to Ready for Checkpoint. Only requirements in this status are included when you create a checkpoint.

You can update the status from the requirement's detail view or from the requirements list using the inline status dropdown.

Best Practices

  • One idea per requirement. Avoid combining multiple behaviors in a single requirement — it makes acceptance criteria harder to write and testing harder to verify.
  • Write from the user's perspective. Functional requirements should describe what the user or system can do, not how the code should be structured.
  • Use Won't deliberately. Explicitly marking something as Won't is more useful than leaving it unaddressed. It shows the team has considered and deferred it.
  • Link survey evidence. Requirements that trace back to customer feedback are easier to defend in planning sessions and less likely to be deprioritized.
  • Review before checkpointing. Treat the "Ready for Checkpoint" status as a team gate — not a solo decision. A brief async review catches ambiguities early.
← Back to Documentation Next: Checkpoints →