QUESTION 1 Rmtoo comes without a graphical interface and in exchange, it uses a command line tool optimized for handling requirements. Why this decision?

rmtoo is based on the long history of *nix commands: Let one thing do one thing. In the *nix environment there are lots and lots small commands - each doing one thing - but perfectly, quickly and applicable in many different applications and environments.

rmtoo handles requirements - nothing more - nothing less. It does not deal with things like version control, history handling, branching or baselining. There are other good tools around which do this (such as svn, mercurial or git): so there is no need to reinvent the wheel.

The exact same argument applies to the GUI: there are lots of good editing applications which are able to edit requirements. There are also lots of good programs for converting text files into graphs or PDFs.

Selecting which program to use must be the choice of the user - not of the requirements management tool.

At the moment, rmtoo interfaces with nearly a dozen other applications: emacs, Open Office, graphviz, LaTeX, make, Ganttproject, … and there are more to come.

One additional reason for this decision is that rmtoo is used in continuous build environments - where the requirements and all the requirements artifacts are stored in the same place as the source code and the artifacts are automatically generated. In this scenario, a command line tool is mandatory - there is no way to handle it with a GUI.

QUESTION 2 Rmtoo is a powerful management tool. How can Rmtoo help a developer handle its projects?

The central idea behind rmtoo is that all requirements depend on other requirements. Therefore rmtoo forces a developer to work in a structured way. When a developer solves a problem he splits up one requirement into many ‘steps’ or ‘solutions’. When viewing this on the next, higher level of abstraction, it’s quite clear that these ‘steps’ or ‘solutions’ are also requirements.

A developer therefore turns the requirements he gets (e.g. from the marketing department) into more and more requirements - until they are ‘bite-sized’ chunks that can be directly implemented. Therefore rmtoo forces the developer to think before he implements anything.

It has been proven useful for the developer to have the requirements and the sources side-by-side - generally in a single version control system.

QUESTION 3 Can you tell us more about Rmtoo supported formats?

There is only one input format: text files. This can be seen as the database rmtoo operates on.

With rmtoo it is possible to either output (almost) everything in one document or have only certain aspects of the requirements displayed. The basis for document style output are ‘Topics’. These are a meta-output descriptions of the document. They make it possible to have exactly the same content in, for example, a PDF document or HTML pages. It is also possible to define other topics which only include specific themes. It is therefore very easy to print out a requirements document for a vendor which only delivers a small part of your project - without the need to send him the whole document, which may include confidential information.

Currently supported output formats are:

  • LaTeX document files with support for PDF creation including links to dependent requirements.
  • Backlog files which can be used in SCRUM - also in LaTeX format.
  • graphviz files which can be rendered in a graphic format like png, jpg.
  • HTML files including links to dependent requirements.
  • XML files for interfacing with many other applications.
  • GanttProject files: each requirement gets one line, dependencies and topics are used for project dependencies.
  • Current requirement version as simple txt file.
  • Pricing sheet in Open Office format.

AND: rmtoo is easily extensible. Writing a small, new output module can be done within hours - even complicated ones can be created in a couple of days.

QUESTION 4 Rmtoo received several important awards and it becomes more and more popular with every day that passes. Are you happy with this success? How do you image Rmtoo future?

To date, rmtoo has been downloaded about 2500 times from the sites we control. There is also quite a high percentage of responses from the community. As far as I know, rmtoo is currently used in projects in different technologies all over the world.

Of course it’s nice when others like the ideas which have been incorporated into rmtoo. It seems that a niche in requirements management tools has been found and that the rmtoo approach is needed and rmtoo is useful.

The future of rmtoo heavily depends on the community and on customers. Their feedback directly influences the roadmap. All features which are currently available are actually used.

The next few releases will concentrate on documentation and testing. At the moment there is a lot of documentation - but some small parts are still missing. Also, the current test suite ‘only’ covers about 92% of the code. After finishing these things rmtoo might be placed on some well known requirements management tool lists.

Also, there are a lot of requests for new features - so there are enough things waiting on the road map for at least 10 releases.

QUESTION 5 Beside Rmtoo, is there any other project you are currently working on? If yes, can you give us a few details about that project?

Of course - I can give you some details.

One project is to build a ‘low power’ office server. The server is designed so that it will not consume more than 30W power. The server will be the ‘backend’ server for a small office, handling things like: high availability backup and file server using RAID6, Wlan access point, SIP phone system (for Wlan and cable SIP phones). Last but not least it must be affordable - so only standard components are used. It is not yet clear if this will be turned into a ‘product’. More details can be found on the company’s blog at http://outer-rim.gnu4u.org - when looking for the server project, there is a category ‘SOHO’.

There are some more projects to come - but it is too early to talk about them.

Published at ‘’ (TBD).