StrictDoc Documentation
StrictDoc High-Level Requirements (L2)

StrictDoc High-Level Requirements (L2)

VERSION: Git commit: 0.27.0, Git branch: HEAD
DATE: 2026-07-13 11:24:49

1. SDoc data model

MID: bd8a7931c1e04df9bf08d291488c67aa
SDOC-SRS-18
1.1. Data model
MID: e8d5b55055254144b96d1ffeb587ec72
UID: SDOC-SRS-18
STATUS: Active
STATEMENT:

StrictDoc shall be based on a data model.
RATIONALE:

Designing StrictDoc with a goal of having a consistent data model ensures that the tool:

  1. can support a rich set of use cases,
  2. model the existing documentation templates used by the industries,
  3. interface well with other formats for storing documentation and requirements, e.g., ReqIF and SPDX.
COMMENT:

Verification: data model diagram TBD.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-26
1.2. Requirement model
MID: 3b31cad22529476db01aca41caf39750
UID: SDOC-SRS-26
STATUS: Active
STATEMENT:

StrictDoc's data model shall support modeling requirements.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-100
1.3. Requirement model fields
MID: 8e2ffffd33af4a969d5bb7ca40cb49a4
UID: SDOC-SRS-100
STATUS: Active
STATEMENT:

StrictDoc's "Requirement" model shall support configurable fields system.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-132
1.4. Requirement model default fields
MID: 2d4020ba06d74571aef7aafe8604215b
UID: SDOC-SRS-132
STATUS: Active
STATEMENT:

By default, the Requirement shall support the following fields:

  • MID
  • UID
  • STATUS
  • TITLE
  • STATEMENT
  • RATIONALE
  • COMMENT.
RATIONALE:

These fields are the most typical fields found in requirement documents.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-98
1.5. Document model
MID: f94419a390f2403daa3c4cd0e96f6cb6
UID: SDOC-SRS-98
STATUS: Active
STATEMENT:

StrictDoc's data model shall support modeling documents.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-110
1.6. Document metadata
MID: 435f856197d743c1b9b1dcbe91a22863
UID: SDOC-SRS-110
STATUS: Active
STATEMENT:

StrictDoc's data model shall support a Document metadata model including at least:

  • UID
  • Document version
  • Document classification
  • Document authors.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-151
1.7. Document configuration
MID: abcced8724d743c1b9b1dcbe91a22863
UID: SDOC-SRS-151
STATUS: Active
STATEMENT:

StrictDoc's data model shall support configuring the document options:

  • Enable/disable MID
  • Markup choice, e.g., RST, HTML, etc.
  • Levels (automatic or manual)
  • Node style
  • Default presentation view.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-99
1.8. Section model
MID: 63821c507d584cf985f05904710b9779
UID: SDOC-SRS-99
STATUS: Active
STATEMENT:

StrictDoc's data model shall support a concept of a "Section" which nests other Sections, Requirements, Texts.
RATIONALE:

"Section" corresponds to a chapter or a section in a document and helps to organize a document by grouping text nodes, requirements and other sections.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-135
1.9. Free text
MID: 899d2f68749b4be1a3124fe4d01de1aa
UID: SDOC-SRS-135
STATUS: Active
STATEMENT:

StrictDoc's data model shall support a "Free Text" model, representing non-normative documentation content.
RATIONALE:

Documentation comprises normative components, such as uniquely identifiable elements like requirements or design items, and non-normative components, including introductory text, overview chapters, and other content. The non-normative parts help provide a general understanding for the reader but do not contribute to traceability information. StrictDoc's free text is designed to store this type of non-normative information in SDoc documents.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-109
1.10. Composeable document
MID: 983653fc26214f46977dc792d65ae65f
UID: SDOC-SRS-109
STATUS: Active
STATEMENT:

StrictDoc's data model shall allow composing a Document from other Documents.
RATIONALE:

The logic behind the parent requirement remains fully relevant. Additionally, an alternative approach could involve using a dedicated entity, like "Fragment", to allow a Document to be composed of includable sections or document fragments. Managing composition at the Document level eliminates the need in additional entities like "Fragment", streamlining both the conceptual understanding and the practical implementation of composability.
COMMENT:

The corresponding UI capability for Fragments CRUD is TBD.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-31
1.11. Requirement relations
MID: fad4cf5dcf4d40518c7c9826fd6bd18a
UID: SDOC-SRS-31
STATUS: Active
STATEMENT:

The StrictDoc data model shall support connecting requirements using Parent and Child relations.
RATIONALE:

Support of both Parent and Child relations allows to build typical requirements relations such as child-to-parent and less common relations when one document can have parent links to a parent document and child links to a child document (e.g., the so-called "compliance" or "tailoring matrix" documents may use this structure).
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-101
1.12. Requirement relation roles
MID: 9930894b08c44f5eba996c0a255e9e3f
UID: SDOC-SRS-101
STATUS: Active
STATEMENT:

Each SDoc relation shall be optionally configurable with a relation role.

NOTE: A relation role is a string value. Typical examples: "refines", "verifies", "implements".
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-149
1.13. Inline links
MID: fa090bc6976c4275aadbf522da6b920b
UID: SDOC-SRS-149
STATUS: Active
STATEMENT:

StrictDoc shall support referencing any node by embedding a hyperlink within the text content of another node.
RATIONALE:

The inline links do not replace the relations between SDoc nodes. Instead, an inline link could be an easy way to refer from one textual node to a chapter or a document. A common use case is "See section ABC for more details".
RELATIONS (File):
SDOC-SRS-150
1.14. Inline anchors
MID: 54132bc6976c4275aadbf522da6b920b
UID: SDOC-SRS-150
STATUS: Active
STATEMENT:

StrictDoc shall support adding anchors within the text content of any node, such that these anchors can be referenced by inline links from other nodes.
RATIONALE:

Anchors allow authors to define precise reference points within SDoc node fields.
RELATIONS (File):

2. SDoc text markup

MID: cbc7f72c6e0b4c858817bf17357105a5
SDOC-SRS-20
2.1. SDoc markup language
MID: 27a6da48c65445539e536ee034921fb5
UID: SDOC-SRS-20
STATUS: Active
STATEMENT:

StrictDoc shall implement its own text markup language called S-Doc (strict-doc).
RATIONALE:

The most commonly used Markdown format lacks the ability to store requirements metadata. While the RST syntax does allow for customization with directives to implement metadata extensions, its visual appearance contradicts other requirements of StrictDoc, such as the type-safety of the grammar and visual readability. Therefore, a markup language tailored specifically to the needs of the requirements tool provides direct control over the capabilities implemented in both the markup and the user interface.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-136
2.2. Identical SDoc content by import/export roundtrip
MID: 1f147feed60245378de2e099facd196d
UID: SDOC-SRS-136
STATUS: Active
STATEMENT:

StrictDoc shall ensure that identical SDoc content is produced every time StrictDoc reads an SDoc file and then writes it to another SDoc file.
RATIONALE:

