The use of this configuration file format is deprecated and in supported in version 21 only. For new projects use the new configuration file format which is described in rmtoo-config3(5).
rmtoo-config - requirements management tool configuration file version 2
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.
This is the second version of the configuration file format. This has some major advantages over the first version: changing the format to JSON enables the possibility to use other programing languages than python to be used - esspecially 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.
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.
{
"constraints": {
"search_dirs": [
"rmtoo/collection/constraints"
]
},
"global": {
"modules": {
"directories": [
"."
]
}
},
"processing": {
"analytics": {
"stop_on_errors": false
}
},
"requirements": {
"input": {
"commit_interval": {
"begin": "FILES",
"end": "FILES"
},
"default_language": "en_GB",
"dependency_notation": [
"Solved by"
],
"directory": "doc/requirements",
|
"txtfile": { "reqtag": { "max_line_length": 80 } } |
},
"inventors": [
"flonatel"
],
"stakeholders": [
"development",
"management",
"users",
"customers"
]
},
"topics": {
"all_topics": {
"directory": "doc/topics",
"name": "ReqsDocument",
"output": {
"graph": [
{
"output_filename":
"artifacts/req-graph1.dot"
}
],
"html": [
{
"footer": "doc/html/footer.html",
"header": "doc/html/header.html",
"output_directory": "artifacts/html"
}
],
"latex2": [
{
"output_filename":
"artifacts//reqtopics.tex"
}
],
"prios": [
{
"output_filename":
"artifacts/reqsprios.tex",
"start_date": "2011-04-25"
}
],
"stats_reqs_cnt": [
{
"output_filename":
"artifacts/stats_reqs_cnt.csv"
}
],
}
"marketing_topics": {
"directory": "doc/topics",
"name": "ReqsDocument",
"output": {
"graph": [
{
"output_filename":
"artifacts/req-graph1-marketing.dot"
}
],
"latex2": [
{
"output_filename":
"artifacts/reqtopics-marketing.tex"
}
],
}
"customer_topics": {
"directory": "doc/customer_topics",
"name": "InitialReq",
"output": {
"latex2": [
{
"output_filename":
"artifacts/reqtopics-customer.tex"
}
],
}
}
}
}
The file must contain a map (dictionary) as the top level element. Valid keys for the top level map are: constraints, global, processing, requirements, topics.
constraints
The only available entry in the constraints map is
search_dirs. The value is a list of directories where
constraints definitions are searched.
global
The only available entry in the global map is
modules. The only available entry in the
modules map is directories. The value must be
a list of directories where modules are searched.
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.
input
The input section defines properties of the requirement
input format handling. Possible values are
commit_interval, default_language,
dependency_notation, directory or
txtfile.
commit_interval The commit_interval map has two entries: the begin and the end. The values are either git version numbers (md5 sums) or tag names. The given interval is used during the run of rmtoo and everything e.g. statistics in based (only) on this interval. Mostly all operations are done on the second entry. Additional to the git version strings, the special string FILES can be used. This references to the local stored files.
When both elements are the same, only this unique version is used. When using only files (e.g. during requirements elaboration) an entry like ["FILES", "FILES"] makes sense here: then only the locally stored files are used.
An entry like ["v9", "HEAD"] specifies all checked in files (ignoring possible changes of local files) beginning from the tag v9 up to the HEAD of git.
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.
directory This is the definition of the set of requirements rmtoo uses. It is a dictionary: the entry named directory is the name of the directory where all the requirements can be found.
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.
The topics contain one or more entries: the key is the name of the appropriate entry. The value is a map which can contain the following entries: directory, name or output.
directory The directory where the topic structure is defined.
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.
output The output specification. Please consult the section OUTPUT for more details.
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.
rmtoo(7) - overview of rmtoo including all references to available documentation.
Written by Andreas Florath (rmtoo@florath.net)
Copyright © 2010-2011 by flonatel (rmtoo@florath.net). License GPLv3+: GNU GPL version 3 or later