This document outlines the future work items for StrictDoc.
The following items are listed in descending order of priority, with the topmost items either currently in progress or scheduled to be implemented next.
While this backlog overlaps with StrictDoc’s GitHub issues tracker by more than 50%, it includes more strategic items compared to the GitHub issues, which are primarily focused on actual implementation work.
Very limited development time
Not enough time to develop certain capabilities
Not possible to scale to multi-user environment quickly.
UID: |
SDOC-SRS-13 |
STATUS: |
Backlog |
StrictDoc shall not implement the real-time editing capability to its web interface.
RATIONALE:
The real-time editing feature is hard to achieve with a small part-time involvement from the development team. This requirement can only be reconsidered, if StrictDoc would experience a significant increase in the development power.
UID: |
SDOC-BACKLOG-6 |
STATUS: |
Backlog |
UID: |
SDOC-SRS-86 |
STATUS: |
Backlog |
TBD
UID: |
SDOC-SRS-52 |
STATUS: |
Backlog |
UID: |
SDOC-RMC-27 |
STATUS: |
Backlog |
The Requirements Tool shall provide capabilities for integration with other systems engineering tools.
UID: |
SDOC-RMC-29 |
STATUS: |
Backlog |
The Requirements Tool shall provide integration with Capella MBSE tool.
RATIONALE:
Eclipse Capella is a capable open-source tool for Model-Based Systems Engineering, https://www.eclipse.org/capella/. It should be beneficial for the requirements tool to interface with the Capella engineering community.
COMMENT:
At the very least, the integration can happen through the ReqIF interface that Capella is known to support.
UID: |
SDOC-RMC-55 |
STATUS: |
Backlog |
The Requirements Tool shall provide support for the STPA method.
UID: |
SDOC-RMC-28 |
STATUS: |
Backlog |
The Requirements Tool shall provide capabilities for hardening requirements content with formal semantics.
COMMENT:
The directions to explore:
NASA FRET
bmw-software-engineering/trlc
UID: |
SDOC-RMC-30 |
STATUS: |
Backlog |
The Requirements Tool shall provide integration with AI tools (e.g., ChatGPT).
UID: |
SDOC-SRS-76 |
STATUS: |
Backlog |
UID: |
SDOC-BACKLOG-1 |
STATUS: |
Backlog |
UID: |
SDOC-BACKLOG-2 |
STATUS: |
Backlog |
UID: |
SDOC-BACKLOG-3 |
STATUS: |
Backlog |
UID: |
SDOC-BACKLOG-9 |
STATUS: |
Backlog |
StrictDoc shall provide first-class support for Derived requirements.
Parents:
[DO178-18] Support for Derived requirements
UID: |
SDOC-BACKLOG-4 |
STATUS: |
Backlog |
UID: |
SDOC-BACKLOG-7 |
STATUS: |
Backlog |
UID: |
SDOC-BACKLOG-8 |
STATUS: |
Backlog |
UID: |
SDOC-SRS-129 |
STATUS: |
Backlog |
StrictDoc shall allow exporting/import SDoc content to/from CSV.
Parents:
[SDOC-SSS-59] CSV export/import
UID: |
SDOC-SRS-114 |
STATUS: |
Backlog |
StrictDoc shall provide a web API.
RATIONALE:
A web API allows integration with tools and workflows external to StrictDoc itself.
Parents:
[SDOC-SSS-68] Web API interface
[SDOC-SSS-79] General usability
[SDOC-SSS-85] Programming access via API (Web)
UID: |
SDOC-SRS-123 |
STATUS: |
Backlog |
StrictDoc shall support concurrent use and editing of a single StrictDoc web server instance by multiple users.
Parents:
[DO178-17] Multi-user editing of documents
[SDOC-SSS-81] Support projects with a large number of users
UID: |
SDOC-SRS-130 |
STATUS: |
Backlog |
StrictDoc shall support user accounts.
Parents:
[SDOC-SSS-65] Support user accounts
UID: |
SDOC-SRS-131 |
STATUS: |
Backlog |
StrictDoc shall support notifying a user (users) about updated requirements.
Parents:
[SDOC-SSS-66] Send notifications about updated requirements
[SDOC-SSS-74] Change management
UID: |
SDOC-SRS-116 |
STATUS: |
Backlog |
The SDoc model shall provide validation of requirements according to the EARS syntax.
Parents:
[SDOC-SSS-57] Requirement syntax validation (e.g. EARS)
UID: |
SDOC-SRS-121 |
STATUS: |
Backlog |
StrictDoc shall provide WYSIWYG kind of editing for all multiline text input fields.
RATIONALE:
WYSIWYG improves the user experience, especially for non-programmer users.
Parents:
[DO178-19] WYSIWYG editing
[SDOC-SSS-80] Easy user experience
UID: |
SDOC-SRS-61 |
STATUS: |
Backlog |
StrictDoc shall provide a solution for editing tables in its web interface.
UID: |
SDOC-SRS-94 |
STATUS: |
Backlog |
StrictDoc’s Document screen shall provide a capability to move the nodes between documents.
RATIONALE:
Moving the nodes within a document is a convenience feature that speeds up the requirements editing process significantly.
Parents:
[SDOC-SSS-70] Move nodes between documents
UID: |
SDOC-SRS-120 |
STATUS: |
Backlog |
StrictDoc’s Document screen shall provide controls for automatic completion of requirements UIDs.
COMMENT:
The automatic completion can be especially useful when a user has to fill in a parent relation UID.
Parents:
[SDOC-SSS-6] Auto-provision of Requirement UIDs
[DO178-14] Requirement UID autocompletion
[SDOC-SSS-80] Easy user experience
UID: |
SDOC-SRS-58 |
STATUS: |
Backlog |
UID: |
SDOC-SRS-60 |
STATUS: |
Backlog |
UID: |
SDOC-SRS-63 |
STATUS: |
Backlog |
StrictDoc’s Table screen shall allow hiding/showing columns.
UID: |
SDOC-SRS-117 |
STATUS: |
Backlog |
StrictDoc shall provide the Impact Analysis screen.
NOTE: The Impact Analysis screen helps to get information about the impact that a given change to a requirement has on the other requirements in the project tree.
RATIONALE:
The impact analysis is one of the core functions of a requirements management tool. Analyzing the impact that a requirement has on other requirements and an overall project’s technical definition helps to perform effective change management.
Parents:
[SDOC-SSS-74] Change management
[DO178-11] Impact analysis
UID: |
SDOC-SRS-75 |
STATUS: |
Backlog |
Uploading images via Web interface.
Deleting sections recursively. Correct clean-up of all traceability information.
Editing remaining document options: Inline/Table, Requirements in TOC, etc.
Integration with Git repository. Make the server commit changes to .sdoc files automatically. To a user, provide visibility to what happens under the hood.
LINK between sections and documents.
Option to keep all multi-line text fields to 80 symbols width.
Moving nodes between documents.
TBL view: Column filters to show/hide columns.
TBL view: Completely empty columns are hidden by default.
Contextual help about the RST markup.
How to edit tables conveniently?
What to do with web content going out of sync with the server/file system state?
Issue when adding a child section from a nested section. The child section appears right after the nested section, not after its farthest descendant child.
ReqIF: Export complete documentation tree or a single document.
ReqIF: Import complete documentation tree or a single document.
Configuration file options:
CLI command to dump default config file
Project prefix?
Config options for presenting requirements. - Include/exclude requirements in TOC
StrictDoc as a Python library. Such a use allows a more fine-grained access to the StrictDoc’s modules, such as Grammar, Import, Export classes, etc.
Data exchange with Capella tool. The current idea would be to implement this using ReqIF export/import features.
Language Server Protocol. The LSP can enable editing of SDoc files in IDEs like Eclipse, Visual Studio, PyCharm. A smart LSP can enable features like syntax highlighting, autocompletion and easy navigation through requirements. The promising base for the implementation: https://github.com/openlawlibrary/pygls.
StrictDoc shall support rendering text/code blocks into Markdown syntax.
Fuzzy requirements search. This feature can be implemented in the CLI as well as in the future GUI. A fuzzy requirements search can help to find existing requirements and also identify relevant requirements when creating new requirements.
Support creation of FMEA/FMECA safety analysis documents.
Calculation of checksums for requirements. This feature is relatively easy to implement, but the implementation is postponed until the linking between requirements and files is implemented.
Filtering of requirements by tags.
Import/export: Excel, CSV, PlantUML, Confluence, Tex, Doorstop.
Partial evaluation of Jinja templates. Many of the template variables could be made to be evaluated once, for example, config object’s variables.
UI version for mobile devices (at least some basic tweaks).
When a document is added, the whole documentation is rebuilt from the file system from scratch. A more fine-grained re-indexing of documentation tree can be implemented. The current idea is to introduce a layer of pickled cached data: preserve the whole in-memory traceability graph in a cache, and then use the cached data for making decisions about what should be regenerated.
The “no framework” approach with FastAPI and Turbo/Stimulus allows writing almost zero Javascript, however some proto-framework conventions are still needed. Currently, all code is written in the main_controller which combines all responsibilities, such as parsing HTTP request fields, accessing traceability graph, validations, rendering back the updated AJAX templates. A lack of abstraction is better than a poor abstraction, but some solution has to be found.
Request form object vs Response form object. The workflow of form validations is not optimal.
For Web development, the responsibilities of the TraceabilityIndex class compared to the ExportAction, MarkupRenderer, LinkRenderer classes are unstable. A more ecological composition of classes has to be found. Traceability index is rightfully a “god object” because it contains all information about the in-memory documentation graph.
StrictDoc supports this for HTML already but not for RST.
When passed
strictdoc export ... /path/to/doctree1, /path/to/doctree2, /path/to/doctree3,
the following is generated:
output folder:
- doctree1/
- contents
- doctree2/
- contents
- doctree3/
- contents
and all three doctrees’ requirements are merged into a single documentation space with cross-linking possible.
The question is if it is worth supporting this case further or StrictDoc should only work with one input folder with a single doc tree.