A consistent import/export roundtrip implementation and testing reduces the risk of the SDoc bi-directional import/export corruption.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-127
2.3. SDoc and Git storage
MID: f48a57c0cd764951a667127ce92fdb12
UID: SDOC-SRS-127
STATUS: Active
STATEMENT:

StrictDoc shall assume and implement capabilities for storage of SDoc files using Git version control system.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-104
2.4. SDoc file extension
MID: 9df34a7ab79842d99ee68303f334d4eb
UID: SDOC-SRS-104
STATUS: Active
STATEMENT:

The SDoc markup content shall be stored in files with .sdoc extension.
RATIONALE:

Given that the name of the model is S-Doc (strict-doc), it is reasonable to make the document files have the .sdoc extension. This helps to identify the document files.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-105
2.5. One document per one SDoc file
MID: 8dd6dd3979484dadbe71ac91aab50608
UID: SDOC-SRS-105
STATUS: Active
STATEMENT:

StrictDoc's SDoc file shall represent content of a single document.
COMMENT:

A "Document" corresponds to a "Document" of the SDoc data model.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-19
2.6. Fixed grammar
MID: e5e3033c13f24fa083423230da7994f7
UID: SDOC-SRS-19
STATUS: Active
STATEMENT:

StrictDoc's markup language shall be based on a well-defined grammar.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-93
2.7. Default grammar fields
MID: b97418ceccff438cb0457ed4bdf1be47
UID: SDOC-SRS-93
STATUS: Active
STATEMENT:

The StrictDoc grammar shall have at least the following fields activated by default:

  • UID
  • STATUS
  • TITLE
  • STATEMENT
  • RATIONALE
  • COMMENT
  • RELATIONS (references to other requirements)
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-21
2.8. Custom grammar / fields
MID: 8924c29136944f65ac5efc8b6b90a07b
UID: SDOC-SRS-21
STATUS: Active
STATEMENT:

The SDoc markup shall support custom grammars.
RATIONALE:

A custom grammar allows a user to define their own configuration of requirement fields.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-122
2.9. Importable grammars
MID: 10d23bfbf4504c2e8c995ae89c500be4
UID: SDOC-SRS-122
STATUS: Active
STATEMENT:

StrictDoc shall support an inclusion of a grammar stored in a separate file.
RATIONALE:

A single grammar defined for several documents helps to standardize the structure of all documents in a documentation tree and removes the effort needed to create identical grammars all the time.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-22
2.10. UID identifier format
MID: 5405c74a9eba4e9193007f01ea98bc85
UID: SDOC-SRS-22
STATUS: Active
STATEMENT:

The SDoc markup shall only accept UID identifiers that consist of alphanumeric characters separated by a limited set of ("_", "-", ".") characters (TBD).
RATIONALE:

A standardized UID format supports easier unique identification of requirements. It is easier to visually identify UIDs that look similar and common to a given industry.
COMMENT:

This requirement may need a revision to accommodate for more UID formats.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-24
2.11. Format-specific markup-to-HTML fragment writers
MID: f871dfc381354daf820cc1e2b94fdb05
UID: SDOC-SRS-24
STATUS: Active
STATEMENT:

StrictDoc shall render supported markup formats (at least RST and Markdown) to HTML fragments via dedicated format-specific writers selected by markup type.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-27
2.12. MathJAX
MID: b1b4f03d4e404a14be481626803fcfc2
UID: SDOC-SRS-27
STATUS: Active
STATEMENT:

StrictDoc's markup language shall support integration with MathJax.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-23
2.13. No indentation
MID: 39f117b79cfa4a8485c458280b3d36ce
UID: SDOC-SRS-23
STATUS: Active
STATEMENT:

SDoc text markup blocks shall all start from column 1, i.e., the nesting of the blocks is not allowed.
RATIONALE:

Nesting large text blocks of free text and requirements compromises readability.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-25
2.14. Type-safe fields
MID: 98628e1db3ca4f52b7632674b69dd657
UID: SDOC-SRS-25
STATUS: Active
STATEMENT:

SDoc markup shall provide "type safety" for all fields.

NOTE: "Type safety" means that each field has a type and a corresponding set of validation checks.
RELATIONS (Parent): RELATIONS (File):

3. Markdown markup

MID: 8e175c1aff9c4bc1b20b032d6811e853
SDOC-SRS-202
3.1. Markdown support
MID: 1e1685d8be084a6c98729daae5637860
UID: SDOC-SRS-202
STATUS: Active
STATEMENT:

StrictDoc shall support Markdown markup.
RATIONALE:

Markdown is the most popular markup language among programmers. Compared to the StrictDoc native SDoc markup, Markdown is much more familiar to developers, which lowers the entry barrier for writing formal requirements with StrictDoc or other tools. It is also used extensively by AI tools.
RELATIONS (Child):
SECTION-SRS-Graph-database

4. Graph database

MID: 34b4abc6bb4649de9e56af31c229b0d1
UID: SECTION-SRS-Graph-database
SDOC-SRS-28
4.1. Traceability index
MID: 2c8d7940a23c443f81a7eb373340894e
UID: SDOC-SRS-28
STATUS: Active
STATEMENT:

StrictDoc shall maintain a complete Traceability Index of all documentation- and requirements-related information available in a project tree.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-29
4.2. Uniqueness UID in tree
MID: 272b8933276d4cd48a78fcfa11899573
UID: SDOC-SRS-29
STATUS: Active
STATEMENT:

For each requirement node, the Traceability Index shall ensure its uniqueness throughout the node's lifecycle.
RATIONALE:

The requirement ensures that the Traceability Index takes of care of validating the uniqueness of all nodes in a document/requirements graph.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-30
4.3. Detect links cycles
MID: 8330d61fd5b1438fa90f127f88903a0d
UID: SDOC-SRS-30
STATUS: Active
STATEMENT:

The Traceability Index shall detect cycles between requirements.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-32
4.4. Link document nodes
MID: 07a1e7bef11d4fcca86cd31ee5245d8d
UID: SDOC-SRS-32
STATUS: Active
STATEMENT:

The Traceability Index shall recognize and maintain the relations between all documents of a project tree.
RATIONALE:

The relations between all documents are a summary of all relations between these documents' requirements. This information is useful for:

  1. Structural analysis of a requirements/documents graph.
  2. Incremental regeneration of only those documents whose content was modified.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-102
4.5. Automatic resolution of reverse relations
MID: 2dad5f293bc442eaa98859c4b5eac0d5
UID: SDOC-SRS-102
STATUS: Active
STATEMENT:

The StrictDoc's graph database shall maintain the requirement relations and their reverse relations as follows:

  • For a Parent relation, the database shall calculate the reverse Child relation.
  • For a Child relation, the database shall calculate the reverse Parent relation.
RATIONALE:

The calculation of the reverse relations allows the user interface code to get and display both requirement's parent and child relations.
COMMENT:

