search

ISO-TC211 / StandardsTracker

This GitHub repository lets you - our users - log and track issues that you find with our standards and other document. Tag the issue with the standard or standards effected; we will assign it to the relevant group(s) within TC 211.
12 stars 0 forks source link

Layout conventions for requirements #107

Open isotc211 opened 3 years ago

isotc211 commented 3 years ago

Justification: Resolution 596 Template for table of requirements classes and requirements

ISO/TC 211 invites the PMG in cooperation with the project leaders for projects 19136-2, 19150-2, 19103 and 19160-1 to cooperate on drafting a template for requirements classes and requirements in ISO/TC 211 deliverables.

ISO/TC 211 requests that the project leaders report on the progress at the 35th plenary. Proposal: Include specifications for layout conventions for modularization (recommendation 4 in the report on Configuration management and backward compatibility, document N3165). See also PMG report from Jeddah (slides 17-19).

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

Recent examples: 19159-2 does not format the requirements separately, they are "hidden" inline in the clause text and can be found by searching for "shall"

19119:2016 formats them as in what appears to be a "path-like" string structure... /req/computationalviewpoint/interfaces which i have used before in 19155-2. they are also surrounded by a box.

19107 revision in current development has a numbered structure, with a TOC at the front of the document. however they are formatted as text statements, not "path-like" string structures.

N3936 Recommendations for cultural and linguistic adaptability use a numbered heading type of format, without a box and without the "path-like" structures. some additional information to my earlier examples

it would really be nice if both the requirements format and uml notation text/format could be specified. such as

having a "best approved" method for formatting requirements, that is acceptable to both TC211 and OGC (because of common projects) would be very helpful.

isotc211 commented 3 years ago

201212_PMG_PlenaryReport_Jeddah.pdf

ronaldtse commented 2 years ago

I'd like to revive this issue about presentation of requirements and more importantly the definition of requirements.

Since the creation of this ticket, OGC has formalised its layout presentation for requirements, and the attributes necessary for the "requirements quattro":

The TC 211/AutoDoc group has been working on a draft on requirements models. Can we finally attempt to finish the work here and close this ticket?

cc: @ISO-TC211/adhoc-automated-documentation

ReesePlews commented 2 years ago

hi @ronaldtse thank you for revisiting this important topic! if there is an opportunity to start a revision, perhaps we should clarify the terminology here...

i think it is better to refer to these collectively as "provisions" and iso recognizes the following types of provisions [Source: ISO DIR2 Clause 7]:

people, and that means me included, often find it easy to refer to them in a group as "requirements" but in reality they are "provisions".

i dont know if this means we only have the "quattro" for requirements but we often have other provisions in our documents and some earlier published documents have formatted them as such and we have recognized some of these in our conformance URI scheme.

looking forward to when documents will be ISO SMART compliant, handling all the provisions will be very important. for a long time tc211, following ogc, has structured the documents carefully, however if this is the opportunity to consider such a revision perhaps now is a good time to think how we may work with all of the provisions, not just the ones we are familiar with... for the future when needed.

heidivanparys commented 2 years ago

The TC 211/AutoDoc group has been working on a draft on requirements models. Can we finally attempt to finish the work here and close this ticket?

According to the report, the recommendation of @ISO-TC211/adhoc-automated-documentation is to “set up a NWIP for standardizing the conceptual model for a modular specification. This should be done in collaboration with OGC.”

Is there agreement in the TC that that is the next step?

ronaldtse commented 2 years ago

Thanks @ReesePlews and @heidivanparys . I agree with the term "provisions", but in any case, ISO does not official have "requirements class", "conformance tests" and "conformance classes".

In fact, ISO does have "test methods" defined in ISO DIR 2, Clause 18. I believe we are not going to use the ISO "test methods" because this representation does not meet ISO/TC 211 requirements like URIs and the ability to use "classes".

https://www.iso.org/sites/directives/current/part2/index.xhtml#_idTextAnchor248

18 Measurement and test methods

18.1 Purpose or rationale

Measurement and test methods specify the procedure for determining the values of characteristics or for checking conformity to stated requirements. Using a standardized test method ensures comparability of the results.

Measurement and test methods may be presented as separate clauses, or be incorporated in the requirements, or be presented as annexes (see Clause 20) or as separate parts (see 6.3). A measurement and test method shall be prepared as a separate document if it is likely to be referred to in a number of other documents.

BTW, OGC ModSpec will likely be undergoing a revision soon, proposed by yours truly... But the basic structure of the quattro of requirements, requirements class, conformance test and conformance class will likely remain unchanged.

ronaldtse commented 2 years ago

In the PMG meeting on 2022-10-06 we discussed the following presentations, and it is resolved to handle these in the upcoming plenary at a PMG meeting.

Screen Shot 2022-10-19 at 9 47 48 AM Screen Shot 2022-10-19 at 9 47 57 AM Screen Shot 2022-10-19 at 9 48 06 AM Screen Shot 2022-10-19 at 9 48 15 AM Screen Shot 2022-10-19 at 9 48 24 AM