Login | Register
My pages Projects Community openCollabNet

The Language

There is nothing complicated about RML - we hope.  It is an Extensible Markup Language that allows for a description, a set of attributes, and a set of associations.  That's it!  Here is an example:

<requirement>
  <description>Create a switch in the context of a site</description>
  <attributes>
    <attribute type="string" name="owner">John Smith</attribute>
    <attribute type="date" name="created">01/01/2003</attribute>
  </attributes>
  <associations>
    <association type="url" name="defect A123">http://bugzilla-server/defects/A123</association>
    <association type="relative" name="refining use case">src/ucs/i3/Create_Switch.doc</association>
    <association type="absolute" name="related test case">/testing/tcs/i3/Create_Switch.doc</association>
  </associations>
</requirement>

The Language Elements

At their simplest, requirements are a descriptive statement - therefore a description element. But, for whatever reason, requirements may not have a description throughout their entire lifecycle. Thus, the description is optional.

In different contexts, requirements may or may not have a set of attributes associated with them; therefore, attributes are optional.  Similarly, associations to other artifacts are optional.  For a more formal description of RML, check out the Document Type Description (DTD). 

Why so General?

The reason that we don't try to constrain the language any further is that we realize that every project is different. Each project has its own requirements dialect, whether they know it or not. Hopefully this language is generic enough to support all of the dialects and not so general that it's useless.

Why Requirements Files?

By separating requirements out into individual RML files, we avoid the "monolithic" requirements document that we all fear.  We no longer need to concern outselves with the format of a requirements document; rather, we focus our efforts on the contents of the requirements themselves. We should be able to generate a requirements document, if we need one, by using related technologies (such as XSL/XSLT)

For a more in-depth discussion on why and when we should manage requirements in a file-based architecture, as opposed to ultra-lightweight, lightweight, or heavyweight architectures, read this paper.

What's next?

For some, describing requirements in a dialect of this language might be useful and sufficient. If they need a really lightweight mechanism for managing their requirements, and all of the team members are comfortable reading and writing in this language, this might be suitable in and of itself.

However, XML instances such as RML are not necessarily easy to read and write.  Therefore, we could use some tools to help us read, write, sort, filter, and transform them.  That's another goal of this project - check out the products aimed to provide this support here.

Main Project Pages