rmtoo-config

NAME

rmtoo-config - requirements management tool configuration file version 3

DESCRIPTION

rmtoo needs some information to work, like input directories and which artifacts should be created. This information is stored in one or more configuratio files.

The format of the configuration files is JSON. As alternative the same information can be provided also as YAML. Please see the rmtoo-config4 man page for details. 1.SH EXAMPLE The following example is the configuration file for the rmtoo requirements management tool.

In the example, three different sets of documents (output artifacts) will be created: one document set containing prios, graph, stats, latex2 and html e.g. for internal use is called all_topics. One document for marketing which contains the latex2 document and the requirements dependency graph called marketing_topic. One document for a customer which uses a separate set of requirements. This is called customer_topic.

{
"global": {
"modules": {
"directories": [
"."
]
},

}
},
"processing": {
"analytics": {
"stop_on_errors": false
}
},
"requirements": {
"input": {
"default_language": "en_GB",
"dependency_notation": [
"Solved by"
]
},
"inventors": [
"flonatel"
],
"stakeholders": [
"development",
"management",
"users",
"customers"
]
},
"topics": {
"ts_common": {

"output": {
"graph": [
{
"output_filename": "artifacts/req-graph1.dot"
}
],
"graph2": [
{
"output_filename": "artifacts/req-graph2.dot"
}
],
"html": [
{
"footer": "doc/html/footer.html",
"header": "doc/html/header.html",
"output_directory": "artifacts/html"
}
],
"latex2": [
{
"output_filename": "artifacts/reqtopics.tex"
}
],
"oopricing1": [
{
"output_filename": "artifacts/reqspricing"
}
],
"prios": [
{
"output_filename": "artifacts/reqsprios.tex",
"start_date": "2011-04-25"
}
],
"stats_burndown1": [
{
"output_filename": "artifacts/stats_burndown.csv",
"start_date": "2011-04-25"
}
],
"stats_reqs_cnt": [
{
"output_filename": "artifacts/stats_reqs_cnt.csv"
}
],
"tlp1": [
{
"output_filename": "artifacts/reqdeps1.tlp"
}
],
"version1": [
{
"output_filename": "artifacts/reqs-version.txt"
}
]
}
}
}
}

DETAILS

The file must contain a map (dictionary) as the top level element. Valid keys for the top level map are: global, processing, requirements, topics.

global
There are two possible entries in the global map: modules and logging. The only available entry in the modules map is directories. The value must be a list of directories where modules are searched. Details about configuration the logging can be found in the section LOGGING DETAILS.

processing
The only available entry in the processing map is analytics. The only available entry in the analytics map is stop_on_errors. The value must be a boolean which reflects if rmtoo should stop on errors or not.

requirements
There are three possible values in the requirements map: input, inventors and stakeholders. Please see chapter REQUIREMENTS DETAILS.

topics
The configuration parameter topics is a map. The key is the name with which the entry can be referenced. For a description about the details, please see chapter TOPICS DETAILS.

LOGGING DETAILS

There are two logging streams which can be configured seperately: one is the stdout stream and the other is a file. All log messages are sent to both strams. With the help of the configuration it is possible to filter out only those which may be of some interest.

Configuring the stdout, the key must be stdout. The value must be a map with the entry loglevel. The value of the loglevel must be one of ’debug’, ’info’, ’warn’, ’error’.

The configuration for the file logging is very similar. The key is tracer. It also supports the loglevel entry which is described under stdout. There can be an additional entry called filename which is the name of the file where everything should be logged to.

Please note: due to the fact that the logging can be configured, reading in the configuration is logged with the default logging values.

REQUIREMENTS DETAILS

The input section defines properties of the requirement input format handling. Possible values are default_language, dependency_notation, or txtfile.

default_language The paramter default_language specifies the language in which the requirements are written. This must be a standard language specifier like en_GB or de_DE. Please consult the rmtoo-analytics-descwords(7) man page for the list of available languages.

dependency_notation The parameter dependency_notation determines the way dependencies are specified. There are two ways how requirements can be specified: Depends on and Solved by. The last one is the preferred way of specifying dependencies - but the first is the old and default one. Therefore it is recommended to set the value to Solved by only.

