UID: |
SDOC-SRS-18 |
StrictDoc shall be based on a data model.
COMMENT:
Verification: data model diagram TBD.
Parents:
[SDOC-SSS-88] Text files for storing documentation and requirements
[SDOC-SSS-58] ReqIF export/import
UID: |
SDOC-SRS-26 |
StrictDoc’s data model shall support a “Requirement” model.
Parents:
[SDOC-SSS-4] Requirements CRUD
UID: |
SDOC-SRS-100 |
StrictDoc’s “Requirement” model shall support configurable fields system.
Parents:
[SDOC-SSS-62] Custom fields
UID: |
SDOC-SRS-132 |
By default, the Requirement shall support the following fields:
MID
UID
STATUS
TITLE
STATEMENT
RATIONALE
COMMENT.
RATIONALE:
These fields are the most typical fields found in requirement documents.
Parents:
[SDOC-SSS-61] Minimal requirement field set
UID: |
SDOC-SRS-98 |
StrictDoc’s data model shall support a “Document” model.
Parents:
[SDOC-SSS-64] Structuring requirements in documents
UID: |
SDOC-SRS-110 |
StrictDoc’s data model shall support a Document metadata model including at least:
UID
Document version
Document classification
Document authors.
Parents:
[SDOC-SSS-53] Document meta information (UID, version, authors, signatures, etc)
[SDOC-SSS-75] Document versioning
UID: |
SDOC-SRS-99 |
StrictDoc’s data model shall support a “Section” that nests other Sections, Requirements, Texts.
RATIONALE:
“Section” corresponds to a chapter or a section in a document and helps to organize a document by grouping text nodes, requirements and other sections.
Parents:
[SDOC-SSS-51] Documents with nested sections/chapters structure
UID: |
SDOC-SRS-135 |
STATUS: |
Active |
StrictDoc’s data model shall support a “Free Text” model, representing non-normative documentation content.
RATIONALE:
Documentation comprises normative components, such as uniquely identifiable elements like requirements or design items, and non-normative components, including introductory text, overview chapters, and other content. The non-normative parts help provide a general understanding for the reader but do not contribute to traceability information. StrictDoc’s free text is designed to store this type of non-normative information in SDoc documents.
Parents:
[SDOC-SSS-3] Documents (CRUD)
UID: |
SDOC-SRS-109 |
STATUS: |
Active |
StrictDoc’s data model shall allow composing a Document from other Documents.
RATIONALE:
The logic behind the parent requirement remains fully relevant. Additionally, an alternative approach could involve using a dedicated entity, like “Fragment”, to allow a Document to be composed of includable sections or document fragments. Managing composition at the Document level eliminates the need in additional entities like “Fragment”, streamlining both the conceptual understanding and the practical implementation of composability.
COMMENT:
The corresponding UI capability for Fragments CRUD is TBD.
Parents:
[SDOC-SSS-52] Assembling documents from fragments
[DO178-4] Document fragments in separate files
UID: |
SDOC-SRS-31 |
STATUS: |
Active |
The StrictDoc data model shall support connecting requirements using Parent and Child relations.
RATIONALE:
Support of both Parent and Child relations allows to build typical requirements relations such as child-to-parent and less common relations when one document can have parent links to a parent document and child links to a child document (e.g., the so-called “compliance” or “tailoring matrix” documents may use this structure).
Parents:
[SDOC-SSS-7] Link requirements together
[SDOC-SSS-48] Compliance matrices
UID: |
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”.
Parents:
[SDOC-SSS-8] Multiple link roles
UID: |
SDOC-SRS-20 |
STATUS: |
Active |
StrictDoc shall implement its own text markup language called S-Doc (strict-doc).
RATIONALE:
The most commonly used Markdown format lacks the ability to store requirements metadata. While the RST syntax does allow for customization with directives to implement metadata extensions, its visual appearance contradicts other requirements of StrictDoc, such as the type-safety of the grammar and visual readability. Therefore, a markup language tailored specifically to the needs of the requirements tool provides direct control over the capabilities implemented in both the markup and the user interface.
Parents:
[SDOC-SSS-88] Text files for storing documentation and requirements
UID: |
SDOC-SRS-127 |
STATUS: |
Active |
StrictDoc shall assume and implement capabilities for storage of SDoc files using Git version control system.
Parents:
[SDOC-SSS-87] Programmatic access to requirements data
[SDOC-SSS-33] Version control (Git)
[SDOC-SSS-84] Requirements database
UID: |
SDOC-SRS-104 |
STATUS: |
Active |
The SDoc markup content shall be stored in files with .sdoc extension.
RATIONALE:
Given that the name of the model is S-Doc (strict-doc), it is reasonable to make the document files have the .sdoc extension. This helps to identify the document files.
Parents:
[SDOC-SSS-80] Easy user experience
UID: |
SDOC-SRS-105 |
StrictDoc’s SDoc file shall represent content of a single document.
COMMENT:
A “Document” corresponds to a “Document” of the SDoc data model.
Parents:
[SDOC-SSS-64] Structuring requirements in documents
[DO178-1] Document concept
UID: |
SDOC-SRS-19 |
STATUS: |
Active |
StrictDoc’s markup language shall be based on a well-defined grammar.
Parents:
[DO178-2] Strict specified grammar
[SDOC-SSS-55] Strict text language syntax
[SDOC-SSS-54] Machine-readable format
UID: |
SDOC-SRS-93 |
STATUS: |
Active |
The StrictDoc grammar shall have at least the following fields activated by default:
UID
STATUS
LINKS (references to other requirements)
TITLE
STATEMENT
RATIONALE
COMMENT.
Parents:
[SDOC-SSS-61] Minimal requirement field set
UID: |
SDOC-SRS-21 |
STATUS: |
Active |
The SDoc markup shall support custom grammars.
RATIONALE:
A custom grammar allows a user to define their own configuration of requirement fields.
Parents:
[SDOC-SSS-62] Custom fields
UID: |
SDOC-SRS-122 |
STATUS: |
Active |
StrictDoc shall support an inclusion of a grammar stored in a separate file.
RATIONALE:
A single grammar defined for several documents helps to standardize the structure of all documents in a documentation tree and removes the effort needed to create identical grammars all the time.
Parents:
[DO178-9] Project-level grammar
[SDOC-SSS-52] Assembling documents from fragments
UID: |
SDOC-SRS-22 |
The SDoc markup shall only accept UID identifiers that consist of alphanumeric characters separated by “_” and “-” characters.
RATIONALE:
A standardized UID format supports the parent requirement of unique identification of requirements. It is easier to visually identify UIDs that look similar and common to a given industry.
COMMENT:
This requirement may need a revision to accommodate for more UID formats.
Parents:
[SDOC-SSS-89] Unique identification of requirements
UID: |
SDOC-SRS-24 |
STATUS: |
Active |
StrictDoc shall support the RST markup.
Parents:
[SDOC-SSS-63] Text formatting capabilities
UID: |
SDOC-SRS-27 |
STATUS: |
Active |
StrictDoc’s markup shall enable support integration with MathJax.
Parents:
[SDOC-SSS-63] Text formatting capabilities
UID: |
SDOC-SRS-23 |
STATUS: |
Active |
SDoc text markup blocks shall all start from column 1, i.e., the nesting of the blocks is not allowed.
RATIONALE:
Nesting large text blocks of free text and requirements compromises readability.
Parents:
[SDOC-SSS-55] Strict text language syntax
UID: |
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.
Parents:
[SDOC-SSS-55] Strict text language syntax
UID: |
SDOC-SRS-28 |
StrictDoc shall maintain a complete Traceability Index of all documentation- and requirements-related information available in a project tree.
Parents:
[SDOC-SSS-7] Link requirements together
UID: |
SDOC-SRS-29 |
For each requirement node, the Traceability Index shall ensure its uniqueness throughout the node’s lifecycle.
Parents:
[SDOC-SSS-89] Unique identification of requirements
UID: |
SDOC-SRS-30 |
STATUS: |
Active |
The Traceability Index shall detect cycles between requirements.
Parents:
[SDOC-SSS-47] Requirements database consistency checks
UID: |
SDOC-SRS-32 |
The Traceability Index shall recognize and maintain the relations between all documents of a project tree.
RATIONALE:
The relations between all documents are a summary of all relations between these documents’ requirements. This information is useful for:
Structural analysis of a requirements/documents graph.
Incremental regeneration of only those documents whose content was modified.
Parents:
[SDOC-SSS-47] Requirements database consistency checks
[SDOC-SSS-13] Support large requirements sets
[SDOC-SSS-14] Support large project trees
UID: |
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.
RATIONALE:
The calculation of the reverse relations allows the user interface code to get and display both requirement’s parent and child relations.
COMMENT:
Example: If a child requirement REQ-002 has a parent requirement REQ-001, the graph database first reads the link REQ-002 -Parent> REQ-001, then it creates a corresponding REQ-001 -Child> REQ-002 on the go. Both relations can be queried as follows, in pseudocode:
get_parent_requirements(REQ-002) == [REQ-001]
get_children_requirements(REQ-001) == [REQ-002]
Parents:
[SDOC-SSS-71] Reverse parent links
[SDOC-SSS-48] Compliance matrices
UID: |
SDOC-SRS-115 |
STATUS: |
Active |
StrictDoc shall discover SDoc documents recursively based on a specified input path.
RATIONALE:
Recursive search allows working with documents located in multiple folders, potentially spanning over several Git repositories.
Parents:
[SDOC-SSS-34] Requirements data from multiple repositories
UID: |
SDOC-SRS-49 |
STATUS: |
Active |
StrictDoc shall support generating requirements documentation into static HTML.
Parents:
[SDOC-SSS-30] Static HTML export
UID: |
SDOC-SRS-50 |
STATUS: |
Active |
StrictDoc shall provide a web interface.
Parents:
[SDOC-SSS-31] Graphical user interface (GUI)
[DO178-6] Graphical user interface (GUI)
[SDOC-SSS-79] General usability
[SDOC-SSS-80] Easy user experience
UID: |
SDOC-SRS-51 |
STATUS: |
Active |
StrictDoc shall provide export to printable HTML pages.
Parents:
[DO178-5] PDF and HTML publishing
UID: |
SDOC-SRS-48 |
STATUS: |
Active |
For all export operations, StrictDoc shall maintain the original filenames of the documents when producing output files.
RATIONALE:
Name preservation helps to visually identify which input file an output file corresponds to.
Parents:
[SDOC-SSS-80] Easy user experience
UID: |
SDOC-SRS-53 |
StrictDoc’s “Project tree” screen shall provide browsing of a documentation project tree.
Parents:
[SDOC-SSS-91] Browsing documentation tree
UID: |
SDOC-SRS-107 |
STATUS: |
Active |
StrictDoc’s Project Tree screen shall allow creating documents.
Parents:
[SDOC-SSS-3] Documents (CRUD)
UID: |
SDOC-SRS-108 |
STATUS: |
Active |
StrictDoc’s Project Tree screen shall allow deleting documents.
Parents:
[SDOC-SSS-3] Documents (CRUD)
UID: |
SDOC-SRS-54 |
STATUS: |
Active |
StrictDoc’s Document screen shall allow reading documents.
Parents:
[SDOC-SSS-3] Documents (CRUD)
UID: |
SDOC-SRS-106 |
STATUS: |
Active |
StrictDoc’s Document screen shall allow updating documents.
Parents:
[SDOC-SSS-3] Documents (CRUD)
UID: |
SDOC-SRS-55 |
STATUS: |
Active |
StrictDoc’s Document screen shall allow editing requirements.
Parents:
[SDOC-SSS-4] Requirements CRUD
UID: |
SDOC-SRS-92 |
STATUS: |
Active |
StrictDoc’s Document screen shall provide a capability to move the nodes within a document.
RATIONALE:
Moving the nodes within a document is a convenience feature that speeds up the requirements editing process significantly.
Parents:
[SDOC-SSS-5] Move requirement nodes within document
UID: |
SDOC-SRS-56 |
STATUS: |
Active |
StrictDoc’s screen shall allow editing a document’s grammar.
RATIONALE:
Editing document grammar allows a user to customize the requirements fields.
Parents:
[SDOC-SSS-62] Custom fields
UID: |
SDOC-SRS-57 |
STATUS: |
Active |
StrictDoc’s Document screen shall provide controls for configuring the document-specific options.
Parents:
[SDOC-SSS-93] Document-level configuration
UID: |
SDOC-SRS-96 |
STATUS: |
Progress |
StrictDoc’s Document screen shall provide controls for automatic generation of requirements UIDs.
Parents:
[SDOC-SSS-6] Auto-provision of Requirement UIDs
[SDOC-SSS-80] Easy user experience
UID: |
SDOC-SRS-62 |
STATUS: |
Active |
StrictDoc’s Table screen shall allow reading documents in a table-like manner.
Parents:
[SDOC-SSS-73] Excel-like viewing and editing of requirements
UID: |
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.
Parents:
[SDOC-SSS-28] Traceability matrices
UID: |
SDOC-SRS-66 |
STATUS: |
Active |
StrictDoc shall provide a deep traceability screen.
Parents:
[DO178-12] Uncovered requirement report
UID: |
SDOC-SRS-97 |
STATUS: |
Active |
StrictDoc shall provide a Project Statistics screen that displays the following project information:
Project title
Date of generation
Git revision
Total documents
Total requirements
Requirements status breakdown
Total number of TBD/TBC found in documents.
RATIONALE:
TBD
Parents:
[SDOC-SSS-49] Progress report
[DO178-12] Uncovered requirement report
[SDOC-SSS-29] Requirements coverage
UID: |
SDOC-SRS-112 |
STATUS: |
Active |
StrictDoc shall provide a traceability matrix screen.
Parents:
[SDOC-SSS-28] Traceability matrices
[DO178-10] Traceability matrices
[DO178-12] Uncovered requirement report
UID: |
SDOC-SRS-111 |
STATUS: |
Active |
StrictDoc shall provide a project tree diff screen.
Parents:
[SDOC-SSS-75] Document versioning
[SDOC-SSS-74] Change management
[DO178-15] Diff between document trees
UID: |
SDOC-SRS-33 |
STATUS: |
Active |
StrictDoc shall support bi-directional linking requirements with source files.
Parents:
[SDOC-SSS-72] Traceability between requirements and source code
UID: |
SDOC-SRS-34 |
STATUS: |
Active |
StrictDoc shall support a dedicated markup language for annotating source code with links referencing the requirements.
Parents:
[SDOC-SSS-72] Traceability between requirements and source code
UID: |
SDOC-SRS-124 |
STATUS: |
Active |
StrictDoc’s source file marker syntax shall support single-line markers.
NOTE: A single-line marker points to a single line in a source file.
RATIONALE:
The advantage of a single-line marker compared to a range marker is that a single-line marker is not intrusive and does not clutter source code. Such a single-marker can be kept in a comment to a function (e.g., Doxygen), not in the function body.
Parents:
[ZEP-12] Non-intrusive links in source code
UID: |
SDOC-SRS-35 |
STATUS: |
Active |
StrictDoc shall generate project source code coverage information.
NOTE: Source code information can be visualized using both web or CLI interfaces.
Parents:
[SDOC-SSS-72] Traceability between requirements and source code
[DO178-13] Source file coverage
UID: |
SDOC-SRS-36 |
STATUS: |
Active |
StrictDoc shall generate single file traceability information.
RATIONALE:
With this capability in place, it is possible to focus on a single implementation file’s links to requirements which helps in the code reviews and inspections.
Parents:
[SDOC-SSS-72] Traceability between requirements and source code
UID: |
SDOC-SRS-70 |
StrictDoc shall allow exporting SDoc content to the RST format.
RATIONALE:
Exporting SDoc content to RST enables:
Generating RST to Sphinx HTML documentation.
Generating RST to PDF using Sphinx/LaTeX.
Parents:
[DO178-5] PDF and HTML publishing
[DO178-16] Interoperability with Sphinx
UID: |
SDOC-SRS-71 |
STATUS: |
Active |
StrictDoc shall generate RST markup to HTML using Docutils.
RATIONALE:
Docutils is the most mature RST-to-HTML converter.
COMMENT:
TBD: Move this to design decisions.
Parents:
[DO178-5] PDF and HTML publishing
[DO178-16] Interoperability with Sphinx
UID: |
SDOC-SRS-72 |
STATUS: |
Progress |
StrictDoc shall support exporting/importing requirements content from/to ReqIF format.
Parents:
[SDOC-SSS-58] ReqIF export/import
UID: |
SDOC-SRS-73 |
STATUS: |
Active |
StrictDoc shall maintain the core ReqIF implementation as a separate software component.
RATIONALE:
ReqIF is a well-defined standard which exists independently of StrictDoc’s development. It is reasonable to maintain the ReqIF codebase as a separate software component to allow independent development and easier maintainability.
Parents:
[SDOC-SSS-90] Long-term maintainability of a tool
UID: |
SDOC-SRS-74 |
StrictDoc shall allow exporting SDoc documents to Excel, one Excel file per document.
Parents:
[SDOC-SSS-60] Excel export/import
UID: |
SDOC-SRS-134 |
STATUS: |
Active |
StrictDoc Excel export shall allow exporting SDoc documents to Excel with only selected fields.
Parents:
[SDOC-SSS-60] Excel export/import
UID: |
SDOC-SRS-90 |
STATUS: |
Active |
StrictDoc shall support exporting requirements information to PDF format using Graphviz.
RATIONALE:
Graphviz is one of the most capable tools for visualizing graph information, which makes it a perfect tool for visualizing requirements graphs create in StrictDoc.
Parents:
[SDOC-SSS-56] 1000-feet view
UID: |
SDOC-SRS-103 |
StrictDoc shall provide a command-line interface.
Parents:
[SDOC-SSS-32] Command-line interface
UID: |
SDOC-SRS-85 |
STATUS: |
Active |
StrictDoc shall allow automatic generation of requirements UIDs.
Parents:
[SDOC-SSS-6] Auto-provision of Requirement UIDs
UID: |
SDOC-SRS-125 |
STATUS: |
Active |
StrictDoc shall provide a Python API for its core functions:
Reading SDoc files
Creating traceability graph
Generating HTML exports
Converting SDoc to other formats.
Parents:
[SDOC-SSS-79] General usability
[SDOC-SSS-86] Programming access via API (SDK)
[SDOC-SSS-87] Programmatic access to requirements data
UID: |
SDOC-SRS-126 |
STATUS: |
Active |
StrictDoc shall provide a web server.
RATIONALE:
A web server is a precondition for StrictDoc’s web interface. A web server can be available to a single user on their local machine or it can be deployed to a network and be made accessible by several computers.
Parents:
[SDOC-SSS-83] Server-based deployments (IT-friendly setup)
UID: |
SDOC-SRS-6 |
STATUS: |
Active |
StrictDoc’s default mode of operation shall treat all warnings as errors.
Parents:
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-37 |
StrictDoc shall support a configuration of project-level options through a TOML file named strictdoc.toml.
Parents:
[SDOC-SSS-92] Project-level configuration
UID: |
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.
Parents:
[SDOC-SSS-92] Project-level configuration
UID: |
SDOC-SRS-119 |
StrictDoc shall support configuring a host/port on which the StrictDoc web server is run.
Parents:
[DO178-8] Configuration: ‘Host’ parameter
UID: |
SDOC-SRS-1 |
STATUS: |
Active |
StrictDoc shall support process-based parallelization for time-critical tasks.
RATIONALE:
Process-based parallelization can provide a good speed-up when several large documents have to be generated.
Parents:
[SDOC-SSS-13] Support large requirements sets
[SDOC-SSS-14] Support large project trees
UID: |
SDOC-SRS-95 |
STATUS: |
Active |
StrictDoc shall implement caching of parsed SDoc documents.
Parents:
[SDOC-SSS-13] Support large requirements sets
[SDOC-SSS-14] Support large project trees
UID: |
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.
Parents:
[SDOC-SSS-13] Support large requirements sets
[SDOC-SSS-14] Support large project trees
UID: |
SDOC-SRS-3 |
StrictDoc shall cache the RST fragments rendered to HTML.
RATIONALE:
Conversion of RST markup to HTML is a time consuming process. Caching the rendered HTML of each fragment helps to save time when rendering the HTML content.
Parents:
[SDOC-SSS-13] Support large requirements sets
[SDOC-SSS-14] Support large project trees
UID: |
SDOC-SRS-4 |
StrictDoc’s web interface shall generate the HTML content only when it is directly requested by a user.
RATIONALE:
Generating a whole documentation tree for a user project can be time consuming. The on-demand loading ensures the “do less work” approach when it comes to rendering the HTML pages.
Parents:
[SDOC-SSS-13] Support large requirements sets
[SDOC-SSS-14] Support large project trees
UID: |
SDOC-SRS-5 |
StrictDoc shall support a precompilation of HTML templates.
RATIONALE:
The StrictDoc-exported HTML content visible to a user is assembled from numerous small HTML fragments. Precompiling the HTML templates from which the content gets rendered improves the performance of the HTML rendering.
Parents:
[SDOC-SSS-13] Support large requirements sets
[SDOC-SSS-14] Support large project trees
UID: |
SDOC-SRS-133 |
All critical issues reported in relation to StrictDoc shall be addressed with utmost priority.
RATIONALE:
Prioritizing major issues ensures StrictDoc remains stable and reliable, preventing serious problems that could compromise its performance and integrity.
Parents:
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-128 |
STATUS: |
Active |
StrictDoc’s development shall be requirements-based.
Parents:
[SDOC-SSS-78] Tool qualification
[SDOC-SSS-76] Requirements engineering
UID: |
SDOC-SRS-91 |
STATUS: |
Active |
StrictDoc’s requirements shall be written using StrictDoc.
Parents:
[SDOC-SSS-50] Self-hosted requirements
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-8 |
STATUS: |
Active |
StrictDoc shall be written in Python.
RATIONALE:
Python has an excellent package ecosystem. It is a widely used language. It is most often the next language for C/C++ programming community when it comes to the tools development and scripting tasks.
Parents:
[SDOC-SSS-69] Conservative languages for implementation
UID: |
SDOC-SRS-9 |
STATUS: |
Active |
StrictDoc shall support the Linux operating systems.
Parents:
[SDOC-SSS-67] Support major operating systems
UID: |
SDOC-SRS-10 |
STATUS: |
Active |
StrictDoc shall support the macOS operating system.
Parents:
[SDOC-SSS-67] Support major operating systems
UID: |
SDOC-SRS-11 |
STATUS: |
Active |
StrictDoc shall support the Windows operating system.
Parents:
[SDOC-SSS-67] Support major operating systems
UID: |
SDOC-SRS-89 |
STATUS: |
Active |
StrictDoc shall be built using only open source software components.
RATIONALE:
No commercial/proprietary dependency chain ensures that StrictDoc remain free and open for everyone.
Parents:
[DO178-7] No use of proprietary technology
[SDOC-SSS-39] Only open source dependencies
UID: |
SDOC-SRS-14 |
STATUS: |
Active |
StrictDoc shall avoid using large and demanding UI frameworks.
NOTE: An example of frameworks that require a very specific architecture: React JS, AngularJS.
Parents:
[SDOC-SSS-90] Long-term maintainability of a tool
UID: |
SDOC-SRS-15 |
STATUS: |
Active |
StrictDoc shall avoid extending its infrastructure with anything based on NPM-ecosystem.
RATIONALE:
StrictDoc already deals with the Python/Pip/Pypi ecosystem. The amount of necessary maintenance is already quite high. NPM is known for splitting its projects into very small parts, which increases the complexity of maintaining all dependencies.
Parents:
[SDOC-SSS-90] Long-term maintainability of a tool
UID: |
SDOC-SRS-16 |
STATUS: |
Active |
StrictDoc shall avoid using JavaScript-based programming languages.
RATIONALE:
The development team does not have specific experience with any of the JS alternatives. Staying with a general subset of JavaScript is a safer choice.
Parents:
[SDOC-SSS-90] Long-term maintainability of a tool
UID: |
SDOC-SRS-87 |
STATUS: |
Active |
StrictDoc shall avoid using microservices and microservice-based architectures.
RATIONALE:
The project is too small to scale to a multi-service architecture.
COMMENT:
This requirement could be re-considered only if a significant technical pressure would require the use of microservices.
Parents:
[SDOC-SSS-82] Individual use (home PC)
UID: |
SDOC-SRS-88 |
STATUS: |
Active |
StrictDoc shall avoid using containers and containerization technologies.
RATIONALE:
Containers are significant extra layer of complexity. They are hard to debug.
COMMENT:
This constraint does not block a StrictDoc user from wrapping StrictDoc into their containers.
Parents:
[SDOC-SSS-82] Individual use (home PC)
UID: |
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.
Parents:
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-41 |
StrictDoc’s development shall ensure a use of type annotations throughout the project’s Python codebase.
Parents:
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-42 |
StrictDoc’s development shall ensure that the project’s codebase is compliant with the modern Python community’s practices.
Parents:
[SDOC-SSS-90] Long-term maintainability of a tool
UID: |
SDOC-SRS-43 |
STATUS: |
Active |
StrictDoc’s development shall include a continuous type checking of StrictDoc’s codebase.
Parents:
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-44 |
STATUS: |
Active |
StrictDoc’s development shall provide unit testing of its codebase.
Parents:
[SDOC-SSS-77] Test coverage
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-45 |
StrictDoc’s development shall provide complete black-box integration testing of its command-line interface.
Parents:
[SDOC-SSS-77] Test coverage
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-46 |
STATUS: |
Active |
StrictDoc’s development shall provide complete end-to-end testing of the web interface.
Parents:
[SDOC-SSS-77] Test coverage
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-47 |
STATUS: |
Active |
Every update to the StrictDoc codebase shall be complemented with a corresponding provision of at least one test as follows:
For web interface: at least one end-to-end test.
For command-line interface: at least one black-box integration test.
For internal Python functions: at least one unit test.
NOTE: This requirement implies that no modifications to StrictDoc’s functionality can be merged unless accompanied by at least one test.
RATIONALE:
This requirement ensures that every new feature or a chance in the codebase is covered/stressed by at least one test, according to the change type.
Parents:
[SDOC-SSS-77] Test coverage
[SDOC-SSS-78] Tool qualification
UID: |
SDOC-SRS-12 |
STATUS: |
Active |
StrictDoc’s source code shall be hosted on GitHub.
Parents:
[SDOC-SSS-38] Open source
[SDOC-SSS-82] Individual use (home PC)
UID: |
SDOC-SRS-118 |
STATUS: |
Active |
All StrictDoc software shall be licensed under the Apache 2 license.
Parents:
[SDOC-SSS-40] Free