Roadmap.txt

This is a description of the next and next-next generation of to be
implemented features.

There is no exact time line because the amount of time spend for this
tools changes from time to time (depending on many factors).  From
history it may be assumed that it takes about 6 to 8 weeks for one
release.

Also the version number shown here might change: if there are other
requests from customers those will be done first.  Also it might be
that from time to time there is a bug-fix release of rmtoo.

The history of this file, i. e. the already implemented features can
be found the appropriate release notes.

There are some major aims to go for:
o Get rmtoo listed in the INCOSE tool survey.
o Get rmtoo added to at least one Linux distribution (preferred
  Debian)

=> Mail to INCOSE was sent - they answered that they will include
   rmtoo in their list as soon as possible. (Status 2011-02-14:
   they move servers - therefore the inclusion will take some time.) 
=> This will be the point of time to get rmtoo into one Linux
   distribution - preferred Debian.
   Problem: will eat up a lot of time

v24
===
o Is there a need in the blackbox test to have a non empty
  stderr / stdout?

v25
===
o Add support for setup.py
  (At least check, if the current available setup.py does
   its job while installing the package in the system.)
o Think about GUI
o Add support for Tasks / Issues
  ( -> import from Bugzilla? )
o If possible:
  Add GUI for creating and modifying a configuration.
o Check Web-Site for user features / bugs
  - Fix (small) bugs
  - Add feature request requirements
o Man page: (???)
  + graph
  + graph2
  + EfEU

v26
===
o Add to FAQ: max level of topic inclusion.
o Add changes to presentation
o More testcases
o Archive old versions from slashdot to flonatel.de
  (leave only last three versions on slashdot)

IMPORTANT
=========
o Design GUI
  - Server
  - Clients
  - Protocoll / Interface
o Add requirements from Roadmap.
o Rethink about the modules: they should also run (at least partially)
  for the topic based output.  Is there a way to unify this?

OTHER / LATER
=============
o Add tasks to rmtoo
  (Maybe import possibility from Bugzilla.)
o Draw overview picture for current Sprint (a la 'Paper' overview with
  'Chosen', 'In Progress' and 'Finished'.
o Now that the finished date and duration is available, gantt output
  should be extended to use this.
o SCRUM Burndown diagram
o Due Date for all requirements as optional
o Requirement: prosponed, withdrawn as additional state of a requirement
o For later 'gantt' export:
  start-date, end-date, ...
o Design issue: (from WEB)
  If the intent of the original heuristic was to discover disconnected
  (i.e. floating) topics, the checks should definitely be adjusted to
  also count sub-topics and parent topics, as parent-child connections
  are of course valid connections, too.
o Build a server which can serve as the interface to different GUIs
  (e.g. native gtk, WEB, ...)
  - Build gtk GUI
  - Build WEB GUI
o Include sub-graphs in the PDF and HTML documentation
  - Topic based (all reqs of a topic)
  - req based (all reqs dependend and depend on one req)
  - Try to implement this is a generic way that makes it
    possible to include dot files from within a requirement.
    (If this is not possible, add this to the OTHER / LATER
    features.)
  o Adapt man pages
  o Adapt presentation
o It often happens that one requirement is resolved into two different
  'types' of solutions:
  1) The genral properties of all 'direct' solutions
  2) The direkt solutions.
  There is currently no way to differ between those two different
  'types' of requirements. It should be elaborated if these are really
  two 'types' or if this can be described with the current implemented
  features. 
o Long Term Evolution: It's all about data storage and who (which
  program) can access (read, write, change, ...) which data.
  - Write requirements
  - Discuss with other projects (ganttproject, freemind, ...)
  - Storage vs. Bus-System
  - Verfügbarkeit
  - Ausfallsicherheit
  - Colaboration
  - Concurrency
o Add makefile dependencies: .rmtoo_dependencies depends
  on the ConfigX.py file.
o output level in 'prios.py' must be configurable
o traceability of changes
  - Dependent on changes: list all depended requirements which must
    be checked.
o Add change marks for at last latex output:
  - specify one additional version number from which the difference is
    made
  - Mark
    + Additions
    + Changes
    + Deletions
    (Should be not that hard when creating the difference based on the
    requirements - but also the topics must be included)
o Translations / Intenationalization
  - Input: possible define a new set of tags - one for each language.
o Topic includereqs: There is the need to at least specify ONE
  requirement which is located before all others.
o Add version number to rmtoo -v or something
o Add roadmap feature
o Add ToDo list feature
o History in document: specify two versions and create automatically a
  list of all changed requirements.
o History must have the form:
  YYYY-MM-DD:name:explanation what changed
  additional to the things stored in the VCS.
o Clean up code (XXX, ToDo, ...)
o Use MemLog instead of print.
o 'The only requirement management tool which comes with the
  requirements for the tool'. 
o A requirement cannot be 'finished' if on of the dependent is not
  finished. 
o Add glossary
o Add man page for glossary
o Add glossary to presentation
o Emacs mode for editing topic (tic) files.
o Better list of preconditions
  (When is what needed? Version?)



Long Term Evolution or:
This will be another project
============================

Interaction between programs
----------------------------
The *nix base idea is: let one thing do one thing (but this very
well).  Examples: mostly all commands in /bin and /usr/bin.  They
all work on plain text files and every program has exactly one
functionality. 
When looking to mostly all other areas of data processing, the
interaction of different programs is very, very limited - which
depends on the file format.  Complex programs (like office word
processor) work on complex data.  Mostly each program has it's own
file format.  The file format is mostly not interchangeable with other
programs - and if so, it's mostly hard to convert and often some
aspects are lost during conversion.
Another aspect is, that mostly all programs work on the input data in
a way that they think they 'own' the data. When programs cannot deal
with data, they tend to either complain about corrupted input files or
they ignore the unknown parts in the way that when saving the read-in
data in a program those unknown parts are not contained any more.
Others just rename internally used labels and attributes in a way that
it is impossible to find the original elements after one of those
programs worked on them. Example: OpenOffice Calc.