StrictDoc Documentation
StrictDoc High-Level Requirements (L2)

1. SDoc data model
  • SDOC-SSS-88
    12.1. Text files for storing documentation and requirements SDOC-SSS-88

    The Requirements Tool shall allow storage of documentation and requirements content using text files.
  • SDOC-SSS-58
    6.2. ReqIF export/import SDOC-SSS-58

    The Requirements Tool shall support exporting/importing requirements content from/to ReqIF format.
    • ZEP-6
      6. ReqIF export ZEP-6

      Requirements specification shall be exportable to ReqIF.
SDOC-SRS-18
1.1. Data model SDOC-SRS-18

StrictDoc shall be based on a data model.
  • SDOC-SSS-4
    3.1. Requirements CRUD SDOC-SSS-4

    The Requirements Tool shall enable the main requirements management operations:

    • Create a requirement
    • Read / view / browse a requirement
    • Update / edit a requirement
    • Delete a requirement.
SDOC-SRS-26
1.2. Requirement model SDOC-SRS-26

StrictDoc's data model shall support modeling requirements.
  • SDOC-SSS-62
    3.3. Custom fields SDOC-SSS-62

    The requirements tool shall support configuring a requirement item with an arbitrary set of fields.

    NOTE: Examples of typical fields include: UID, Title, Statement, Rationale, Comment. Other fields that are used very often are: Status, Tags, Criticality level, Priority, etc.
    • ZEP-3
      3. Custom fields ZEP-3

      Requiremements objects shall be configurable to create several types with a number of custom fields.
SDOC-SRS-100
1.3. Requirement model fields SDOC-SRS-100

StrictDoc's "Requirement" model shall support configurable fields system.
  • SDOC-SSS-61
    3.2. Minimal requirement field set SDOC-SSS-61

    The Requirements Tool shall support at least the following requirement field set:

    • UID
    • STATUS
    • TITLE
    • STATEMENT
    • RATIONALE
    • COMMENT
    • RELATIONS (connections with other requirements).
    • ZEP-10
      10. Minimal requirement field set ZEP-10

      A requirements object shall at least comprise the following fields (or similar):

      • title
      • ID
      • Description
      • Status
      • Outbound links
      • Inbound links (optional?)
    • ZEP-14
      14. Status field ZEP-14

      Each requirements object type shall have a configurable status workflow.
SDOC-SRS-132
1.4. Requirement model default fields SDOC-SRS-132

By default, the Requirement shall support the following fields:

  • MID
  • UID
  • STATUS
  • TITLE
  • STATEMENT
  • RATIONALE
  • COMMENT.
  • SDOC-SSS-64
    3.4. Structuring requirements in documents SDOC-SSS-64

    The Requirements Tool shall support structuring requirements in documents.
    • ZEP-13
      13. Structuring requirements in documents ZEP-13

      Requirements objects shall be structurable in a document like manner (with requirements ordering, and organized in chapters).
SDOC-SRS-98
1.5. Document model SDOC-SRS-98

StrictDoc's data model shall support modeling documents.
  • SDOC-SSS-53
    2.5. Document meta information (UID, version, authors, signatures, etc) SDOC-SSS-53

    The Requirements Tool shall support management of document meta information.
  • SDOC-SSS-75
    2.6. Document versioning SDOC-SSS-75

    The Requirements Tool shall provide capabilities for document versioning.
SDOC-SRS-110
1.6. Document metadata SDOC-SRS-110

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

  • UID
  • Document version
  • Document classification
  • Document authors.
  • SDOC-SSS-53
    2.5. Document meta information (UID, version, authors, signatures, etc) SDOC-SSS-53

    The Requirements Tool shall support management of document meta information.
  • SDOC-SSS-75
    2.6. Document versioning SDOC-SSS-75

    The Requirements Tool shall provide capabilities for document versioning.
SDOC-SRS-151
1.7. Document configuration SDOC-SRS-151

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.
  • SDOC-SSS-51
    2.3. Documents with nested sections/chapters structure SDOC-SSS-51

    The Requirements Tool shall allow management of documents with nested sections/chapters structure.
SDOC-SRS-99
1.8. Section model SDOC-SRS-99

StrictDoc's data model shall support a concept of a "Section" which nests other Sections, Requirements, Texts.
  • SDOC-SSS-3
    2.1. Documents (CRUD) SDOC-SSS-3

    The Requirements Tool shall provide the CRUD operations for document management:

    • Create document
    • Read document
    • Update document
    • Delete document.
SDOC-SRS-135
1.9. Free text SDOC-SRS-135

StrictDoc's data model shall support a "Free Text" model, representing non-normative documentation content.
  • SDOC-SSS-52
    2.4. Assembling documents from fragments SDOC-SSS-52

    The Requirements Tool shall allow composing documents from other documents or fragments.

    NOTE: If a Requirements Tool implements stores documents in a file system, the composition can be arranged at a file level when a parent document file includes the child fragment files and produces a composite document.
    • ZEP-1
      1. Multiple files / include mechanism ZEP-1

      Requirements or groups of requirements shall be distributable over several files and still form a full specification (document) via some kind of include mechanism.
  • DO178-4
    1.5. Document fragments in separate files DO178-4

    StrictDoc shall support assembly of documents from multiple files.
SDOC-SRS-109
1.10. Composeable document SDOC-SRS-109

StrictDoc's data model shall allow composing a Document from other Documents.
  • SDOC-SSS-7
    3.8. Link requirements together SDOC-SSS-7

    The Requirements Tool shall allow bi-directional linking of requirements nodes together using Parent or Child relations.
    • ZEP-4
      4. Links ZEP-4

      Linking shall in general be supported between any requirement object of any object type in a 1:n manner.
  • SDOC-SSS-48
    4.4. Compliance matrices SDOC-SSS-48

    The Requirements Tool shall allow generating a Compliance Matrix document.
SDOC-SRS-31
1.11. Requirement relations SDOC-SRS-31

The StrictDoc data model shall support connecting requirements using Parent and Child relations.
  • SDOC-SSS-8
    3.9. Multiple link roles SDOC-SSS-8

    The Requirements Tool shall support the link roles.

    Example of roles for a child-to-parent link: "verifies", "implements", "satisfies", etc.
    • ZEP-5
      5. Multiple link roles ZEP-5

      Links shall be configurable to create multiple link roles.
SDOC-SRS-101
1.12. Requirement relation roles SDOC-SRS-101

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

NOTE: A relation role is a string value. Typical examples: "refines", "verifies", "implements".
SDOC-SRS-149
1.13. Inline links SDOC-SRS-149

StrictDoc shall support referencing any node by embedding a hyperlink within the text content of another node.
SDOC-SRS-150
1.14. Inline anchors SDOC-SRS-150

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.

2. SDoc text markup
  • SDOC-SSS-88
    12.1. Text files for storing documentation and requirements SDOC-SSS-88

    The Requirements Tool shall allow storage of documentation and requirements content using text files.
SDOC-SRS-20
2.1. SDoc markup language SDOC-SRS-20

StrictDoc shall implement its own text markup language called S-Doc (strict-doc).
  • SDOC-SSS-94
    9.1. Data integrity of documentation/requirements SDOC-SSS-94

    The Requirements Tool shall ensure the integrity of stored documentation and requirements data throughout its lifecycle.
SDOC-SRS-136
2.2. Identical SDoc content by import/export roundtrip SDOC-SRS-136

StrictDoc shall ensure that identical SDoc content is produced every time StrictDoc reads an SDoc file and then writes it to another SDoc file.
  • SDOC-SSS-87
    10.10. Programmatic access to requirements data SDOC-SSS-87

    The Requirements Tool shall provide programmatic access to requirements data.
  • SDOC-SSS-33
    11.5. Version control (Git) SDOC-SSS-33

    The Requirements Tool shall support the software version control systems (e.g., Git).
  • SDOC-SSS-84
    10.7. Requirements database SDOC-SSS-84

    The Requirements Tool shall store documentation and requirements data in a database.
  • SDOC-SSS-94
    9.1. Data integrity of documentation/requirements SDOC-SSS-94

    The Requirements Tool shall ensure the integrity of stored documentation and requirements data throughout its lifecycle.
SDOC-SRS-127
2.3. SDoc and Git storage SDOC-SRS-127

StrictDoc shall assume and implement capabilities for storage of SDoc files using Git version control system.
  • SDOC-SSS-80
    10.3. Easy user experience SDOC-SSS-80

    The Requirements Tool shall provide a smooth user experience.

    NOTE: Documentation and requirements management are composite activities that consist of several types of repetitive tasks. A requirements tool user experience should assist in automating these tasks as far as possible and make the overall workflow efficient and precise.
SDOC-SRS-104
2.4. SDoc file extension SDOC-SRS-104

The SDoc markup content shall be stored in files with .sdoc extension.
  • SDOC-SSS-64
    3.4. Structuring requirements in documents SDOC-SSS-64

    The Requirements Tool shall support structuring requirements in documents.
    • ZEP-13
      13. Structuring requirements in documents ZEP-13

      Requirements objects shall be structurable in a document like manner (with requirements ordering, and organized in chapters).
  • DO178-1
    1.1. Document concept DO178-1

    StrictDoc shall store requirements in document files.
SDOC-SRS-105
2.5. One document per one SDoc file SDOC-SRS-105

StrictDoc's SDoc file shall represent content of a single document.
  • DO178-2
    1.2. Strict specified grammar DO178-2

    StrictDoc shall feature a specified document grammar.
  • SDOC-SSS-55
    12.2. Strict text language syntax SDOC-SSS-55

    The Requirements Tool shall provide a strict syntax for its text language.
  • SDOC-SSS-54
    12.3. Machine-readable format SDOC-SSS-54

    The Requirement Tool's text language shall be machine-readable.
    • ZEP-2
      2. Clear separation of requirements (machine-readable) ZEP-2

      Requirements objects shall be clearly separated from each other, also when organized in the same file.
  • SDOC-SSS-94
    9.1. Data integrity of documentation/requirements SDOC-SSS-94

    The Requirements Tool shall ensure the integrity of stored documentation and requirements data throughout its lifecycle.
SDOC-SRS-19
2.6. Fixed grammar SDOC-SRS-19

