Skip to content
TRACE ALM Documentation

StrictDoc

What it is

Section titled “What it is”

StrictDoc is an open-source requirements-management tool that uses a Git-friendly plain-text format (.sdoc) with strict, project-defined grammars. Every requirement, every test specification, every change record is a structured block in a .sdoc file under version control — the source of truth for the project’s regulated artefacts.

Why we chose it

Section titled “Why we chose it”
  • Plain-text + Git — every change is a regular diff that fits the developer review flow; no vendor lock-in
  • Grammar enforcement — the [GRAMMAR] block at the top of each document defines required fields and allowed values; ill-formed documents fail at parse time, not silently
  • First-class typed relations — derivedFrom, fulfils, verifies, controlsRisk relations are part of the model, which is what makes traceability across requirements / tests / risk controls computable rather than freeform-text
  • MID stability — auto-generated machine identifiers (MIDs) survive renames, so links across documents don’t break when an item gets re-numbered
  • Open-source + actively maintained — no commercial vendor risk; bugs fixable upstream

Alternatives considered: Doorstop (lighter but less expressive grammar), proprietary ALM suites (cost + lock-in), plain Markdown with conventions (no enforcement, regulators can’t trust convention-only). StrictDoc won on the combination of plain-text storage and strict grammar.

Where it lives

Section titled “Where it lives”
  • Configuration: regulatory-docs/strictdoc_config.py (project config)
  • Source documents (three-tier requirements graph):
    • regulatory-docs/10_system.sdoc — system / stakeholder requirements (SYS-) — ISO/IEC/IEEE 29148
    • regulatory-docs/11_srs.sdoc — software requirements (SRS-) — IEC 62304 §5.2
    • regulatory-docs/20_architecture.sdoc — software architecture (ARCH-) — IEC 62304 §5.3
    • regulatory-docs/30_unit_tests.sdoc, regulatory-docs/31_integration_tests.sdoc, regulatory-docs/32_system_tests.sdoc — UT, IT, ST specifications
  • Layout overview: regulatory-docs/00_README.md
  • Authoring rules + workflow: .claude/skills/strictdoc-requirements/SKILL.md — canonical source for terminology and process; this page intentionally does not duplicate it

How to operate it

Section titled “How to operate it”

Install (Python ≥ 3.11, uv):

Terminal window
uv sync

Export to HTML for browsing:

Terminal window
uv run strictdoc export regulatory-docs/ --output-dir regulatory-docs/output

Browse with the interactive web UI:

Terminal window
uv run strictdoc server regulatory-docs/

Then open http://localhost:5111. Do not use the web UI’s edit features — manual edits bypass the regulated change-record process. See the skill file §8 for why.

For more operational notes (version bumps, SOUP register, troubleshooting), see dev-docs/strictdoc.md.

Versioning / update policy

Section titled “Versioning / update policy”
  • Pinned at strictdoc==0.22.0 in pyproject.toml
  • Regulated SOUP — bumps follow the procedure in dev-docs/strictdoc.md and are recorded in the SOUP register
  • The grammar declared at the top of each .sdoc file is the project’s effective contract with StrictDoc; unknown fields are rejected at parse time, so a StrictDoc upgrade that changes grammar semantics surfaces immediately

External documentation

Section titled “External documentation”

The canonical StrictDoc documentation is at https://strictdoc.readthedocs.io. This site does not duplicate StrictDoc’s own documentation; refer there for the full grammar reference, command-line options, and feature documentation.

For the rules specific to how BioFlow uses StrictDoc — type taxonomy, custom fields, review workflow — read the skill file.