Requirements Structuring

Requirements

• R1: Express ordered trees of requirements
• R2: Express closure - that unless otherwise stated, no other resources are part of that structure
• R3: Capture provider-specific "whole-structure" semantics such as subtree move.
• R4: Cater for large structures without placing undesirable burden on consumer and/or provider
• R4: The ETag of a requirement is not necessarily changed when it is used/unused in a structure

Possible requirements

• R5: Notifications: when a requirement is modified in a structure, how do consumers of the structure detect that a requirement in it has been modified (should we care?)
• R6: sub-structures should be resources in their own right. This to support use cases in which new structures are composed from existing sub-structures.

One of the features of structure resources is that they define an order over the resources so used - an ordered tree. RM 1.0 and 2.0 used RDF Containers to express similar semantics for RequirementCollection? resources; in the 1.0 specification rdf:Bag container was used, yet the wording in the specification indicates that these are in fact ordered. The V2 specificaiton loses this distinction - there is no RDF container and there is no mention of orderedness or otherwise. (We may want to address this as part of V2.1.)

RDF collections (RDF Collections) additionally express closure (by convention only), so the requirement on closure would suggest that RDF collections are part of the resource model for requirements structuring.

Vocabulary for structures (Interesting read here.) R4 suggests that adding a requirement to a structure (akin to adding it to a collection) is not an update on the requirement; rather, it is an update on some other resource(s).

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

In this resource there is a single requirement (req/1) and there are two sub-structures (modules 2 and 3). rdf:list has been used to order those resources. (The rdf:list has been surfaced in the XML as parseType="Collection".)

Sub-structures 2 and 3 would would be defined similarly. Notice that there is nothing in the representation which commits to "module/2" and "module/3" being substructures - they could be any resource.

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

So the overall tree structure looks like this:

module 1:
  req 1
    req 2
    req 3
  ...

Where "..." is the elision of module 3. This view is somewhat misleading since it appears that req 2 is parented on req 1 but that is not the case - req 2 is parented on something which is a sibling of req 1. In the folder/folderitems use case, we might render this as:

folder 1:
  item 1
  folder 2:
    item 2
    item 3
  ...

which more faithfully reflects the structure.

Use cases adding a new substructure removing a substructure moving a substructure (move is two PUTs? - this impacts R3) adding a new resource to a structure