Requirements

A requirement is written on a DRP's Requirements module, but it belongs to the project rather than to that one DRP. Linking it into a DRP simply says "this DRP uses this requirement" — the link itself carries no review state. Sign-off happens once, on that DRP's Requirements module, covering its narrative summary and its whole linked set together, exactly like every other module.

There is one shared record, so a requirement reads the same in every DRP that uses it. To stop its wording changing underneath a pack that may already be in review or signed off, a requirement can only be edited while no DRP uses it. Try to edit one that is linked and Requio says which DRPs use it — for example "This requirement is linked to 2 DRPs (Payments Phase 1, Payments Phase 2), so it cannot be edited. Unlink it there first if the wording needs to change."

Every requirement shows one of three statuses:

• Draft — it still has a temporary reference, such as REQ-TMP-004.
• Complete — it has its permanent reference, because a DRP using it finished its Requirements section, but no approver has signed it off. On a project with review switched off, which is the default, finished requirements read Complete.
• Approved — an approver signed off a Requirements section that uses it. It stays Approved if that section is later reopened, because a requirement's wording cannot change while a DRP uses it. Editing it, which is only possible once it is unlinked everywhere, takes it back to Complete.

A Requirements section finished with Mark Complete as an override, shown as "Approved (override)", leaves its requirements Complete: nobody approved them. See "Temporary and permanent references" below for how the permanent reference is given.

Because requirements belong to the project, a requirement captured while working on one DRP can be used by any other DRP in the same project. There is no need to write it again.

1. 1Open the DRP that needs the requirement and go to Modules, then Requirements.
2. 2Click "Manage requirements". A window titled "Requirements in this project" lists every requirement in the project in full, including ones first written while working on another DRP. The ones this DRP already uses are marked "In this DRP", and a search box finds one by title, description, ID or tag.
3. 3Click "Link to this DRP" on the one you want. It appears in the Linked Requirements table straight away.

The linked requirement is the same record in both DRPs, not a copy, which is why it can no longer be edited once it is in use: a change would rewrite it in both packs at once.

A requirement starts life with a temporary reference — REQ-TMP-001 — and earns a permanent one (REQ-001) the first time a DRP that uses it finishes its Requirements module: either approved by its approver or, where that module needs no sign-off, marked complete. Numbering runs per project, and the prefix is configurable per workspace.

When a requirement gets its permanent reference, Requio updates everywhere in that DRP that quoted the temporary one — table columns such as Test Cases' Linked Requirement ID, references written into ordinary sentences in any section ("see REQ-TMP-001" becomes "see REQ-001"), and user story references such as REQ-TMP-001-UA-1, which becomes REQ-001-UA-1. Only whole references are changed, so nothing else you wrote is touched.

A well-formed requirement is atomic (covers one thing), clear (no vague terms), complete, and testable. A requirement is just its title, description, type, MoSCoW priority, and tags — nothing else is required to create one. The type is one of five:

• Business — a goal, objective or outcome for the organisation as a whole. For example, "Reduce claim handling time by 30% within a year".
• Stakeholder — what a particular stakeholder or group needs, which links business requirements to the solution. For example, "Claims handlers need to see a member's full claim history on one screen".
• Functional — a capability or behaviour the solution must have. For example, "The system records a decision and its reason against each claim".
• Non-Functional — a quality or condition the solution must meet, rather than something it does. For example, "Search results return in under two seconds".
• Transition — something needed only to move from the current state to the future state, and not needed once that is done. For example, "Migrate the last five years of claims from the old system before go-live".

Business rules and constraints are not requirement types; they have their own homes in Requio: business rules in Reference Data's Business Rules category, and constraints in the Constraints section.

On a DRP's Requirements module, "+ Add requirement" opens a "New requirement" window with those five fields. "Add and link" saves the requirement to the project and links it to the DRP you are working in. To change one that no DRP uses yet, open "Manage requirements" and press "Edit" on it; "Save changes" keeps the change. Nothing is saved until you press the button, and Cancel leaves the requirement exactly as it was — if you have typed something, it asks before throwing it away.

The same window has "Get AI Suggestions", which proposes a clearer title and description for you to apply or ignore, and "Check Quality", which checks the wording before you save.

Two different things, side by side on each requirement in the "Manage requirements" window. "Unlink from this DRP" takes the requirement out of this DRP and leaves it in the project, ready to be used somewhere else. "Delete" removes it from the project entirely.

Neither quietly takes anything else with it. Where something would be lost, Requio stops, says exactly what is in the way, and offers the destructive version as a separate, clearly worded choice:

• Unlinking is refused while the requirement still has user stories in this DRP, and the refusal names them — for example UA-4 and UA-7. "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 has been sent for review, is waiting for approval, or is approved or complete cannot be deleted at all, and there is no way to override that — the set being signed off must not change underneath the people signing it. Requio names each of those DRPs and its state, for example "Payments Phase 1 (being reviewed)". To take it out, open that DRP's Requirements module, press "Reopen to edit" (which clears its sign-off in the open), and unlink it there first.

User stories and acceptance criteria are not part of a requirement. They belong to the User Stories & Acceptance Criteria module, per DRP — so one requirement can be decomposed into several stories, and decomposed differently in each DRP that uses it. See that module's guide page for how to write them.

Projects, then Requirements, lists every requirement in the project in one place — whichever DRPs they are linked to, and which those are — with a search box for finding one by title or ID. It is a place to read across the whole project rather than to work in: apart from starting a brand new requirement, the adding, linking, editing and removing all happen on each DRP's Requirements module.

It is also where requirements leave Requio. "Export" offers a plain Spreadsheet, or a file shaped for a Jira or an Azure DevOps import — the two import files carry the acceptance criteria from the User Stories & Acceptance Criteria module along with each requirement.