This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
RmHome
>
RmSpecificationNeedsV2
(25 Jun 2010,
IanGreen
)
(raw view)
---+ 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. 1 Shift from oslc_rm namespace to the OSLC Core namespaces for those resources which are defined by core. 1 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). 1 Move "plumbing" from RM specification and adopt core. This includes, but is not limited to, the following: 1 Service Discovery 1 Delegated UI 1 Define a coherent set of OSLC relationship types across OSLC (OSLCCoreLinksDRAFT) 1 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. 1 Extend this specification as required by our scenario work. The specification needs are outlined above, and will develop with the scenarios. 1 Adopt the OSLC UI Preview guideline.
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r8
<
r7
<
r6
<
r5
<
r4
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r8 - 25 Jun 2010 - 10:21:28 -
IanGreen
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback