Type | Level | UID | STATUS | TAGS | REFS | Title | Statement | Rationale | Comment | ||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Section | 1 |
Project goals
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
Free text | – |
StrictDoc is an attempt to create an open source tool for writing technical requirements specifications. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.1 | GOAL-1-TOOL-SUPPORT | Children: |
Software support for writing requirements and specifications documents
|
There shall exist free and lightweight yet capable software for writing requirements and specifications documents |
Technical documentation is hard, it can be an extremely laborious process. Software shall support engineers in their work with documentation. | |||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.2 | GOAL-2-REDUCE-DOCUMENTATION-HAZARDS |
Reduce documentation hazards
|
There shall exist no (or less) opportunity for writing incorrect or inconsistent documentation. |
Every serious engineering activity, such as safety engineering or systems engineering, starts with requirements. The more critical is a product the higher the importance of good documentation. Technical documentation can be and often becomes a source of hazards. It is recognized that many failures stem from inadequate requirements engineering. While it is not possible to fix the problem of inadequate requirements engineering in general, it is definitely possible to improve software that supports engineers in activities such as requirements engineering and writing technical documentation. | ||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.3 | GOAL-3-NO-RUNAWAY-DOCUMENTATION |
No (or less) run-away documentation
|
Software shall support engineers in keeping documentation up-to-date. |
Technical documentation easily becomes outdated. Many existing tools for documentation do not provide any measures for ensuring overall consistency of documents and documentation trees. | ||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 1.4 | GOAL-4-CHANGE-MANAGEMENT |
Change management
|
Software shall provide capabilities for change management and impact assessment. |
Change management is difficult. The bigger the project is, the harder it is to maintain its documentation. If a change is introduced to a project, it usually requires a full revision of its requirements. When the basic capabilities of StrictDoc are in place, it should be possible to do a more advanced analysis of requirements and requirement trees:
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 2 |
User interfaces
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
Free text | – |
There are two user interfaces for StrictDoc:
The CLI interface is already developed, the web interface is (slow) work-in-progress. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 2.1 | UI-1-TEXT |
Command-line interface
|
StrictDoc shall provide a command-line interface. |
|||||||||||||||||||||||||||||||||||||||||||||||||||
Requirement | 2.2 | UI-2-WEB |
Web interface
|
StrictDoc shall provide a web interface. |
|||||||||||||||||||||||||||||||||||||||||||||||||||
Section | 3 |
Development team
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
Free text | – |
StrictDoc is a spare time project developed and maintained by two people with occasional contributions from the Open Source community. |