Functional Requirements
The Requirements page of a project: what the system shall do, each requirement with its reference, statement, rationale, source, priority, verification method, status and owner, its review lifecycle and its versions.
By the end of this page you will have written down what a project's system shall do as requirements the client can sign off, know every field a requirement carries and what reads it downstream, and know how a requirement moves from a draft to a baseline, how it is deleted, and where every version of it is kept.
A requirement is one sentence the client and the team agree the system must honour. A
functional requirement says what it does for a person: the system shall let a member reset
their password from the sign-in page by email. It is written in the client's words, in the shall
form, one behaviour per requirement, with where it came from, how important it is and how it will
be shown to be met. Functional requirements number on their own sequence (CRM-FR-12), so a
requirement and a story never share a key, and every save of one is kept as a
version. The qualities the system keeps while it does all
this are non-functional requirements, written on the same
page with a category and a measure.
Before you begin
| You want to | You need |
|---|---|
| Open the Requirements page | requirement:view-any on the project, which every default role carries. A client guest sees the agreed requirements only. |
| Add a requirement | requirement:create. Project managers and business analysts have it by default. |
| Edit or move a requirement | requirement:update. |
| Delete a requirement | requirement:delete. |
| Name an owner | The person to be a member of the team. |
| Name a source stakeholder | The stakeholder to be on the project's stakeholder list. |
The page lives under a project: open the project and choose Requirements in the sidebar, badged with how many requirements you may see.
Read the requirements
The table lists one requirement per row, functional and non-functional together:
| Column | What it shows |
|---|---|
| Reference | The requirement's key, painted in the colour of its kind. |
| Requirement | The title, with the first line of the statement beneath it. Press the title to open the detail flyout. |
| Kind | Functional or non-functional, with the category beside it for a non-functional one. |
| Status | Draft, in review, approved, baselined or deprecated, as a badge. Hidden from a guest. |
| Priority | The MoSCoW letter: M, S, C or W. |
| Owner | The person who answers for the requirement, or Unassigned. |
| Verified By | Test, inspection, analysis or demonstration. |
| Updated | How long ago the record last changed. |
| Row menu | View Requirement, Edit Requirement, Move to, Activity, Delete Requirement. |
Sort by reference, title, kind, status, priority, verification method or updated by pressing a column heading; press it again to flip the direction. The list opens in the project's own order.
Above the table, narrow the list with the search box (words in the reference, the title or the source), the kind, category, status and priority lists. The filters travel in the page address, so a filtered list can be shared; Clear Filters on the empty state drops them all.
Add a requirement
- Press New Requirement.
- Pick the Kind first. It decides the sequence the requirement is numbered from and cannot change later; leave it on functional for a behaviour.
- Type the Title and the Statement: what the requirement is called and, in one testable sentence in the shall form, what the system does. These two are enough; Heimdall will draft the rest from the brief once the brief import lands.
- Write the Rationale, and under Where it came from pick the Stakeholder who asked for it and type the Source: the meeting, document or regulation.
- Pick the Owner, the Priority and how it is Verified By.
- Press Create Requirement.
The requirement takes the next number of its kind (the first functional requirement of CRM is
CRM-FR-1), starts as a draft, appears in the table at once, writes its first version, and
requirement.created goes out to every endpoint subscribed to it.
One behaviour per requirement
A requirement that says two things is tested as two things and argued about as two things. Split the system shall send a receipt and let the member download it into two requirements with their own references, so each can be approved, traced and verified on its own.
Open a requirement
Press a requirement's title, or View Requirement in its row menu, to open the detail flyout: the reference, kind, category, status and priority at the top, then the statement and the rationale, the measure of a non-functional requirement, the stakeholder and the source, the owner, the verification method, the dates, and the Versions section with every save of the requirement. From the flyout:
- Edit opens the editor on this requirement.
- Move to changes the status in one step, offering only the moves the lifecycle allows.
- Restore this version under any earlier version puts it back; see revisions and versions.
- Activity opens the requirement's history: every change, who made it and where it came from.
- Delete opens the confirmation.
A link such as /projects/<id>/requirements?show=<requirement id> opens the page with that
requirement's flyout already open; Heimdall's View buttons use it.
Edit a requirement
- Press Edit Requirement in the row menu, or Edit in the flyout.
- Change what you need. The kind is shown as a badge and cannot change; the owner must be a member of the team and the stakeholder one of the project's.
- Press Save Changes.
The save writes a new version of the requirement and requirement.updated goes out with the
columns that changed, each with its old and new value. An edit that changes nothing writes nothing
and announces nothing. The status does not change from the editor; it moves from the list or the
flyout.
Move a requirement along its lifecycle
A requirement reaches In review and Approved through its approval alone: Submit for review on the approval bar puts it in review, and the approvers' verdicts move it out, to approved when the request carries and back to where it stood when it is rejected or withdrawn. Move to in the row menu or the flyout offers the other moves the lifecycle allows from where the requirement stands, and is refused while a request is open:
| From | To |
|---|---|
| Draft | Deprecated |
| In review | Draft, deprecated |
| Approved | Baselined, deprecated |
| Baselined | Deprecated |
| Deprecated | Draft |
An approval stamps when the requirement was agreed and at which version, and a client guest sees
it from that moment on, through baselined, and loses it when it is deprecated. Every move writes a
version with the reason moved and requirement.status_changed goes out with the status before
and after; an approval writes one with the reason approval.
Baselined is the freeze's badge
A baseline that holds an approved requirement moves it to baselined when the baseline is frozen and locks it: the editor, the status menu and the restore button refuse, naming the baseline, until an approved change request unlocks it, which returns it to approved. The status menu still offers the move to baselined by hand, for a scope agreed outside the application; that badge carries no lock.
Delete a requirement
Delete Requirement in the row menu or Delete in the flyout opens the confirmation.
Deleting removes the requirement with every version it kept and its activity history; its number
is never handed out again. requirement.deleted goes out. Prefer Deprecated for a requirement
the client withdrew: it keeps the record and the reasoning.
All the fields
What happens next
- Every save, move and restore writes a version and an entry in the project's activity history.
requirement.created,requirement.updated,requirement.status_changed,requirement.restoredandrequirement.deletedgo out to the webhook endpoints subscribed to therequirement.*family.- Stories will implement requirements and test cases will verify them through links, the traceability matrix will show which requirement has no story and no test, and the baselines will freeze the agreed set, as those modules land.
Heimdall on this page
Quality in the flyout asks Heimdall to read the requirement for one testable statement, a rationale, a fitting verification method, conflicts with the project's business rules and duplicates among its siblings, and to score it out of 100 with the findings to fix. See Quality review.
Heimdall reads requirements and their versions through the same tools the MCP server offers, drafts requirements as drafts a person reviews, and carries the open project as its context.
On the editor, Ask Heimdall beside each long field drafts it, improves it, shortens it, makes it testable or rewrites it as Given, When, Then; the draft waits under the field until you take it or drop it. See inline assists.
The brief import will draft whole specifications into a review queue, and the quality review will flag a statement that is not testable or that says two things.
From the API and MCP
Requirements API
List, read, add, change, move and delete requirements, and read and restore their versions.
Planning tools
list_requirements, get_requirement and create_requirement_draft: the MCP tools that read and draft requirements.
Permissions
| Action | Permission |
|---|---|
| See the requirements | requirement:view-any, requirement:view; a client guest sees the agreed requirements only |
| Add a requirement | requirement:create |
| Edit or move a requirement | requirement:update |
| Delete a requirement | requirement:delete |
| Read or restore its versions | requirement:view to read, requirement:update to restore; never a client guest |
Frequently asked
Related
- Quality review — the Quality panel in the flyout: Heimdall's score and findings, and the badge on the row
- Traceability — the Links panel in the flyout: what this implements, verifies, depends on or relates to, read from either side
- Comments and mentions — the Discussion panel in the flyout: questions, answers, mentions, followers
- Attachments — the Files panel in the flyout: wireframes, specifications and samples pinned on the record
- Non-functional requirements — the qualities, with a category and a measure
- Epics and the Backlog — the scope and the stories that implement the requirements
- Revisions and versions — every save kept, any version put back
- Status reference — every status, kind, category and verification method
requirement.*webhook events
How is this guide?
Last updated on
Acceptance Criteria
The acceptance criteria rows on a work item: one sentence each with an optional Given, When and Then and a kind, written in the item's editor, ordered, versioned with the item and replaced over the API.
Non-Functional Requirements
The qualities a system shall keep: each non-functional requirement with the category it belongs to and the measure that says when it is met, the categories, how to write a target and what reads them.