Example: If a child requirement REQ-002 has a parent requirement REQ-001, the graph database first reads the link REQ-002 -Parent> REQ-001, then it creates a corresponding REQ-001 -Child> REQ-002 on the go. Both relations can be queried as follows, in pseudocode:

get_parent_requirements(REQ-002) == [REQ-001]
get_children_requirements(REQ-001) == [REQ-002]
RELATIONS (Parent): RELATIONS (File):

5. Documentation tree

MID: 4dce611287954289b1c2a6a15c413611
SDOC-SRS-115
5.1. Finding documents recursively
MID: 50b2d5d6eb1140f0a2b980203468a5f7
UID: SDOC-SRS-115
STATUS: Active
STATEMENT:

StrictDoc shall discover SDoc documents recursively based on a specified input path.
RATIONALE:

Recursive search allows working with documents located in multiple folders, potentially spanning over several Git repositories.
RELATIONS (Parent): RELATIONS (Child): RELATIONS (File):
SECTION-SRS-Web-HTML-frontend

6. Web/HTML frontend

MID: fcbf717009ce4cb2a8def7eb7b377654
UID: SECTION-SRS-Web-HTML-frontend
SECTION-SRS-General-export-requirements-2

6.1. General export requirements

MID: a3603184d571449792f5cd752c978686
UID: SECTION-SRS-General-export-requirements-2
SDOC-SRS-49
6.1.1. Export to static HTML website
MID: 37f17fdd57ff47e9b7f4147adaeabde1
UID: SDOC-SRS-49
STATUS: Active
STATEMENT:

StrictDoc shall support generating requirements documentation into static HTML.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-50
6.1.2. Web interface
MID: 37399be2a8ac46889e3437209f9dffa9
UID: SDOC-SRS-50
STATUS: Active
STATEMENT:

StrictDoc shall provide a web interface.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-123
6.1.3. Multi-user editing of documents
MID: f97dc050ddab4a08bf1689200118faaa
UID: SDOC-SRS-123
STATUS: Active
STATEMENT:

StrictDoc shall support concurrent use and editing of a single StrictDoc web server instance by multiple users.
RELATIONS (Parent):
SDOC-SRS-48
6.1.4. Preserve generated file names
MID: 8811f0ef33de4365bc66a602a8c184f6
UID: SDOC-SRS-48
STATUS: Active
STATEMENT:

For all export operations, StrictDoc shall maintain the original filenames of the documents when producing output files.
RATIONALE:

Name preservation helps to visually identify which input file an output file corresponds to.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Screen-Project-tree

6.2. Screen: Project tree

MID: b99ebebdadb94fec968785429cef9002
UID: SECTION-SRS-Screen-Project-tree
SDOC-SRS-53
6.2.1. View project tree
MID: 100fa410f4b443e69c48738899cfb5bd
UID: SDOC-SRS-53
STATUS: Active
STATEMENT:

StrictDoc's "Project tree" screen shall provide browsing of a documentation project tree.
RATIONALE:

This screen is the main tool for visualizing the project tree structure.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-107
6.2.2. Create document
MID: eb04abcfd64146f3b7be509afd1693f9
UID: SDOC-SRS-107
STATUS: Active
STATEMENT:

StrictDoc's Project Tree screen shall allow creating documents.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-108
6.2.3. Delete document
MID: de7cda1156e043d7999933a2df630a30
UID: SDOC-SRS-108
STATUS: Active
STATEMENT:

StrictDoc's Project Tree screen shall allow deleting documents.
RELATIONS (Parent):
SECTION-SRS-Screen-Document-DOC

6.3. Screen: Document (DOC)

MID: 185cfc2d1ed4429ebaf0689f70a8cb0a
UID: SECTION-SRS-Screen-Document-DOC
SDOC-SRS-201
6.3.1. Format-specific document handling
MID: 93e6f08c949a48fa98cf86288492d8fd
UID: SDOC-SRS-201
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall arrange all CRUD operations according to the input document format.

Example: If an SDoc document is read from a Markdown file using a dedicated reader, it shall be written back using a Markdown writer.
RELATIONS (Parent):
SDOC-SRS-54
6.3.2. Read document
MID: 9c962637ef7f45b6af6c83964b0a06d9
UID: SDOC-SRS-54
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall allow reading documents.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-106
6.3.3. Create node
MID: 201187122be14ea48d69106d396c6790
UID: SDOC-SRS-106
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall allow creating document nodes.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-161
6.3.4. Clone node from existing node
MID: 9b291b5df5914f13b23fb8c367be0a24
UID: SDOC-SRS-161
STATUS: Active
STATEMENT:

StrictDoc shall support cloning nodes from existing nodes.
RATIONALE:

Simplifies the creation of similar nodes.
RELATIONS (File):
SDOC-SRS-55
6.3.5. Update node
MID: 13968ae160744e10ba8979eaee2f4f54
UID: SDOC-SRS-55
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall allow update document content.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-162
6.3.6. Delete node
MID: 0ec87f08626a4839b5951d98fef9e0e1
UID: SDOC-SRS-162
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall support the deletion of document nodes.
RELATIONS (File):
SDOC-SRS-159
6.3.7. Create node relation
MID: b805e36294764e8f8cb5a88ab8fa0467
UID: SDOC-SRS-159
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall creating updating node relations.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-158
6.3.8. Update node relation
MID: f32c091454c94bc5bd2091e2c4f38582
UID: SDOC-SRS-158
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall allow updating node relations.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-92
6.3.9. Move requirement / section nodes within document
MID: edc02a3a97704007b70b93102c76b278
UID: SDOC-SRS-92
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall provide a capability to move the nodes within a document.
RATIONALE:

Moving the nodes within a document is a convenience feature that speeds up the requirements editing process significantly.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-56
6.3.10. Edit Document grammar
MID: 197e00dd3b1d42309250c89de23ea51b
UID: SDOC-SRS-56
STATUS: Active
STATEMENT:

StrictDoc's screen shall allow editing a document's grammar.
RATIONALE:

Editing document grammar allows a user to customize the requirements fields.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-57
6.3.11. Edit Document options
MID: 2706ac7ccb8148edb7b200a1b78c25d6
UID: SDOC-SRS-57
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall provide controls for configuring the document-specific options.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-96
6.3.12. Auto-generate requirements UIDs
MID: d64f7a0f6ba54672a62634304c54e2d4
UID: SDOC-SRS-96
STATUS: Active
STATEMENT:

StrictDoc's Document screen shall provide controls for automatic generation of requirements UIDs.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-120
6.3.13. Auto-completion for requirements UIDs
MID: 956371b6a7824d0b91caa5603faeeae2
UID: SDOC-SRS-120
STATUS: Active
STATEMENT:

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.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-59
6.3.14. Buttons to copy text to buffer
MID: 738b63b7f55b43eb99f5600bd65f5ba7
UID: SDOC-SRS-59
STATUS: Active
STATEMENT:

StrictDoc shall provide a "copy text to buffer" button for all requirement's text fields.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Screen-Table-TBL

6.4. Screen: Table (TBL)

MID: 2b5d74dafd6d43f4bab4c05ed4da6f0d
UID: SECTION-SRS-Screen-Table-TBL
SDOC-SRS-62
6.4.1. View TBL screen
MID: e12b4c5b4f13444d99279ab445df5bcc
UID: SDOC-SRS-62
STATUS: Active
STATEMENT:

StrictDoc's Table screen shall allow reading documents in a table-like manner.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Screen-Traceability-TR

6.5. Screen: Traceability (TR)

MID: 3c589969eb6a41c19b1dd246dabadbc8
UID: SECTION-SRS-Screen-Traceability-TR
SDOC-SRS-65
6.5.1. View TR screen
MID: 35d4c1dd30814c2a80918a90081a88b7
UID: SDOC-SRS-65
STATUS: Active
STATEMENT:

StrictDoc shall provide a single document-level traceability screen.

NOTE: This screen helps to read a document like a normal document while the traceability to this document's parent and child elements is visible at the same time.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Screen-Deep-traceability-DTR

6.6. Screen: Deep traceability (DTR)

MID: 9d337068b6a940b7a98d40697ea200a8
UID: SECTION-SRS-Screen-Deep-traceability-DTR
SDOC-SRS-66
6.6.1. View DTR screen
MID: 48bc17d898c94605b17d0267480f57ee
UID: SDOC-SRS-66
STATUS: Active
STATEMENT:

StrictDoc shall provide a deep traceability screen.
RELATIONS (Parent): RELATIONS (File):

6.7. Screen: HTML2PDF

MID: 181dfbcbbfac41e18f7fb09af0df8f4e
SDOC-SRS-51
6.7.1. Export to HTML content to PDF (HTML2PDF)
MID: f2fd90ad8a2946e7b085233a9c7a8a75
UID: SDOC-SRS-51
STATUS: Active
STATEMENT:

StrictDoc shall allow exporting documents and entire documentation trees to PDF.
RATIONALE:

As required by the parent requirement, PDF is one of the most common documentation formats.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-203
6.7.2. Cross-linking PDF documents from same project tree
MID: 50eabada50be47a1938e55fc10814972
UID: SDOC-SRS-203
STATUS: Active
STATEMENT:

When exporting multiple HTML documents from a same project tree into PDF, StrictDoc shall preserve all cross-document linking in the output PDF documents.
RATIONALE:

This enables navigation between PDF documents within the same project tree, which can be useful for simplifying the review and tracing work performed by readers.
RELATIONS (Child):
SDOC-SRS-160
6.7.3. Custom PDF export template
MID: 6cfcb21b3f1949f49d13af6b00d3d37a
UID: SDOC-SRS-160
STATUS: Active
STATEMENT:

StrictDoc shall support the customization of the PDF export template.
RELATIONS (File):

6.8. Screen: Project statistics

MID: ddf15b3113a54107979752ec192e2ded
SDOC-SRS-97
6.8.1. Display project statistics
MID: 19f7c2d35237423e950584a4a7aa95a7
UID: SDOC-SRS-97
STATUS: Active
STATEMENT:

StrictDoc shall provide a Project Statistics screen that displays the following project information:

  • Project title
  • Date of generation
  • Git revision
  • Total documents
  • Total requirements
  • Requirements status breakdown
  • Total number of TBD/TBC found in documents.
RATIONALE:

TBD
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-154
6.8.2. Support for user-provided custom statistics generators
MID: 7968fb7612f64504b5a430ccbffe80f1
UID: SDOC-SRS-154
STATUS: Active
STATEMENT:

StrictDoc shall support customization of the project statistics screen, enabling users to define and display their own project-specific statistics.
RATIONALE:

Projects often have unique traceability and reporting requirements, and supporting custom statistics allows StrictDoc to display metrics that are most relevant to each project's context.
RELATIONS (Parent): RELATIONS (File):

6.9. Screen: Document tree map

MID: d84e3a79b3e443cabe96d7c18ea5d322
SDOC-SRS-157
6.9.1. Tree map
MID: 1520fa85ed7a4f1aa80c49ed858f402f
UID: SDOC-SRS-157
STATUS: Active
STATEMENT:

StrictDoc shall provide a tree map screen, visualizing the following information:

  • Document tree map
  • Requirements coverage by source code
  • Requirements coverage by test files.
RATIONALE:

Enables the visualization and browsing of the overall document tree and requirements coverage information.
RELATIONS (Parent): RELATIONS (File):

6.10. Screen: Source coverage

MID: 63df985038374acb82e9b4185eff5a7e
SDOC-SRS-35
6.10.1. Project source code coverage
MID: 3aeb1eea0dba4041a9161a1a8d291999
UID: SDOC-SRS-35
STATUS: Active
STATEMENT:

StrictDoc shall generate project source code coverage information.

NOTE: Source code information can be visualized using both web or CLI interfaces.
RELATIONS (Parent): RELATIONS (File):

6.11. Screen: Single source file coverage

MID: 9c19eea544ec4d90bb65fd8fd9b13cc4
SDOC-SRS-36
6.11.1. Single source file coverage
MID: 56ecfb19152e45b09c0e55de2d1d5f05
UID: SDOC-SRS-36
STATUS: Active
STATEMENT:

StrictDoc shall generate single file traceability information.
RATIONALE:

With this capability in place, it is possible to focus on a single implementation file's links to requirements which helps in the code reviews and inspections.
RELATIONS (Parent): RELATIONS (File):

6.12. Screen: Traceability matrix

MID: 14ad600308434e6baaeef02d3e90b720
SDOC-SRS-112
6.12.1. Traceability matrix
MID: 167f6fe66d7247a6bf628ed6c1949275
UID: SDOC-SRS-112
STATUS: Active
STATEMENT:

StrictDoc shall provide a traceability matrix screen.
RELATIONS (Parent): RELATIONS (File):

6.13. Screen: Project tree diff

MID: 544f8ffed8604e63a269a3f953681163
SDOC-SRS-111
6.13.1. Project tree diff
MID: aef80cc1a3144564bf23bf3c2a1cfd7f
UID: SDOC-SRS-111
STATUS: Active
STATEMENT:

StrictDoc shall provide a project tree diff screen.
RELATIONS (Parent): RELATIONS (File):

6.14. Content search

MID: 8380fb39beb04d1c9370733bcfafbc01
SDOC-SRS-155
6.14.1. Content search
MID: 3e85dd6bf05a4cecb8e070fd81aa333a
UID: SDOC-SRS-155
STATUS: Active
STATEMENT:

StrictDoc shall provide searching documentation content with queries via a search bar.
RATIONALE:

As per the parent requirement, a search bar with query support enables users to interactively find specific content without navigating the entire documentation tree.
RELATIONS (Parent): RELATIONS (Child): RELATIONS (File):
SECTION-SRS-Requirements-to-source-traceability

