[OSLC-RM] Discussion on requirement factory

[Ian Green1]

Hello fellow OSLCRMers,

I'd like to continue the discussion of how we best introduce requirement 
creation into the specification.  My current proposal, which I outlined on 
the previous call, is to to use the service discovery mechanism.   That 
mechanism is part of the draft spec. (
http://open-services.net/bin/view/Main/RmServiceDescription).  The OSLC 
"Service Provider Catalog" provides a way to address a hierarchy of 
RM-specific service documents.

You will recall from that meeting that I was somewhat uncomfortable with 
this approach, as was Steve.  One of the limitations of this approach is 
that it cannot describe richer contexts - okay for the moment perhaps, but 
limiting in the longer run.  This reason alone is not good grounds to 
reject it from RM 1.0.  Steve had a concern that this approach was not 
consistent across the other OSLC domains.  I'd like Steve to put this case 
since I feel that we're rather generalizing from a sample size of one (the 
CM specification).

I'd like to provoke some discussion on how we move forward with this 
issue.

The problem is:

How do we cater for the creation of resources in some particular context. 
In the case of DOORS, requirements live in a structure - in a ordered 
tree, called a module in DOORS;  in RRC, requirements are organised into a 
folder hierarchy.

Here are some options for modelling this context:
        - reflect the context in the structure of the service documents 
(this is the approach i refer to above)
        - describe an association between a requirement and the places in 
which it occurs (or "bound").
        - ignore the context and require that providers deal with the 
inability to express context in OSLC RM.

This last option is really there only for completeness - i can't see this 
being valuable.

On the second option, one can imagine structural properties on a 
requirement which describe, for example, tree position, or perhaps 
containing folder and so on.  We would have to work to generalize this. If 
a requirement is REQUIRED to have such context described, then the 
specification MUST describe this structure.  If  we make such descriptions 
OPTIONAL, the specification can say less, but that also lessens the value 
since a client cannot uniformly treat all providers.

A variation on option 1 is to mimic the service provider catalogue 
structure, but to do so wholly within the scope of OSLC RM - so that 
"consistency" issues can be finessed.  A family/structure of factories 
could be described.  The spec. could admit "progressive" factory discovery 
- here I intend that a client would dig to more specific factories, but 
only as required/supported by the provider. In the case of DOORS, a usable 
factory would be available at the module level, but additional, more 
fine-grained factories could also be discovered inside that context if the 
client wanted to make a requirement at a particular node in the 
requirement tree.  This option offers a little more flexibility, and we 
could base some of it on what is already present at the catalogue level.

option 1 (both variants) are really an instance of option 2.

I invite your thoughts and comments.

best wishes,
    -ian

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-rm_open-services.net/attachments/20091013/9a7d2cbb/attachment-0003.html>