txtfile This defines limitations while parsing the text file. By default for all different types of input, the maximum length of a line is 80. To change this, add the type (e.g. ’reqtag’ for requirments or ’ctstag’ for constraints). This map can contain the entry max_line_length which can be set to the new maximum line length.

inventors
This must be a list of string specifying inventors. Inventors can invent a requirement. Tags: Invented by.

stakeholders
This must be a list of strings specifying the stakeholders. Stakeholders can own a and prioritize a requirement. Tags: Owner and Priority.

TOPICS DETAILS

Each topic contains configuration is a map as a value which the name of the topic set as the key.

The map can contain the following entries: sources and output.

name The name of the entry node of the topic. It is possible to use the same directory but another entry name for additional topic specifications. This makes it possible to easily use a sub-topic for a complete set of output documents.

sources The sources to build up the documents from. Please consult the section SOURCES for more details.

output The output specification. Please consult the section OUTPUT for more details.

SOURCES

The sources are a list of sources from possible different input access methods. Currently there are two input access methods supported: files in the filesystem and files from a version control system like git.

The key in the map defines the access method name: eihter ’git’ or ’filesystem’.

For git the following attributes must be defined: start_vers, end_vers, requirements_dirs, topics_dirs, topic_root_node and constraints_dirs.

For filesystem the following attributes must be defined: requirements_dirs, topics_dirs, topic_root_node and constraints_dirs. (Which are the same as for git - except that the version information is missing - which is not needed for files in the filesystem.)

The given intervals are concatenated and rmtoo works on all of them. Some output modules e.g. statistics are based on the whole input. Mostly all other operations are done on the last entry only.

start_vers, end_vers The values are either git version numbers (md5 sums) or tag names.

An entry like "start_vers": "v9" and "end_vers": "HEAD" specifies all checked in files (ignoring possible changes of local files) beginning from the tag v9 up to the HEAD of git.

requirements_dirs This contains a list of directories where the requirements are read from.

topics_dirs A list of directories where the topics are read from.

topic_root_node The name of the master (first) topic to read.

constraints_dirs A list of directories where the constraints are read from.

constraints
The only available entry in the constraints map is search_dirs. The value is a list of directories where constraints definitions are searched.

OUTPUT

The output which rmtoo writes out for one topic in different formats must be specified with the help of the output variable. The key describes the artifact to output, the value is specific to the chosen output parameter.

graph
When this option is specified a requirements dependency graph is written. Please see rmtoo-art-req-dep-graph(1) for more details.

graph2
This is similar to the graph - but additionally groups the output requirements within the same topic as a cluster. Please see rmtoo-art-req-dep-graph2(1) for more details.

latex2
When latex2 is specified as output, rmtoo outputs a LaTeX document as output. For a detailed description about the needed parameters and a detailed description, see rmtoo-art-latex2(1).

oopricing1
This is a pricing module with ODF output. It can be used for commercial bidding. See rmtoo-art-oopricing1 for further details.

prios
This outputs a small LaTeX formatted artifact which includes the priority list and the requirements elaboration list. For more details consult rmtoo-art-prio-lists(1).

stats_reqs_cnt
When using git as the underlying revision control system it is possible to create a history of the number of requirements. See rmtoo-art-reqs-history-cnt(1) for more details.

version1
The version1 output writes the currently used version from the version control system to a file. This can then be used by other output documents.

xml1
This outputs the requirements as an xml file. See rmtoo-art-xml1(1) for details.

HISTORY

This is the third version of the configuration file format. This has some major advantages over the first versions: changing the format to JSON enables the possibility to use other programing languages than python to be used - especially with a possible future GUI in mind. Also the new format provides more flexibility: it is now possible to output two different documents of the same type (e.g. LaTeX documents) for the same topic set in only one rmtoo call.

SEE ALSO

rmtoo(7) - overview of rmtoo including all references to available documentation.

AUTHOR

Written by Andreas Florath (rmtoo@florath.net)

COPYRIGHT

Copyright © 2010-2012 by flonatel (rmtoo@florath.net). License GPLv3+: GNU GPL version 3 or later