7. Requirements-to-source traceability

MID: 2d4dc6fc901f4b28aaf414fcfbdfabca
UID: SECTION-SRS-Requirements-to-source-traceability
SDOC-SRS-33
7.1. Link requirements with source files
MID: 221b544dab2e4b96be124e1caf84a7c2
UID: SDOC-SRS-33
STATUS: Active
STATEMENT:

StrictDoc shall support bi-directional linking requirements with source files.
RELATIONS (Parent): RELATIONS (File):

7.2. Language-aware parsing of source code

MID: 2f63252320d546d88462849b521f45ba
SDOC-SRS-142
7.2.1. Language-aware parsing of source code
MID: 79a8080f6e41485f9835ccda067b34bc
UID: SDOC-SRS-142
STATEMENT:

StrictDoc shall support parsing the most commonly used formats and programming languages to the Abstract Syntax Tree (AST) level.

The format examples: C, C++, Python, Rust, Ada, Robot, Gherkin, etc.
RATIONALE:

StrictDoc must be capable of traversing the AST of common formats and programming languages to identify and extract function and class markers.
RELATIONS (File):
SDOC-SRS-146
7.2.2. Language-aware parsing of C/C++ code
MID: 85a8080f8441485f9111ccda063b34bc
UID: SDOC-SRS-146
STATUS: Active
STATEMENT:

StrictDoc shall support parsing the C and C++ source files which includes:

  • Recognizing functions and their Doxygen comments.
  • Recognizing function declarations and function definitions.
RATIONALE:

C and C++ languages are common languages for embedded and general systems programming. These languages have to be handled with a dedicated parser because of these languages' specifics.
RELATIONS (File):
SDOC-SRS-147
7.2.3. Language-aware parsing of Python code
MID: 3456080f1358485f9bacdcda063b34bc
UID: SDOC-SRS-147
STATUS: Active
STATEMENT:

StrictDoc shall support parsing the Python source files which includes:

  • Recognizing Python functions, including nested functions.
  • Recognizing Python classes, including nested classes.
  • Recognizing decorated functions.
RATIONALE:

Python language has to be handled with a dedicated parser because of this language's specifics.
RELATIONS (File):
SDOC-SRS-204
7.2.4. Language-aware parsing of Rust code
MID: e71074247fbe47bfb5265f3bd631170f
UID: SDOC-SRS-204
STATUS: Active
STATEMENT:

StrictDoc shall support parsing the Rust source files.
RATIONALE:

Rust language has to be handled with a dedicated parser because of this language's specifics.
RELATIONS (Child):
SDOC-SRS-148
7.2.5. Language-aware parsing of Robot framework code
MID: 9183080f1358485f9bacdcda0635109
UID: SDOC-SRS-148
STATUS: Active
STATEMENT:

StrictDoc shall support parsing the Robot framework test files.
RATIONALE:

Robot framework's markup has to be handled with a dedicated parser because of this language's specifics.
RELATIONS (File):
SDOC-SRS-143
7.3. Link requirements with test files and test reports
MID: bdeda4b89d82446281e2c7c2eae46708
UID: SDOC-SRS-143
STATUS: Active
STATEMENT:

StrictDoc shall support bi-directional linking between requirements, test files, and test reports.
RATIONALE:

Tracing requirements to not just test files but also the test report information closes the verification cycle more completely.
RELATIONS (File):
SDOC-SRS-144
7.4. Link requirements with code coverage information
MID: aefeb5b89d82446281e2c7c2eae12345
UID: SDOC-SRS-144
STATUS: Active
STATEMENT:

StrictDoc shall support linking between requirements, source files, and code coverage information.
RATIONALE:

Tracing requirements to not just test files but also to the code coverage information closes the verification cycle more completely.
RELATIONS (File):

7.5. Forward linking from requirements to source code

MID: 5fedbaba39d24da79d074501198ff654
SDOC-SRS-145
7.5.1. SDoc markup's forward relations
MID: 21637d9bec434d32bb6b97ba5a4e70e6
UID: SDOC-SRS-145
STATEMENT:

StrictDoc shall support forward linking from SDoc nodes to source files.
RATIONALE:

There are cases when it is not possible to modify source code directly. The forward linking enables to refer to the files or their parts from SDoc nodes. Depending on a project structure, the forward linking from requirements to source files can replace the backward linking from source code back to requirements, or both approaches can co-exist.
RELATIONS (File):

7.6. Source code markup – Relations

MID: 9c1dd6cbabd44ac680985c403cf710a7
SDOC-SRS-34
7.6.1. Relation markers syntax
MID: b9144222a7f3454da2989f494cd9647c
UID: SDOC-SRS-34
STATUS: Active
STATEMENT:

StrictDoc shall support annotating source code with links that reference the requirements.
RELATIONS (Parent): RELATIONS (Child): RELATIONS (File):
SDOC-SRS-124
7.6.2. Line marker
MID: 61c25cab106e4283b2c6d64bf1db96b2
UID: SDOC-SRS-124
STATUS: Active
STATEMENT:

StrictDoc's shall support line markers that can be attached to single source code lines.

NOTE: A single-line marker points to a single line in a source file.
RATIONALE:

Sometimes a requirement can influence only a single line in the source code. The advantage of a single-line marker compared to a range marker is that a single-line marker is not intrusive and does not clutter source code.
RELATIONS (Parent): RELATIONS (Child): RELATIONS (File):
SDOC-SRS-137
7.6.3. Language element marker
MID: 61c23c1b106e4583b2c6d64bf1d296ba
UID: SDOC-SRS-137
STATUS: Active
STATEMENT:

StrictDoc shall support relation markers that can be attached to individual source code elements. StrictDoc shall support an optional scope attribute to disambiguate the target element where StrictDoc can't infer it solely from the marker position.

Note: The most basic example of such traceable elements are functions and classes, but generally supported elements and available scope attributes depend on the programming language.
RATIONALE:

Source code elements can often be considered as the next level to trace from a requirement. For example, a low level element is implemented by a function, or a test case is implemented by a test function.

Sometimes it's also feasible to consider the source code elements as lean replacement for prose requirement or test-case definitions.
RELATIONS (Parent): RELATIONS (Child): RELATIONS (File):
SDOC-SRS-139
7.6.4. File marker
MID: 82345cab106e4283b2c7774bf1db96b1
UID: SDOC-SRS-139
STATUS: Active
STATEMENT:

StrictDoc's shall support file markers that can be attached to entire source files.
RATIONALE:

There are cases when a requirement can be attached to an entire file.
RELATIONS (Parent): RELATIONS (Child): RELATIONS (File):
SDOC-SRS-138
7.6.5. Range marker
MID: 11c23c1b105e4583b2c6d64bf1d296cc
UID: SDOC-SRS-138
STATUS: Active
STATEMENT:

StrictDoc shall support relation markers that can be attached to source code ranges.

