RE: [oslc-domains] TC review of draft migrated Requirements Management Specification

Hi

 

I have made some changes in response to Martin & Mark’s review comments. Attached is the status of what is left to do. Is there a way
 I can post this document somewhere, so we can avoid emailing different versions of it?

 

Besides the action to write an abstract, I would like a quick followup on most other items before we can proceed.

 

regards

______________________________

Jad El-khoury,
PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

,
www.kth.se

 

From:  [mailto:]
On Behalf Of Schulte, Mark D

Sent: 08 March 2018 22:47

To: 

Subject: RE: [oslc-domains] TC review of draft migrated Requirements Management Specification

 

My comments:

 

Specification:

1)     
General

a.      
I thought we were going to client and supplier instead of consumer and service provider but there are still instances of the former references
 scattered throughout the document.

2)     
Specification URIs

a.      
There are a couple of references in this section to “OASIS OSLC Lifecycle Integration Domains TC”.  The official name of the TC appears
 to be “OASIS OSLC Lifecycle Integration for Domains TC”.

3)     
Related Work

a.      
It might be good to add a couple of lines on how this is related to the 2.0 Specification and what has/has not been touched.  If more appropriate,
 that perhaps could also be part of the currently blank Abstract section.

4)     
Citation Format

a.      
When does “OASIS Working Draft 01“
 get dropped?  Surely we don’t release this with ‘working draft’ in the document?

5)     
Notices

a.      
In paragraph 5, there are two uses of “infringed”.  I think it would read better if instead we used “infringed upon”.

b.      
In paragraph 7, it says “OASIS’ procedures”.   I’m not sure the possession marker is needed here.

6)     
Base Requirements

a.      
Paragraph 1, Syntax…..addition
à
“recommendations in both of
these specifications”

7)     
2.5 Authentication

a.      
Reference to OSLC CM servers…..instead of OSLC RM servers

8)     
2.6 Error Responses

a.      
See previous comment

9)     
2.9 Labels for Relationships

a.      
Change
“…it may be helpful to display an informative and useful textual label instead
 of or in addition to the URI of the predicate and or object.” To “…it may be helpful to display an informative and useful textual label instead of, or in addition to,
the URI of the predicate and/or object.”

b.      
For Link definition…..”…resource,
only then OSLC servers may support” doesn’t sound right.

10)  
4.1 Server Resources – “outwith” can’t be right.  Should that have been “within”.

11)  
4.3 Query Capabilities – misspelling, “oslc:resutls”

12) 
Acknowledgements – Nicholas Kruk should not have a “?” after his name.  First and last names should be separated by a space.  Might consider listing
 people alphabetically but up to you since the list is short.

 

 

Vocabulary:

13)  
1.2 Terminology

a.      
First paragraph might be improved as a bulleted list.

14)  
2.1.4 RequirementCollection

a.      
“A collection
uses includes
zero or more requirements”……better, more accurate?

15)  
All of the relationship type descriptions seem like they should be consistently described and using the same example as the title.

a.      
For instance, instead of “a defect may be said to affect a requirement” as an example of “affectedby” say instead “a requirement may be
 affected by a defect.”

                                                              
i.      From a consistency standpoint, 2.1.8 for “satisfiedBy” does in fact follow the
 format but the others do not.  At a minimum, this is inconsistent.

b.      
2.1.12 says “For example, a test plan may be said to validated
 a requirement collection.”    Correct the grammar here.

16)  
3.1 Resource:Requirement

a.      
Suggest a period instead of a comma in the following sentence:

                                                              
i.      Requirement resource properties are not limited to the ones defined in this specification, service
 providers may provide additional properties.

b.      
Description section, need to fix grammar here – “or possed
 by a solution component,”

c.       
Add ‘or to’ here
à “……achieve
 an objective, or to satisfy a contract, standard, specification, or other formally imposed documents.”

d.      
In the description column,
foaf:person
is referenced.  Shouldn’t resource names there follow the same font convention as other references such as
oslc:AnyResource

 

 

Mark D. Schulte

OSLC MS Steering Committee, Domains TC

Boeing Defense Systems

The Boeing Company



Office: +1
314-777-7331

 

 

 

 

From:
 [mailto:]
On Behalf Of Jim Amsden

Sent: Thursday, March 01, 2018 10:31 AM

To: 

Subject: [oslc-domains] TC review of draft migrated Requirements Management Specification

 

The Requirements Management 2.1 specification working draft document is ready for OASIS Domains TC review. Thanks Mark and Jad for getting
 this document ready. The document can be accessed at:

http://htmlpreview.github.io/?https://github.com/oasis-tcs/oslc-domains/blob/master/rm/requirements-management-spec.html

This is a multi-part document including the specification and vocabulary documents. Both should be reviewed and can be accessed from the link above.

TC members should consider the following when reviewing these documents:

1. Verify OASIS document formatting, and formatting vitality (HTML issues, section/subsection issues, etc.)

2. Verify the Base Requirements section is correctly migrated from version 2.0:
http://open-services.net/bin/view/Main/RmSpecificationV2

3. Verify the appropriate document sections from the version 2.0 specification have been migrated to the appropriate sections in the 2.1 specification

4. Verify the vocabulary and shapes are consistent with the HTML tables in the 2.0 specification

5. Verify the overall structure, completeness and readability of the specification

6. Ensure compatibility with OSLC core 2.0 and 3.0, and that no semantic or implementation dependent changes have been made in the 2.1 specification.

These and other guidelines are summarized on the OSLC Domains TC Wiki:
https://github.com/oasis-tcs/oslc-domains/wiki

Please send your review comments to this mailing list. Let's try to get the RM spec reviewed within the next two weeks. Then we will create a committee specification draft and
 submit for public review.

Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data

919-525-6575

Attachment:
OSLC RM Reviews.docx

Description: OSLC RM Reviews.docx