Package: reqqie
Reqqie - text based requirement management toolOverviewReqqie is a text based tool to manage requirements. It does so by parsing text files, rewriting them and output reports.
Future feature is to use git to automatically check versions/changes to requirements.
The input files uses the tdbase format.Getting startedInstall reqqie: "pip install reqqie"Create a file "test.req1" with the following content:.config:
  top_requirement -> R1

.req R1:
descr: This describes requirement R1
depends:
  -> R2

.req R2:
descr: This describes requirement R2Run reqqie: "reqqie test1.req". Note that if /Scripts are not in your path, you will have to use the full path to reqqie.Concepts:Reqqie uses tdbase to read a database of different records.
Record types are defined in the "input file format" section.
The most important one is naturally a requirement (req).The idea is that all requirements are connected in a Directed Acyclic Graph (DAG). In addition:all requirements should be connected through exactly one DAG. Ie, floating/free requirements are not allowed.There should be exactly one top requirement. All other requirements should be connected from "higher level" requirement(s).A simple example:R1 - top requirement. Depends on R2,R3,R4R2 - Leaf requirement (does not depend on other requirements)R3 - middle requirement (not top, but depends on other requirement(s)). Depends on R4R4 - Leaf requirement.This can be shown as (note that R4 appears twice, but is actually the same requirement):R1
  R2
  R3
    R4
  R4Another way to show this is:R1
    |
  +-+-+--+
  |   |  |
 R2   R3 |
      |  |
       R4Depending on the position in the DAG, every requirement get a numeric level. The top level requirement is always 1, and the others are "max(level of requirements that depends on it)+1". Ie:R1, numeric lvl 1R2, numeric lvl 2R3, numeric lvl 2R4, numeric lvl 3This numeric level is calculated by reqqie, and is an indication of how low level/high level a requirement is.In addition to the numeric levels, there can be "main levels", defined by the "main_levels" attribute in the config file. The main level is always manually given to each attribute. However, Reqqie will asure that no requirement from a lower level will depend on a requirement from a higher level. It is OK to depend on requirements in the same level though (but the numeric/automatic/fine grain levels assure that the graph is a DAG).A simple example of main levels are:main_levels:
        - system
        - design
        - moduleThis is a quite common distinction in simple projects. Ie, some requirements are on the "system" level, defining things on the overall system level, often more from usage point of view. More detailed requirements are on the "design" level, defining more from the design point of view. Lowest level in this simple model defines requirements on the module level.Besides the levels, requirement can have other metadata, further helping the understanding of the complete requirement set:categories. Categories are records in a parallell DAG. They define more what a requirement is about. For instance, categories for a SW product could be:System - top level category.Doc - documentationSW - software categorySW could be further divided in PC, Frontend, backend etc.tags. There are just free text tags.release. For project management, requirements can be attached to different releases, and then in reporting, requirement fulfillment per release can be tracked.stage: Every requirement goes through different stages. These are propagated up in the requirement DAG. See separate section regarding stages.Input file formatInput files are tdbase formatted. The record types supported are:.config - singleton record defining structure.category - tree structured data used to categorize requirement records.release - used to divide requirements into releases.req - an actual requirement.configSingleton record which defines structure etc for the requirementsAttributes:paths - list of paths (strs) where external files are checked.tags - list of strings. These are possible tags to further define what a requirement is. Completely optional.top_category - pointer to the top level category recordtop_requirement - pointer to the top level/main requirementmain_levels - list of strings which gives names to the main levels. There are sub levels automatically assigned, so no requirement ever depends on a requirement at the same or higher level..categoryEvery requirement should belong to a category. From a definition point of view, this normally reflects how broad or detailed a requirement is. There are some similarities with "level", but those are two different things..releaseFor project management, it is possible to tag requirements with different releases. Ie, a first release can normally not fulfill all requirements, but by tagging future requirements with later releases, it is possible to get status reports regarding requirement fulfillment for different releases..reqThis record defines one requirement.Attributes:descr - text string which describes the requirement. Ie, "General requirement for requirements"def - text string which defines the requirement. Normally a short sentence which "Shall" in it. Ie, "Requirements shall be testable and possible to measure. A clear pass/fail criteria shall exist."test-spec: either a text string or a link to external document that defines how to test the requirementtest: link to test report document that shows the test resultsstage:depends: list of links to other requirements which must be fulfilled for this requirement to be fulfilledcategory: link to category recordrelease: link to the release where this requirement must be fulfilled in.level: which main_level this requirement belongs tobackground: string or link to external document. Describes the reason for the requirement. This can be a very helpful information later on when revisiting requirements.Examples1. Minimal.config:
  top_category -> only_category
  top_requirement -> top_req

.category only_category:
  name: The one and only category

.req top_req:
  descr: Top requirement which links all other requirements.
  def: All dependant requirements shall be fulfilled and tested.
  depends:
    -> R2

.req R2:
  descr: Example requirement