DRPs
A Digital Requirements Pack (DRP) is Requio's modern take on the traditional Business Requirements Document — the single, governed document a project runs on.
What a DRP is
A DRP brings business context, scope, stakeholders, processes, and requirements into one place, built up module by module, reviewed and approved through a clear workflow, and versioned so nothing gets lost.
Every plan except Enterprise limits how many active DRPs a workspace can have at once, counted across all of its projects — see the pricing page for the current limits. The "Create DRP" button shows a lock icon and is disabled once you hit the limit, with a tooltip prompting you to upgrade — the same pattern as the project limit on the Projects guide page.
Working inside a DRP
Each DRP has its own workspace with up to four tabs. Modules and Review Assignments only appear for people who can edit this DRP, so a Reviewer or Approver opens it on Versions:
- Modules — the DRP's content, organised into structured sections (see the DRP Module Reference for what each one covers). Opening the Requirements module shows the requirements linked to this DRP, and is where they are added, linked, edited, unlinked and deleted. Requirements have no sign-off of their own: they are approved together, when this DRP's Requirements module is approved.
- Versions — the full version history, each with its own status (Draft, In Review, Awaiting Approval, Approved, Approved (Void), or Void).
- AI KB — the DRP's own AI Knowledgebase: reference documents that layer on top of the project's knowledgebase to give AI suggestions extra context.
- Review Assignments — who reviews and approves this DRP's modules and its generated versions, inherited from the project unless changed here.
Saving your work
On a module's page, nothing you type is saved until you press "Save Module". While there is something unsaved, "● Unsaved changes" shows under the title; once saved, it says when. Leaving the page with unsaved work asks you first, so a stray click on "Back to DRP" cannot lose it.
If you would rather not think about it, tick "Autosave" beside the Save Module button. What you type then saves on its own a moment after you stop. It is off by default, applies to that one module of that one DRP, and is remembered on the computer you switched it on from — so switching it on for Solution Scope on your laptop does not switch it on for the RAID Log, for Solution Scope in another DRP, or on another computer.
The review level, reviewers and approver in a module's Module Review panel never save with the content, autosave or not. They have their own "Save review settings" button.
A few other tools sit at the top of the module page:
- "Export CSV" — on any module with a table (RAID Log, Stakeholders & RACI, Test Cases and so on), downloads that table as a spreadsheet file.
- "Refresh from latest docs" — appears when a document has been added to the Knowledgebase since you last asked for AI suggestions, and asks again so the suggestions take it into account.
- "Sources used" — under an AI suggestion, lists the Knowledgebase documents the AI drew on, so you can check where a statement came from. If the Knowledgebase could not be searched, it says so plainly rather than leaving the list empty.
Module access and your plan
Some DRP modules are only available on certain plans. If your plan changes and a module is no longer included, that module becomes locked: its existing content and progress are preserved exactly as they were, but it can't be edited until the module is available again on your plan. A locked module that was already marked complete still counts toward generating new versions of the DRP — locking only pauses further work on that specific module, it doesn't undo what's already been done.
Versioning and approval
A DRP's modules are written, and signed off where they need it, first. Once every required module is finished, the DRP is generated as a version, which starts in Draft. Submitting that version for review moves it to In Review; once every reviewer has finished it moves to Awaiting Approval, and once the approver named on the DRP signs it off it is marked Approved. With no reviewers on the DRP, the button reads Submit for approval and the version goes straight to Awaiting Approval. A version can be shared while it is Draft, In Review, Awaiting Approval or Approved; a voided version cannot.
Submit for review, and Reset, are only offered on the newest version. An older version is history — to change what is being signed off, generate a new one.
Older versions are never deleted, so your history stays intact:
- Generating a new version automatically voids any earlier version still sitting in Draft, In Review or Awaiting Approval — they've been superseded before anyone finished reviewing them.
- Approving a version automatically supersedes every other version of that DRP: a previously Approved version becomes Approved (Void) rather than plain Void, so its history as a once-current version stays visible; any other Draft, In Review or Awaiting Approval version becomes Void, since it's no longer relevant once a different version has been signed off.
- If the newest version is Approved or Void and needs reworking, Reset puts it back to Draft. Resetting deactivates any share link tied to that version, since the content is no longer the shared, reviewed version reviewers were looking at. A version that is still in review or with its approver cannot be reset.
Module-level review and approval
Beyond the version-level Draft/In Review/Approved status above, each module has a review level that decides whether it is signed off on its own (Module-level), swept into a single review of the whole generated version (DRP-level), or not reviewed at all. Levels and assignments are set once on the project's Modules tab and inherited by every DRP, and can be overridden per DRP from its Review Assignments tab. See the Review & Approval Workflow topic for the full picture.
A DRP version cannot be moved to Approved until every required Module-level module has been approved, Requirements included — a module marked Approved (override) counts. DRP-level and Not required modules are covered by the version's own review instead.
The Review & Approval module shows a live, read-only summary of every module's reviewer, approver, and status — it updates automatically as assignments and sign-offs happen. The only thing you write there is any commentary you want published alongside it.
A module cannot be edited once it has been submitted — In review, Awaiting approval, Approved and Complete are all read-only. To change it, press "Reopen to edit": that cancels the round, clears every sign-off given so far, and returns the module to In progress so the next round is judged on the new content. The Requirements module works the same way, since its requirements are signed off as part of it.
See the Review & Approval Workflow guide topic for the full picture, including exactly what gates a version's approval.
Generating the document
Once every required module is finished, a DRP can be generated as a fully formatted .docx with your organisation's branding, correct module ordering, a traceability matrix, and a full audit trail — a single click replaces what used to be manual formatting work.
Each version on the Versions tab can be downloaded as a .docx ("Download DOCX") or saved as a PDF ("Save as PDF (Print)", which opens it ready for your browser's print-to-PDF). If a pack was finished outside Requio, "Upload custom version" adds a .docx or .pdf you already have as a version of its own, marked "Custom upload".
On the Free plan, every generated document carries a small "Created by Requio" footer. Paid plans have no footer.
Previewing and reading a version
Once every required module is finished, "Preview latest version" appears at the top of the DRP, beside the button that generates it. It opens a window showing the pack as it stands right now, laid out with your project's logo and colours — a last look at how it reads before you generate. Nothing is saved or sent by opening it.
Once a version exists, "Review" beside it on the Versions tab opens that version as a full page of its own. It has three tabs — Overview, Sections and Comments — and shows the revision history and the sign-off table as they will appear in the document. From there you can:
- Leave a comment on a particular section ("Post comment"), or a general one on the whole version ("Add General Comment").
- Delete a comment you wrote — you are asked to confirm first. A Lead Analyst on the project can also delete other people's comments while the version is still Draft, In Review or Awaiting Approval, for example to remove a duplicate; that is recorded in the Audit Log with what the comment said. Once a version is approved or voided, only a comment's author can delete it.
- Download it as a .docx, or print or save it as a PDF.
These comments belong to the version. They are separate from the comment threads at the foot of each module's page, which belong to the module while it is being written.
When a version is out of date
If your project's name, project code or sponsors change after a DRP version has already been generated, that version is flagged as reflecting outdated project details — a reminder to generate a fresh version if you want the document to match your project's current details. This is informational only; an outdated version can still be reviewed, approved, or shared as normal.