Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repetition & inconsistency within Clause 6.1 Requirements : The Specification (Core) / Specification model #30

Closed
PeterParslow opened this issue Jul 22, 2024 · 0 comments

Comments

@PeterParslow
Copy link
Contributor

Bullet items 6 & 8 of Clause 6.1 of 08-131r3 overlap rather:

In the current (2009) version, they say:

  1. Tests may be grouped for convenience into conformance test modules (ISO 19105)
  2. The tests are organized into some number of conformance "classes". If a standard does not do this, it is has by default only one "conformance class".

In the editors draft as at 22nd July 2024, the clause is numbered 7.1 and these two bullets say:

  1. Tests are be grouped for convenience into conformance test classes and if desired the classes are grouped into conformance test modules.
  2. The tests are organized into some number of conformance “classes” where each conformance class has a one to one relationship with a requirements class. If a standard does not do this, it is has by default only one “conformance class”.

I started looking because of the "are be"! I support the change from "may be" to "are", but propose that 6 is about requirements & 8 about tests:

  1. The requirements are grouped for convenience into requirements classes and if desired the classes are grouped into requirements modules. If a standard does not do this, it is has by default only one “requirements class”.
  2. The tests are organized into some number of conformance “classes” where each conformance class has a one to one relationship with a requirements class. If a standard does not do this, it is has by default only one “conformance class”.

This could be agreed, but the changes can't be finalised until #29 & #19 are decided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants