florath/rmtoo

.\" 
.\" Man page for rmtoo configuration version 1
.\"
.\" This is free documentation; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License as
.\" published by the Free Software Foundation; either version 3 of
.\" the License, or (at your option) any later version.
.\"
.\" The GNU General Public License's references to "object code"
.\" and "executables" are to be interpreted as the output of any
.\" document formatting or typesetting system, including
.\" intermediate and printed output.
.\"
.\" This manual is distributed in the hope that it will be useful,
.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
.\" GNU General Public License for more details.
.\"
.\" (c) 2010-2011 by flonatel (rmtoo@florath.net)
.\"
.TH rmtoo-config 5 2011-02-14 "User Commands" "Requirements Management"
.SH NAME
rmtoo-config1 \- requirements management tool configuration file version 1
.SH DEPRECATION WARNING
\fBThe 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).
.SH DESCRIPTION
One parameter calling the 
.B rmtoo
requirements management tool is the configuration file.  (For a
detailed description about command line parameters see
\fBrmtoo-invoking(1)\fR). 
.P
The configuration file is a python file which must define a class
named \fIConfig\fR.  See the \fBDETAILS\fR section for an explanation
about the configuration parameters.
.SH EXAMPLE
The following example is the configuration file for the 
.B rmtoo
requirements management tool.
.P
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 \fIall_topics\fR.  One
document for marketing which contains the latex2 document and the
requirements dependency graph called \fImarketing_topic\fR.  One
document for a customer which uses a separate set of requirements.
This is called \fIcustomer_topic\fR.
.sp
.RS
.nf
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 = \
    {
       "requirements": { "max_line_length": 80 },
       "topics": { "max_line_length": 990 },
    }

.SH DETAILS
The class \fBConfig\fR must contain some class level variables.
.SS stakeholders
This must be a list of strings specifying the stakeholders.
Stakeholders can own a and prioritize a requirement.  Tags:
\fIOwner\fR and \fIPriority\fR.
.SS inventors
This must be a list of string specifying inventors.  Inventors can
invent a requirement. Tags: \fIInvented by\fR.
.SS reqs_spec
This is the definition of the set of requirements \fBrmtoo\fR uses.
It is a dictionary: the entry named \fIdirectory\fR is the name of the
directory where all the requirements can be found.
.P
The entry named \fIcommit_interval\fR 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 \fBrmtoo\fR
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 \fIFILES\fR can be used.  This
references to the local stored files.
.P
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.
.P
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.
.P
The paramter \fIdefault_language\fR specifies the language in
which the requirements are written.  This must be a standard language
specifier like \fIen_GB\fR or \fIde_DE\fR. Please consult the 
\fBrmtoo-analytics-descwords(7)\fR man page for the list of available
languages. 
.P
The parameter \fIdependency_notation\fR determines the way
dependencies are specified.  There are two ways how requirements can
be specified: \fIDepends on\fR and \fISolved by\fR.  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
\fISolved by\fR only.
.SS topic_specs
The configuration parameter \fItopic_spec\fR 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.
.SS analytics_specs
The configuration parameter \fIanalytics_specs\fR is a map.  See
\fBrmtoo-analytics(7)\fI for a detailed description of the
parameters. 
.SS output_specs
The variable \fIoutput_specs\fR 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 \fBOUTPUT\fR for further details.
.SS parser
The parser is a map which contains two entries: \fIrequirements\fR
and \fItopics\fR 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 \fImax_line_length\fR to specify the maximum line
length of the input files. If this is not specified, the default is 80
characters. 
.SH OUTPUT
The output which 
.B rmtoo
writes out in different formats must be specified with the help of the
\fIoutput_specs\fR variable.  The key describes the artifact to
output, the value is specific to the chosen output parameter.
.SS graph
When this option is specified a requirements dependency graph is
written.  Please see \fBrmtoo-art-req-dep-graph(1)\fR for more
details.
.SS graph2
This is similar to the graph - but additionally groups the output
requirements within the same topic as a cluster.  Please see
\fBrmtoo-art-req-dep-graph2(1)\fR for more details.
.SS latex2
When \fIlatex2\fR is specified as output,
.B rmtoo
outputs a LaTeX document as output.  For a detailed description about
the needed parameters and a detailed description, see
\fBrmtoo-art-latex2(1)\fR. 
.SS oopricing1
This is a pricing module with ODF output.  It can be used for
commercial bidding. See \fBrmtoo-art-oopricing1\fR for further
details. 
.SS prios
This outputs a small LaTeX formatted artifact which includes the
priority list and the requirements elaboration list.  For more details
consult \fBrmtoo-art-prio-lists(1)\fR.
.SS stats_reqs_cnt
When using \fIgit\fR as the underlying revision control system it is
possible to create a history of the number of requirements.  See
\fBrmtoo-art-reqs-history-cnt(1)\fR for more details.
.SS 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. 
.SS xml1
This outputs the requirements as an xml file. See \fBrmtoo-art-xml1(1)\fR 
for details.
.SH "SEE ALSO"
.B rmtoo(7)
- overview of rmtoo including all references to available documentation. 
.SH AUTHOR
Written by Andreas Florath (rmtoo@florath.net)
.SH COPYRIGHT
Copyright \(co 2010-2011 by flonatel (rmtoo@florath.net).
License GPLv3+: GNU GPL version 3 or later