NOTE: Compared to other marker types, to indicate a range, two markers are needed: one to start a range and one to end a range.
RATIONALE:

There are cases when a requirement implementation results in the requirement affecting only a range/block of source code.
RELATIONS (Parent): RELATIONS (Child): RELATIONS (File):

7.7. Source code markup – Nodes

MID: 5ce2ea410dd94927807a258f482483a5
SDOC-SRS-141
7.7.1. Parse nodes from source code
MID: f44df3c6a84f4b4e9201a61023446d9c
UID: SDOC-SRS-141
STATUS: Active
STATEMENT:

StrictDoc shall support parsing nodes from source code.
RATIONALE:

It can be practical to define the requirement and other nodes directly in source comments and then let a requirements tool generate documents from these nodes' content automatically.

A reference example: Generating test specifications from the TEST_SPEC nodes which are defined directly in source code comments.
RELATIONS (Child): RELATIONS (File):
SECTION-SRS-Export-import-formats

8. Export/import formats

MID: 1acdd6ddf9d24dbaa320230402152226
UID: SECTION-SRS-Export-import-formats
SECTION-SRS-RST

8.1. RST

MID: ce1d174a4d794250931a5ba519583be6
UID: SECTION-SRS-RST
SDOC-SRS-70
8.1.1. Export to RST
MID: 2aa615b9cf264e7aad826f4ff466e514
UID: SDOC-SRS-70
STATUS: Active
STATEMENT:

StrictDoc shall allow exporting SDoc content to the RST format.
RATIONALE:

Exporting SDoc content to RST enables:

  1. Generating RST to Sphinx HTML documentation.
  2. Generating RST to PDF using Sphinx/LaTeX.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-71
8.1.2. Docutils
MID: 6faffbd1d4cc47ea88c08ef38966e5ec
UID: SDOC-SRS-71
STATUS: Active
STATEMENT:

StrictDoc shall generate RST markup to HTML using Docutils.
RATIONALE:

Docutils is the most mature RST-to-HTML converter.
COMMENT:

TBD: Move this to design decisions.
RELATIONS (Parent):
SECTION-SRS-ReqIF

8.2. ReqIF

MID: a906dfb776334b8985f778f0fe1b79e4
UID: SECTION-SRS-ReqIF
SDOC-SRS-72
8.2.1. Export/import from/to ReqIF
MID: 2bf94015818e4770b2b1947b5fdbb969
UID: SDOC-SRS-72
STATUS: Active
STATEMENT:

StrictDoc shall support exporting/importing requirements content from/to ReqIF format.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-73
8.2.2. Standalone ReqIF layer
MID: bb52b698d7a544aca420d606e4e51356
UID: SDOC-SRS-73
STATUS: Active
STATEMENT:

StrictDoc shall maintain the core ReqIF implementation as a separate software component.
RATIONALE:

ReqIF is a well-defined standard which exists independently of StrictDoc's development. It is reasonable to maintain the ReqIF codebase as a separate software component to allow independent development and easier maintainability.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Excel

8.3. Excel and CSV

MID: 0ffda51372b641f6ba460bf5ac8b3627
UID: SECTION-SRS-Excel
SDOC-SRS-74
8.3.1. Export to Excel
MID: f7b587f66dda402dbd58768e2740742f
UID: SDOC-SRS-74
STATUS: Active
STATEMENT:

StrictDoc shall allow exporting SDoc documents to Excel, one Excel sheet per document.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-152
8.3.2. Import from Excel
MID: 97b587f66dda402dbd58768e2740742f
UID: SDOC-SRS-152
STATUS: Active
STATEMENT:

StrictDoc shall allow importing Excel documents to SDoc documents, one Excel sheet per document.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-134
8.3.3. Selected fields export
MID: 5aa75848972249d5bec8a40812b99d86
UID: SDOC-SRS-134
STATUS: Active
STATEMENT:

StrictDoc Excel export shall allow exporting SDoc documents to Excel with only selected fields.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Command-line-interface

9. Command-line interface

MID: 53cfa6296eec45479544e6c5165d7fb9
UID: SECTION-SRS-Command-line-interface

9.1. General CLI requirements

MID: 63373c3875404f1c820add84ea057c73
SDOC-SRS-103
9.1.1. Command-line interface
MID: 598647eed3a446fe93e2c54b197f830e
UID: SDOC-SRS-103
STATUS: Active
STATEMENT:

StrictDoc shall provide a command-line interface.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Command-Manage

9.2. Command: Manage

MID: 7c6a0efe76b84dcd842ef371796e787e
UID: SECTION-SRS-Command-Manage
SECTION-SRS-Command-Auto-UID

9.2.1. Command: Auto UID

MID: bea76afe9bf241eaaf5984b54e00ff76
UID: SECTION-SRS-Command-Auto-UID
SDOC-SRS-85
9.2.1.1. Auto-generate requirements UIDs
MID: 7daa1310876a421f8e39f8ac25b99c1d
UID: SDOC-SRS-85
STATUS: Active
STATEMENT:

StrictDoc shall allow automatic generation of requirements UIDs.
RELATIONS (Parent): RELATIONS (File):

10. Python API

MID: a0ed7cdd06ec4f0ab6d3ba56cced8c7e
SDOC-SRS-125
10.1. StrictDoc Python API
MID: a20c5b6a021f4dd5a5a5dda2880c1b87
UID: SDOC-SRS-125
STATUS: Active
STATEMENT:

StrictDoc shall provide a Python API for its core functions:

  • Reading SDoc files
  • Creating traceability graph
  • Generating HTML exports
  • Converting SDoc to other formats.
RELATIONS (Parent):

11. Web server

MID: 590121ded2074757aa1720b4d8013426
SDOC-SRS-126
11.1. Web server
MID: 409f462f1f4645c8ad24980727a72521
UID: SDOC-SRS-126
STATUS: Active
STATEMENT:

StrictDoc shall provide a web server.
RATIONALE:

A web server is a precondition for StrictDoc's web interface. A web server can be available to a single user on their local machine or it can be deployed to a network and be made accessible by several computers.
RELATIONS (Parent): RELATIONS (File):

12. User experience

MID: 44eb09d0e5b542d5984d234167e6f337
SDOC-SRS-163
12.1. StrictDoc identification
MID: 2bfb3703b218411b87864733bffb59cf
UID: SDOC-SRS-163
STATUS: Active
STATEMENT:

StrictDoc shall provide 'about' and 'version' commands that display the project's title, current version, license, and links to the project's web pages.
RELATIONS (Parent): RELATIONS (File):
SECTION-SSRS-Strict-mode-by-default

12.2. Strict mode by default

MID: 821c01118a9643a188a4ecc5b0cec6a5
UID: SECTION-SSRS-Strict-mode-by-default
SDOC-SRS-6
12.2.1. Warnings are errors
MID: c4e9dce647654deeab8471d04573f8cb
UID: SDOC-SRS-6
STATUS: Active
STATEMENT:

StrictDoc's default mode of operation shall treat all warnings as errors.
RATIONALE:

When warnings are treated as errors, the user becomes aware of potential issues as soon as they appear.
RELATIONS (Parent):
SECTION-SRS-Configurability

13. Configurability

MID: 40e7bd8aabdf4cb889e9d7b01b8729e6
UID: SECTION-SRS-Configurability
SDOC-SRS-37
13.1. strictdoc.toml file
MID: da446e6d3c6d4b13badd4a47bdbcc5a3
UID: SDOC-SRS-37
STATUS: Active
STATEMENT:

StrictDoc shall support a configuration of project-level options through a TOML file named strictdoc.toml.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-39
13.2. Feature toggles
MID: a6e70c0619204a26b135d1e5fca45dd7
UID: SDOC-SRS-39
STATUS: Active
STATEMENT:

StrictDoc shall allow a user to select a subset of StrictDoc's available features by listing them in the strictdoc.toml file.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-119
13.3. 'Host' parameter
MID: a8a17295d3e24601891c7d19d5ca67d9
UID: SDOC-SRS-119
STATUS: Active
STATEMENT:

StrictDoc shall support configuring a host/port on which the StrictDoc web server is run.
RELATIONS (Parent): RELATIONS (File):
SECTION-SSRS-Performance

14. Performance

MID: bb14fb2c46f34cf1a82b417b57e95853
UID: SECTION-SSRS-Performance
SDOC-SRS-1
14.1. Process-based parallelization
MID: acd97ca6b9d2451da53168917d96705e
UID: SDOC-SRS-1
STATUS: Active
STATEMENT:

StrictDoc shall support process-based parallelization for time-critical tasks.
RATIONALE:

Process-based parallelization can provide a good speed-up when several large documents have to be generated.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-95
14.2. Caching of parsed SDoc documents
MID: 54602f6d120548c8bbd70d1d25113d53
UID: SDOC-SRS-95
STATUS: Active
STATEMENT:

StrictDoc shall implement caching of parsed SDoc documents.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-2
14.3. Incremental generation of documents
MID: 6fec2f8c0baa4ddba95bee05ad03a785
UID: SDOC-SRS-2
STATUS: Active
STATEMENT:

StrictDoc shall support incremental generation of documents.

NOTE: "Incremental" means that only the modified documents are regenerated when StrictDoc is run repeatedly against the same project tree.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-3
14.4. Caching of RST fragments
MID: 5f2df631605543d18d57e09bc3791003
UID: SDOC-SRS-3
STATUS: Active
STATEMENT:

StrictDoc shall cache the RST fragments rendered to HTML.
RATIONALE:

Conversion of RST markup to HTML is a time consuming process. Caching the rendered HTML of each fragment helps to save time when rendering the HTML content.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-4
14.5. On-demand loading of HTML pages
MID: d0c4828ed8434613aae844481bbef1ca
UID: SDOC-SRS-4
STATUS: Active
STATEMENT:

StrictDoc's web interface shall generate the HTML content only when it is directly requested by a user.
RATIONALE:

Generating a whole documentation tree for a user project can be time consuming. The on-demand loading ensures the "do less work" approach when it comes to rendering the HTML pages.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-5
14.6. Precompiled Jinja templates
MID: 4e014d3291ce460c993a0ff334eff4a7
UID: SDOC-SRS-5
STATUS: Active
STATEMENT:

StrictDoc shall support a precompilation of HTML templates.
RATIONALE:

The StrictDoc-exported HTML content visible to a user is assembled from numerous small HTML fragments. Precompiling the HTML templates from which the content gets rendered improves the performance of the HTML rendering.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Quality-requirements

15. Development process requirements

MID: de3a4de44f474784bf233ea7610eac6c
UID: SECTION-SRS-Quality-requirements

15.1. General process

MID: cbee3d3e8a9d440abaa58387c342602c
SDOC-SRS-133
15.1.1. Priority handling of critical issues in StrictDoc
MID: 27319e3866b8423099774d8770950acd
UID: SDOC-SRS-133
STATUS: Active
STATEMENT:

All critical issues reported in relation to StrictDoc shall be addressed with utmost priority.
RATIONALE:

Prioritizing major issues ensures StrictDoc remains stable and reliable, preventing serious problems that could compromise its performance and integrity.
RELATIONS (Parent):
SECTION-SRS-Requirements-engineering

15.2. Requirements engineering

MID: 47cec130eb3d4583825355f2635e7011
UID: SECTION-SRS-Requirements-engineering
SDOC-SRS-128
15.2.1. Requirements-based development
MID: d0ab977bbb494cbf818c92a1cab1bef0
UID: SDOC-SRS-128
STATUS: Active
STATEMENT:

StrictDoc's development shall be requirements-based.
RELATIONS (Parent):
SDOC-SRS-91
15.2.2. Self-hosted requirements
MID: b3fff332c2e342ec9dd372ebd49cb64d
UID: SDOC-SRS-91
STATUS: Active
STATEMENT:

StrictDoc's requirements shall be written using StrictDoc.
RELATIONS (Parent):
SECTION-SRS-Implementation-requirements

15.3. Implementation requirements

MID: dfbaabc0529f4cc987358ae0563910e9
UID: SECTION-SRS-Implementation-requirements
SECTION-SRS-Programming-languages

15.3.1. Programming languages

MID: 5eb734a4b8944531aa75f0b71ef22d52
UID: SECTION-SRS-Programming-languages
SDOC-SRS-8
15.3.1.1. Python language
MID: 4053ea6c8f6c4c29b89fea0e39912861
UID: SDOC-SRS-8
STATUS: Active
STATEMENT:

StrictDoc shall be written in Python.
RATIONALE:

Python has an excellent package ecosystem. It is a widely used language. It is most often the next language for C/C++ programming community when it comes to the tools development and scripting tasks.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Cross-platform-availability

15.3.2. Cross-platform availability

MID: 131af6457a9f43299306e6dc9fce65a7
UID: SECTION-SRS-Cross-platform-availability
SDOC-SRS-9
15.3.2.1. Linux
MID: ceee07bdc9bd42fc9a4d0e9b4bfc312f
UID: SDOC-SRS-9
STATUS: Active
STATEMENT:

StrictDoc shall support the Linux operating systems.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-10
15.3.2.2. macOS
MID: f8c7586e1b324480ac0bd153e068350d
UID: SDOC-SRS-10
STATUS: Active
STATEMENT:

StrictDoc shall support the macOS operating system.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-11
15.3.2.3. Windows
MID: 6af3dbb1e05244579622d3d2a26b5413
UID: SDOC-SRS-11
STATUS: Active
STATEMENT:

StrictDoc shall support the Windows operating system.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Implementation-constraints

15.4. Implementation constraints

MID: 852396c217184ba98a0d26b92f36fd04
UID: SECTION-SRS-Implementation-constraints
SDOC-SRS-89
15.4.1. Use of open source components
MID: 83d5c896004948b48c3597d58267dafa
UID: SDOC-SRS-89
STATUS: Active
STATEMENT:

