rmtoo-config

NAME

rmtoo-config1 - requirements management tool configuration file version 1

DEPRECATION WARNING

The use of this configuration file format is deprecated and will be supported upto version 20. For new projects use the new configuration file format which is described in rmtoo-config3(5).

DESCRIPTION

One parameter calling the rmtoo requirements management tool is the configuration file. (For a detailed description about command line parameters see rmtoo-invoking(1)).

The configuration file is a python file which must define a class named Config. See the DETAILS section for an explanation about the configuration parameters.

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.

class Config:
stakeholders = ["development", "management", "users",
"customers"]
inventors = ["flonatel", ]

reqs_spec = {
"directory": "doc/requirements",
"commit_interval":
["93c4951bed1a01c82342e370be891a5fc569985f", "FILES"],
"default_language": "en_GB",
"dependency_notation": set(["Solved by", ])
}

topic_specs = {
"all_topics": ["doc/topics", "ReqsDocument"],
"marketing_topic": ["doc/topics", "Marketing"],
"customer_topic": ["doc/cust_topics", "Customer"],
}

analytics_specs = {
"stop_on_errors": False,
"topics": "all_topics",
}

output_specs = [
["prios",
["all_topics", "doc/latex2/reqsprios.tex"]],

["graph",
["all_topics", "reqtree.dot"]],

["stats_reqs_cnt",
["all_topics", "doc/latex2/stats_reqs_cnt.csv"]],

["latex2",
["all_topics", "doc/latex2/reqtopics.tex"]],

["html",
["all_topics",
"doc/html/reqs", "doc/html/header.html",
"doc/html/footer.html"]],

["graph",
["marketing_topic", "marketing_reqtree.dot"]],

["latex2",
["marketing_topic", "doc/latex2/marketing.tex"]],

["latex2",
["customer_topic", "doc/latex2/customer.tex"]],

["oopricing1",
["ts_common", "reqspricing"]],

["version1",
["ts_common", "reqs-version.txt"]],

]

parser =

DETAILS

The class Config must contain some class level variables.

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

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

reqs_spec
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.

The entry named commit_interval is a list (pair) of start and end specification: these 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.

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.

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.

topic_specs
The configuration parameter topic_spec is a map. The key is the name with which the entry can be referenced. The value is a list containing two elements. The first is the directory where all the topics for this topic set can be found. The second is the initial (first) topic.

analytics_specs
The configuration parameter analytics_specs is a map. See rmtoo-analytics(7) for a detailed description of the parameters.

output_specs
The variable output_specs must be a list which contains pairs. Each pair itself is a list containing two elements: the first is the name of the output module, the second is the list of parameters for the given output module. For details about the different output modules, see section OUTPUT for further details.

parser
The parser is a map which contains two entries: requirements and topics to specify the appropriate parser. Each entry is also a map. Currently the only parameter which can used here in this inner map is the parameter max_line_length to specify the maximum line length of the input files. If this is not specified, the default is 80 characters.

OUTPUT

The output which rmtoo writes out in different formats must be specified with the help of the output_specs 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.

SEE ALSO

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

AUTHOR

Written by Andreas Florath (rmtoo@florath.net)

COPYRIGHT

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