Type | Level | UID | REFS | Title | Statement | Rationale | Comment | ||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Section | 1 |
High-level requirements
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.1 | SDOC-HIGH-REQS-MANAGEMENT | Parents: Children: |
Requirements management
|
StrictDoc shall enable requirements management. |
||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.2 | SDOC-HIGH-DATA-MODEL | Children: |
Data model
|
StrictDoc shall be based on a well-defined data model. |
StrictDoc is a result of several attempts to find a solution for working with text-based requirements:
The result of these efforts was the realization that a text-based requirements and specifications management tool could be built on top of a domain-specific language (DSL) created specifically for the purpose of writing requirements and specifications documents. Such a language allows an explicit definition of a document data model which is called "grammar". | |||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.3 |
Command-line interface
|
StrictDoc shall provide a command-line interface. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 1.4 |
Graphical user interface
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Free text | – |
StrictDoc shall provide a Graphical User Interface (GUI). Several trade-offs to consider:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 1.5 |
Statically generated website
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Free text | – |
StrictDoc shall allow generating requirements content to static HTML website. |
|||||||||||||||||||||||||||||||||||||||||||||||||||
Composite requirement | 1.6 |
Platform support
|
StrictDoc shall work on all major platforms. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.6.1 |
macOS support
|
StrictDoc shall work on macOS systems. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.6.2 |
Linux support
|
StrictDoc shall work on Linux systems. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.6.3 |
Windows support
|
StrictDoc shall work on Windows systems. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.7 | SDOC-HIGH-VALIDATION | Children: |
Requirements validation
|
StrictDoc shall allow validation of requirement documents. |
||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.8 |
Requirements text format
|
StrictDoc shall allow storage of requirements in a plain-text human readable form. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.9 |
Linking requirements
|
StrictDoc shall support linking requirements to each other. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.10 |
Scalability
|
StrictDoc shall allow working with large documents and document trees containing at least 10000 requirement items. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.11 | SDOC-HIGH-REQS-TRACEABILITY |
Traceability
|
StrictDoc shall support traceability of requirements. |
|||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.12 |
Visualization
|
StrictDoc shall provide means for visualization of requirement documents. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.13 |
Open source software
|
StrictDoc shall always be free and open source software. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 2 |
Implementation requirements
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 2.1 | SDOC-IMPL-PARAL |
Parallelization
|
StrictDoc shall enable parallelization of the time-consuming parts of the code. |
|||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 2.2 | SDOC-IMPL-INCREMENTAL |
Incremental generation
|
StrictDoc shall enable incremental generation of the documents. |
When exporting documentation tree, StrictDoc shall regenerate only changed documents and files. | ||||||||||||||||||||||||||||||||||||||||||||||||
Section | 3 |
Data model
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 3.1 | SDOC-DM-MODEL | Parents: Children: |
Modeling capability
|
StrictDoc's Data Model shall accommodate for maximum possible standard requirement document formats. |
Examples of standard requirements documents include but are not limited to:
| |||||||||||||||||||||||||||||||||||||||||||||||
Composite requirement | 3.2 |
Project
|
StrictDoc shall support the "Project" concept as a top-level entity that serves for grouping of SDoc documents into a single project documentation tree. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 3.2.1 |
Project title
|
Project shall have a "Title" property. |
Currently, the project title aspect is not part of the SDoc grammar. It is simply specified via the --project-title command-line option. This might change when the project title will be configured as part of the project-level config file (TOML or SDoc-like grammar). | |||||||||||||||||||||||||||||||||||||||||||||||||
Section | 3.3 |
Document
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Free text | – |
TBD |
|||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 3.4 |
Section
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Free text | – |
TBD |
|||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 3.5 |
Requirement item
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 3.5.1 |
Statement
|
Requirement item shall have a statement. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Composite requirement | 3.5.2 |
UID identifier
|
Requirement item may have an UID identifier. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 3.5.2.1 |
UID identifier format
|
StrictDoc shall not impose any restrictions on the UID field format. |
Conventions used for requirement UIDs can be very different. And there seems to be no way to define a single rule. Some examples:
| |||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 3.5.3 |
Title
|
Requirement item may have an title. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 3.5.4 |
References
|
Requirement item may have one or more references. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 3.5.5 |
Comments
|
Requirement item may have one or more comments. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 3.5.6 |
Special fields
|
StrictDoc shall support customization of the default Requirement's grammar with special fields. |
Examples:
| |||||||||||||||||||||||||||||||||||||||||||||||||
Section | 3.6 |
Composite Requirement item
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Free text | – |
TBD |
|||||||||||||||||||||||||||||||||||||||||||||||||||
Composite requirement | 3.7 |
Links
|
StrictDoc's data model shall support linking document content nodes to each other. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 3.7.1 |
Parent links
|
StrictDoc's data model shall support linking a requirement to another requirement using PARENT link. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 4 |
SDoc file format
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 4.1 | SDOC-FMT-PRIMARY | Parents: |
Primary text implementation
|
The SDoc format shall support encoding the Strict Doc Data Model in a plain-text human readable form. |
||||||||||||||||||||||||||||||||||||||||||||||||
Composite requirement | 4.2 | SDOC-FMT-GRAMMAR | Parents: |
Grammar
|
The SDoc format shall be based on a fixed grammar. |
||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 4.2.1 |
No indentation
|
The SDoc grammar's building blocks shall not allow any indentation. |
Rationale: Adding indentation to any of the fields does not scale well when the documents have deeply nested section structure as well as when the size of the paragraphs becomes sufficiently large. Keeping every keyword like [REQUIREMENT] or [COMMENT] with no indentation ensures that one does not have to think about possible indentation issues. | |||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 4.3 |
Type safety
|
The SDoc format shall allow type-safe encoding of requirement documents. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 5 |
Export and import capabilities
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 5.1 |
General
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 5.1.1 |
Generated file names
|
StrictDoc shall preserve original document file names when generating to all export formats. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 5.2 |
HTML Export
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 5.2.1 |
Single document: Normal form
|
StrictDoc shall export single document pages in a normal document-like form. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 5.2.2 |
Single document: Tabular form
|
StrictDoc shall export single document pages in a tabular form. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 5.2.3 |
Single document: 1-level traceability
|
StrictDoc shall export 1-level traceability document. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 5.2.4 |
Single document: Deep traceability
|
StrictDoc shall export deep traceability document. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 5.2.5 |
Left panel: Table of contents
|
StrictDoc shall export all HTML pages with Table of Contents. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 5.3 |
PDF Export
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 5.3.1 |
Sphinx documentation generator
|
StrictDoc shall support exporting documents to Sphinx/RST format. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 5.4 | SDOC-GEN-EXCEL-EXPORT |
Excel Export
|
StrictDoc shall support exporting documents to Excel format. |
|||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 5.5 |
ReqIF import/export
|
StrictDoc shall support the ReqIF format. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 6 |
Validation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 6.1 | SDOC-VALIDATION-UNIQUE-UID | Parents: |
Uniqueness of UID identifiers in a document tree
|
StrictDoc shall ensure that each UID used in a document tree is unique. |
This is implemented but the error message shall be made more readable. | |||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 6.2 | SDOC-VALIDATION-NO-CYCLES | Parents: |
No cycles in a document tree
|
StrictDoc shall ensure that no requirements in document tree reference each other. |
||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 6.3 | SDOC-VALIDATION-VALID-HTML | Parents: |
Valid HTML markup
|
StrictDoc's HTML export tests shall validate the generated HTML markup. |
First candidate: Table of contents and its nested <ul>/<li> items. | |||||||||||||||||||||||||||||||||||||||||||||||
Section | 7 |
Traceability and coverage
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Composite requirement | 7.1 |
Linking with implementation artifacts
|
StrictDoc shall support linking requirements to files. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 7.1.1 |
Validation: Broken links from requirements to source files
|
StrictDoc shall warn a user about all requirements whose links reference source files that do not exist. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 7.1.2 |
Validation: Broken links from source files to requirements
|
StrictDoc shall warn a user about all source files whose links reference requirements that do not exist. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 7.2 |
Requirements coverage
|
StrictDoc shall generate requirements coverage information. |
Requirements coverage screen shows how requirements are linked with source files. | |||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 7.3 |
Source coverage
|
StrictDoc shall generate source coverage information. |
Source coverage screen shows how source files are linked with requirements. | |||||||||||||||||||||||||||||||||||||||||||||||||
Section | 8 |
Web frontend requirements
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 8.1 |
AJAX updates of multiple web forms
|
StrictDoc's Web GUI shall provide capability to do multipart updates. |