• Desire for OSLC RM scenarios covering elaboration of business requirements (see RmElaborationBusinessRequirements)
  • Are business requirements RM resources?
• Desire for RM-to-RM scenarios
  • Satisfaction, Decomposition, etc.
• Structure of requirements

Apologies: DominicTulley

Attendee: VishyRamaswamy, PaulMcMahan

Minutes

Relationships between artefacts between resources of the same type (rm-to-rm). Also is a resource almost always local, or remote. In QM, resources are "same provider". QM is thinking about QM-to-QM - also.

How would query be affected? Query for all failing test executions - no way to describe what is missing - some results would be in different providers and so not presented.

What kinds of changes are permitted, with what kinds of specification change?

What would we need to say, if anything, about intra-domain dual links? How would a client know which links to explicitly create and which are "automagically" created by the provider. As we bring multiple domains together, static linkage will not scale. We need user-defined links will be desirable, if not required.

The semantics of such a link need not be relevant from a user point of view - all they want is to have named relationships.

The ability to create new oslc:Property resources would allow a more flexible/dynamic linking mechanism.

Vishy. FocalPoint? scenario - business needs, and then requirements are used to elaborate those business needs. The creation factories create resources in the "wrong" place; the creation factories do not admit parameters to "place" the created resource, nor do they allow the created resource to have other application properties like folders, tags etc.

Paul reports that RQM had similar issues consuming the RRC RM provider. RQM also has categories - something between folder and tag. Categories are not surfaced on the RQM OSLC QM resources. There may be a "common" categorization that could be shared across all the applications (bulk creation, query, etc.)

There is the "extensions to OSLC" approach, and/or the "private API" which is separate from OSLC.