Requirements

Atomic, testable requirement records with type, MoSCoW priority, and permanent references — authored once per project and linked into the DRPs that use them. One of several modules whose content shapes a DRP's requirements.

AI in this module

How AI suggestions work

Click "Get AI Suggestions" to have the AI draft or improve this narrative summary in one pass. It reads the requirements linked to this DRP and describes the set — its themes, coverage and priorities — quoting their real IDs where useful, as well as drawing on the rest of the DRP and any AI Knowledgebase documents. It will not invent a requirement, and will not copy the list out as a table, since the live table already sits above the summary.

"Get AI Suggestions" only ever drafts the summary — it never adds, changes or removes a requirement record. "Check Quality", beside it, checks the summary together with the set linked to this DRP, on plans that include quality checks. See the AI Guardrails & Quality Checks guide topic.

Quality checks

What "Check Quality" looks for here

Real summarization value. Flags a narrative that just restates module names instead of genuinely summarising this project's requirements.

Clear, unambiguous language. Flags generic filler that could describe any project's requirements.

What it captures

A short narrative summary of the DRP's requirements, plus the set of real requirement records this DRP uses. Requirements are added and linked from this page; the module is signed off as a whole, covering the narrative and the linked set together.

Using this module

This page has two parts, signed off together. "Linked Requirements" at the top is the real content — the requirement records this DRP uses, listed with their ID, the requirement itself (its title with the description beneath), type, priority and a Draft, Complete or Approved status. The free-text field below it is a summary of those requirements at a level a non-technical reader can follow: the themes, the overall shape, what's in and out.

The table is for reading. Two buttons above it do the work:

  1. 1Click "+ Add requirement" to write a new one in a "New requirement" window: a title, a description, a type, a priority and any tags, then "Add and link". For example, a title of "Search results return in under two seconds", typed as Non-Functional and prioritised Must Have. It is saved to the project and linked to this DRP in one step.
  2. 2Click "Manage requirements" to see every requirement in the project in full. From there, "Link to this DRP" reuses one already written for another DRP — requirements belong to the project, so it never needs retyping — and "Unlink from this DRP", "Edit" and "Delete" act on the ones you have.

A requirement can only be edited while no DRP uses it — the record is shared, so editing one that is linked would change it underneath every pack that uses it. Try it and Requio names the DRPs it is linked to, so you can unlink it there first.

Unlink and Delete stop and explain themselves rather than quietly taking content with them. Unlinking is refused while the requirement still has user stories in this DRP, and names them — "Unlink and delete those stories" then removes the link and those stories together. Deleting is refused for a requirement linked to any DRP at all: the refusal names every DRP it is linked to and every user story that would be destroyed with it, and offers "Unlink everywhere and delete" as one deliberate action. A requirement used by a DRP whose Requirements section is in review, awaiting approval, approved or complete cannot be deleted at all, with no override — reopen that module and unlink it there first. The same goes for linking and unlinking: once this section has been submitted, its set of requirements is fixed until it is reopened.

A requirement starts life with a temporary reference (REQ-TMP-001) and earns its permanent one (REQ-001) the first time a DRP that uses it finishes this module — approved, or marked complete where no sign-off is needed. Its status then reads Approved if an approver signed this module off, or Complete if it was marked complete instead — an override finish included. That permanent reference is never revoked afterwards, whatever happens to the DRP — once a reference has been given it may already be quoted elsewhere.

User stories and acceptance criteria are not part of a requirement. They live in the User Stories & Acceptance Criteria module, per DRP — so one requirement can be decomposed differently in each DRP that uses it.

Review and approval

Reviewed as a whole, like every other module — the narrative summary and the linked set of requirements together, in one sign-off. A Lead Analyst or Analyst assigns this module's reviewers and approver and steps it through Submit for review → Mark review complete → Approve. Individual requirements are not reviewed one at a time.

Once this module has been submitted, "+ Add requirement" and "Manage requirements" disappear, exactly as the rest of a module's editing does: reviewers and the approver see the same table read-only, because they are signing the set off rather than changing it. To change the set, press "Reopen to edit", which cancels the round and returns the module to In progress.

Reviewers and the approver only see this DRP's linked requirements once the module has actually reached them: a reviewer at In Review, the approver once reviewers have signed off. Neither can reach the project's wider requirements library.

Tips

  • See the Requirements guide topic for the full authoring and review workflow.
  • Write or refresh this narrative once requirements are mostly settled — it reads better as a summary of something real than a draft of something that might still change.