During RM V1.0, we worked on Scenario A - Requirements are implemented validated and delivered. This scenario contains a precondition which asserted the existence of a requirement collection that described the scope of work to be undertaken. This style of requirement-driven development, on a larger scale, requires that the process of arriving at such a collection be better supported across a lifecycle.

Typically, different teams will work on several aspects of the requirements. As requirements specifications grow in size, simple "flat" collections, as we specificed for V1 and V2 are inadequate - they are hard to work with as the only means of organizing requirements.

A common way of scaling larger collections of requirements is by organizing them hierarchically. Doing so impacts not only RM applications but also the other lifecycle applications around them. For example, a test engineer needs to be able to understand such a hierarchy when they are making a test plan.

In previous releases of the RM specification collections were primarily a planning or communication device - the requirements in a collection were not necessarily related to one another (other than being delivered in the same iteration, for example).

Hierarchy of resources

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:oslc_rm="http://open-services.net/rm#">
<oslc_rm:RequirementCollection rdf:about="http://example.com/reqcoll/1">
  <oslc_rm:uses rdf:parseType="Collection">
    <rdf:Description rdf:about="http://example.com/req/1"/>
    <rdf:Description rdf:about="http://example.com/reqcoll/2"/>
    <rdf:Description rdf:about="http://example.com/reqcoll/3"/>
  </oslc_rm:uses>
</oslc_rm:RequirementCollection> 
<oslc_rm:RequirementCollection rdf:about="http://example.com/reqcoll/2">
  <oslc_rm:uses rdf:parseType="Collection">
    <rdf:Description rdf:about="http://example.com/req/34"/>
  </oslc_rm:uses>
</oslc_rm:RequirementCollection> 

<oslc_rm:RequirementCollection rdf:about="http://example.com/reqcoll/3">
  <oslc_rm:uses rdf:parseType="Collection">
    <rdf:Description rdf:about="http://example.com/req/66"/>
  </oslc_rm:uses>
</oslc_rm:RequirementCollection>
</rdf:RDF> 

In this model the ordered-ness of the requirements is represented by the RDF collection resources; the tree-like structure stems from the way that multiple collections are nested within one another. The result is an ordered tree of requirements.

Questions

Given a requirement, how would you determine where it is "oslc:used"? OSLC Simple Query?

The sub-sections of a collection are reusable in other contexts. Is this desirable?

Is the point of usage of a resource something that assertions can be made about? For example, reviewing a requirement in the context of a requirement collection. A more crucial case is whether trace relations are between the requirements, or between the uses of those requirements in a collection.

Sample Interactions

Finding those places in which a requirement has been used That is, find all collections C that use rquirement r1. Given an OSLC query base for collections as http://rrc.example.com/oslc/collections, the query would be

GET http://rrc.example.com/collections?oslc.where=oslc_rm:uses=<http://rrc.example.com/requirements/r1&gt;

Finding all requirements which are present in a collection c1 uses a query over the query base for requirements

GET http://rrc.example.com/requirements?oslc.where=oslc_rm:uses=<http://rrc.example.com/collections/c1&gt;

Notice that the results of such queries are limited to those resources which are covered by the query base.

In the resource model above there are RDF blank nodes between the collection resource and the requirement it contains. This reflects the fact that the collection has a structure. In the V2 query specification one could query for those collections that oslc_rm:used a requirement, as follows:

oslc.

Client wants to generate a document (eg PDF) of a requirements specification. The chapter, section, subsection structure of the document should reflect the hierarchy of the requirements specification. A GET on the specification will yield a resource representation which contains some fragment or perhaps the entire tree. The representation of a large tree may pose problems for client and/or server; resource paging could help with this. (Q: but the paging may not respect the logical structure of the tree - depth-first or breadth-first, for example. In a reporting scenario, we expect that the client will need a complete representation, and so the traversal algorithm doesn't matter.)

When the