[OSLC-RM] Discussion on requirement factory

[Lachlan Macpherson]

Hi All,

If we did use the existing Service Discovery mechanism, I assume that we 
would still need to add extra information to the RDF / XML of the 
Requirement itself. The Service Discovery mechanism would allow us to 
model a "parent/child" relationship but would not handle child order 
information. Would this also mean that we potentially have 2 different 
URLs for a requirement? One for editing / reading the Requirement and one 
in the Service Discovery document for creating child Requirements.

I'm also not sure if this is subverting the use of the Service Discovery 
mechanism for something for which it was not intended to be used. 

I think the easiest solution would be to have a generic factory and have 
extra information such as links that linked to parents / siblings to 
provide the structure. As Ian has said, this is not very generic and it 
would not be right to assume that all implementers of OSLC/RM would have 
structures that conform to this.

Ian mentioned having structural properties on a Requirement. Another 
possibility might be having something like a container Resource (Module in 
DOORS) and having structure properties on that in the form of an ordered 
tree of links-to-requirements. In this, the Requirements themselves don't 
need to know where they live but it is up to some other resource to 
capture their context and the same Requirement could be specified in a 
number of different places.. This is just some initial thoughts I had so I 
thought I would just share them.

Cheers,

Lachlan





From:
Ian Green1/UK/IBM at IBMGB
To:
oslc-rm at open-services.net
Date:
13/10/2009 13:25
Subject:
[OSLC-RM] Discussion on requirement factory
Sent by:
oslc-rm-bounces at open-services.net




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 





_______________________________________________
OSLC-RM mailing list
OSLC-RM at open-services.net
http://open-services.net/mailman/listinfo/oslc-rm_open-services.net








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/20091014/971f068d/attachment-0003.html>