Development Plan
This document presents the goals of the StrictDoc project and describes how the project is developed.
1. Project goals
StrictDoc is an open-source tool for writing technical documentation and requirements management. The long-term goal of the project is to provide a capable, open-source platform for creating and managing technical documentation.
Requirements automation
The tool aims to automate the requirements documentation process at various levels.
Target groups
The project targets different user groups including those in software, hardware, systems (systems engineering, electrical, thermal), as well as quality assurance, safety, management, and non-technical areas.
Use on individual computers and cloud
The project is already usable on individual personal computer, the long-term goal is to enable its use on cloud.
Open data
An important feature of StrictDoc is its focus on open data, ensuring ease of data transfer both into and out of the system.
Synergies with other tools
StrictDoc shall be compatible with other software and engineering tools. This includes at least the compatibility with the Python ecosystem, the model-based systems engineering tools, such as Capella, and the formats providing Software Bill of Materials, such as SPDX.
2. Roadmap
All StrictDoc work is tracked on GitHub via the StrictDoc issues and StrictDoc Pull Requests on GitHub.
As an open-source project, StrictDoc is developed without strict deadlines. However, there are certain high-level priorities that influence its development. In particular, features aligned with the core roadmap and those strongly requested by active users are usually given the highest priority. StrictDoc also benefits from contributions by users who want a particular feature and are willing to develop it themselves.
2.1. Project milestones
The work is loosely organized in quarters which are maintained as GitHub milestones, such as 2025-Q1, 2025-Q2, etc.
| Quarter | Planned / accomplished work |
|---|---|
| 2019-Q2 | Pre-StrictDoc development in a fork of Doorstop. |
| 2019-Q3 | StrictDoc, first prototype. Markdown-based C++ program. Custom requirements metadata in YAML. |
| 2020-Q1 | The second prototype of StrictDoc based on RST/Sphinx. Using Sphinx extensions to manage meta information. First integration tests. |
| 2020-Q2 | StrictDoc created on GitHub. The code still uses RST for parsing requirements meta information and PySide for GUI. |
| 2020-Q3 | The RST parsing is replaced with a TextX-based DSL, new StrictDoc grammar is created. The PySide is replaced with a simple export to HTML using Jinja templates. Export to Sphinx HTML/PDF is introduced. |
| 2020-Q4 | Improvements in the styles of HTML/PDF exports. First Table, Traceability, and Deep Traceability screens. |
| 2021-Q1 | Excel export. The first implementation for forward and reverse traceability between SDoc and source files. |
| 2021-Q2 | Further work on the SDoc-source traceability. |
| 2021-Q3 | Further work on the SDoc-source traceability. Tree cycles detection, validations. MathJax support. |
| 2021-Q4 | Improvements of the traceability index generation and validation. Initial implementation of ReqIF. First support of custom grammars. |
| 2022-Q1 | Further work on ReqIF and custom grammars. Document fragments feature. |
| 2022-Q2 | Excel conversion improvements. Improvements of how meta information is displayed in HTML export. |
| 2022-Q3 | No work in this quarter. |
| 2022-Q4 | Installation using PyInstaller. The first prototype of a Web-based interface. First end-to-end Web tests using SeleniumBase. Improvements of the ReqIF support. |
| 2023-Q1 | Improvements of the Web-based interface towards first release. Improvements of the ReqIF support. |
| 2023-Q2 | Further stabilization of the Web interface. RST markup stability improvements. Work on StrictDoc's own requirements traceability. |
| 2023-Q3 | Anchors and incoming links. Improvements of the ReqIF interface. Work on StrictDoc's own requirements traceability. Mermaid diagramming tool. Reverse parent / child links. Project statistics screen. Performance improvements. |
| 2023-Q4 | Requirements relations and roles. UI improvements and stabilization. Further ReqIF work. Search engine and requirements filters. Project tree Diff/Changelog screens. Basic Git operations. |
| 2024-Q1 | Experimental SPDX support. JSON export. Custom views (static HTML). Basic traceability matrix screen. |
| 2024-Q2 | Includable/composable documents. FREETEXT-to-TEXT migration. ReqIF improvements. |
| 2024-Q3 | HTML2PDF improvements. ReqIF roundtrip for RELATION/ROLE. Consistent automatic escaping of Jinja templates. Passthrough->export command migration. |
| 2024-Q4 | Connecting requirements to functions (C, Python) and classes (Python) in source code. Support the linking in both directions independently: from requirements to source using RELATION/File and from source to requirements using @relation markers. LINK to documents. |
| 2025-Q1 | Connecting requirements to source code – further work. StrictDoc containerized in Docker. JUnit XML report generation. |
| 2025-Q2 | Gcov coverage justification report. SDoc node VERSIONs. External links. |
| 2025-Q3 | Static HTML search. Testing large documentation trees (100+ documents). Tree map visualization. Initial work for Ada support. |
| 2025-Q4 | Python file for StrictDoc configuration instead of TOML. Requirement validations and node constraints. Reading SDoc nodes from source files, e.g., SPDX-* identifiers. |
| 2026-Q1 | Parse Rust code. Preparing the server for concurrent use. WHAT-WHY-HOW tutorial. Markdown support. Static HTML search on server. |
| 2026-Q2 | Further Markdown work. Parse C macros. Table screen editing. Rust's cargo-nextest. Drag-and-drop image upload (WIP). |
2.2. Roadmap diagram
Additionally, a StrictDoc project maintains a high-level roadmap overview using a draw.io diagram.
The diagram contains work items at both the epic and single-task levels. It represents the already open StrictDoc GitHub issues, as well as some concepts in the backlog that are yet to be worked on.
2.3. Backlog
StrictDoc maintains its backlog in a dedicated SDoc document (see 🔗 StrictDoc Backlog), as well as among the GitHub issues specifically tracked under the milestone Backlog.
2.4. Backlog diagram
The following diagram contains the backlog work items at the epic and single task levels.
3. Versioning
As of release 0.1.0 (2024-11-01), StrictDoc follows a semantic versioning-oriented release scheme. The MAJOR.MINOR.PATCH components are managed according to the guidelines of the semantic versioning specification.
4. Quality
StrictDoc's development incorporates quality measures to ensure a high standard of code quality.
4.1. Bug reporting and tracking
StrictDoc provides an issue template for bug reports, which users can use to report bugs and other issues.
All known bugs in StrictDoc are reported as GitHub issues and labeled with the Bug tag:
4.2. Linting of code
StrictDoc uses Ruff to ensure consistent code formatting and to check for common issues in Python code.
4.3. Static analysis
StrictDoc uses mypy to statically check the robustness of its Python type system.
4.4. Testing
StrictDoc has three groups of tests: unit, integration, end-to-end tests.
The unit tests are based on pytest.
The integration tests are based on the LLVM Integrated Tester and FileCheck.py. These tools are not very common, refer to How to test command-line programs with Python tools: LIT and FileCheck for a good description.
The end-to-end web interface tests are based on the SeleniumBase test framework.
4.5. Traceability between StrictDoc requirements, code, and tests
Most of StrictDoc's implemented features are tested through its own documentation artifacts. In terms of traceability, StrictDoc maintains a growing number of trace links between:
- Documentation and source files
- Source files and tests
- Tests, test results, and code coverage data
The goal is to achieve 100% traceability across all artifacts in the StrictDoc codebase.
4.6. Continuous integration (CI)
Contributions to StrictDoc are made through GitHub pull requests. Each pull request is validated by a series of checks and test jobs run on GitHub Actions CI servers.
5. Python baseline
The supported version of Python is kept to be as low as possible. As of 2025-Q4, the currently supported version is Python 3.10.
Ideally, the lowest Python version should only be raised when it is consistently deprecated by the major software platforms like Ubuntu or GitHub Actions.
Another reason for upgrading the minimum Python version is due to the upstream dependencies. As these dependencies stop supporting the older versions of Python, StrictDoc must be upgraded to maintain compatibility. With the existing dependency graph, this happens rather infrequently as most dependencies also maintain the compatibility with the older Python versions.