Requirement Organisation

Feedback from SimonWills:

As discussed last time, I believe that this is an important area for consideration in OSLC-RM 3. From my perspective, the key organisational principles are as follows:

a. Requirements may be held in ‘containers’ (in DOORS, these are called ‘modules’)

b. Containers may be held in a hierarchical folder structure, like a file system

c. Containers and folders would be resources in their own right, and may have their own properties (e.g. name, at a minimum)

d. Requirements within containers may be held in an ordered list

e. Requirements within containers may also be held in a hierarchical tree

Associated with such organisation is a critical capability: the ability to ‘walk the tree’. From any one resource (requirement, container, folder), it should be possible to navigate to parent, child, following sibling or preceding sibling resources. This very significantly enhances the ‘findability’ of information, enabling selection of resources based on structure rather than content (as currently provided by OSLC query).

A few additional comments:

a. This area is not specific to requirements – like the debate on linking, it’s arguably OSLC Core business. Replace the word ‘requirement’ in the list above with ‘resource’, and we have a pretty general organisational approach.

b. We are used to containers and folder hierarchies being ‘physical’ (e.g. a requirement belongs to exactly one container). But, properly implemented, there’s nothing in these principles that would prevent virtual containers and hierarchies.

c. Where a provider does not support one of these organisational principles, everything collapses in a controlled manner (e.g. if a provider did not support a folder hierarchy, this is equivalent to a single root folder with no siblings or children).

I think that’s it for now.