Requirements

A requirement carries three fields beside its title: Priority, Category and Acceptance criteria.

The fields

Field	What it takes
Priority	A free label: trimmed text, 1 to 40 characters. The field suggests the labels already used in the project, with how many requirements use each, and offers Create “text” for a new one.
Category	functional, non-functional, other, or not set.
Acceptance criteria	Markdown text, up to 20,000 characters. The requirement’s page shows it as a list.

The list

The Requirements list has a Priority and a Category column and a filter for each. Both filters also offer Not set.

A read-only member sees the fields that are set, cannot edit them, and sees no hints for empty ones.

Import from Markdown

Import on the Requirements list reads requirements from a .md file. It is not shown to read-only members.

1. File. Choose a .md file, up to 1 MiB.

2. Mapping. Tick the tables that hold requirements — several can be ticked. For each, choose which column is Key, Title or Text, Description, Priority, Category, Type, Status or Acceptance criteria.

   • Acceptance criteria is never filled in automatically.
   • Category values map to functional, non-functional or other.
   • A table’s priority values can be kept as written or renamed.

   A file without tables is read by sections; in a file with both, What holds the requirements switches between Tables and Sections. Content that is not a requirement is listed under Not imported.

3. Preview. Counts of created, updated, unchanged and skipped requirements, and for each row its line number, key and the reason. The preview says Nothing is written yet.

4. Import. Import N requirements on the preview writes them in one go, all or none. Only now is anything written.

• At most 2,000 requirements per import.
• Importing the same file a second time changes nothing.
• If a key was taken in the meantime, the import says that nothing was written and offers Check again.

A table, as an SRS writes it

A row per requirement with a stable id, the document’s own priority words, and parts that are not requirements: the scope and the definitions.

## 1. Scope

- Covers the web checkout
- Leaves out refunds

## 3. Functional requirements

| ID | Requirement | Priority | Category |
|----|-------------|----------|----------|
| REQ-FN-001 | A signed-in customer can pay by card | Critical | Functional |
| REQ-FN-002 | A receipt is emailed after payment | High | Functional |
| REQ-FN-003 | The receipt page opens within 2 seconds | Medium | Non-functional |

## 4. Definitions

| Term | Meaning |
|------|---------|
| Order | The items paid for in one checkout |

On Mapping the requirements table is already ticked and marked looks like requirements; the Definitions table is offered unticked. The columns come from the headers: Key is ID, Title or Text is Requirement · as Text, Priority and Category are their namesakes. Under Priority values, leave Critical becomes empty to keep Critical, or type the label your project uses, such as Must; Functional and Non-functional already become Functional and Non-functional. Check 3 requirements then shows create 3.

Sections, as a PRD writes them

Front matter, ### sections, and the requirements as bullets under one section, grouped by priority sub-headings.

---
title: Payment reminders
status: draft
team: billing
---

### Problem

Customers pay their invoices late.

### Goals

- Fewer overdue invoices

### Requirements

#### Must-have

- REM-1: Email a reminder three days before the due date
- REM-2: Let a customer switch reminders off

#### Should-have

- REM-3: Edit the text of the reminder

#### Nice-to-have

- Show the reminders sent on the invoice

With no table in the file, Mapping shows sections:

• Section: Requirements · 4 bullets · 3 sub-headings. It starts on the first section with bullets or sub-headings, here Goals.
• One requirement per: Bullet. The default, Sub-heading, or bullet when there are none, would make Must-have, Should-have and Nice-to-have the requirements.
• Key prefix: REM-. A bullet that starts with it carries its key; the last bullet has none and gets a generated REQ-<n>.
• Tick Bullets take their sub-heading as priority.

Sections have no priority values to rename: Must-have, Should-have and Nice-to-have are kept as written. To import other labels, name the sub-headings that way in the file.

Content that is not a requirement

What the chosen tables or section leave out is listed under Not imported: the left-out tables, the sections that have bullets, and the front matter’s keys other than title. A section of plain paragraphs, like Problem above, is not listed. Nothing on the list is imported unless you tick it.

A ticked part becomes the description of a requirement of this import: it is added to the end of that requirement’s description, under its own heading. The nearest requirement above it in the file is chosen and marked nearest above in the file; another one can be chosen. In the SRS example, 4. Definitions goes to REQ-FN-003. 1. Scope has no requirement above it, so the dialog says Nothing above it in the file is a requirement — pick one or untick it., and Check stays off until one is picked. The preview’s Changes column names the source: description + 1. Scope (lines 1–5).

• The file itself is never changed.
• A description holds up to 16 KiB; a requirement that would pass it is skipped, with the reason.
• Front matter has no tick: in the PRD example, Not imported says Front matter: status, team, and it stays out.