StrictDoc's markup language shall be based on a well-defined grammar.
  • SDOC-SSS-61
    3.2. Minimal requirement field set SDOC-SSS-61

    The Requirements Tool shall support at least the following requirement field set:

    • UID
    • STATUS
    • TITLE
    • STATEMENT
    • RATIONALE
    • COMMENT
    • RELATIONS (connections with other requirements).
    • ZEP-10
      10. Minimal requirement field set ZEP-10

      A requirements object shall at least comprise the following fields (or similar):

      • title
      • ID
      • Description
      • Status
      • Outbound links
      • Inbound links (optional?)
    • ZEP-14
      14. Status field ZEP-14

      Each requirements object type shall have a configurable status workflow.
SDOC-SRS-93
2.7. Default grammar fields SDOC-SRS-93

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

  • UID
  • STATUS
  • TITLE
  • STATEMENT
  • RATIONALE
  • COMMENT
  • RELATIONS (references to other requirements)
  • SDOC-SSS-62
    3.3. Custom fields SDOC-SSS-62

    The requirements tool shall support configuring a requirement item with an arbitrary set of fields.

    NOTE: Examples of typical fields include: UID, Title, Statement, Rationale, Comment. Other fields that are used very often are: Status, Tags, Criticality level, Priority, etc.
    • ZEP-3
      3. Custom fields ZEP-3

      Requiremements objects shall be configurable to create several types with a number of custom fields.
SDOC-SRS-21
2.8. Custom grammar / fields SDOC-SRS-21

The SDoc markup shall support custom grammars.
  • DO178-9
    1.11. Project-level grammar DO178-9

    StrictDoc shall support creation of a project-level grammar.
  • SDOC-SSS-52
    2.4. Assembling documents from fragments SDOC-SSS-52

    The Requirements Tool shall allow composing documents from other documents or fragments.

    NOTE: If a Requirements Tool implements stores documents in a file system, the composition can be arranged at a file level when a parent document file includes the child fragment files and produces a composite document.
    • ZEP-1
      1. Multiple files / include mechanism ZEP-1

      Requirements or groups of requirements shall be distributable over several files and still form a full specification (document) via some kind of include mechanism.
SDOC-SRS-122
2.9. Importable grammars SDOC-SRS-122

StrictDoc shall support an inclusion of a grammar stored in a separate file.
  • SDOC-SSS-89
    3.11. Unique identification of requirements SDOC-SSS-89

    The Requirements Tool shall provide means for unique identification of every requirement.
SDOC-SRS-22
2.10. UID identifier format SDOC-SRS-22

The SDoc markup shall only accept UID identifiers that consist of alphanumeric characters separated by a limited set of ("_", "-", ".") characters (TBD).
  • SDOC-SSS-63
    2.7. Text formatting capabilities SDOC-SSS-63

    The Requirements Tool shall provide "rich text" formatting capabilities which includes but not limited to:

    • Headings
    • Lists
    • Tables
    • UML diagrams
    • etc.
    • ZEP-9
      9. Text formatting capabilities ZEP-9

      The description field shall allow for formatting such as:

      • lists
      • tables
      • headings
      • UML diagrams
      • etc.
SDOC-SRS-24
2.11. Format-specific markup-to-HTML fragment writers SDOC-SRS-24

StrictDoc shall render supported markup formats (at least RST and Markdown) to HTML fragments via dedicated format-specific writers selected by markup type.
  • SDOC-SSS-63
    2.7. Text formatting capabilities SDOC-SSS-63

    The Requirements Tool shall provide "rich text" formatting capabilities which includes but not limited to:

    • Headings
    • Lists
    • Tables
    • UML diagrams
    • etc.
    • ZEP-9
      9. Text formatting capabilities ZEP-9

      The description field shall allow for formatting such as:

      • lists
      • tables
      • headings
      • UML diagrams
      • etc.
SDOC-SRS-27
2.12. MathJAX SDOC-SRS-27

StrictDoc's markup language shall support integration with MathJax.
  • SDOC-SSS-55
    12.2. Strict text language syntax SDOC-SSS-55

    The Requirements Tool shall provide a strict syntax for its text language.
SDOC-SRS-23
2.13. No indentation SDOC-SRS-23

SDoc text markup blocks shall all start from column 1, i.e., the nesting of the blocks is not allowed.
  • SDOC-SSS-55
    12.2. Strict text language syntax SDOC-SSS-55

    The Requirements Tool shall provide a strict syntax for its text language.
  • SDOC-SSS-94
    9.1. Data integrity of documentation/requirements SDOC-SSS-94

    The Requirements Tool shall ensure the integrity of stored documentation and requirements data throughout its lifecycle.
SDOC-SRS-25
2.14. Type-safe fields SDOC-SRS-25

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.

3. Markdown markup
SDOC-SRS-202
3.1. Markdown support SDOC-SRS-202

StrictDoc shall support Markdown markup.
  • SDOC-LLR-183
    1.1. Read Markdown markup SDOC-LLR-183

    StrictDoc shall support reading Markdown files into in-memory SDoc documents.
  • SDOC-LLR-197
    1.2. Write Markdown markup SDOC-LLR-197

    StrictDoc shall support writing in-memory SDoc documents to Markdown files.
  • SDOC-LLR-192
    1.3. Markdown files discovery SDOC-LLR-192

    StrictDoc shall discover Markdown files *.md and *.markdown using the same mechanism as used for SDoc files.
SECTION-SRS-Graph-database

4. Graph database

 SECTION-SRS-Graph-database
  • SDOC-SSS-7
    3.8. Link requirements together SDOC-SSS-7

    The Requirements Tool shall allow bi-directional linking of requirements nodes together using Parent or Child relations.
    • ZEP-4
      4. Links ZEP-4

      Linking shall in general be supported between any requirement object of any object type in a 1:n manner.
SDOC-SRS-28
4.1. Traceability index SDOC-SRS-28

StrictDoc shall maintain a complete Traceability Index of all documentation- and requirements-related information available in a project tree.
  • SDOC-SSS-89
    3.11. Unique identification of requirements SDOC-SSS-89

    The Requirements Tool shall provide means for unique identification of every requirement.
  • SDOC-SSS-94
    9.1. Data integrity of documentation/requirements SDOC-SSS-94

    The Requirements Tool shall ensure the integrity of stored documentation and requirements data throughout its lifecycle.
SDOC-SRS-29
4.2. Uniqueness UID in tree SDOC-SRS-29

For each requirement node, the Traceability Index shall ensure its uniqueness throughout the node's lifecycle.
  • SDOC-SSS-47
    3.12. Requirements database consistency checks SDOC-SSS-47

    The Requirements Tool shall provide a validation mechanism that ensures the integrity of requirements and connections between them.

    NOTE: Examples of integrity checks:

    • Requirements have correct fields.
    • Requirements do not form cycles.
    • Requirements only link to other requirements as specified in a project configuration.
  • SDOC-SSS-94
    9.1. Data integrity of documentation/requirements SDOC-SSS-94

    The Requirements Tool shall ensure the integrity of stored documentation and requirements data throughout its lifecycle.
SDOC-SRS-30
4.3. Detect links cycles SDOC-SRS-30

The Traceability Index shall detect cycles between requirements.
  • SDOC-SSS-47
    3.12. Requirements database consistency checks SDOC-SSS-47

    The Requirements Tool shall provide a validation mechanism that ensures the integrity of requirements and connections between them.

    NOTE: Examples of integrity checks:

    • Requirements have correct fields.
    • Requirements do not form cycles.
    • Requirements only link to other requirements as specified in a project configuration.
  • SDOC-SSS-13
    8.1. Support large requirements sets SDOC-SSS-13

    The Requirements Tool shall support requirement trees with at least 10000 requirements.
  • SDOC-SSS-14
    8.2. Support large project trees SDOC-SSS-14

    The Requirements Tool shall be able to handle documentation packages of at least 100 documents without significant performance degradation.
SDOC-SRS-32
4.4. Link document nodes SDOC-SRS-32

The Traceability Index shall recognize and maintain the relations between all documents of a project tree.
  • SDOC-SSS-71
    3.10. Reverse parent links SDOC-SSS-71

    The Requirements Tool shall support the Reverse Parent relationship.
  • SDOC-SSS-48
    4.4. Compliance matrices SDOC-SSS-48

    The Requirements Tool shall allow generating a Compliance Matrix document.
SDOC-SRS-102
4.5. Automatic resolution of reverse relations SDOC-SRS-102

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.

5. Documentation tree
  • SDOC-SSS-34
    12.4. Requirements data from multiple repositories SDOC-SSS-34

    The Requirement Tool shall allow reading requirements files from multiple folders or repositories.

    NOTE: The folders/repositories can be arbitrarily nested.
  • DO178-3
    1.4. Multiple git repositories document assembly DO178-3

    StrictDoc shall support generating requirement trees from multiple Git repositories.
SDOC-SRS-115
5.1. Finding documents recursively SDOC-SRS-115

StrictDoc shall discover SDoc documents recursively based on a specified input path.
  • SDOC-LLR-192
    1.3. Markdown files discovery SDOC-LLR-192

    StrictDoc shall discover Markdown files *.md and *.markdown using the same mechanism as used for SDoc files.
SECTION-SRS-Web-HTML-frontend

6. Web/HTML frontend

 SECTION-SRS-Web-HTML-frontend
SECTION-SRS-General-export-requirements-2

6.1. General export requirements

 SECTION-SRS-General-export-requirements-2
  • SDOC-SSS-30
    11.1. Static HTML export SDOC-SSS-30

    The Requirements Tool shall support generation of documentation to static HTML.
SDOC-SRS-49
6.1.1. Export to static HTML website SDOC-SRS-49

StrictDoc shall support generating requirements documentation into static HTML.
  • SDOC-SSS-31
    11.2. Graphical user interface (GUI) SDOC-SSS-31

    The Requirements Tool shall provide a graphical user interface.
  • DO178-6
    1.7. Graphical user interface (GUI) DO178-6

    StrictDoc shall support a graphical user interface.
  • SDOC-SSS-79
    10.1. General usability SDOC-SSS-79

    The Requirements Tool shall be accessible to a broad spectrum of users.

    NOTE: Factors to consider:

    • The cost of a tool.
    • The easy of installation.
    • The availability of a graphical user interface.
    • The availability of a programmatic access to the functions of a tool.
    • The interoperability of the tool with other tools.
  • SDOC-SSS-80
    10.3. Easy user experience SDOC-SSS-80

    The Requirements Tool shall provide a smooth user experience.

    NOTE: Documentation and requirements management are composite activities that consist of several types of repetitive tasks. A requirements tool user experience should assist in automating these tasks as far as possible and make the overall workflow efficient and precise.
SDOC-SRS-50
6.1.2. Web interface SDOC-SRS-50

StrictDoc shall provide a web interface.
  • DO178-17
    2.7. Multi-user editing of documents DO178-17

    StrictDoc shall allow multi-user editing of documents.
  • SDOC-SSS-81
    10.4. Support projects with a large number of users SDOC-SSS-81

    The Requirements Tool shall be capable of supporting a large number of users.
SDOC-SRS-123
6.1.3. Multi-user editing of documents SDOC-SRS-123

StrictDoc shall support concurrent use and editing of a single StrictDoc web server instance by multiple users.
  • SDOC-SSS-80
    10.3. Easy user experience SDOC-SSS-80

    The Requirements Tool shall provide a smooth user experience.

    NOTE: Documentation and requirements management are composite activities that consist of several types of repetitive tasks. A requirements tool user experience should assist in automating these tasks as far as possible and make the overall workflow efficient and precise.
SDOC-SRS-48
6.1.4. Preserve generated file names SDOC-SRS-48

For all export operations, StrictDoc shall maintain the original filenames of the documents when producing output files.
SECTION-SRS-Screen-Project-tree

6.2. Screen: Project tree

 SECTION-SRS-Screen-Project-tree
  • SDOC-SSS-91
    2.2. Browsing documentation tree SDOC-SSS-91

    The Requirements Tool shall provide browsing of the documentation tree.
SDOC-SRS-53
6.2.1. View project tree SDOC-SRS-53

StrictDoc's "Project tree" screen shall provide browsing of a documentation project tree.
  • SDOC-SSS-3
    2.1. Documents (CRUD) SDOC-SSS-3

    The Requirements Tool shall provide the CRUD operations for document management:

    • Create document
    • Read document
    • Update document
    • Delete document.
SDOC-SRS-107
6.2.2. Create document SDOC-SRS-107

StrictDoc's Project Tree screen shall allow creating documents.
  • SDOC-SSS-3
    2.1. Documents (CRUD) SDOC-SSS-3

    The Requirements Tool shall provide the CRUD operations for document management:

    • Create document
    • Read document
    • Update document
    • Delete document.
SDOC-SRS-108
6.2.3. Delete document SDOC-SRS-108

StrictDoc's Project Tree screen shall allow deleting documents.
SECTION-SRS-Screen-Document-DOC

6.3. Screen: Document (DOC)

 SECTION-SRS-Screen-Document-DOC
  • SDOC-SSS-3
    2.1. Documents (CRUD) SDOC-SSS-3

    The Requirements Tool shall provide the CRUD operations for document management:

    • Create document
    • Read document
    • Update document
    • Delete document.
SDOC-SRS-201
6.3.1. Format-specific document handling SDOC-SRS-201

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.
  • SDOC-SSS-3
    2.1. Documents (CRUD) SDOC-SSS-3

    The Requirements Tool shall provide the CRUD operations for document management:

    • Create document
    • Read document
    • Update document
    • Delete document.
SDOC-SRS-54
6.3.2. Read document SDOC-SRS-54

StrictDoc's Document screen shall allow reading documents.
  • SDOC-SSS-3
    2.1. Documents (CRUD) SDOC-SSS-3

    The Requirements Tool shall provide the CRUD operations for document management:

    • Create document
    • Read document
    • Update document
    • Delete document.
SDOC-SRS-106
6.3.3. Create node SDOC-SRS-106

StrictDoc's Document screen shall allow creating document nodes.
SDOC-SRS-161
6.3.4. Clone node from existing node SDOC-SRS-161

StrictDoc shall support cloning nodes from existing nodes.
  • SDOC-SSS-4
    3.1. Requirements CRUD SDOC-SSS-4

    The Requirements Tool shall enable the main requirements management operations:

    • Create a requirement
    • Read / view / browse a requirement
    • Update / edit a requirement
    • Delete a requirement.
SDOC-SRS-55
6.3.5. Update node SDOC-SRS-55

StrictDoc's Document screen shall allow update document content.
SDOC-SRS-162
6.3.6. Delete node SDOC-SRS-162

StrictDoc's Document screen shall support the deletion of document nodes.
  • SDOC-SSS-7
    3.8. Link requirements together SDOC-SSS-7

    The Requirements Tool shall allow bi-directional linking of requirements nodes together using Parent or Child relations.
    • ZEP-4
      4. Links ZEP-4

      Linking shall in general be supported between any requirement object of any object type in a 1:n manner.
SDOC-SRS-159
6.3.7. Create node relation SDOC-SRS-159

StrictDoc's Document screen shall creating updating node relations.
  • SDOC-SSS-7
    3.8. Link requirements together SDOC-SSS-7

    The Requirements Tool shall allow bi-directional linking of requirements nodes together using Parent or Child relations.
    • ZEP-4
      4. Links ZEP-4

      Linking shall in general be supported between any requirement object of any object type in a 1:n manner.
SDOC-SRS-158
6.3.8. Update node relation SDOC-SRS-158

StrictDoc's Document screen shall allow updating node relations.
  • SDOC-SSS-5
    3.5. Move requirement nodes within document SDOC-SSS-5

    The Requirements Tool shall allow moving nodes (sections, requirements) within the containing document.
SDOC-SRS-92
6.3.9. Move requirement / section nodes within document SDOC-SRS-92

StrictDoc's Document screen shall provide a capability to move the nodes within a document.
  • SDOC-SSS-62
    3.3. Custom fields SDOC-SSS-62

    The requirements tool shall support configuring a requirement item with an arbitrary set of fields.

    NOTE: Examples of typical fields include: UID, Title, Statement, Rationale, Comment. Other fields that are used very often are: Status, Tags, Criticality level, Priority, etc.
    • ZEP-3
      3. Custom fields ZEP-3

      Requiremements objects shall be configurable to create several types with a number of custom fields.
SDOC-SRS-56
6.3.10. Edit Document grammar SDOC-SRS-56

StrictDoc's screen shall allow editing a document's grammar.
  • SDOC-SSS-93
    7.2. Document-level configuration SDOC-SSS-93

    The Requirements Tool shall provide a solution for configuring the document-level options.

    NOTE: Examples of document-level options:

    • Document title
    • Requirement prefix.
    • Other options local to the content and the presentation of a given document.
SDOC-SRS-57
6.3.11. Edit Document options SDOC-SRS-57

StrictDoc's Document screen shall provide controls for configuring the document-specific options.
  • SDOC-SSS-6
    3.7. Auto-provision of Requirement UIDs SDOC-SSS-6

    The Requirements Tool shall provide controls for automatic generation of requirements UIDs.
    • ZEP-8
      8. Unique ID management ZEP-8

      Requirements objects shall allow unique ID management when adding new requirements on different branches.

      Options could be:

      • UUID: no checking required, but not handy
      • Manually assigned: collision checking required
      • Centralized: when not affected by branching".
  • SDOC-SSS-80
    10.3. Easy user experience SDOC-SSS-80

    The Requirements Tool shall provide a smooth user experience.

    NOTE: Documentation and requirements management are composite activities that consist of several types of repetitive tasks. A requirements tool user experience should assist in automating these tasks as far as possible and make the overall workflow efficient and precise.
SDOC-SRS-96
6.3.12. Auto-generate requirements UIDs SDOC-SRS-96

StrictDoc's Document screen shall provide controls for automatic generation of requirements UIDs.
  • SDOC-SSS-6
    3.7. Auto-provision of Requirement UIDs SDOC-SSS-6

    The Requirements Tool shall provide controls for automatic generation of requirements UIDs.
    • ZEP-8
      8. Unique ID management ZEP-8

      Requirements objects shall allow unique ID management when adding new requirements on different branches.

      Options could be:

      • UUID: no checking required, but not handy
      • Manually assigned: collision checking required
      • Centralized: when not affected by branching".
  • DO178-14
    1.3. Requirement UID autocompletion DO178-14

    StrictDoc shall provide autocompletion feature for requirement UID identifiers.

    Note: Most immediate use case: adding/editing parent requirements.
  • SDOC-SSS-80
    10.3. Easy user experience SDOC-SSS-80

    The Requirements Tool shall provide a smooth user experience.

    NOTE: Documentation and requirements management are composite activities that consist of several types of repetitive tasks. A requirements tool user experience should assist in automating these tasks as far as possible and make the overall workflow efficient and precise.
SDOC-SRS-120
6.3.13. Auto-completion for requirements UIDs SDOC-SRS-120

StrictDoc's Document screen shall provide controls for automatic completion of requirements UIDs.
  • SDOC-SSS-80
    10.3. Easy user experience SDOC-SSS-80

    The Requirements Tool shall provide a smooth user experience.

    NOTE: Documentation and requirements management are composite activities that consist of several types of repetitive tasks. A requirements tool user experience should assist in automating these tasks as far as possible and make the overall workflow efficient and precise.
SDOC-SRS-59
6.3.14. Buttons to copy text to buffer SDOC-SRS-59

StrictDoc shall provide a "copy text to buffer" button for all requirement's text fields.
SECTION-SRS-Screen-Table-TBL

6.4. Screen: Table (TBL)

 SECTION-SRS-Screen-Table-TBL
  • SDOC-SSS-73
    4.1. Excel-like viewing and editing of requirements SDOC-SSS-73

    The Requirements Tool shall provide an Excel-like user interface for viewing and editing requirements.

    NOTE: This interface does not have to be the only or a default interface.
SDOC-SRS-62
6.4.1. View TBL screen SDOC-SRS-62

StrictDoc's Table screen shall allow reading documents in a table-like manner.
SECTION-SRS-Screen-Traceability-TR

6.5. Screen: Traceability (TR)

 SECTION-SRS-Screen-Traceability-TR
  • SDOC-SSS-28
    4.3. Traceability matrices SDOC-SSS-28

    The Requirements Tool shall support generation of traceability matrices.
SDOC-SRS-65
6.5.1. View TR screen SDOC-SRS-65

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.
SECTION-SRS-Screen-Deep-traceability-DTR

6.6. Screen: Deep traceability (DTR)

 SECTION-SRS-Screen-Deep-traceability-DTR
  • DO178-12
    2.5. Uncovered requirement report DO178-12

    StrictDoc shall support generation of uncovered requirement report.

    Note: An uncovered requirement is one that has no children.
SDOC-SRS-66
6.6.1. View DTR screen SDOC-SRS-66

StrictDoc shall provide a deep traceability screen.

6.7. Screen: HTML2PDF
  • DO178-5
    1.6. PDF and HTML publishing DO178-5

    StrictDoc shall support publication of documents to HTML and PDF formats.
  • SDOC-SSS-96
    6.1. PDF export SDOC-SSS-96

    The Requirements Tool shall support exporting documentation content to PDF, both individual documents and complete documentation trees.
SDOC-SRS-51
6.7.1. Export to HTML content to PDF (HTML2PDF) SDOC-SRS-51

StrictDoc shall allow exporting documents and entire documentation trees to PDF.
SDOC-SRS-203
6.7.2. Cross-linking PDF documents from same project tree SDOC-SRS-203

When exporting multiple HTML documents from a same project tree into PDF, StrictDoc shall preserve all cross-document linking in the output PDF documents.
  • SDOC-LLR-204
    2.2. Use of PyPDF for PDF postprocessing SDOC-LLR-204

    StrictDoc shall employ the PyPDF library for the following tasks:

    • Rewriting all StrictDoc's LINK/ANCHOR to documents of the same project tree into the PDF anchors.
  • SDOC-LLR-205
    2.3. Cross-linking PDF documents from one project tree SDOC-LLR-205

    When exporting HTML documents to PDF, StrictDoc shall rewrite all LINK/ANCHOR to documents of the same project tree into the PDF document links/anchors according to the following rule:

    • The Chrome Driver resolves the relative links to other documents with full paths, e.g., file:///<full-path-to-another-SDoc-document>-PDF.html#<anchor>.
    • The PDF postprocessing step shall convert these absolute file:///...` links to just relative paths: ``<relative-path-to-another-SDoc-document>.pdf without the leading slash character.
    • If one PDF is in a nested folder compared to another PDF, the link to this PDF anchor shall have relative ../ path components.
SDOC-SRS-160
6.7.3. Custom PDF export template SDOC-SRS-160

StrictDoc shall support the customization of the PDF export template.

6.8. Screen: Project statistics
  • SDOC-SSS-49
    4.6. Progress report SDOC-SSS-49

    The Requirements Tool shall allow generating a Progress Report document.

    NOTE: A progress report document shall include at least the following Key Performance Indicators.

    Project-level KPIs:

    • Total number of requirements
    • Total number of requirements without parent (excluding top-level and derived)
    • Total number of TBD/TBC
    • Total number of requirements without rationale
    • Tags breakdown

    Document-level KPIs: the same but per document.
  • DO178-12
    2.5. Uncovered requirement report DO178-12

    StrictDoc shall support generation of uncovered requirement report.

    Note: An uncovered requirement is one that has no children.
  • SDOC-SSS-29
    4.5. Requirements coverage SDOC-SSS-29

    The Requirements Tool shall provide means for getting information about the requirements coverage of a given project.

    NOTE: The requirements coverage can be presented in a tabular form or visualized with a set of graphs.
SDOC-SRS-97
6.8.1. Display project statistics SDOC-SRS-97

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.
  • SDOC-SSS-49
    4.6. Progress report SDOC-SSS-49

    The Requirements Tool shall allow generating a Progress Report document.

    NOTE: A progress report document shall include at least the following Key Performance Indicators.

    Project-level KPIs:

    • Total number of requirements
    • Total number of requirements without parent (excluding top-level and derived)
    • Total number of TBD/TBC
    • Total number of requirements without rationale
    • Tags breakdown

    Document-level KPIs: the same but per document.
SDOC-SRS-154
6.8.2. Support for user-provided custom statistics generators SDOC-SRS-154

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

6.9. Screen: Document tree map
  • SDOC-SSS-29
    4.5. Requirements coverage SDOC-SSS-29

    The Requirements Tool shall provide means for getting information about the requirements coverage of a given project.

    NOTE: The requirements coverage can be presented in a tabular form or visualized with a set of graphs.
SDOC-SRS-157
6.9.1. Tree map SDOC-SRS-157

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

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

6.10. Screen: Source coverage
  • SDOC-SSS-72
    5.1. Traceability between requirements and source code SDOC-SSS-72

    The Requirements Tool shall support bi-directional tracing between requirements content and implementation source code with only minimal changes needed in the source code.

    NOTE: The Requirements Tool does not necessarily have to implement the complete tracing process. It may delegate parts of the traceability task to other tools, e.g., Doxygen, Lobster, etc.
    • ZEP-11
      11. Requirements to source code traceability ZEP-11

      Linking from requirements objects to code or from code to requirements objects via ID shall be supported.
    • ZEP-12
      12. Non-intrusive links in source code ZEP-12

      Linking from code to requirements objects via ID shall be least code intrusive.
  • DO178-13
    1.10. Source file coverage DO178-13

    StrictDoc shall support generation of source code coverage information.
SDOC-SRS-35
6.10.1. Project source code coverage SDOC-SRS-35

StrictDoc shall generate project source code coverage information.

NOTE: Source code information can be visualized using both web or CLI interfaces.

6.11. Screen: Single source file coverage
  • SDOC-SSS-72
    5.1. Traceability between requirements and source code SDOC-SSS-72

    The Requirements Tool shall support bi-directional tracing between requirements content and implementation source code with only minimal changes needed in the source code.

    NOTE: The Requirements Tool does not necessarily have to implement the complete tracing process. It may delegate parts of the traceability task to other tools, e.g., Doxygen, Lobster, etc.
    • ZEP-11
      11. Requirements to source code traceability ZEP-11

      Linking from requirements objects to code or from code to requirements objects via ID shall be supported.
    • ZEP-12
      12. Non-intrusive links in source code ZEP-12

      Linking from code to requirements objects via ID shall be least code intrusive.
SDOC-SRS-36
6.11.1. Single source file coverage SDOC-SRS-36

StrictDoc shall generate single file traceability information.

6.12. Screen: Traceability matrix
  • SDOC-SSS-28
    4.3. Traceability matrices SDOC-SSS-28

    The Requirements Tool shall support generation of traceability matrices.
  • DO178-10
    2.3. Traceability matrices DO178-10

    StrictDoc shall support generation of forward and backward traceability matrices.
  • DO178-12
    2.5. Uncovered requirement report DO178-12

    StrictDoc shall support generation of uncovered requirement report.

    Note: An uncovered requirement is one that has no children.
SDOC-SRS-112
6.12.1. Traceability matrix SDOC-SRS-112

StrictDoc shall provide a traceability matrix screen.

6.13. Screen: Project tree diff
  • SDOC-SSS-75
    2.6. Document versioning SDOC-SSS-75

    The Requirements Tool shall provide capabilities for document versioning.
  • SDOC-SSS-74
    4.7. Change management SDOC-SSS-74

    The Requirements Tool shall provide capabilities for change management:

    • Visualizing changes between project tree versions.
    • Visualizing changes between document versions.
    • Visualizing the impact that a changed requirement has on a project tree.
  • DO178-15
    2.2. Diff between document trees DO178-15

    StrictDoc shall allow calculating Diff between two document trees.

    Note: The primary use case is calculating a diff between two Git revisions.
SDOC-SRS-111
6.13.1. Project tree diff SDOC-SRS-111

StrictDoc shall provide a project tree diff screen.

6.14. Content search
  • SDOC-SSS-95
    2.8. Content search SDOC-SSS-95

    The Requirements Tool shall provide functionality to search content in the documentation tree.
SDOC-SRS-155
6.14.1. Content search SDOC-SRS-155

StrictDoc shall provide searching documentation content with queries via a search bar.
  • SDOC-SRS-156
    6.1. Static HTML search SDOC-SRS-156

    The static HTML search is implemented using a custom JavaScript solution that consumes a search index JS file generated by the same StrictDoc Python pipeline that produces all other artifacts.

    The following requirements are relevant in the StrictDoc context:

    • The JS library must start up quickly, so search indexes need to be generated in advance. Since StrictDoc is based on Python, index generation must be done in Python rather than in JS/NPM.
    • The Python code must generate indexes incrementally and allow caching, e.g., one index per document.
    • The JS library must support matching search terms using OR by default and AND when the terms are enclosed in quotes, e.g., "foo bar".
    • The JS library must support incremental and decremental search terms.

    Several existing solutions, such as Lunr and FlexSearch, were considered, but none were found to support all of the above features.

    Note

    Incremental/decremental search means that a search index maintains the following additional terms for a word "foo" found in a document node with MID "abc":

    • "foo" => "abc"
    • "f" => "abc"
    • "fo" => "abc"
    • "o" => "abc"
    • "oo" => "abc"

    The current implementation builds per-document indexes immediately after parsing the SDoc documents from .sdoc files. The generated index is cached along with the overall document content, significantly speeding up tree generation once the document caches are available. StrictDoc generates a JSON file containing a search index { search term => node MID } as well as a map { MID => SDoc node }.

    The corresponding JS file has access to the pre-built search indexes generated by Python. The JavaScript algorithms are simple but enable basic search functionality:

    • Incremental/decremental search for terms using OR when multiple terms are provided without quotes, and AND when the terms are quoted. Currently, only one quoted search term is supported.
    • The algorithm is reasonably fast and has been tested with documentation trees of up to 130+ documents with the largest documents reaching up to 1.5 megabytes.
SECTION-SRS-Requirements-to-source-traceability

7. Requirements-to-source traceability

 SECTION-SRS-Requirements-to-source-traceability
  • SDOC-SSS-72
    5.1. Traceability between requirements and source code SDOC-SSS-72

    The Requirements Tool shall support bi-directional tracing between requirements content and implementation source code with only minimal changes needed in the source code.

    NOTE: The Requirements Tool does not necessarily have to implement the complete tracing process. It may delegate parts of the traceability task to other tools, e.g., Doxygen, Lobster, etc.
    • ZEP-11
      11. Requirements to source code traceability ZEP-11

      Linking from requirements objects to code or from code to requirements objects via ID shall be supported.
    • ZEP-12
      12. Non-intrusive links in source code ZEP-12

      Linking from code to requirements objects via ID shall be least code intrusive.
SDOC-SRS-33
7.1. Link requirements with source files SDOC-SRS-33

StrictDoc shall support bi-directional linking requirements with source files.

7.2. Language-aware parsing of source code
SDOC-SRS-142
7.2.1. Language-aware parsing of source code SDOC-SRS-142

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.
SDOC-SRS-146
7.2.2. Language-aware parsing of C/C++ code SDOC-SRS-146

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

  • Recognizing functions and their Doxygen comments.
  • Recognizing function declarations and function definitions.
