rmtoo - requirements management tool
The rmtoo package is used to work on a set of requirements and create artifacts from them.
rmtoo uses a different approach than most other requirements management tools: it comes as a command line tool optimized for handling requirements. The power of rmtoo is that a typical development environment can handle the input files with ease, as they are plain text.
rmtoo input files can be handled by mostly all standard *nix commands like grep(1), awk(1) or sed(1). When replacing text, commands like streplace(1) can be used.
rmtoo is a tool. It helps everybody who understands Requirements Management. It does not turn people into Requirements Management experts. You have to know what you are doing!
rmtoo gives everybody the unique chance to adapt the tools to their needs and their processes because it’s open source. Often other tools force the user to change their habits or processes. With rmtoo the user has the control.
The output of requirements is handled in groups of requirements - so called topics. Each requirement belongs to exactly one topic. Typically a topic corresponds to one section; a topic can have sub-topic (sub-sections). For further information please consult the section TOPIC
For handling history and baselines an arbitrary revision control system can be used (such as git, mercurial, subversion ...). Nevertheless currently rmtoo supports git as default for version access and statistics.
Let one thing do one thing.
rmtoo is no integrated, ’do-everything’ tool as it comes with no GUI at all.
The rmtoo requirements management tool works on a set of requirements. It reads them in, parses them, preprocesses them and checks them for syntactic and semantic problems. If no errors are found, all artifacts which are specified are generated.
This page is an overview page. It gives a short overview of the uses of rmtoo. Also it points to other man pages where information about input and output files can be found.
The rmtoo reads in a set of input files: requirements and topics.
These files are plain text files stored in the file system. rmtoo parses these files and runs some checks on them. These checks include syntax checks, semantic checks and some heuristics to provide ideas for improving the quality of the requirements.
After passing these checks, rmtoo outputs all configured artifacts, like PDF or HTML documents, dependency graphs or statistics.
rmtoo uses a unique method for describing and handling output: so called topics. A topic is a description of one set of related requirements. It has a name and contains text, requirements and other topics. With topics it is possible to build hierarchies of document output structures. In a PDF file a topic may be one chapter which includes other topics which are handled as sections, for example. Using HTML output, each topic corresponds to one HTML page, while a subtopic is a link to the appropriate (sub-)topic HTML page it represents. When using graph output the requirements of a topic are clustered.
This makes it possible to define the output structure once (in so called topic files) and use this structure over and over for all different output artifacts.
It is possible (by adding one additional line in the configuration file) to create an independent and self-contained (set of) document(s) from an arbitrary sub-topic. This makes it possible, for example, to create a separate document for the marketing department which bears no relation to technical decisions and security requirements.
Of course it is also possible to map one set of requirements to a completely different set of topics. This makes it possible to have one set of requirements for internally used project documentation and another for an external company which delivers only one small part of the whole project.
rmtoo is a requirements management tool in the sense that it is possible to mange the typical requirements documents with the help of the tool.
Strictly speaking most so called requirements are not ’really’ requirements but ’decisions’. Example: it is not a requirement that a company want to build a EMail Client, it is the decision of the marketing department.
If a decision is made, more decisions will follow (e.g. which operating system to support, how should the GUI looks like, which mail protocols to implement).
A requirement is something, which is really needed in the sense to realize the design decision which were made. Example: if it is decided to use SMTP, there is a must that the appropriate specification (RFC) is implemented. There is no other way.
Two definitions:
A requirement is something which must be done to implement / realize the previous made decisions. There is no other way.
A (design) decision is something which is chosen from a list of alternatives.
It is very important to show and vizualize what a design decision and what a requirement is. rmtoo supports this concept.
Requirements and decisions live in trees. There is always a root which comes first (and typically describes the whole project / product).
All other requirements and decisions depend on this. This first decision entails other decisions / requirements - which agains entail futher decisions and requirements. This is what the so called requirements management process is about.
In a project all requirements and design decisions are connected in some way. There are no separate ones.
The possible solutions of requirements are mostly always limited: Software must run on a specific hardware or operating system, a device must have a minimal shock resistance.
The main difference between requirements and constraints is, that constraints are inherited: when a requirement has one constraint, all the dependent ones inherit this constraint. For example: if one device has a minimal shock resistance of 7G all it’s parts must also have a minimal shock resistance of 7G.
It is possible that a requirement has a constraint and this constraint is also inherited from a parent. In this case it must be individually decided how to handle this. Example: A device must be designed which has a minimal shock resistance of 7G. One component you already designed some time ago can be reused for the new device. The decision whether this component can be used or not depends on it’s minimal shock resistance: if the minimal shock resistance of the device is lower or equal, it is possible to use this component in the new device. If it is higher, it is not possible to use the component to build up the new device.
rmtoo supports constraints. rmtoo supports automatic constraint checking.
rmtoo-invoking(1)
- overview of command line parameters executable for
requirements
management
rmtoo-normalize-dependencies(1) - convert dependency notation.
rmtoo-template-project(1) - template project
rmtoo-req-format(5) - format description for requirement files
rmtoo-topic-format(5) - format description for topic files
rmtoo-testcase-format(5) - format description for test case files
rmtoo-constraints(5) - format description for constraints files
rmtoo-config3(5) - description of the config file which is needed for rmtoo environment definition and output specification in YAML format.
rmtoo-config2(5) - description of the config file which is needed for rmtoo environment definition and output specification in JSON format.
rmtoo-analytics(7) - general concept for handling analytics on requirements
rmtoo-analytics-descwords(7) - heuristic for word evaluation in the requirement description
rmtoo-analytics-hotspot(7) - check incoming and outgoing links
rmtoo-analytics-topic-coherence(7) - check topic in-link against out-link numbers
rmtoo-analytics-req-topic-coherence(7) - check topic of a requirement for in-link against out-link numbers
rmtoo-art-req-dep-graph(1) - output description of the requirements dependency graph
rmtoo-art-req-dep-graph2(1) - output description of the requirements dependency graph - version 2
rmtoo-art-html(1) - html artifact output
rmtoo-art-latex2(1) - output description for LaTeX output of all requirements
rmtoo-art-oopricing(1) - output description for ODF commercial price bidding
rmtoo-art-prio-lists(1) - output description for the backlog and list of requirements for elaboration.
rmtoo-art-reqs-history-cnt(1) - output description of the requirement history count.
rmtoo-art-stats-burndown1(1) - output the burndown diagram for the whole project.
rmtoo-art-stats-sprint-burndown1(1) - output the burndown diagram for the current sprint.
rmtoo-art-xml1(1) - output requirements as xml - version 1.
rmtoo-art-tlp1(1) - tulip graph output - version 1
rmtoo-art-xml-ganttproject1(1) - [deprecated] output requirements as project plan for ganttproject version 1.
rmtoo-art-xml-ganttproject2(1) - output requirements as project plan for ganttproject version 2.
rmtoo-pricing-graph(1) - creates graph from pricing
rmtoo-emacs-mode-req(7) - major mode for Emacs for writing requirements
Written by Andreas Florath (rmtoo@florath.net)
Copyright © 2010-2012 by flonatel (rmtoo@florath.net). License GPLv3+: GNU GPL version 3 or later