Specification Needs for V2.0 of the OSLC RM specification

Deferred from V1.0

• The ability to deal with non-textual requirement data.
  • Motivating scenario RmEADSTraceabilityScenario1
• The need to discover the relationships understood by a provider, for example, the kinds of links that a provider declares that it will accept, perhaps with some documentation or description of the intended usage of those links. OSLC AM has something similar: AmLinkTypeManagementV1.
• The ability to discover requirements. This includes, for example, querying over requirements (see OslcSimpleQuerySyntaxV1 which will become part of OslcCore in V2 timescales).

Supporting V2 scenarios

• The need to classify requirement resources, for example, "evidence", or "argument".
  • Motivating scenarios: RmTraceabilityScenarios
• The need to support relationships between requirements and model elements (motivated by RmRequirementElaboration)
  • elaborates: A relationship between a two artefacts. An artefact elaborates another artefact when it supports the understanding of that artefact.
  • satisfies: A set of derived requirements satisfy an input requirement when fullfilment of each of the derived requirements implies the fullfilment of the input requirement.
• The need to create a collection, and to be able to add requirements to that collection (motivated by RmRequirementElaboration)
  • This scenario describes how the AM user is responsible for the creation of a requirement collection containing the derived requirements. If this step were done by the RM user, this spec. need would disappear, but i think there would be other challenges as a result; not least of which is that the creation of the satisfaction traceability would require an analysis of the internal relationships between AM resources.
• The need to support non-textual requirement data (repeated from above). (Motivated by RmRequirementElaboration.)
  • It may be necessary to use pictures and other non-textual representations to express, either in whole or in part, derived requirements. An example might be a requirement containing a UML diagram of a use case.
• The need to determine which requirements do not have a satisfaction relationship (Motivated by RmRequirementElaboration.)
  • As requirements are analysis and derived requirements are obtained, one driver for completion is that all input requirements are covered by derived requirements. This could be done by inspecting requirements one by one but clearly this does not scale to large numbers of requirements. It seems reasonable to propose that the provider can offer a more efficient way to find such unstatisfied requirements.
  • This needs to be scoped to some interesting set of requirements - in the scenario the scoping would be on the requirement collection.

Adoption of OslcCore specification/guidance (currently unclear as the core spec/guidance is in a state of flux)

• Standardization on existing terminology
• Refactoring to the common specification elements
• Changes to the representation of resources
• Introduction of new resource representations
  • JSON, HTML, RDFa are potential candidates