Requirements Document for Example Comercial Pricing Module

Analytics

Description
The requirements must be analyzed.
Rationale

It is hard to write good requirements - as far as possible rmtoo should support writing good requirements.

Note
Analytics are implemented using modules with a defined interface.
Depends on:
Processing
Id
Analytics
Priority
10.00
Owner
development
Invented on
2010-08-05
Invented by
flonatel
Status
finished (Florath, 2011-04-18, 4 h)
Class
detailable

Automatic Generation of Results

Description
rmtoo must support the automatic genration of outputs.
Rationale

Because rmtoo is aimed to be used in productive development environments, there is the need that all the different outputs (e.g. PDFs, graphs, ...) must be generated automatically (without user interaction).

Depends on:
Processing
Id
AutomaticGeneration
Priority
3.00
Owner
development
Invented on
2010-02-12
Invented by
flonatel
Status
not done
Class
detailable

Documentation Man Page

Description
rmtoo must come with a (*nix) man page describing the basic behaviour.
Rationale

This typically describes the input and output and all the parameters needed (but not the ideas behind).

Depends on:
Documentation
Id
DocManPage
Priority
4.12
Owner
development
Invented on
2010-02-12
Invented by
flonatel
Status
not done
Class
selected

Documentation Slides

Description
For documentation purposes there must exists a slide show introducing the major features.
Rationale

Software not only needs to be good --- also the 'marketing' aspect should be considered: the more people / companies rmtoo using, the more bug reports and comments there will be, the better rmtoo will be.

Depends on:
Documentation
Id
DocSlides
Priority
4.68
Owner
development
Invented on
2010-02-14
Invented by
flonatel
Status
finished (Florath, 2011-04-18, 21 h)
Class
selected

Documentation

Description
rmtoo must be documented.
Depends on:
rmtoo
Dependent
DocManPage, DocSlides
Id
Documentation
Priority
5.50
Owner
development
Invented on
2010-02-12
Invented by
flonatel
Status
not done
Class
detailable

Different Inputs

Description
rmtoo must support different types of input files - one type for each usage.
Note
A usage is e.g. documenting requirements or handling topics.
Depends on:
Processing
Id
Input
Priority
10.00
Owner
development
Invented on
2010-05-16
Invented by
flonatel
Status
not done
Class
detailable

Output of Different Artifacts

Description
rmtoo must support generation of different outputs.
Rationale

It's not very easy to e.g. visualize the dependency graph. Also typically for the testing department a document is needed that decribes the requirements (features) of the product.

Depends on:
Processing
Id
Output
Priority
10.00
Owner
development
Invented on
2010-02-12
Invented by
flonatel
Status
assigned (Florath, 2011-04-12)
Class
selected

Processing

Description
rmtoo must process the requirements by means of a defined order.
Rationale

First the requirements must be read in (and checked for syntactic - and if possible for semantic) problems.

Then the requirements must be analyzed.

As a last step the output artifacts must be generated.

Note
Please see the depended requirements for more details.
Depends on:
rmtoo
Dependent
Analytics, AutomaticGeneration, Input, Output
Id
Processing
Priority
10.00
Owner
development
Invented on
2010-08-05
Invented by
flonatel
Status
not done
Class
implementable

Simplicity

Description
rmtoo must be simple.
Rationale

To get started, concentrate on the major things, which are really needed.

Use techniques which are available.

Depends on:
rmtoo
Id
Simplicity
Priority
9.00
Owner
development
Invented on
2010-02-08
Invented by
flonatel
Status
not done
Class
detailable

Test Integration

Description
For each requirement there must be a integration test which tests the requirement in a larger context.
Rationale

This tests the interaction between the different layers of implementation and makes sure that the interaction works.

Depends on:
Testing
Id
TestIntegration
Priority
10.00
Owner
development
Invented on
2010-03-10
Invented by
flonatel
Status
not done
Class
selected

Unit Testing

Description
For each code path there must be a unit test.
Rationale

Each class, function and method must be tested. Each decision and error condition must be tested.

Depends on:
Testing
Id
TestUnit
Priority
10.00
Owner
development
Invented on
2010-03-10
Invented by
flonatel
Status
not done
Class
detailable

rmtoo Automated Testing

Description
Each feature of rmtoo must be automatically testable.
Rationale

This gives the possibility to run a set of regression test and check the whole functionality of rmtoo.

Depends on:
rmtoo
Dependent
TestIntegration, TestUnit
Id
Testing
Priority
10.00
Owner
development
Invented on
2010-03-04
Invented by
flonatel
Status
not done
Class
detailable

rmtoo

Description
rmtoo must exists.
Rationale

The world needs a good, usable and free Requirements Management Tool.

It looks that there are no such programs out.

But: it's complex!

Dependent
Documentation, Processing, Simplicity, Testing
Id
rmtoo
Priority
10.00
Owner
development
Invented on
2010-02-06
Invented by
flonatel
Status
not done
Class
detailable