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:
<description>Create a switch in the context of a site</description>
<attribute type="string" name="owner">John Smith</attribute>
<attribute type="date" name="created">01/01/2003</attribute>
<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>
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.
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
Main Project Pages