Open Requirements Management API


A software (sw) project starts with the srd, the software requirements document. It is basically a document written by the client which describe with more or less detail in a formal way what he wants, and it is the starting point for a sw provider to begin the analysis phase.

The srd is broken down by the sw provider into small paragraphs (preserving the original literature), representing basic ideas, and each one is assigned an unique identifier (i.e. a number). These are the requirements.

During the development of the project, the provider must know each time all kind of statistics like which percent of the requirements are already coded, or coded and tested, which set of functions supports a particular requirement, etc. The client also might want some of this reports.

At the end of the project, the client will use its srd to check the software. It will require the traceability matrixes to the sw provider, that is, for each requirement, which pieces of the software are implicated to cover it, and which test cases must be executed to check if the former pieces work fine.

But the provider employs from the begining a wide variety of tools to produce the final product: it would choose to use a particular UML designer, a particular IDE to code and compile, a bug tracking system, a versioning system, an unit testing tool, etc etc.

The trace from an element (package, class, method, test case, source file, problem report, change request or whatever) to another element and/or to a requiment must exist, and the whole net of traces must be always consistent and up to date.

It means that all the different applications and tools used to aid the development process must, apart of do their specific job, work together for this purpose, generating traces.

a requirement management tool

One of the applications a sw provider use is a program to store the requirements. A spreadsheet, a database, a specific tool, etc.


an elemnt is something to trace to or from: an instance of a class, a particular method, ...


a classifier is a type, for example, class, attribute, bug report, test case, problem report are classifiers; a particular element belong to one or more classifier.


tools are designed to focus on their specific classifiers and elements.

for an UML tool, the classifiers it might provide are: package, class, operation, attribute, use case, secuence diagram, actor, etc ...

for a bug tracking system (BTS), the classifiers it might provide are: problem report (PR), change request (CR)

some traceability can be automatically done by each tool, since the UML tool knows which class an operation belongs to, and the BTS knows which CR is associated with a particular PR.

whilst an engineer is working in the definition of an operation, there should be a way he can easily trace it to an specific bug report of the bug tracking system, or to a requirement

the ORMA specification

The ORMA interface specification is a 'contract' signed by each one of the applications certifying they can dialogue and understand each others.

It would allow applications to show a specific dialogue to manage traceability between the native elements the application is handling and the rest of elements published by the other applications implicated in the whole development and/or managing process.

It would also permit programs or scripts to access programatically to the traceability information, so the data can be treated in a particular way.