rmtoo-req-format(5)

NAME
rmtoo-req-format - requirements management tool: requirements format

FILE FORMAT
Each requirement must be in its own file. The filename must be end in '.req'. Only ASCII characters are allowed. Each line must at maximum 80 characters long.

The requirement must be written as a set of 'key: value' pairs. A value is extended if the first column of a line is a space.

A key can only exists once in a requirement description file.

KEYS
The following keys with the described syntax and semantic exists:

KEY 'Name'
This value of this key is a short headline for the requirement. It is used as a section headline in the output document.

KEY 'Type'
This value can be one of master requirement, requirement and design decision.

There can only be one 'master requirement'. This is the requirement (product, artifact) the whole project is about. This can be typically have the project title as the name. There can only be one master requirement in a whole set.

KEY 'Invented on'
The value of 'Invented on' is the date when the requirement was written. The format must be YYYY-MM-DD.

KEY 'Invented by'
This value is the name of the author of the requirement. The author is the person who wrote the requirement. It must not be necessary one of the stakeholders.

KEY 'Owner'
This is the owner of the requirement. He is responsible for the requirement.

KEY 'Description'
The description is the formulation of the requirement. There must be one of the words 'must' or 'shall'. The following words are not allowed: may, possible, might, and, or. Requirements must be testable.

Requirements must be positive; negative requirements can mostly not tested.

KEY 'Rationale'
This is optional. This gives a hint and some more details about the requirement. Typically some background information is given here.

KEY 'Note'
The note is an additional comment for the requirement.

KEY 'Solved by'
Each requirement which is 'solved' by other requirements must have one or more children. The 'Solved by' tag contains a list of these children.

KEY 'Status'
The status can be one of 'not done' or 'finished'.

KEY 'Topic'
This is the topic this requirement belongs to.

KEY 'Class'
This gives the class of the requirement. Currently two values are possible 'detailable', 'implementable' or 'selected'

detailable means that the requirement must be elaborated before they can be implemented.

implementable means that the requirement is detailed enough to start with implementation.

selected means that the requirement is selected for the next sprint. Based on this selection the sprint burndown and the selected table is printed.

KEY 'Priority'
Each requirement must have a priority. The effective priority is computed by the currently given priority multiplied by a normalized maximum priority of all parents.

The format is 'stakeholer:num'. 'num' must be a number between and including 0 and 10. It is possible to specify more than one stakeholders separating them with a space.

KEY 'Effort estimation'
The effort estimation is done with the help of an abstract measurement so called 'effort points'. These effort points are used in agile processes (especially SCRUM) to get a prediction about the burn-down speed and the expected finished date.

0 - no effort

1 - tiny effort

2 - very small effort (two times a tiny effort)

3 - small effort (same as a tiny and a very small effort)

5 - medium effort (same as a very small and a small effort)

8 - big effort (same as a small and a medium effort)

13 - very big effort (same as big effort and a medium effort)

21 - huge effort (same as very big effort and big effort)

KEY 'Constraints'
This must be a list of constraints - including possible arguments. Please consult the rmtoo-constraints(5) man page for more details.

EXAMPLE
Note that the following example has some initial indent resulting from the word processing program. The keywords must start at the first column. Additional lines must have a space in column one.

    Name: Example Requirement
    Type: requirement
    Invented on: 2010-02-14
    Invented by: Mustermann
    Description: The example application must use TCP/IP for
     communication with the database instance.
    Rationale: Here are some reasons why this must be
     implemented in this way.
    Owner: security
    Solved by: DetailedRequirement
    Status: not done
    Constraints: [ "MinShockResistance(5)" ]

SEE ALSO
rmtoo(7) - overview over rmtoo requirements management tool. All references can be found there.

HISTORY
There is also a tag named 'Depends on' which is the opposite of the 'Solved by' tag: Instead of specifying the requirement's children the parents were specified. The 'Depends on' must be seen as deprecated.

The 'Depends on' tag is the older and is still (for compatibility reasons) the default. Nevertheless the 'Solved by' tag is the one which should be used in new projects.

AUTHOR
Written by Andreas Florath (rmtoo@florath.net)

COPYRIGHT
Copyright © 2010-2011 by flonatel (rmtoo@florath.net). License GPLv3+: GNU GPL version 3 or later