46
provide knowledge and experts about regional standard and interoperability arrangements; support the SIF to complete the tasks submitted by Communities.
The SIF European Regional team will identify subject matter experts representing each or most of the Societal Benefit Areas of GEOSS in
Europe. facilitate the registration of European standards and interoperability best practices e.g. special
arrangements. be prepared to review standards and special arrangements submitted for entry into the standards registry.
help reach out to scientific Communities in Europe, as far as GEOSS is concerned. URL for accessing the present GEOSS deployed services is http:geossregistries.info
Copyright © OGC 2010
47
9.3 Annex 3 Requirements on Requirements
The following requirements define a set of basic rules on how to write requirements. The rules are derived from ECSS E-10 6C [RD7] which can be used as a reference for writing
requirements.
Each requirement shall be separately stated. A requirement shall be self-contained.
Each requirement shall consist of a single sentence with ―shall‖ or ―should‖, Note: notes like this can be used to clarify the sense of the requirement
The verbal form ―shall‖ shall be used whenever a provision is a requirement. The verbal form ―should‖ shall be used whenever a provision is a
recommendation. The verbal form ―may‖ shall be used whenever a provision is a permission.
The verbal form ―can‖ shall be used to indicate possibility or capability. Requirements should be stated in performance or ―what-is-necessary‖ terms, as
opposed to telling a supplier ―how to‖ perform a task, unless the exact steps in performance of the task are essential to ensure the proper functioning of the
product. Requirements should be expressed in a positive way, as a complete sentence verb
and noun. The entity responsible of the technical requirement shall be identified.
All technical requirements shall be backwards-traceable and forwards-traceable. Any detected ambiguity in a requirement shall be removed.
Each requirement shall be unique. Each requirement shall have a unique identifier
A proposed syntax for the requirement identifier should be project-acronym-XXX-YYY-NNN
Where project-acronym is something like GEO
XXX is an identifier of the topicworking group, e.g. CAT for ―‖Catalogue‖
48 YYY is a 2nd level acronym e.g. FUN for functional, GEN for general,
OPE for operational.. NNN is a counter, it is suggested to start numbering requirements with a
step of 10 e.g. 010, 020 etc, in order to be able to insert new requirements later e.g 011, 012 etc.
The requirements should be grouped by type or in accordance with the different situations of the product or system life cycle in regard of the needs, the
environmental conditions and the constraints. The requirements shall be unambiguous and not in conflict with the other
associated requirements in contractual documentation. A priority should be identified for each requirement.
Each performance requirement shall be described in quantifiable terms. Each performance requirement should include an attribute that defines the
method used to determine the required performance. A requirement shall be verifiable using one or more approved verification
methods. The following items and similar ones should not be used in a requirement
o ―andor‖,
o ―etc‖,
o ―goal‖,
o ―shall be included but not limited to‖,
o ―relevant‖, ―necessary‖, ―appropriate‖,
o ―as far as possible‖,
o ―optimize‖, ―minimize‖, ―maximize‖,
o ―typical‖,
o ―rapid‖, ―quick‖
o ―user-friendly‖,
o ―easy‖,
o ―sufficient‖, ―enough‖,
o ―suitable‖, ―satisfactory‖, ―adequate‖,
o ―first rate‖,
