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).
• Standardisation of link types that pertain to the supported OSLC RM scenarios.
  • Work in progress: see OSLCCoreLinksDRAFT where the specification is evolving.

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.
  • Need to validate the specification needs. Can RM role be responsible for forming the collection from the elaborated requirements?
• 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.
  • How would such non-textual requirement data be represented in a resource? Wrapper resources?
• 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.
• The need to be able to distinguish between different types of requirement (motivated by RmRequirementElaboration). For example, the distinction between a "user requirement" and a "system requirement" (input requirement and derived requirement in the scenario). Being able to represent that distinction is useful and can be effected in a number of ways. At the least, a consumer should be able to present to the end-user such a difference; additionally, it would be desirable for this distinction to be accessible to query and resource creation.
  • For V2.0 I suggest we do two things to support such needs: Use of dcterms:type to provide a human-readable indication of the difference between requirements. (2) Admit the use of rdf:type to assert that a requirement also has additional types. So a resource would be asserted to be both a Requirement and also a SystemRequirement? . Only the meaning of Requirement is defined by the specification - the meaning of SystemRequirement? is not specified. The namespace in which SystemRequirement? is defined is not an OSLC namespace.
• The need to capture types in a general manner. This can't be contained within 2.0 - we need to deal with this in a future revision. Notice that for 2.0 we have "oslc_rm:elaboratedBy" and "oslc_rm:specifiedBy".

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

Plan for 2010

Outline plan for how the workgroup should proceed (this is an ordered list of activites).

1. Adopt the OSLC Core specification. This is a refactoring exercise and should not introduce new functionality to the RM defined services. Mostly this is a straightforward exercise. The following aspects will need to be pursued by the workgroup (this is not a list of tasks):
   1. Adopt terminology and structure of the OSLC Core (wording etc.) Bring the OSLC RM specification into a single wiki page.
   2. Shift from oslc_rm namespace to the OSLC Core namespaces for those resources which are defined by core.
   3. Adjust the specification of the RM resources from the current style to that standardized by core (for example, Requirement is an "OSLC Defined Resource", and many of the "OSLC Properties" of a Requirement are defined by core).
   4. Move "plumbing" from RM specification and adopt core. This includes, but is not limited to, the following:
      1. Service Discovery
      2. Delegated UI
2. Define a coherent set of OSLC relationship types across OSLC (OSLCCoreLinksDRAFT)
3. Extend this specification to query over RM resources. The OSLC Core specification includes "OSLC Simple Query", which describes the syntax and semantics of a simple query languuage over OSLC Defined Resources. NB. Is is known that this query language is insufficient for some of the scenarios we have been looking.
4. Extend this specification as required by our scenario work. The specification needs are outlined above, and will develop with the scenarios.
5. Adopt the OSLC UI Preview guideline.