Documents Shared With You
Where the final BRD and SRS of your projects appear, how to download or open one, what the status badges mean, and why a draft the team is still working on is not shown to you.
By the end of this page you will know where the documents the team shares with you appear, how to read them, what their statuses mean, and what stays on the team's side until it is final.
What a shared document is
The team generates its documents from the project's own record: the business requirements document (BRD) that says what you need and why, with the scope, the rules and the people, and the software requirements specification (SRS) the team builds and tests against. A document is the team's working draft until the project manager approves it; from that moment it is final and shared with you, exactly as approved. A later copy of the same kind, once approved, supersedes the earlier one, and both stay readable so you can see what changed between them.
Open the page
Documents in the project's sidebar lists every final and superseded document of the project: its title, its reference (BRD #2), the kind, the status, the file format and its size, when it was rendered and when it became final. Narrow the list by kind or status, or search by title. Open a row for the flyout: the title, the opening page the team wrote, what the document reads (the record as it stood, or the baseline it was rendered from), when it was rendered and when it became final.
Download or open it
Download saves the file under the document's title; Open shows it in a browser tab. A PDF reads on any device; an HTML document is the same content as a single page. The row menu offers Download as well. The file is served to you by the application itself and never from a public address, so a link to it works only while you are signed in.
What the statuses mean
| Status | Meaning |
|---|---|
| Final | Approved by the project manager; the current copy of its kind, exactly as the team shared it. |
| Superseded | Replaced by a newer final copy of the same kind, or retired by the team; kept for the record, unchanged. |
A document the team is still writing, one whose render failed, or one with its approvers reads Rendering, Draft, Failed or In review on the team's side and is not shown to you at all. If the team tells you a document is ready and you cannot see it, it has not been approved yet.
The document and the signature are two things
A BRD rendered from the scope baseline is the readable form of what you sign; the signature itself is given on the baseline, from your Approvals, as described under signing off the scope. The document's last page carries a signature table for a printed copy.
What stays with the team
The drafts and the versions behind a document, who rendered it and what Heimdall drafted before the team edited it, the activity on it, and the working copies that print records still in draft. These are hidden in the application's services, not merely on the screen, so an API token minted for your account lists and downloads exactly what you see here.
Related
- Signing off the scope: the baseline a client copy is rendered from.
- Generated documents: the team's side of the same page.
How is this guide?
Last updated on
Signing Off the Scope
What a frozen baseline is, how the sign-off reaches you and what your signature means, what a change request is and how to raise one, and what you read of each afterwards.
Status Reference
Every status badge the application shows, enum by enum: client and project lifecycle statuses, project health, the review of a glossary term or data entity, design reference kinds, Git providers, epic statuses and priorities, work item kinds, statuses, resolutions, priorities, bug severities and criterion kinds, requirement kinds, categories, verification methods and statuses, business rule kinds, use case flows, RAID kinds, areas and statuses, decision kinds and statuses, baseline kinds and statuses, change reasons, change request statuses and impact levels, document statuses, sprint statuses, link kinds, attachment kinds, quality bands and finding severities, import, research, council sitting, council finding and suggestion statuses, suggestion kinds, revision reasons, webhook delivery states and the states of a Heimdall action.