Requirements

The requirements module is where you define what to build. Each requirement can have business rules, concrete examples, and open questions — giving developers (and AI) the context they need.

Creating Requirements

Use the quick-add row at the bottom of the table for rapid entry — just type a title and press Enter. For full editing (description, type, priority, domain), click a requirement to open the edit dialog.

Each requirement has:

• Title — concise and specific (e.g., "Return policy calculates refund within 30 days")
• Type — User Story or EARS (see Concepts)
• Priority — Must, Should, Could, or Won't (MoSCoW)
• Domain — business area (e.g., "Payments", "Shipping")
• Status — Draft, Approved, Blocked, Deprecated, or Delivered

Rules and Examples

This is the heart of Example Mapping. Expand a requirement to manage its rules and examples.

Rules are business rules that constrain the requirement. Add them with a title and optional description. Drag to reorder.

Examples belong to rules. Each example is a concrete scenario — optionally written in Gherkin format — that illustrates how the rule works. Start with the happy path, then add edge cases.

Open Questions

Questions are unknowns that surface during refinement. Each question has a status:

• Open — needs an answer
• Answered — resolved, with the answer recorded
• Dismissed — not relevant or answered elsewhere

Best practice: resolve all Open questions before moving a requirement to Approved.

Prioritization

Priority badges give you a visual overview: Must (red), Should (orange), Could (yellow), Won't (gray). Use the faceted filters to show only Must items when planning a release.

Avoid making everything Must — it defeats the purpose. If a release fails without it, it's Must. Everything else is Should or Could.

Lifecycle

Requirements move through statuses as they mature:

Draft → Approved → Delivered
  ↓        ↓
Blocked  Deprecated

• Draft — being written, not yet reviewed (default)
• Approved — rules defined, questions resolved, ready for planning
• Blocked — can't proceed (dependency or unresolved question)
• Deprecated — no longer relevant (preserved for history)
• Delivered — implemented and verified

Use the Draft → Approved transition as a quality gate: require rules, examples, and resolved questions before approving.