Vision Document
Why Heimdall exists, who it serves, its stakeholders, goals, and what success looks like.
Requirements
The specification: vision, system requirements, use cases, technology stack, data protection, testing, workflow, and operations.
These fourteen documents are the specification for Heimdall. Everything else on this site describes what was built; these say what must be true.
They are also the working documents of the project, not a retrospective write-up: a feature is implemented by picking a use case, following its main and alternative flows, and citing the requirement identifiers in the code.
| Document | What it settles |
|---|---|
| Vision Document | Why the system exists, who it serves, and what success looks like. |
| System Requirements Document | The functional (FR-…) and non-functional (NFR-…) requirements, the data model, the endpoints, the authorization matrix, and the deletion strategy. |
| Use Case Specification Document | Every use case (UC-…) with its main flow and numbered alternative flows (AF-11a, AF-11b, …). |
| Technology Stack Document | The technologies, libraries, and pinned versions. The single source of truth for versions. |
| Data Retention Schedule Document | How long each category of personal data is kept and why — the record NFR-19 requires, and the source of truth the retention passes are configured against. |
| Data Protection Document | Who controls what, on what basis, shared with whom, and across which borders — the record LGPD Art. 37 and GDPR Art. 30 require. |
| Data Protection Impact Assessment | The risks this system creates for the people in it, rated for them rather than for the system. |
| Privacy Notice | What Heimdall does with personal data, told to the people it belongs to. Versioned, and the Encarregado’s published contact. |
| Data Processing Agreement | The terms on which Heimdall processes a tenant’s users’ data, and the sub-processor list. |
| Incident Response Document | What counts as a personal data breach, who declares one, the clocks that start, and who has to be told. |
| Testing Specification Document | What to test for each use case, the unit and functional standards, and the required coverage. |
| Development Workflow Document | How a use case goes from backlog to merged — branch, issue status, testing gate, pull request. |
| Operations & Infrastructure Document | The technical foundation and the health-check feature. |
Identifier conventions
| Prefix | Meaning | Example |
|---|---|---|
FR-XX-nn | Functional requirement, grouped by capability | FR-AU-04 — the claims an auth token carries |
NFR-nn | Non-functional requirement | NFR-15 — internal ids never reach a caller |
UC-nn | Use case | UC-11 — Login |
AF-nna | Alternative flow within a use case | AF-11g — the person has active 2FA |
The capability groups are SC (scope), PE (person), RO (role), AU (authentication), PR
(password recovery), EV (email verification), AP (application), GO (Google Sign-In), SP
(scope permission), 2F (two-factor), HC (health check).
Rendered in place, not copied
The pages in this section are the very files under
docs/requirements/
in the
repository, mounted into this site by Hugo. There is no second copy to keep in sync — editing the
Markdown updates both GitHub and this site.
System Requirements Document
Functional and non-functional requirements, the data model, endpoints, authorization matrix, and deletion strategy.
Use Case Specification Document
The actor-facing use cases, each with its main flow and numbered alternative flows.
Technology Stack Document
The technologies, libraries, and pinned versions the project is built on.
Data Protection Impact Assessment
The risks this system creates for the people in it, and what is done about them — GDPR Art. 35, LGPD Art. 38.
Data Retention Schedule Document
How long each category of personal data is kept, why, and which periods the API enforces itself.
Data Protection Document
Who controls what, on what basis, shared with whom, and across which borders — the record LGPD Art. 37 and GDPR Art. 30 require.
Privacy Notice
What Heimdall does with personal data, told to the people it belongs to — LGPD Art. 9, GDPR Art. 13 and 14.
Data Processing Agreement
The terms on which Heimdall processes a tenant’s users’ data — LGPD Art. 39, GDPR Art. 28.
Incident Response Document
What counts as a personal data breach, who declares one, the clocks that start, and who has to be told.
Testing Specification Document
How each use case is tested — the unit and functional standards and the required coverage.
Threat Model Document
What the security controls defend against, organised by trust boundary, and what remains after them.
Development Workflow Document
How a use case goes from backlog to merged: branch, issue status, testing gate, pull request.
Operations & Infrastructure Document
Hosting, the four environments, the technical foundation and the health-check feature.