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 specified 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. A reporting consumer typically needs to be aware of this structure.

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).

Structures may have ordering semantics. In the RM domain we see this in specifications where the sequence of requirements is material to their meaning; In AM method parameters are ordered. A series of comments in a discussion thread is ordered.

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> 

I think the RDF/XML serialization is hard to read in this case. Here it is in turtle:

@prefix oslc_rm: <http://open-services.net/rm#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
<http://example.com/reqcoll/1> oslc_rm:uses
        (<http://example.com/req/1> <http://example.com/reqcoll/2> <http://example.com/reqcoll/3>);
   a oslc_rm:RequirementCollection.
<http://example.com/reqcoll/2> oslc_rm:uses (<http://example.com/req/34>);
   a oslc_rm:RequirementCollection.
<http://example.com/reqcoll/3> oslc_rm:uses (<http://example.com/req/66>);
   a oslc_rm:RequirementCollection.

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 and Issues

Backwards compatibility

V1 and V2 specificatioins have a collection which is "flat". Do we want to introduce a new element in the vocabulary (e.g., "Specification") or do we want to extend what we already have? How to we avoid breaking existing clients?

Example: The DOORS 9 OSLC RM 1.0 provider models DOORS module views with RequirementCollection? - the structural information is lost. Clients that already consume and expect this flat structure might break if they were to be presented with a "Specification" resource.

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.

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

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/requirement/r1>

Finding all requirements which are present in a collection c1 cannot be done with an OSLC Query since there is no property on a requirement to each of the collections it belongs too. That case needs to be dealt with by a GET /collections/c1.

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. That intervening structure needs to be accounted for in the query

Q: What would that query look like? 
 

Scenario A

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.)

Scenario B

User wants to create a UML package heirarchy whose structure is related to the folder structure of requirement specifications.

Scenario C

Adding a newsubsection to an existing specification - for example following a requirements elaboration