[oslc-rm] Contributing scenarios to reporting workgroup

[Ian Green1]

Sorry, I omitted the reference to the scenarios:

[1] http://open-services.net/bin/view/Main/RmTraceabilityScenarios


best wishes,
    -ian

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



From:
Ian Green1/UK/IBM
To:
Tack Tong/Toronto/IBM at IBMCA
Cc:
Arthur Ryman/Toronto/IBM at IBMCA, oslc-rm at open-services.net, James 
Conallen/Philadelphia/IBM at IBMUS, Paul McMahan/Raleigh/IBM at IBMUS
Date:
04/03/2010 12:21
Subject:
Contributing scenarios to reporting workgroup


Hello Tack,

The OSLC RM workgroup has been looking at some scenarios relating to 
traceability (see [1]).   In our discussions it became evident that RM 
alone cannot meaningfully make good progress in this area, since 
traceability is not confined to a single domain.  For example, "assessing 
the impact of a proposed change" might have a scope that reaches beyond RM 
into QM and AM. 

Out current thinking is that such scenarios require two things:
        - a means of describing the resources that are to be considered 
for the impact analysis (resource type, relationships etc.)
        - a means of remembering such a description so that progress on 
dealing with the impacts can be monitored

The first feels very much like a query, of the sort that reporting has 
been considering - in general it is cross-domain.  The second, which we've 
called a "traceability graph" is a resource that offers a way of tracking 
progress, and also of including impacts that do not result from 
traceability.  We're focusing currently on the first of these - a way of 
querying for "impacted" resources.  (We're agreed that the graph idea is 
interesting but can be investigated separately and, we think, without 
affecting the query part.)

Do you agree that traceability analysis has some affinity with reporting? 
There are certainly differences - one being that it seems necessary that 
the traceability analysis has to be represented as a resource.  Our hope 
is that we can progress these scenarios - perhaps in collaboration with 
your workgroup - do you have any comments?

If we don't have a cross-domain approach we could make progress but at the 
cost of drawing (artificial) boundaries between RM, AM and QM, ...


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













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