SDOC-SRS-147
7.2.3. Language-aware parsing of Python code SDOC-SRS-147

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.
SDOC-SRS-204
7.2.4. Language-aware parsing of Rust code SDOC-SRS-204

StrictDoc shall support parsing the Rust source files.
  • SDOC-LLR-164
    3.1.1. Auto-scoped relation markers in Rust docs SDOC-LLR-164

    If a StrictDoc relation marker is inside a Rust doc comment, the marker scope shall be set to exact the item the Rust language defines as target of the containing doc comment. The @relation(scope=...) parameter shall therefore be optional and shall be ignored if provided.

    1 /// @relation(REQ-1)
2 impl Foo {
3 
4     /// @relation(REQ-2)
5     fn foo() {
6     }
7 }

    In the given example, the first marker shall link REQ-1 to the impl Foo implementation, highlighting lines 1 to 7. The second marker shall link REQ-2 to the fn foo() function, highlighting lines 4 to 6.
  • SDOC-LLR-165
    3.1.2. Inner doc attributes SDOC-LLR-165

    StrictDoc shall support relation markers in inner doc attribute s.
  • SDOC-LLR-166
    3.1.3. Inner line docs SDOC-LLR-166

    StrictDoc shall support auto-scoped relation relation markers in inner line docs.
  • SDOC-LLR-167
    3.1.4. Inner block docs SDOC-LLR-167

    StrictDoc shall support auto-scoped relation relation markers in inner block docs.
  • SDOC-LLR-168
    3.1.5. Outer doc attributes SDOC-LLR-168

    StrictDoc shall support auto-scoped relation markers in outer doc attribute s.
  • SDOC-LLR-169
    3.1.6. Outer line docs SDOC-LLR-169

    StrictDoc shall support auto-scoped relation markers in outer line docs.
  • SDOC-LLR-170
    3.1.7. Outer block docs SDOC-LLR-170

    StrictDoc shall support auto-scoped relation markers in outer block docs.
  • SDOC-LLR-171
    3.1.8. File, line and range markers SDOC-LLR-171

    StrictDoc shall point to lines and line ranges of Rust code by using file, line and range markers. These marker types shall be parsed from regular line and block comments.

    Note: File markers may also result from the inner doc comments of the top-level module.
  • SDOC-LLR-172
    3.1.9. Source nodes from doc comments SDOC-LLR-172

    If a Rust doc comments contains custom tags, and the containing Rust source file matches an entry in the source node configuration, StrictDoc shall create document nodes from the custom tags and automatically link the created node with the Rust item targeted by the doc comment.
  • SDOC-LLR-173
    3.1.10. Forward relations to Rust items SDOC-LLR-173

    StrictDoc shall support linking from a requirement in SDoc to a language item in Rust code by using a FILE relation of type FUNCTION. For example

    [REQUIREMENT]
UID: REQ-1
RELATIONS:
- TYPE: File
  VALUE: file.rs
  FUNCTION: file::foo

    This shall work for all kinds of Rust items that have a canonical path, including const, enum, fn, mod, static, struct, trait, type, union.
  • SDOC-LLR-174
    3.1.11. Forward relation by canonical path SDOC-LLR-174

    The identifier for forward relations shall be the canonical path as the rustc compiler would set it when invoked for a single file like

    rustc --crate-type rlib --emit=obj src/lib.rs

    Note: cargo build usually result in a different canonical path, since it considers the file position relative to the crate root. Using a single file as root is a simplification, needed because StrictDoc is unaware of the Rust file and directory-based module hierarchy.
  • SDOC-LLR-175
    3.1.12. Collapse doc comments SDOC-LLR-175

    Multiple scattered doc comments shall be collapsed as done by the rustdoc tool when using the collapse-docs option to determine the highlight range(s).

    For example, rustdoc would collapse alle these comments into the description of fn foo()

     1 /// Some
 2 /// line
 3 
 4 /// doc,
 5 
 6 /**
 7   * and some
 8   * block dock,
 9   */
10 
11 #[doc = "and some"]
12 
13 #[doc = "doc attr."]
14 
15 fn foo() {
16 }

    In the given example, the StrictDoc highlight range for the relation marker shall be from line 1 to line 16.
  • SDOC-LLR-176
    3.1.13. Rust marker descriptions SDOC-LLR-176

    StrictDoc should use the marker labels as rustdoc would set them in the description of a documented node.
  • SDOC-LLR-177
    3.1.14. Valid positions of doc comments SDOC-LLR-177

    StrictDoc shall find doc comments where the language allows them and ignore those in other positions.
  • SDOC-LLR-178
    3.1.15. Inner doc comments for functions SDOC-LLR-178

    StrictDoc shall find inner doc comments in function blocks.
  • SDOC-LLR-179
    3.1.16. Inner doc comments for modules SDOC-LLR-179

    StrictDoc shall find inner doc comments in module blocks.
  • SDOC-LLR-180
    3.1.17. Inner doc comments for external blocks SDOC-LLR-180

    StrictDoc shall find inner doc comments in external blocks.
  • SDOC-LLR-181
    3.1.18. Inner doc comments for implementation blocks SDOC-LLR-181

    StrictDoc shall find inner doc comments in implementation blocks.
  • SDOC-LLR-182
    3.1.19. Allowed position for outer docs SDOC-LLR-182

    StrictDoc shall find outer doc comments in allowed positions as specified by the Rust language:

    • All item declarations
    • Most statements
    • Block expressions, but only when they are the outer expression of an expression statement or the final expression of another block expression.
    • Enum variants, struct and union fields
    • Generic lifetime or type parameter
    • Expressions in limited situations
    • Function, closure and function pointer parameters
SDOC-SRS-148
7.2.5. Language-aware parsing of Robot framework code SDOC-SRS-148

StrictDoc shall support parsing the Robot framework test files.
SDOC-SRS-143
7.3. Link requirements with test files and test reports SDOC-SRS-143

StrictDoc shall support bi-directional linking between requirements, test files, and test reports.
SDOC-SRS-144
7.4. Link requirements with code coverage information SDOC-SRS-144

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

7.5. Forward linking from requirements to source code
SDOC-SRS-145
7.5.1. SDoc markup's forward relations SDOC-SRS-145

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

7.6. Source code markup – Relations
  • SDOC-SSS-72
    5.1. Traceability between requirements and source code SDOC-SSS-72

    The Requirements Tool shall support bi-directional tracing between requirements content and implementation source code with only minimal changes needed in the source code.

    NOTE: The Requirements Tool does not necessarily have to implement the complete tracing process. It may delegate parts of the traceability task to other tools, e.g., Doxygen, Lobster, etc.
    • ZEP-11
      11. Requirements to source code traceability ZEP-11

      Linking from requirements objects to code or from code to requirements objects via ID shall be supported.
    • ZEP-12
      12. Non-intrusive links in source code ZEP-12

      Linking from code to requirements objects via ID shall be least code intrusive.
SDOC-SRS-34
7.6.1. Relation markers syntax SDOC-SRS-34

StrictDoc shall support annotating source code with links that reference the requirements.
  • SDOC-LLR-164
    3.1.1. Auto-scoped relation markers in Rust docs SDOC-LLR-164

    If a StrictDoc relation marker is inside a Rust doc comment, the marker scope shall be set to exact the item the Rust language defines as target of the containing doc comment. The @relation(scope=...) parameter shall therefore be optional and shall be ignored if provided.

    1 /// @relation(REQ-1)
2 impl Foo {
3 
4     /// @relation(REQ-2)
5     fn foo() {
6     }
7 }

    In the given example, the first marker shall link REQ-1 to the impl Foo implementation, highlighting lines 1 to 7. The second marker shall link REQ-2 to the fn foo() function, highlighting lines 4 to 6.
  • SDOC-SSS-72
    5.1. Traceability between requirements and source code SDOC-SSS-72

    The Requirements Tool shall support bi-directional tracing between requirements content and implementation source code with only minimal changes needed in the source code.

    NOTE: The Requirements Tool does not necessarily have to implement the complete tracing process. It may delegate parts of the traceability task to other tools, e.g., Doxygen, Lobster, etc.
    • ZEP-11
      11. Requirements to source code traceability ZEP-11

      Linking from requirements objects to code or from code to requirements objects via ID shall be supported.
    • ZEP-12
      12. Non-intrusive links in source code ZEP-12

      Linking from code to requirements objects via ID shall be least code intrusive.
SDOC-SRS-124
7.6.2. Line marker SDOC-SRS-124

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.
  • SDOC-LLR-171
    3.1.8. File, line and range markers SDOC-LLR-171

    StrictDoc shall point to lines and line ranges of Rust code by using file, line and range markers. These marker types shall be parsed from regular line and block comments.

    Note: File markers may also result from the inner doc comments of the top-level module.
  • SDOC-SSS-72
    5.1. Traceability between requirements and source code SDOC-SSS-72

    The Requirements Tool shall support bi-directional tracing between requirements content and implementation source code with only minimal changes needed in the source code.

    NOTE: The Requirements Tool does not necessarily have to implement the complete tracing process. It may delegate parts of the traceability task to other tools, e.g., Doxygen, Lobster, etc.
    • ZEP-11
      11. Requirements to source code traceability ZEP-11

      Linking from requirements objects to code or from code to requirements objects via ID shall be supported.
    • ZEP-12
      12. Non-intrusive links in source code ZEP-12

      Linking from code to requirements objects via ID shall be least code intrusive.
SDOC-SRS-137
Incoming link from: 1.16. Support for file relations
1
 7.6.3. Language element marker SDOC-SRS-137

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.
  • SDOC-LLR-212
    1.16. Support for file relations SDOC-LLR-212

    StrictDoc shall support multiple file relation entries in the Relations list of a markdown file.

    Example of a language element reference:

    **Relations**:
- **Type**: `File` \
  **Path**: `file.py` \
  **Element**: `Function` \
  **ID**: `hello_world` \
  **Hash**: `5c2e9a1b7d4f8c3a6e0b2d1f9a7c5e3b8d6f1a4c2e9b7d0f3a5c8e1b6d2f4a9`

    Example of a line range reference (see 🔗 7.6.5. Range marker):

    **Relations**:
- **Type**: `File` \
  **Path**: `foo.c` \
  **Lines**: `10, 20`

    Each file relation shall support the following keys-value pairs:

    • Type (mandatory) File marks a relation as file relation
    • Path (mandatory) tells the file name.
    • Hash (optional) value covers the referenced source code part for drift detection.

    If no further key-value pairs are given, StrictDoc shall create a file marker (see 🔗 7.6.4. File marker).

    If the user provided additional mutually exclusive keys-value sets, StrictDoc shall refine the file relation. It shall create a language element reference (see 🔗 7.6.3. Language element marker) if following fields are provided:

    • Element (optional within language element kv-set) disambiguate the namespace where if a programming language has separate namespaces per item category. For example, Element: Function selects void foo() instead of struct foo in C.
    • ID (mandatory for language element kv-set) is the name of an item in language-specific notation. The used notation should stem from a given programming language's standard or specification.

    It shall create a range marker (see 🔗 7.6.5. Range marker) if the following field is provided:

    • Lines (mandatory for line kv-set) specifies the referenced line range as a start and end line number separated by a comma and a space (e.g., 10, 20).

    If the language element kv-set and the line kv-set are both provided in a single file relation entry, StrictDoc shall raise a StrictDocSemanticError.

    Back-ticks for values shall be optional. They can be used to protect special characters in the value that would otherwise be interpreted by a native markdown reader. If given, they shall not count to the parsed string.

    If mandatory keys are missing or unknown keys are provided, StrictDoc shall raise a StrictDocSemanticError.

    On export, all file relation key-value pairs including Line Range shall be written to Markdown output.
  • SDOC-LLR-164
    3.1.1. Auto-scoped relation markers in Rust docs SDOC-LLR-164

    If a StrictDoc relation marker is inside a Rust doc comment, the marker scope shall be set to exact the item the Rust language defines as target of the containing doc comment. The @relation(scope=...) parameter shall therefore be optional and shall be ignored if provided.

    1 /// @relation(REQ-1)
2 impl Foo {
3 
4     /// @relation(REQ-2)
5     fn foo() {
6     }
7 }

    In the given example, the first marker shall link REQ-1 to the impl Foo implementation, highlighting lines 1 to 7. The second marker shall link REQ-2 to the fn foo() function, highlighting lines 4 to 6.
  • SDOC-SSS-72
    5.1. Traceability between requirements and source code SDOC-SSS-72

    The Requirements Tool shall support bi-directional tracing between requirements content and implementation source code with only minimal changes needed in the source code.

    NOTE: The Requirements Tool does not necessarily have to implement the complete tracing process. It may delegate parts of the traceability task to other tools, e.g., Doxygen, Lobster, etc.
    • ZEP-11
      11. Requirements to source code traceability ZEP-11

      Linking from requirements objects to code or from code to requirements objects via ID shall be supported.
    • ZEP-12
      12. Non-intrusive links in source code ZEP-12

      Linking from code to requirements objects via ID shall be least code intrusive.
SDOC-SRS-139
Incoming link from: 1.16. Support for file relations
1
 7.6.4. File marker SDOC-SRS-139

StrictDoc's shall support file markers that can be attached to entire source files.
  • SDOC-LLR-212
    1.16. Support for file relations SDOC-LLR-212

    StrictDoc shall support multiple file relation entries in the Relations list of a markdown file.

    Example of a language element reference:

    **Relations**:
- **Type**: `File` \
  **Path**: `file.py` \
  **Element**: `Function` \
  **ID**: `hello_world` \
  **Hash**: `5c2e9a1b7d4f8c3a6e0b2d1f9a7c5e3b8d6f1a4c2e9b7d0f3a5c8e1b6d2f4a9`

    Example of a line range reference (see 🔗 7.6.5. Range marker):

    **Relations**:
- **Type**: `File` \
  **Path**: `foo.c` \
  **Lines**: `10, 20`

    Each file relation shall support the following keys-value pairs:

    • Type (mandatory) File marks a relation as file relation
    • Path (mandatory) tells the file name.
    • Hash (optional) value covers the referenced source code part for drift detection.

    If no further key-value pairs are given, StrictDoc shall create a file marker (see 🔗 7.6.4. File marker).

    If the user provided additional mutually exclusive keys-value sets, StrictDoc shall refine the file relation. It shall create a language element reference (see 🔗 7.6.3. Language element marker) if following fields are provided:

    • Element (optional within language element kv-set) disambiguate the namespace where if a programming language has separate namespaces per item category. For example, Element: Function selects void foo() instead of struct foo in C.
    • ID (mandatory for language element kv-set) is the name of an item in language-specific notation. The used notation should stem from a given programming language's standard or specification.

    It shall create a range marker (see 🔗 7.6.5. Range marker) if the following field is provided:

    • Lines (mandatory for line kv-set) specifies the referenced line range as a start and end line number separated by a comma and a space (e.g., 10, 20).

    If the language element kv-set and the line kv-set are both provided in a single file relation entry, StrictDoc shall raise a StrictDocSemanticError.

    Back-ticks for values shall be optional. They can be used to protect special characters in the value that would otherwise be interpreted by a native markdown reader. If given, they shall not count to the parsed string.

    If mandatory keys are missing or unknown keys are provided, StrictDoc shall raise a StrictDocSemanticError.

    On export, all file relation key-value pairs including Line Range shall be written to Markdown output.
  • SDOC-LLR-171
    3.1.8. File, line and range markers SDOC-LLR-171

    StrictDoc shall point to lines and line ranges of Rust code by using file, line and range markers. These marker types shall be parsed from regular line and block comments.

    Note: File markers may also result from the inner doc comments of the top-level module.
  • SDOC-SSS-72
    5.1. Traceability between requirements and source code SDOC-SSS-72

    The Requirements Tool shall support bi-directional tracing between requirements content and implementation source code with only minimal changes needed in the source code.

    NOTE: The Requirements Tool does not necessarily have to implement the complete tracing process. It may delegate parts of the traceability task to other tools, e.g., Doxygen, Lobster, etc.
    • ZEP-11
      11. Requirements to source code traceability ZEP-11

      Linking from requirements objects to code or from code to requirements objects via ID shall be supported.
    • ZEP-12
      12. Non-intrusive links in source code ZEP-12

      Linking from code to requirements objects via ID shall be least code intrusive.
SDOC-SRS-138
Incoming links from: 1.16. Support for file relations 1.16. Support for file relations
2
 7.6.5. Range marker SDOC-SRS-138

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.
  • SDOC-LLR-212
    1.16. Support for file relations SDOC-LLR-212

    StrictDoc shall support multiple file relation entries in the Relations list of a markdown file.

    Example of a language element reference:

    **Relations**:
- **Type**: `File` \
  **Path**: `file.py` \
  **Element**: `Function` \
  **ID**: `hello_world` \
  **Hash**: `5c2e9a1b7d4f8c3a6e0b2d1f9a7c5e3b8d6f1a4c2e9b7d0f3a5c8e1b6d2f4a9`

    Example of a line range reference (see 🔗 7.6.5. Range marker):

    **Relations**:
- **Type**: `File` \
  **Path**: `foo.c` \
  **Lines**: `10, 20`

    Each file relation shall support the following keys-value pairs:

    • Type (mandatory) File marks a relation as file relation
    • Path (mandatory) tells the file name.
    • Hash (optional) value covers the referenced source code part for drift detection.

    If no further key-value pairs are given, StrictDoc shall create a file marker (see 🔗 7.6.4. File marker).

    If the user provided additional mutually exclusive keys-value sets, StrictDoc shall refine the file relation. It shall create a language element reference (see 🔗 7.6.3. Language element marker) if following fields are provided:

    • Element (optional within language element kv-set) disambiguate the namespace where if a programming language has separate namespaces per item category. For example, Element: Function selects void foo() instead of struct foo in C.
    • ID (mandatory for language element kv-set) is the name of an item in language-specific notation. The used notation should stem from a given programming language's standard or specification.

    It shall create a range marker (see 🔗 7.6.5. Range marker) if the following field is provided:

    • Lines (mandatory for line kv-set) specifies the referenced line range as a start and end line number separated by a comma and a space (e.g., 10, 20).

    If the language element kv-set and the line kv-set are both provided in a single file relation entry, StrictDoc shall raise a StrictDocSemanticError.

    Back-ticks for values shall be optional. They can be used to protect special characters in the value that would otherwise be interpreted by a native markdown reader. If given, they shall not count to the parsed string.

    If mandatory keys are missing or unknown keys are provided, StrictDoc shall raise a StrictDocSemanticError.

    On export, all file relation key-value pairs including Line Range shall be written to Markdown output.
  • SDOC-LLR-171
    3.1.8. File, line and range markers SDOC-LLR-171

    StrictDoc shall point to lines and line ranges of Rust code by using file, line and range markers. These marker types shall be parsed from regular line and block comments.

    Note: File markers may also result from the inner doc comments of the top-level module.

7.7. Source code markup – Nodes
SDOC-SRS-141
7.7.1. Parse nodes from source code SDOC-SRS-141

StrictDoc shall support parsing nodes from source code.
  • SDOC-LLR-172
    3.1.9. Source nodes from doc comments SDOC-LLR-172

    If a Rust doc comments contains custom tags, and the containing Rust source file matches an entry in the source node configuration, StrictDoc shall create document nodes from the custom tags and automatically link the created node with the Rust item targeted by the doc comment.
SECTION-SRS-Export-import-formats

8. Export/import formats

 SECTION-SRS-Export-import-formats
SECTION-SRS-RST

8.1. RST

 SECTION-SRS-RST
  • DO178-5
    1.6. PDF and HTML publishing DO178-5

    StrictDoc shall support publication of documents to HTML and PDF formats.
  • DO178-16
    2.6. Interoperability with Sphinx DO178-16

    StrictDoc shall support interoperability with Sphinx:

    1. StrictDoc shall read RST fragments with Sphinx directives without errors.
    2. StrictDoc shall render Sphinx plugins natively.
SDOC-SRS-70
8.1.1. Export to RST SDOC-SRS-70

StrictDoc shall allow exporting SDoc content to the RST format.
  • DO178-5
    1.6. PDF and HTML publishing DO178-5

    StrictDoc shall support publication of documents to HTML and PDF formats.
  • DO178-16
    2.6. Interoperability with Sphinx DO178-16

    StrictDoc shall support interoperability with Sphinx:

    1. StrictDoc shall read RST fragments with Sphinx directives without errors.
    2. StrictDoc shall render Sphinx plugins natively.
SDOC-SRS-71
8.1.2. Docutils SDOC-SRS-71