StrictDoc shall be built using only open source software components.
RATIONALE:

No commercial/proprietary dependency chain ensures that StrictDoc remain free and open for everyone.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-14
15.4.2. No heavy UI frameworks
MID: b22bf982e73246a79a5ba4ae653d21e5
UID: SDOC-SRS-14
STATUS: Active
STATEMENT:

StrictDoc shall avoid using large and demanding UI frameworks.

NOTE: An example of frameworks that require a very specific architecture: React JS, AngularJS.
RELATIONS (Parent):
SDOC-SRS-15
15.4.3. No use of NPM
MID: 309e4108c1fa47e99d4331af642f3b81
UID: SDOC-SRS-15
STATUS: Active
STATEMENT:

StrictDoc shall avoid extending its infrastructure with anything based on NPM-ecosystem.
RATIONALE:

StrictDoc already deals with the Python/Pip/Pypi ecosystem. The amount of necessary maintenance is already quite high. NPM is known for splitting its projects into very small parts, which increases the complexity of maintaining all dependencies.
RELATIONS (Parent):
SDOC-SRS-16
15.4.4. No use of JavaScript replacement languages (e.g., Typescript)
MID: b9cacb97a045418385c7f870b23ac063
UID: SDOC-SRS-16
STATUS: Active
STATEMENT:

StrictDoc shall avoid using JavaScript-based programming languages.
RATIONALE:

The development team does not have specific experience with any of the JS alternatives. Staying with a general subset of JavaScript is a safer choice.
RELATIONS (Parent):
SDOC-SRS-87
15.4.5. Monolithic application with no microservices
MID: 70f05a744a0546909dc5b69de88ad41f
UID: SDOC-SRS-87
STATUS: Active
STATEMENT:

StrictDoc shall avoid using microservices and microservice-based architectures.
RATIONALE:

The project is too small to scale to a multi-service architecture.
COMMENT:

This requirement could be re-considered only if a significant technical pressure would require the use of microservices.
RELATIONS (Parent):
SDOC-SRS-88
15.4.6. No reliance on containerization
MID: 7d68821750a54cb5833b608cfc278f47
UID: SDOC-SRS-88
STATUS: Active
STATEMENT:

StrictDoc shall avoid using containers and containerization technologies.
RATIONALE:

Containers are significant extra layer of complexity. They are hard to debug.
COMMENT:

This constraint does not block a StrictDoc user from wrapping StrictDoc into their containers.
RELATIONS (Parent):
SECTION-SRS-Coding-constraints

15.5. Coding constraints

MID: e4e5b9934e074cdb9567fa197db20a4a
UID: SECTION-SRS-Coding-constraints
SDOC-SRS-40
15.5.1. Use of asserts
MID: 61d96cd1d03e40c48187ee67ac0b65f6
UID: SDOC-SRS-40
STATUS: Active
STATEMENT:

StrictDoc's development shall ensure a use of assertions throughout the project codebase.

NOTE: At a minimum, the function input parameters must be checked for validity.
RELATIONS (Parent):
SDOC-SRS-41
15.5.2. Use of type annotations in Python code
MID: 72b5b0c925cf4ef49749b7e466675df1
UID: SDOC-SRS-41
STATUS: Active
STATEMENT:

StrictDoc's development shall ensure a use of type annotations throughout the project's Python codebase.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Linting

15.6. Linting

MID: 61e87567580045378d970b327d218cac
UID: SECTION-SRS-Linting
SDOC-SRS-42
15.6.1. Compliance with Python community practices (PEP8 etc)
MID: 6c0163c56ade49faa353ec06cbd676cd
UID: SDOC-SRS-42
STATUS: Active
STATEMENT:

StrictDoc's development shall ensure that the project's codebase is compliant with the Python community's modern practices.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Static-analysis

15.7. Static analysis

MID: 3029f97a1276499dbbd5d7c71691908e
UID: SECTION-SRS-Static-analysis
SDOC-SRS-43
15.7.1. Static type checking
MID: 2cc9b494ca6248058b6bf63b6e2c1cfa
UID: SDOC-SRS-43
STATUS: Active
STATEMENT:

StrictDoc's development shall include a continuous type checking of StrictDoc's codebase.
RELATIONS (Parent): RELATIONS (File):
SECTION-SRS-Testing

15.8. Testing

MID: 3aba8ca86d404ba9a063ce125489f35b
UID: SECTION-SRS-Testing
SDOC-SRS-44
15.8.1. Unit testing
MID: 2731c64ab32146eeb4b8167df4a34540
UID: SDOC-SRS-44
STATUS: Active
STATEMENT:

StrictDoc's development shall provide unit testing of its codebase.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-45
15.8.2. CLI interface black-box integration testing
MID: 70ef3986cfc4437bbb10288d3b55958c
UID: SDOC-SRS-45
STATUS: Active
STATEMENT:

StrictDoc's development shall provide complete black-box integration testing of its command-line interface.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-46
15.8.3. Web end-to-end testing
MID: a42c65f1a53b4c9bb50bc2a1ecb855cb
UID: SDOC-SRS-46
STATUS: Active
STATEMENT:

StrictDoc's development shall provide complete end-to-end testing of the web interface.
RELATIONS (Parent): RELATIONS (File):
SDOC-SRS-47
15.8.4. At least one integration or end-to-end test
MID: c90f35ab9a7f4c29a418557151878b9f
UID: SDOC-SRS-47
STATUS: Active
STATEMENT:

Every update to the StrictDoc codebase shall be complemented with a corresponding provision of at least one test as follows:

  • For web interface: at least one end-to-end test.
  • For command-line interface: at least one black-box integration test.
  • For internal Python functions: at least one unit test.

NOTE: This requirement implies that no modifications to StrictDoc's functionality can be merged unless accompanied by at least one test.
RATIONALE:

This requirement ensures that every new feature or a chance in the codebase is covered/stressed by at least one test, according to the change type.
RELATIONS (Parent):

16. Code hosting and distribution

MID: 83bdb9731e78431cb48d584d279443b4
SECTION-SRS-Code-hosting

16.1. Code hosting

MID: dbd186fae9624fd6af8aeb55edfaa43b
UID: SECTION-SRS-Code-hosting
SDOC-SRS-12
16.1.1. GitHub
MID: b112c60bc2f34114ab1f3361a1a10a00
UID: SDOC-SRS-12
STATUS: Active
STATEMENT:

StrictDoc's source code shall be hosted on GitHub.
RELATIONS (Parent):
SDOC-SRS-118
16.2. StrictDoc license
MID: bd949cbbe07c4cb29492ea0c8e5c1eec
UID: SDOC-SRS-118
STATUS: Active
STATEMENT:

All StrictDoc software shall be licensed under the Apache 2 license.
RELATIONS (Parent): RELATIONS (File):