Dynamic Behaviour

Main

This is the base workflow:

../../_images/main_workflow.drawio.png

Fig. 11 Main workflow

Notes:

  • Not all subcommands require to load files, e.g. for printing the version.

  • If any action fails, the exit code is set to 1 instead of 0.

  • Exceptions are not caught. If a Ruby application terminates abnormally, the exit code is set to a value != 0 depending on the exception type.

Parse Options

../../_images/options.drawio.png

Fig. 12 Options

The outcome of this workflow can be either:

  • An option was found which causes the tool to gracefully exit immediately, e.g. after printing the license.

  • Parsing failed, e.g. something is missing, invalid or inconsistent.

  • All options successfully loaded and stored globally.

Load Files

../../_images/loader.drawio.png

Fig. 13 Loader

Load:
If a filename was specified in the options, this loader workflow is executed. The file can be a config file or a requirements file. A config file can refer to one or more requirements files.
Store:
Loaded requirements are harmonized, which means not specified attributes will become empty strings. This makes further processing easier. The result of this harmonization is called original data and stored in the loader instance. It is used by e.g. the format subcommand. Afterwards the default values get resolved and are set for empty attributes if applicable.
Check:
At the end the consistency is always checked, independently from the subcommand.

Execute Subcommand

../../_images/subcommand.drawio.png

Fig. 14 Subcommands

This part of the program flow is straight forward. Depending on the command line options, the appropriate subcommand is executed. Invalid subcommand options were already handled in Parse Options.

Subcommand “check”

This subcommand is just a dummy and completely empty. The consistency check is always done when loading the files.

Subcommand “export”

../../_images/export.drawio.png

Fig. 15 Exporting requirements

The files are exported to a specific output folder in a specific type specified with command line options. A filter can be specified to export only a part of the requirements. Files like images listed in the enclosed attribute of the input file are also copied to the output folder.

The algorithm is always the same, but internally different implementations of the ExporterInterface (see Classes) are called depending on the type which can be RST, JSON and CSV.

RST

Requirements are exported to Sphinx so that the dox_trace extension of Sphinx can understand the content and generate a nice HTML view.

This is the only export type where an index file is generated (with the Sphinx toctree element).

JSON

This exporter simply uses the Ruby JSON library to convert the requirement objects to JSON objects which can be written to the output folder.

No index file is written.

CSV

The requirements are converted to a CSV format.

No index file is written.

Subcommand “format”

../../_images/format.drawio.png

Fig. 16 Formatting input files

The following types of formatting are possible:

  • in-place: See use case Change Requirements.

  • check-only: Executed from the verifier in the Version Control System use case.

  • extra: A debugging feature to write to separate files instead of changing the input files directly.

  • stdout: similar to extra, but writing the output to the console.

Subcommand “stats”

../../_images/stats.drawio.png

Fig. 17 Printing statistics

This subcommand prints generic statistics of the requirements specified in the input files like number of total number of requirements and number of accepted or rejected requirements.