StrictDoc shall generate RST markup to HTML using Docutils.
SECTION-SRS-ReqIF

8.2. ReqIF

 SECTION-SRS-ReqIF
  • SDOC-SSS-58
    6.2. ReqIF export/import SDOC-SSS-58

    The Requirements Tool shall support exporting/importing requirements content from/to ReqIF format.
    • ZEP-6
      6. ReqIF export ZEP-6

      Requirements specification shall be exportable to ReqIF.
SDOC-SRS-72
8.2.1. Export/import from/to ReqIF SDOC-SRS-72

StrictDoc shall support exporting/importing requirements content from/to ReqIF format.
  • SDOC-SSS-90
    11.8. Long-term maintainability of a tool SDOC-SSS-90

    The Requirements Tool shall be designed for long-term maintenance.

    NOTE: Long-term maintenance aspects to consider:

    • Careful selection of the technologies used, e.g., avoid building on too many unrelated technologies at the same time.
    • Take into account the existing experience of the development team. Consider the availability of qualified developers in the future.
    • Take into account maintainability by the development team as well as the users, e.g., IT/DevOps department.
SDOC-SRS-73
8.2.2. Standalone ReqIF layer SDOC-SRS-73

StrictDoc shall maintain the core ReqIF implementation as a separate software component.
SECTION-SRS-Excel

8.3. Excel and CSV

 SECTION-SRS-Excel
  • SDOC-SSS-60
    6.4. Excel export/import SDOC-SSS-60

    The Requirements Tool shall support exporting/importing requirements content from/to Excel.
SDOC-SRS-74
8.3.1. Export to Excel SDOC-SRS-74

StrictDoc shall allow exporting SDoc documents to Excel, one Excel sheet per document.
  • SDOC-SSS-60
    6.4. Excel export/import SDOC-SSS-60

    The Requirements Tool shall support exporting/importing requirements content from/to Excel.
SDOC-SRS-152
8.3.2. Import from Excel SDOC-SRS-152

StrictDoc shall allow importing Excel documents to SDoc documents, one Excel sheet per document.
  • SDOC-SSS-60
    6.4. Excel export/import SDOC-SSS-60

    The Requirements Tool shall support exporting/importing requirements content from/to Excel.
SDOC-SRS-134
8.3.3. Selected fields export SDOC-SRS-134

StrictDoc Excel export shall allow exporting SDoc documents to Excel with only selected fields.
SECTION-SRS-Command-line-interface

9. Command-line interface

 SECTION-SRS-Command-line-interface

9.1. General CLI requirements
  • SDOC-SSS-32
    11.3. Command-line interface SDOC-SSS-32

    The Requirements Tool shall provide a command line interface (CLI).
SDOC-SRS-103
9.1.1. Command-line interface SDOC-SRS-103

StrictDoc shall provide a command-line interface.
SECTION-SRS-Command-Manage

9.2. Command: Manage

 SECTION-SRS-Command-Manage
SECTION-SRS-Command-Auto-UID

9.2.1. Command: Auto UID

 SECTION-SRS-Command-Auto-UID
  • SDOC-SSS-6
    3.7. Auto-provision of Requirement UIDs SDOC-SSS-6

    The Requirements Tool shall provide controls for automatic generation of requirements UIDs.
    • ZEP-8
      8. Unique ID management ZEP-8

      Requirements objects shall allow unique ID management when adding new requirements on different branches.

      Options could be:

      • UUID: no checking required, but not handy
      • Manually assigned: collision checking required
      • Centralized: when not affected by branching".
SDOC-SRS-85
9.2.1.1. Auto-generate requirements UIDs SDOC-SRS-85

StrictDoc shall allow automatic generation of requirements UIDs.

10. Python API
  • SDOC-SSS-79
    10.1. General usability SDOC-SSS-79

    The Requirements Tool shall be accessible to a broad spectrum of users.

    NOTE: Factors to consider:

    • The cost of a tool.
    • The easy of installation.
    • The availability of a graphical user interface.
    • The availability of a programmatic access to the functions of a tool.
    • The interoperability of the tool with other tools.
  • SDOC-SSS-86
    10.9. Programming access via API (SDK) SDOC-SSS-86

    The Requirements Tool shall provide a Software Development Kit (SDK) that allows customization of the Requirements Tool functions.

    NOTE: An SDK provides access to the API of the Requirements Tool. Examples of functions that may be used by the users of the tool:

    • Custom import/export functions to/from various requirements/documentation formats.
    • Implement custom visualization functions.
    • Implement integration with other tools.
  • SDOC-SSS-87
    10.10. Programmatic access to requirements data SDOC-SSS-87

    The Requirements Tool shall provide programmatic access to requirements data.
SDOC-SRS-125
10.1. StrictDoc Python API SDOC-SRS-125

StrictDoc shall provide a Python API for its core functions:

  • Reading SDoc files
  • Creating traceability graph
  • Generating HTML exports
  • Converting SDoc to other formats.

11. Web server
  • SDOC-SSS-83
    10.6. Server-based deployments (IT-friendly setup) SDOC-SSS-83

    The Requirements Tool shall be deployable to the network of computers, e.g., provide a server instance.
SDOC-SRS-126
11.1. Web server SDOC-SRS-126

StrictDoc shall provide a web server.

12. User experience
  • SDOC-SSS-97
    10.2. Tool identification SDOC-SSS-97

    The Requirements Tool shall provide identifying information, including title, release version, and project website links.
SDOC-SRS-163
12.1. StrictDoc identification SDOC-SRS-163

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

12.2. Strict mode by default

 SECTION-SSRS-Strict-mode-by-default
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-6
12.2.1. Warnings are errors SDOC-SRS-6

StrictDoc's default mode of operation shall treat all warnings as errors.
SECTION-SRS-Configurability

13. Configurability

 SECTION-SRS-Configurability
  • SDOC-SSS-92
    7.1. Project-level configuration SDOC-SSS-92

    The Requirements Tool shall provide a solution for configuring the project-level options.

    NOTE: Examples of project-level options:

    • Project title.
    • Global settings for the Requirements Tool itself.
SDOC-SRS-37
13.1. strictdoc.toml file SDOC-SRS-37

StrictDoc shall support a configuration of project-level options through a TOML file named strictdoc.toml.
  • SDOC-SSS-92
    7.1. Project-level configuration SDOC-SSS-92

    The Requirements Tool shall provide a solution for configuring the project-level options.

    NOTE: Examples of project-level options:

    • Project title.
    • Global settings for the Requirements Tool itself.
SDOC-SRS-39
13.2. Feature toggles SDOC-SRS-39

StrictDoc shall allow a user to select a subset of StrictDoc's available features by listing them in the strictdoc.toml file.
  • DO178-8
    1.8. Configuration: 'Host' parameter DO178-8

    StrictDoc shall provide an option to configure a host where a server is deployed.
SDOC-SRS-119
13.3. 'Host' parameter SDOC-SRS-119

StrictDoc shall support configuring a host/port on which the StrictDoc web server is run.
SECTION-SSRS-Performance

14. Performance

 SECTION-SSRS-Performance
  • SDOC-SSS-13
    8.1. Support large requirements sets SDOC-SSS-13

    The Requirements Tool shall support requirement trees with at least 10000 requirements.
  • SDOC-SSS-14
    8.2. Support large project trees SDOC-SSS-14

    The Requirements Tool shall be able to handle documentation packages of at least 100 documents without significant performance degradation.
SDOC-SRS-1
14.1. Process-based parallelization SDOC-SRS-1

StrictDoc shall support process-based parallelization for time-critical tasks.
  • SDOC-SSS-13
    8.1. Support large requirements sets SDOC-SSS-13

    The Requirements Tool shall support requirement trees with at least 10000 requirements.
  • SDOC-SSS-14
    8.2. Support large project trees SDOC-SSS-14

    The Requirements Tool shall be able to handle documentation packages of at least 100 documents without significant performance degradation.
SDOC-SRS-95
14.2. Caching of parsed SDoc documents SDOC-SRS-95

StrictDoc shall implement caching of parsed SDoc documents.
  • SDOC-SSS-13
    8.1. Support large requirements sets SDOC-SSS-13

    The Requirements Tool shall support requirement trees with at least 10000 requirements.
  • SDOC-SSS-14
    8.2. Support large project trees SDOC-SSS-14

    The Requirements Tool shall be able to handle documentation packages of at least 100 documents without significant performance degradation.
SDOC-SRS-2
14.3. Incremental generation of documents SDOC-SRS-2

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.
  • SDOC-SSS-13
    8.1. Support large requirements sets SDOC-SSS-13

    The Requirements Tool shall support requirement trees with at least 10000 requirements.
  • SDOC-SSS-14
    8.2. Support large project trees SDOC-SSS-14

    The Requirements Tool shall be able to handle documentation packages of at least 100 documents without significant performance degradation.
SDOC-SRS-3
14.4. Caching of RST fragments SDOC-SRS-3

StrictDoc shall cache the RST fragments rendered to HTML.
  • SDOC-SSS-13
    8.1. Support large requirements sets SDOC-SSS-13

    The Requirements Tool shall support requirement trees with at least 10000 requirements.
  • SDOC-SSS-14
    8.2. Support large project trees SDOC-SSS-14

    The Requirements Tool shall be able to handle documentation packages of at least 100 documents without significant performance degradation.
SDOC-SRS-4
14.5. On-demand loading of HTML pages SDOC-SRS-4

StrictDoc's web interface shall generate the HTML content only when it is directly requested by a user.
  • SDOC-SSS-13
    8.1. Support large requirements sets SDOC-SSS-13

    The Requirements Tool shall support requirement trees with at least 10000 requirements.
  • SDOC-SSS-14
    8.2. Support large project trees SDOC-SSS-14

    The Requirements Tool shall be able to handle documentation packages of at least 100 documents without significant performance degradation.
SDOC-SRS-5
14.6. Precompiled Jinja templates SDOC-SRS-5

StrictDoc shall support a precompilation of HTML templates.
SECTION-SRS-Quality-requirements

15. Development process requirements

 SECTION-SRS-Quality-requirements

15.1. General process
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-133
15.1.1. Priority handling of critical issues in StrictDoc SDOC-SRS-133

All critical issues reported in relation to StrictDoc shall be addressed with utmost priority.
SECTION-SRS-Requirements-engineering

