Requirements resources are used to document the necessary
attributes, functions, or qualities of a system. Requirements may take many
forms -- use cases, process models, diagrams story boards, etc. A
requirements definition tool may understand several requirement
formats, while a requirements management tool may not need to understand
these detailed formats.
Referenced Namespaces:
http://example.org/xmlns/alm/rm/v0.1/ - The Open Services for Lifecycle Collaboration
Requirements Management Namespace (default -- unless otherwise specified,
the elements and attributes defined in this specification are from this
namespace).
http://example.org/xmlns/alm/v0.1/ - The Open Services for Lifecycle Collaboration
Namespace
http://purl.org/dc/elements/1.1/ - The "simple" Dublin Core
Metadata Element Set Version 1.1
Summary of Resources:
Requirement - A very general, basic, but extensible
"requirement" resource
Resource Description
XML Representation of Requirement Resource
Example
<?xml version="1.0" encoding="ASCII"?>
<jzrdm:requirement
xmlns:supp="http://example.org/my-attributes/supplemental"
xmlns:h="http://www.w3.org/TR/REC-html40"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:jzrdm="http://example.org/xmlns/alm/rm/v0.1/"
xsi:schemaLocation=""http://example.org/my-attributes/supplemental
http://example.org/my-attributes/supplemental.xsd">
<dc:title>Browser Compliance</dc:title>
<dc:description>A requirement about browser compliance</dc:description>
<jzrdm:reqBody id="1">
<h:h2 id="2">The system shall support lots of very good browsers.</h:h2>
</jzrdm:reqBody>
<supp:priority rmData="true">Must</supp:priority_id>
<supp:status rmData="true">Proposed</supp:status>
<supp:difficulty rmData="true">High</supp:difficulty>
<supp:stability rmData="true">High</supp:stability>
</requirement:requirement>
The optional string description of
the requirement.
{reqBody}
The optional text description of the
requirement. The value of the description must be suitable for use as
the inside of an XHTML body. This element may contain an
xml:lang attribute to indicate the language of the
requirement's body. It may contain an href attribute
who's value is the URI of another resource that contains data
describing the requirement.
The requirement resource is obviously quite simple. It does not have any
required elements other than the title; the only thing that clients should,
in general, count on is that a requirement is meaningful to a person in some context.
However, most requirements definition and management applications will want
to put additional data in a requirement. Other requirements file formats
(such as RIF) focus on mechanisms for defining attributes within the
requirements. In contrast, we are suggesting a lighter-weight approach. Here, a
requirement is essentially an empty shell into which other data can be inserted. The added
data is defined using standard XML techniques and contained in appropriate
namespaces, each of which may (if appropriate) have its own schema.
In the example above, the requirement contains the expected elements defined in this document
(dc:title, dc:description, and jzrdm:reqBody). In addition, it declares the
http://example.org/my-attributes/supp namespace, and includes
elements in that namespace. This supports applications that need properties
such as the priority, status, and difficulty of requirements. Clients that
wish to share these attributes need to agree on the definition of the
corresponding elements. Clients that want to display and allow users to edit
these properties can reference the schema for type information. To help
distinguish data that an RM tool user might be interested in editing and
viewing from foreign markup that an RM tool should ignore but preserve, tools
may decorate these elements with an attribute that indicates their interest
in these properties -- in the example, this was done using
rmdata="true". Alternatively, tools can be configured to
present data from certain namespaces to their users.
Jazz.net Homepage
