This document outlines a set of high-level requirements for StrictDoc, a text-based requirements management system. While StrictDoc already meets many of these requirements, a further discussion is needed to clarify any remaining questions. For the outstanding requirements, we can establish a practical implementation plan within the upcoming 2023-2024 StrictDoc roadmap.
These requirements are recommended by engineers who adhere to the DO-178B and DO-178C standards of the aviation industry. For a visual summary of the DO-178 standard, please refer to this link: https://upload.wikimedia.org/wikipedia/commons/4/4f/DO-178B_Process_Visual_Summary_Rev_A.pdf.
UID: |
DO178-1 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall store requirements in document files.
RATIONALE:
A concept of a “document file with requirements” helps to structure requirements like they are normally structured in the documents.
An alternative implementation of “1 file per 1 requirement” can be very restrictive in some use cases. For example, one needs to open lots of files to edit, if one file can only have one requirement.
Children:
[SDOC-SRS-105] One document per one SDoc file
UID: |
DO178-2 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall feature a specified document grammar.
RATIONALE:
The grammar helps to standardize a document structure.
COMMENT:
N: StrictDoc is nice.
Children:
[SDOC-SRS-19] Fixed grammar
UID: |
DO178-14 |
STATUS: |
Active |
StrictDoc shall provide autocompletion feature for requirement UID identifiers.
Note: Most immediate use case: adding/editing parent requirements.
COMMENT:
N: When adding parent links, StrictDoc GUI shall present a selection list of UID, with a completion filter, then compute the sha1 of the selected parent req.
COMMENT:
N: Upon req editing, a completion list of already existing reqs (+ “derived” item) would be definitely nice in Webgui ! and would be the ultimate argument to NOT text edit.
Children:
[SDOC-SRS-120] Auto-completion for requirements UIDs
UID: |
DO178-3 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall support generating requirement trees from multiple Git repositories.
COMMENT:
N: StrictDoc is compliant.
Children:
[SDOC-SRS-115] Finding documents recursively
UID: |
DO178-4 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall support assembly of documents from multiple files.
COMMENT:
S: StrictDoc supports document fragments. A document fragment corresponds to a section that can be kept in a separate file. A document stored in another file can import the fragment and have it included in the main document.
Children:
[SDOC-SRS-109] Composeable document
UID: |
DO178-5 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall support publication of documents to HTML and PDF formats.
COMMENT:
N: Sphinx is nice for release.
Children:
[SDOC-SRS-51] Export to printable HTML pages (HTML2PDF)
[SDOC-SRS-70] Export to RST
[SDOC-SRS-71] Docutils
UID: |
DO178-6 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall support a graphical user interface.
COMMENT:
N: A Web GUI in StrictDoc is nice in daily work, especially for non developer people.
COMMENT:
N: GUI for editing is NTH but it shall scale well to thousands of requirements. And it could also contribute to traceability feature.
Children:
[SDOC-SRS-50] Web interface
UID: |
DO178-8 |
STATUS: |
Active |
StrictDoc shall provide an option to configure a host where a server is deployed.
COMMENT:
N: Binding to any local address (localhost) with an option would enable to edit from a smartphone bound to a Raspberry server, for instance.
Children:
[SDOC-SRS-119] ‘Host’ parameter
UID: |
DO178-7 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall not use any proprietary tools.
RATIONALE:
Use of proprietary tools complicates the workflows and the interoperability between companies and teams.
COMMENT:
S: StrictDoc is written using Python and supports the ReqIF format out of the box. All StrictDoc’s dependencies are open-source software components.
Children:
[SDOC-SRS-89] Use of open source components
UID: |
DO178-13 |
STATUS: |
Active |
StrictDoc shall support generation of source code coverage information.
COMMENT:
S: Source file coverage is StrictDoc’s experimental feature. With a more detailed specification, we can turn it to a more advanced and clear presentation of the needed aspects.
Children:
[SDOC-SRS-35] Generate source coverage
UID: |
DO178-9 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall support creation of a project-level grammar.
RATIONALE:
A single grammar defined for a project (same grammar for several documents) helps to standardize the structure of all documents in a documentation tree and reduces the effort needed to create identical grammars all the time.
COMMENT:
S: This feature is easy to implement. The easiest implementation path is to include a config parameter, such as project_grammar in the already-existing strictdoc.toml file. At startup, StrictDoc recognizes the parameter and reads the grammar from a separate file. The project grammar becomes a single source of truth for all documents in the project tree but the option to override a grammar for a given document is still preserved.
Children:
[SDOC-SRS-122] Importable grammars
UID: |
DO178-19 |
STATUS: |
Active |
StrictDoc’s GUI shall support a WYSIWYG text editing.
COMMENT:
Simplifies editing of formatted text.
Children:
[SDOC-SRS-121] WYSIWYG editing
UID: |
DO178-15 |
STATUS: |
Active |
StrictDoc shall allow calculating Diff between two document trees.
Note: The primary use case is calculating a diff between two Git revisions.
COMMENT:
N: Highlight a req diff with its previous version (Git).
Children:
[SDOC-SRS-111] Project tree diff
UID: |
DO178-10 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall support generation of forward and backward traceability matrices.
COMMENT:
N: Trace matrix publishing (both ways : is covered by … and covers …) published in HTML/PDF.
COMMENT:
S: This feature, especially a very basic initial one, is very easy to implement, and it is already on the nearest roadmap, see https://github.com/strictdoc-project/strictdoc/issues/964#issuecomment-1497900436>. We only need to agree on if we are on the same page about how the produced matrices look like.
Children:
[SDOC-SRS-112] Traceability matrix
UID: |
DO178-11 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall support generation of Impact Analysis information.
COMMENT:
N: Impact analysis – upon modification of a requirement: report the recursive list of impacted items.
COMMENT:
S: This feature is doable and a basic variant can be derived from the existing code that generates the Deep Traceability screen. A more advanced one includes a document-to-document Diff between version control revisions, including “tell me what changed between the latest commit and my changes”. Based on this information, a full impact analysis package can be generated. This is less trivial to implement and requires prioritization.
COMMENT:
N: For impact analysis we were thinking about some design which help to satisfy these feature: upon modification of a requirement which owns some parent links, a SHA1 of each parent requirement statement is computed and set in the edited requirement. => this could be captured by the GUI, and there also could exist a CLI command to perform this tagging.
For overall analysis, a CLI command could parse the tree and compute the SHA1 and tel which requirement are to be updated because one of there ancestor were modified. This is almost the same feature called review status in doorstop.
COMMENT:
N: When adding parent links, the GUI could present a selection list of UID, with a completion filter, then compute the SHA1 of the selected parent req. Then highlight uncovered requirement, and requirements impacted by parent change.
Children:
[SDOC-SRS-117] Impact analysis
UID: |
DO178-12 |
COMPLIANCE: |
C |
STATUS: |
Active |
StrictDoc shall support generation of uncovered requirement report.
Note: An uncovered requirement is one that has no children.
COMMENT:
S: This is easy to implement but would be nice to have it specified in terms of how exactly it should look like. The requirements coverage screen was one experimental attempt to visualize and highlight the uncovered requirements but we didn’t stabilize the feature in terms of the visual clarity.
Children:
[SDOC-SRS-66] View DTR screen
[SDOC-SRS-97] Display project statistics
[SDOC-SRS-112] Traceability matrix
UID: |
DO178-16 |
COMPLIANCE: |
PC |
STATUS: |
Backlog |
StrictDoc shall support interoperability with Sphinx:
StrictDoc shall read RST fragments with Sphinx directives without errors.
StrictDoc shall render Sphinx plugins natively.
COMMENT:
N: Support various fragments (images, csv, doxygen, uml, math expr…) => Sphinx extensions nice.
COMMENT:
S: It should be possible to achieve the goal 1 by implementing a complete or limited behavior of each Sphinx plugin feature like I already suggested here. For each needed plugin, we can implement a simulative directive using Docutils, and I expected that for many plugins we can achieve a good compatible behavior. The goal 2 needs a special R&D activity where it has to be decided what would be the interface between StrictDoc and Sphinx.
COMMENT:
N: image.* is MTH to enable both HTML and pdf.
breathe is required for the Software Design Description document which defines software architecture, low level requirements and code component interfaces. But it could be Split in 2 separate documents. LLR in .sdoc and code component interface with sphinx/breathe. So I consider it as NTH.
Children:
[SDOC-SRS-70] Export to RST
[SDOC-SRS-71] Docutils
UID: |
DO178-17 |
COMPLIANCE: |
NC |
STATUS: |
Backlog |
StrictDoc shall allow multi-user editing of documents.
COMMENT:
N: .sdoc file lock?
Children:
[SDOC-SRS-123] Multi-user editing of documents
UID: |
DO178-18 |
STATUS: |
Backlog |
StrictDoc shall provide first-class support for Derived requirements.
COMMENT:
N: I would mention another important feature related to DO178. The requirement which have not parent are “derived” and shall be assessed by safety.
Two issues when a parent ref is set to REQUIRED: True in grammar:
I cannot specify derived requirements.
Top reqs do not have parents by définition.
I worked around this, using a top .sdoc with grammar parent ref optional. Including a specific requirement titled “derived” on which all other .sdoc derived reqd will point as parent ref. But this might be improved.
Children:
[SDOC-BACKLOG-9] Derived requirements