15.2. Requirements engineering

 SECTION-SRS-Requirements-engineering
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
  • SDOC-SSS-76
    14.1. Requirements engineering SDOC-SSS-76

    The Requirements Tool's development process shall include the Requirements Tool's own requirements engineering.
SDOC-SRS-128
15.2.1. Requirements-based development SDOC-SRS-128

StrictDoc's development shall be requirements-based.
  • SDOC-SSS-50
    14.2. Self-hosted requirements SDOC-SSS-50

    The Requirements Tool's requirements shall be developed and stored using the Requirements Tool itself.
    • ZEP-15
      15. Tool Qualifiability ZEP-15

      The Requirement Tool shall be qualifiable for use in safety-related and/or security-related development. At the very least, the Requirement Tool shall come with its own set of requirements, which shall be amenable to validation in compliance with the relevant standards.
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-91
15.2.2. Self-hosted requirements SDOC-SRS-91

StrictDoc's requirements shall be written using StrictDoc.
SECTION-SRS-Implementation-requirements

15.3. Implementation requirements

 SECTION-SRS-Implementation-requirements
SECTION-SRS-Programming-languages

15.3.1. Programming languages

 SECTION-SRS-Programming-languages
  • SDOC-SSS-69
    11.7. Conservative languages for implementation SDOC-SSS-69

    The Requirements Tool shall be implemented using the popular programming languages.

    NOTE: Examples of the most popular programming languages:

    • Java
    • C++
    • Python
    • JavaScript
SDOC-SRS-8
15.3.1.1. Python language SDOC-SRS-8

StrictDoc shall be written in Python.
SECTION-SRS-Cross-platform-availability

15.3.2. Cross-platform availability

 SECTION-SRS-Cross-platform-availability
  • SDOC-SSS-67
    11.6. Support major operating systems SDOC-SSS-67

    The Requirements Tool shall support at least the following operating systems:

    • Linux
    • Windows
    • macOS.
SDOC-SRS-9
15.3.2.1. Linux SDOC-SRS-9

StrictDoc shall support the Linux operating systems.
  • SDOC-SSS-67
    11.6. Support major operating systems SDOC-SSS-67

    The Requirements Tool shall support at least the following operating systems:

    • Linux
    • Windows
    • macOS.
SDOC-SRS-10
15.3.2.2. macOS SDOC-SRS-10

StrictDoc shall support the macOS operating system.
  • SDOC-SSS-67
    11.6. Support major operating systems SDOC-SSS-67

    The Requirements Tool shall support at least the following operating systems:

    • Linux
    • Windows
    • macOS.
SDOC-SRS-11
15.3.2.3. Windows SDOC-SRS-11

StrictDoc shall support the Windows operating system.
SECTION-SRS-Implementation-constraints

15.4. Implementation constraints

 SECTION-SRS-Implementation-constraints
  • DO178-7
    1.9. No use of proprietary technology DO178-7

    StrictDoc shall not use any proprietary tools.
  • SDOC-SSS-39
    15.2. Only open source dependencies SDOC-SSS-39

    The Requirement Tool's source code shall be based on open source software components.
SDOC-SRS-89
15.4.1. Use of open source components SDOC-SRS-89

StrictDoc shall be built using only open source software components.
  • SDOC-SSS-90
    11.8. Long-term maintainability of a tool SDOC-SSS-90

    The Requirements Tool shall be designed for long-term maintenance.

    NOTE: Long-term maintenance aspects to consider:

    • Careful selection of the technologies used, e.g., avoid building on too many unrelated technologies at the same time.
    • Take into account the existing experience of the development team. Consider the availability of qualified developers in the future.
    • Take into account maintainability by the development team as well as the users, e.g., IT/DevOps department.
SDOC-SRS-14
15.4.2. No heavy UI frameworks SDOC-SRS-14

StrictDoc shall avoid using large and demanding UI frameworks.

NOTE: An example of frameworks that require a very specific architecture: React JS, AngularJS.
  • SDOC-SSS-90
    11.8. Long-term maintainability of a tool SDOC-SSS-90

    The Requirements Tool shall be designed for long-term maintenance.

    NOTE: Long-term maintenance aspects to consider:

    • Careful selection of the technologies used, e.g., avoid building on too many unrelated technologies at the same time.
    • Take into account the existing experience of the development team. Consider the availability of qualified developers in the future.
    • Take into account maintainability by the development team as well as the users, e.g., IT/DevOps department.
SDOC-SRS-15
15.4.3. No use of NPM SDOC-SRS-15

StrictDoc shall avoid extending its infrastructure with anything based on NPM-ecosystem.
  • SDOC-SSS-90
    11.8. Long-term maintainability of a tool SDOC-SSS-90

    The Requirements Tool shall be designed for long-term maintenance.

    NOTE: Long-term maintenance aspects to consider:

    • Careful selection of the technologies used, e.g., avoid building on too many unrelated technologies at the same time.
    • Take into account the existing experience of the development team. Consider the availability of qualified developers in the future.
    • Take into account maintainability by the development team as well as the users, e.g., IT/DevOps department.
SDOC-SRS-16
15.4.4. No use of JavaScript replacement languages (e.g., Typescript) SDOC-SRS-16

StrictDoc shall avoid using JavaScript-based programming languages.
  • SDOC-SSS-82
    10.5. Individual use (home PC) SDOC-SSS-82

    The Requirements Tool shall be usable on the normal personal computers, e.g., do not require a special cloud deployment.
SDOC-SRS-87
15.4.5. Monolithic application with no microservices SDOC-SRS-87

StrictDoc shall avoid using microservices and microservice-based architectures.
  • SDOC-SSS-82
    10.5. Individual use (home PC) SDOC-SSS-82

    The Requirements Tool shall be usable on the normal personal computers, e.g., do not require a special cloud deployment.
SDOC-SRS-88
15.4.6. No reliance on containerization SDOC-SRS-88

StrictDoc shall avoid using containers and containerization technologies.
SECTION-SRS-Coding-constraints

15.5. Coding constraints

 SECTION-SRS-Coding-constraints
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-40
15.5.1. Use of asserts SDOC-SRS-40

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.
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-41
15.5.2. Use of type annotations in Python code SDOC-SRS-41

StrictDoc's development shall ensure a use of type annotations throughout the project's Python codebase.
SECTION-SRS-Linting

15.6. Linting

 SECTION-SRS-Linting
  • SDOC-SSS-90
    11.8. Long-term maintainability of a tool SDOC-SSS-90

    The Requirements Tool shall be designed for long-term maintenance.

    NOTE: Long-term maintenance aspects to consider:

    • Careful selection of the technologies used, e.g., avoid building on too many unrelated technologies at the same time.
    • Take into account the existing experience of the development team. Consider the availability of qualified developers in the future.
    • Take into account maintainability by the development team as well as the users, e.g., IT/DevOps department.
SDOC-SRS-42
15.6.1. Compliance with Python community practices (PEP8 etc) SDOC-SRS-42

StrictDoc's development shall ensure that the project's codebase is compliant with the Python community's modern practices.
SECTION-SRS-Static-analysis

15.7. Static analysis

 SECTION-SRS-Static-analysis
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-43
15.7.1. Static type checking SDOC-SRS-43

StrictDoc's development shall include a continuous type checking of StrictDoc's codebase.
SECTION-SRS-Testing

15.8. Testing

 SECTION-SRS-Testing
  • SDOC-SSS-77
    14.3. Test coverage SDOC-SSS-77

    The Requirements Tool's development process shall ensure:

    • A testability of the tool.
    • The highest possible coverage of the tool's code by test.
    • Usage of modern testing methods to ensure adequate coverage of the tool's functions (e.g., command-line interface, web interface, smallest units of code, etc.).
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-44
15.8.1. Unit testing SDOC-SRS-44

StrictDoc's development shall provide unit testing of its codebase.
  • SDOC-SSS-77
    14.3. Test coverage SDOC-SSS-77

    The Requirements Tool's development process shall ensure:

    • A testability of the tool.
    • The highest possible coverage of the tool's code by test.
    • Usage of modern testing methods to ensure adequate coverage of the tool's functions (e.g., command-line interface, web interface, smallest units of code, etc.).
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-45
15.8.2. CLI interface black-box integration testing SDOC-SRS-45

StrictDoc's development shall provide complete black-box integration testing of its command-line interface.
  • SDOC-SSS-77
    14.3. Test coverage SDOC-SSS-77

    The Requirements Tool's development process shall ensure:

    • A testability of the tool.
    • The highest possible coverage of the tool's code by test.
    • Usage of modern testing methods to ensure adequate coverage of the tool's functions (e.g., command-line interface, web interface, smallest units of code, etc.).
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-46
15.8.3. Web end-to-end testing SDOC-SRS-46

StrictDoc's development shall provide complete end-to-end testing of the web interface.
  • SDOC-SSS-77
    14.3. Test coverage SDOC-SSS-77

    The Requirements Tool's development process shall ensure:

    • A testability of the tool.
    • The highest possible coverage of the tool's code by test.
    • Usage of modern testing methods to ensure adequate coverage of the tool's functions (e.g., command-line interface, web interface, smallest units of code, etc.).
  • SDOC-SSS-78
    14.4. Tool qualification SDOC-SSS-78

    The Requirements Tool's development process shall ensure that the tool can be qualified for the use in critical product developments as required by the rigorous technical standards (e.g., EN IEC 61508).
SDOC-SRS-47
15.8.4. At least one integration or end-to-end test SDOC-SRS-47

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.

16. Code hosting and distribution
SECTION-SRS-Code-hosting

16.1. Code hosting

 SECTION-SRS-Code-hosting
  • SDOC-SSS-38
    15.1. Open source SDOC-SSS-38

    The Requirements Tool's source code shall be publicly available, e.g., hosted on a code hosting platform such as GitHub or GitLab.
  • SDOC-SSS-82
    10.5. Individual use (home PC) SDOC-SSS-82

    The Requirements Tool shall be usable on the normal personal computers, e.g., do not require a special cloud deployment.
SDOC-SRS-12
16.1.1. GitHub SDOC-SRS-12

StrictDoc's source code shall be hosted on GitHub.
  • SDOC-SSS-40
    15.3. Free SDOC-SSS-40

    The Requirements Tool shall be licensed under a permissive license, ensuring no/minimal constraints on the utilization and dissemination of the project.

    NOTE: Example of a permissive license: MIT, Apache 2.
SDOC-SRS-118
16.2. StrictDoc license SDOC-SRS-118

All StrictDoc software shall be licensed under the Apache 2 license.