Software Requirements Specification
What the SRS a project generates prints, section by section, where each section is read from, how the introduction is drafted, and how the team builds and tests against the final copy.
By the end of this page you will know what the software requirements specification prints, which pages of the project each of its sections reads, how the introduction comes to be, and how a team uses the final copy to build and test.
The software requirements specification (SRS) is the team's document: every requirement the system shall honour, the rules behind them, the use cases step by step, the data the system keeps and where each requirement is built, from the pages the business analyst keeps. It is generated from the Documents page with the kind Software Requirements Specification, numbered SRS #1, SRS #2 and so on within the project, and rendered as a PDF on A4 pages or as an HTML page an agent or a wiki can read.
Who reads it
The developers and the testers, before and during the build; the architect who shapes the
components; a coding agent that was handed the project through the MCP server, which reads the
same record through the planning and build tools and can read the SRS itself as plain words
through get_document; and the client's technical lead, once it is final, under
Documents. The sponsor's document is the BRD; an SRS prints no sign-off page.
The cover
Every generated document opens with a cover: the title, the kind, the project's name and key, the client, the document's reference and its version once it is final, when it was rendered and by whom, and the scope it was rendered from (a baseline's name and freeze date, or the record as it stands, with a note when drafts were included). A footer on every page carries the project, the reference and the page number.
Section by section
| Section | What it prints | Read from |
|---|---|---|
| 1. Introduction | The opening page, as written on the document or drafted by Heimdall; Not written yet. when empty. 1.1 The project adds the project's description. | The document's own opening page, Project settings |
| 2. Overall description | 2.1 Components: each component with its kind, description and stack. 2.2 Environments: each with its kind, address and branch. 2.3 Users: each persona with its role and goals. | Components, Environments, Personas |
| 3. Functional requirements | Each functional requirement as a block: key, title, priority and status, the statement, the rationale and how it is verified. | Functional requirements |
| 4. Non-functional requirements | A table of the non-functional requirements: key and title with the statement, the category, the measure and the priority, ordered by category. | Non-functional requirements |
| 5. Business rules | A table of the rules: key and name with the statement, the when and the then. | Business rules |
| 6. Use cases | Each use case with its key, title, actor, goal and trigger, the preconditions, a table of its steps (the flow, what the actor does, how the system responds) and the postconditions. | Use cases |
| 7. Data dictionary | Each entity with its description and a personal-data tag where set, and a table of its fields: name, type, whether required, description, with a tag on each field that holds personal data. | Data dictionary |
| 8. Glossary | Every term with its definition, in alphabetical order. | Glossary |
| 9. Where each epic is built | A table of the epics in scope with the keys of their stories and the epic's status, so a reader walks from a requirement to the backlog items that implement it. | Epics, Backlog |
| 10. Decisions and risks | Each decision with its key, kind and what was decided, then a table of the RAID items with their kind and status. | Decisions, RAID log |
A section with nothing to print says so in one line (No functional requirements recorded., No data entities recorded.) rather than disappearing. A module the person who rendered the document may not open is left out entirely: a guest token cannot render, and a developer whose role does not open the RAID log gets an SRS without section 10's risks.
What is in scope, and what is not
Requirements, rules, use cases and epics print only once they carry a version, the approved ones, unless Include records still in draft is on; components, environments, personas, the glossary and the data dictionary print as they stand, since they carry no approval. A document rendered from a frozen baseline prints exactly the requirements, rules, use cases and epics the baseline holds; the dictionary, the components and the environments print as they stand on the day, which the cover makes plain by naming the baseline.
Keep the SRS and the record in step
The SRS is a snapshot. When a requirement is approved or a rule changes after the render, press Render Again on a draft, or generate a new SRS once the earlier one is final; its approval supersedes the earlier copy, and the version a developer built against stays readable under it.
The introduction
Heimdall drafts the introduction when the field is empty and the project's AI assists are on, from an outline of what the sections above will print: it names the client and what they need, what the project builds and for whom, what the document covers and how it is organised, and ends on what the reader is asked to do, which for an SRS is to build and test against it. It rests on the record alone and names no technology the outline does not carry. The draft is kept on the document for you to edit, and an introduction you wrote is never touched; see how the opening page is drafted.
Build and test against it
- Approve the requirements, rules and use cases the release needs through their own approval, and the epics and stories that implement them.
- On Documents, press Generate → Software Requirements Specification; choose HTML when a coding agent or a wiki will read it, PDF for the client's technical lead. Pick the frozen baseline when the build is scoped to one.
- Read the draft, edit the introduction, and Save & Render Again until it reads right.
- Submit for review; the project manager's approval makes it final and supersedes the earlier SRS on the project.
- Point the team at it: a developer reads it from Documents, and an agent reads it with
get_documentandwith_textset, or walks the same record story by story withget_work_item.
Related
- Generated documents: generating, editing, rendering again, approving, superseding and deleting.
- Business requirements document: the client's half of the record.
- Traceability: the links from a requirement to the stories that implement it and the tests that verify it, which section 9 summarises.
How is this guide?
Last updated on
Business Requirements Document
What the BRD a project generates prints, section by section, where each section is read from, what the executive summary and the sign-off page ask of the client, and how to render the copy the sponsor signs.
Heimdall
The operator inside Zuse Bifrost: ask it about your projects, teams, webhooks and history in plain words, have it do the routine work, and confirm anything that changes what already exists. Beside every page, metered against the team's monthly AI budget.