Skip to content

Instantly share code, notes, and snippets.

@lmmx

lmmx/gist:4d04681b50e306b4a19162e3a9ce318d

Forked from wtpayne/gist:93926afe7d702278d56f9a3835000907
Created February 5, 2025 12:52
Show Gist options
  • Save lmmx/4d04681b50e306b4a19162e3a9ce318d to your computer and use it in GitHub Desktop.
Save lmmx/4d04681b50e306b4a19162e3a9ce318d to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.txt
---
# -----------------------------------------------------------------------------
# qr0001 – /Precision/UseDefiniteArticles
#
qr0001_precision_usedefinitearticles:
definition: >
Use definite article "the" rather than the
indefinite article "a."
description: |
The definite article is "the"; the indefinite
article is "a." Use of the indefinite article can
lead to ambiguity. For example, if the
requirement refers to "a user" it is unclear
whether it means any user or one of the defined
users for which the system has been designed.
This causes further confusion in verification—for
example, babies are arguably users of baby food,
but the system would fail if the test agency
sought to verify that a baby could order,
receive, open, and serve (and even independently
consume) baby food. On the other hand, if the
requirement refers to "the User," the reference
is explicitly to the nature of the user defined
in the glossary.
instruction:
evaluate: |
Evaluate the given requirement statement against
qr0001: "Use definite article 'the' rather than
the indefinite article 'a' or 'an' to avoid
ambiguity."
1. Check if the statement uses indefinite
articles (a/an) in places where the
requirement subject or object should be
precisely defined.
2. Determine if it should instead use "the"
(as per the rule definition).
3. Based on your findings, decide if the
statement is conforming or nonconforming
and briefly explain why.
example:
- nonconforming:
text: |
The system shall provide a time display.
reasoning: |
This is nonconforming because the use of the
indefinite article "a" makes the nature of the
time display ambiguous. As a result the intended
meaning of the requirement unclear and the
requirement is difficult to verify.
evaluation: nonconforming
conforming:
- text: |
The system shall display the Current_Time.
reasoning: |
This is conforming because it uses the term
"Current_Time" which is defined in the glossary,
making the requirement unambiguous and
verifiable.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.1"
# -----------------------------------------------------------------------------
# qr0002 – /Precision/UseActiveVoice
#
qr0002_precision_useactivevoice:
definition: >
Use the active voice with the actor clearly
identified.
description: |
The active voice requires that the actor/entity
performing the action is the subject of the
sentence, since the onus for satisfying the
requirement is on the subject, not the object of
the sentence. If the actor/entity responsible
for the system is not identified explicitly, it
is unclear who/what should perform the action.
Further, verification of the requirement is very
difficult, largely because it is the responsible
actor/entity that is to be the subject of the
verification activity. The subject also helps
ensure the requirement is stated at the
appropriate level consistent with the actor
name (see qr0003_precision_subject). Often when
the phrase "shall be" is used, the statement is
in the passive voice.
instruction:
evaluate: |
Evaluate the given requirement statement against
qr0002: "Use the active voice with the actor
clearly identified."
1. Verify whether the requirement explicitly
names the actor (e.g., a system, subsystem,
or component) that performs the action.
2. Check for passive constructions like
"shall be done" or "shall be confirmed" with
no clear subject.
3. If the requirement uses active voice with a
clear subject, it is conforming. Otherwise,
it is nonconforming. Provide a concise
rationale.
example:
- nonconforming:
text: |
The Identity of the Customer shall be confirmed.
reasoning: |
This is nonconforming because the actor/entity
performing the action is not identified. Without
a clear subject, it is unclear who is responsible
for confirming the identity, which makes
verification difficult.
evaluation: nonconforming
conforming:
- text: |
The Accounting_System shall confirm the Identity
of the Customer.
reasoning: |
This is conforming because the actor
("Accounting_System") is clearly identified as
responsible for performing the action.
This clarification ensures that verification
can be effectively conducted. Terms such as
"Accounting_System," "Identity," and "Customer"
must be defined in the glossary to avoid
ambiguity.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.2"
# -----------------------------------------------------------------------------
# qr0003 – /Precision/Subject
#
qr0003_precision_subject:
definition: >
Make the subject of the requirement appropriate
to the layer in which the requirement exists.
description: |
The subject of a requirement statement is an
indicator of its level. System requirements with
"The <system> shall …"; subsystem requirements
with "The <subsystem> shall ..."; etc.
Ask yourself if the subject of a requirement is
the right one, or would the requirement be
better expressed at a lower or higher level.
Also ask if this is the appropriate level to
verify that the requirement has been met.
instruction:
evaluate: |
Evaluate the given requirement statement against
qr0003: "Make the subject of the requirement
appropriate to the layer in which the requirement
exists."
1. Check if the subject (system, subsystem,
component) matches the level at which this
requirement is intended (system-level,
subsystem-level, etc.).
2. If the statement's subject is too broad or
too narrow for the specified requirement
level, it is nonconforming.
3. Classify the requirement as conforming or
nonconforming and justify briefly.
example:
- nonconforming:
text: |
The <system> shall <some subsystem level
requirement>.
reasoning: |
This is nonconforming because the subject of the
requirement is not appropriate to the level of
the requirement. The requirement specifies a
subsystem-level action but uses the system-level
subject, which may lead to confusion about the
scope and verification of the requirement.
evaluation: nonconforming
conforming:
- text: |
The <subsystem> shall <some subsystem level
requirement>.
reasoning: |
This is conforming because the subject of the
requirement correctly corresponds to the level
at which the requirement is defined. The
subsystem is the correct subject for this
requirement, ensuring clarity and proper scope.
evaluation: conforming
reference:
- id_ref: "qc0002_appropriate"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.3"
# -----------------------------------------------------------------------------
# qr0004 – /Precision/UseDefinedTerms
#
qr0004_precision_usedefinedterms:
definition: >
Only use terms defined in the glossary.
description: |
Most languages are extremely rich with almost
every word having a number of synonyms, each
with a subtly different meaning. In requirements,
shades of meaning will most likely lead to
ambiguity and to difficulty in verification.
The use of a glossary allows the reader of a
requirement to know exactly what the writer
meant when a particular word was chosen.
A standard should be agreed upon in order to
make the use of glossary terms identifiable in
the requirements text; for example, glossary
items may be capitalized and multiple words in
single terms joined by an underscore (e.g.,
"Current_Time"). This is essential for
consistency to avoid using the word with its
general meaning.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0004: "Only use terms defined in the
glossary."
1. Identify any terms in the requirement that
might be ambiguous or undefined.
2. If the statement uses glossary-defined terms
consistently, it is conforming. If it
introduces unrecognized terms or synonyms,
it is nonconforming.
3. Conclude with conforming or nonconforming
and a short explanation.
example:
- nonconforming:
text: |
The arrivals board shall display continuously
the current time.
reasoning: |
This is nonconforming because the term 'current'
is ambiguous. The meaning of 'current' could
vary in terms of time zone, accuracy, and
format. Without a precise definition in the
glossary, this requirement leaves too much room
for interpretation and is difficult to verify.
evaluation: nonconforming
conforming:
- text: |
The Arrivals_Board shall display the
Current_Time.
reasoning: |
This is conforming because "Arrivals_Board" and
"Current_Time" are defined terms, which
eliminates ambiguity. The latter term should
be defined in the glossary to include specific
details like accuracy, format, and time zone,
ensuring clarity and verifiability.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0013_comprehensible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0014_able_to_be_validated"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.4"
# -----------------------------------------------------------------------------
# qr0005 – /Precision/Quantify
#
qr0005_precision_quantify:
definition: >
Quantify requirements precisely.
description: |
Requirements should be quantified precisely.
Avoid words that provide vague quantification,
such as "some," "any," "several," "many,"
"a lot of," "a few," "approximately,"
"almost always," "very nearly," "nearly,"
"about," "close to," "almost," "approximate,"
"significant," "flexible," "expandable,"
"typical," "sufficient," "adequate,"
"appropriate," "efficient," "effective,"
"proficient," "reasonable."
Care should be taken to avoid unspecified units
and unspecified value ranges.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0005: "Quantify requirements precisely."
1. Look for vague words (some, any, several,
approximate, etc.) or unspecified ranges that
make the requirement imprecise.
2. Decide whether there is a clear, measurable
value or tolerance specified.
3. Classify the statement as conforming or
nonconforming, and explain.
example:
- nonconforming:
text: |
The Flight_Information_System shall display the
current altitude to approximately 1 meter
resolution.
reasoning: |
This is nonconforming because the use of
"approximately" introduces imprecision. The
term "approximately" is subjective and lacks a
clear, measurable definition, making the
requirement difficult to verify. The exact
tolerance should be specified to ensure clarity
and verifiability.
evaluation: nonconforming
conforming:
- text: |
The Flight_Information_System shall display
Current_Altitude plus or minus 1 meter.
reasoning: |
This is conforming because it specifies a precise
tolerance, which makes the requirement measurable
and verifiable. The term "Current_Altitude"
should be defined in the glossary to avoid any
ambiguity about its meaning, ensuring that it
can be consistently interpreted and verified.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.5"
# -----------------------------------------------------------------------------
# qr0006 – /Precision/Units
#
qr0006_precision_units:
definition: >
Use appropriate units, with tolerances or limits,
when stating quantities.
description: |
All numbers should have units explicitly stated.
Care should also be taken to ensure the units
are quantified with tolerances or limits. There
are two reasons for this:
1. Several requirements may have to be traded
against each other, and providing tolerances
or limits is a way of describing the
trade-space. Seldom is a quantity in a
requirement absolute. A range of values is
usually acceptable, providing different
performance levels.
2. Verification against a single absolute value
is usually not possible or at best very
expensive and time consuming, whereas
verification against a defined range of
values with upper and lower limits makes
verification more manageable.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0006: "Use appropriate units, with tolerances
or limits, when stating quantities."
1. Check if all numerical values include units
(e.g., seconds, meters, Celsius) and any
relevant tolerances (e.g., +/- 1 second).
2. If units or acceptable ranges are missing,
it is nonconforming.
3. Provide a brief conclusion on conformity.
example:
- nonconforming:
text: |
The Circuit_Board shall have a storage
temperature less than 30 degrees.
reasoning: |
This is nonconforming because the units are
incomplete. The requirement does not specify
which system of measurement is used (Celsius,
Fahrenheit, Kelvin, etc.), making the requirement
unclear and unverifiable.
evaluation: nonconforming
conforming:
- text: |
The Circuit_Board shall have a storage
temperature of less than 30 degrees Celsius.
reasoning: |
This is conforming because the unit of
measurement, "Celsius," is explicitly stated,
removing ambiguity and making the requirement
verifiable.
evaluation: conforming
- nonconforming:
text: |
The system shall establish connection to at least
4 in 10 seconds.
reasoning: |
This is nonconforming because the unit "4" is
ambiguous and does not specify what it applies
to. Additionally, "10 seconds" does not include
a tolerance or range, making verification
difficult. A precise 10-second requirement is
challenging to meet and verify. A defined range
would provide more feasible verification.
evaluation: nonconforming
conforming:
- text: |
The system shall establish connection to at
least 4 satellites in less than or equal to 10
seconds.
reasoning: |
This is conforming because both the quantity
("4 satellites") and the time limit
("10 seconds") are specified with appropriate
units, and the use of a range for time ("less
than or equal to 10 seconds") results in a more
verifiable and feasible requirement.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0008_correct"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.6"
# -----------------------------------------------------------------------------
# qr0007 – /Precision/AvoidAdverbs
#
qr0007_precision_avoidadverbs:
definition: >
Avoid the use of adverbs.
description: |
Adverbs qualify actions in some way. Avoid vague
adverbs, such as "usually," "approximately,"
"sufficiently," "typically." Adverbs can lead to
ambiguous, unverifiable requirements that do not
reflect accurately the stakeholder expectations.
Words that end in "-ly" should be avoided.
instruction:
evaluate: |
Evaluate the given requirement statement against
qr0007: "Avoid the use of adverbs that introduce
vagueness (e.g., usually, sufficiently,
typically)."
1. Check if the statement relies on adverbs that
make the requirement ambiguous.
2. If so, classify it as nonconforming;
otherwise, it is conforming.
3. Summarize your reasoning.
example:
- nonconforming:
text: |
The Flight_Information_System shall usually be
on line.
reasoning: |
This is nonconforming because the adverb
"usually" introduces ambiguity. It is unclear
what "usually" means in terms of system
availability. This vagueness makes the
requirement difficult to verify and does not
provide clear expectations.
evaluation: nonconforming
conforming:
- text: |
The Flight_Information_System shall have an
Availability of at least 98% over a period of
at least 48 hours.
reasoning: |
This is conforming because the requirement
specifies a precise threshold for "Availability"
and a defined time period, which eliminates
ambiguity and makes the requirement measurable
and verifiable. Note that "Availability" should
be defined in the glossary to avoid any potential
misinterpretations.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.7"
# -----------------------------------------------------------------------------
# qr0008 – /Precision/AvoidVagueAdjectives
#
qr0008_precision_avoidvagueadjectives:
definition: >
Avoid the use of vague adjectives.
description: |
Adjectives qualify entities in some way. Avoid
vague adjectives such as "ancillary," "relevant,"
"routine," "common," "generic," and "customary."
Adjectives can lead to ambiguous, unverifiable
requirements that do not reflect accurately the
stakeholder expectations.
instruction:
evaluate: |
Evaluate the given requirement statement against
qr0008: "Avoid the use of vague adjectives
(e.g., relevant, routine, common, generic)."
1. Identify any adjectives that could be
ambiguous or open to interpretation.
2. If vague adjectives appear and are not
clearly defined, mark it nonconforming.
3. Conclude with conforming or nonconforming
and briefly explain.
example:
- nonconforming:
text: |
The Flight_Information_System shall display the
Tracking_Information for relevant aircraft.
reasoning: |
This is nonconforming because the adjective
"relevant" is vague and does not specify which
aircraft are included. The term "relevant"
introduces ambiguity, leaving it up to the
developer to decide, which should instead be
determined by the customer to ensure the
requirement is explicit and verifiable.
evaluation: nonconforming
conforming:
- text: |
The Flight_Information_System shall display the
Tracking_Information of each Aircraft located
less than or equal to 20 kilometers from the
Airfield.
reasoning: |
This is conforming because the requirement
specifies exactly which aircraft are included
("each Aircraft located less than or equal to
20 kilometers from the Airfield"), removing any
ambiguity. Note that "Aircraft,"
"Tracking_Information," and "Airfield" must be
defined in the glossary to avoid any potential
misinterpretations.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.8"
# -----------------------------------------------------------------------------
# qr0009 – /Precision/NoEscapeClauses
#
qr0009_precision_noescapeclauses:
definition: >
Avoid escape clauses.
description: |
Escape clauses give an excuse to the supplier not
to bother with a requirement. They provide vague
conditions or possibilities, using phrases such
as "so far as is possible," "as little as
possible," "as much as possible," "if it should
prove necessary," "where possible," and "if
practicable." Escape clauses can lead to
ambiguous, unverifiable requirements that do
not reflect accurately the stakeholder
expectations.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0009: "Avoid escape clauses (e.g., 'so far
as is possible,' 'where possible,' 'if
practicable')."
1. Check for these or similar phrases that
provide an excuse not to meet the requirement
fully.
2. If found, it is nonconforming.
3. Provide a short rationale.
example:
- nonconforming:
text: |
The GPS shall, where there is sufficient space,
display the User_Location.
reasoning: |
This is nonconforming because the phrase "where
there is sufficient space" introduces vagueness.
It is unclear what constitutes "sufficient
space," and this condition cannot be easily
verified. The requirement would be clearer
and more verifiable without the escape clause.
evaluation: nonconforming
conforming:
- text: |
The GPS shall display the User_Location.
reasoning: |
This is conforming because the requirement
specifies exactly what the system should do
without introducing ambiguity. Note that "GPS"
and "User_Location" must be defined in the
glossary, and specific performance requirements
such as time, format, and accuracy should also
be included for clarity and verifiability.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.9"
# -----------------------------------------------------------------------------
# qr0010 – /Precision/NoOpenEnded
#
qr0010_precision_noopenended:
definition: >
Avoid open-ended clauses.
description: |
Open-ended clauses say that there is more
required without stating exactly what. Avoid
phrases such as "including but not limited to,"
"etc." and "and so on."
Open-ended clauses can lead to ambiguous,
unverifiable requirements that do not reflect
accurately the stakeholder expectations. Use of
open-ended clauses also violates the one thought
rule and singular characteristic. If more cases
are required, then include additional
requirements that explicitly state those cases.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0010: "Avoid open-ended clauses
(e.g., 'including but not limited to,' 'etc.,'
'and so on')."
1. Check for open-ended wording that implies
unspecified or infinite scope.
2. If present, mark as nonconforming.
3. Conclude with your classification and
reasoning.
example:
- nonconforming:
text: |
The ATM shall display the
Customer_Account_Number, Account_Balance, and so
on.
reasoning: |
This is nonconforming because the phrase
"and so on" is open-ended and vague. It leaves
the requirement incomplete and unverifiable by
not specifying exactly what other
account details should be displayed. A clear
and specific list of requirements should be
provided.
evaluation: nonconforming
conforming:
- text: |
- The ATM shall display the
Customer_Account_Number.
- The ATM shall display the Account_Balance.
- The ATM shall display the Account_Type.
- The ATM shall display the Overdraft_limit.
reasoning: |
This is conforming because the original
nonconforming requirement statement has been
broken down into specific, individual
statements, removing ambiguity and ensuring that
each piece of information is clearly defined.
This approach makes the requirements complete
and verifiable. Note that terms like
"Customer_Account_Number" and "Account_Balance"
should be defined in the glossary for
consistency.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0005_singular"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.1.10"
# -----------------------------------------------------------------------------
# qr0011 – /Concision/NoInfinitives
#
qr0011_concision_noinfinitives:
definition: >
Avoid superfluous infinitives.
description: |
We sometimes see a requirement that contains
more verbs than are necessary to describe a basic
action, such as "The system shall be designed to
be able to ..." or "The system shall be designed
to be capable of ..." rather than simply "The
system shall ..." Think ahead to verification.
If the system is able to, or is capable of, doing
something one time but fails 99 times, has the
system met the requirement? No.
Note that at the enterprise and business layers,
requirements for an entity to "provide a
capability" are acceptable. Where capability is
made up of people, processes, and products,
these requirements will be decomposed to address
the people aspects (skill set, training, roles,
etc.), processes (procedures, work instructions,
etc.); and products (hardware and software
systems). The parent requirement will be
allocated to the people, processes, and
products, as appropriate. When the resulting
requirement sets are implemented for all three
areas, the capability will exist to meet the
entity needs.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0011: "Avoid superfluous infinitives such as
'be able to' or 'be capable of.'"
1. Check if the statement uses "be able to,"
"be capable of," or similarly redundant
phrasing.
2. If so, consider it nonconforming because it
can create ambiguous or weak obligations.
3. Conclude with an explanation of your
classification.
example:
- nonconforming:
text: |
The Weapon_Subsystem shall be able to store the
location of all Ordnance.
reasoning: |
This is nonconforming because the infinitive
"be able to" is superfluous. The phrase adds
unnecessary complexity and does not change the
meaning of the requirement. The requirement
should be direct and concise without redundant
phrasing.
evaluation: nonconforming
conforming:
- text: |
The Weapon_Subsystem shall store the location
of all Ordnance.
reasoning: |
This is conforming because it eliminates the
unnecessary infinitive and states the requirement
clearly and directly. The terms
"Weapon_Subsystem" and "Ordnance" must be defined
in the glossary to ensure consistency and
clarity.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.2.1"
# -----------------------------------------------------------------------------
# qr0012 – /Concision/SeparateClauses
#
qr0012_concision_separateclauses:
definition: >
Use a separate clause for each condition or
qualification.
description: |
Each requirement should have a main verb
describing a basic function or need. The main
sentence may then be supplemented by clauses
that provide conditions or qualifications
(performance values or constraints). A single,
clearly identifiable clause should be used for
each condition or qualification expressed.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0012: "Use a separate clause for each condition
or qualification."
1. Check if the statement lumps multiple
conditions or qualifications into a single
sentence.
2. If it does, it is likely nonconforming. If
each condition or qualification is clearly
separate, it is conforming.
3. Provide a brief justification.
example:
- nonconforming:
text: |
The Navigation_Beacon shall provide
Augmentation_Data at an accuracy of 20 meters or
less to each Maritime_User during Harbor_Harbor
Approach (HHA) maneuvering.
reasoning: |
This is nonconforming because the clauses
describing the performance condition ("accuracy
of 20 meters or less") and the qualification
("during Harbor_Harbor Approach (HHA)
maneuvering") are combined into one sentence.
The requirement becomes unclear and harder to
verify due to the separation of the main function
from the related conditions.
evaluation: nonconforming
conforming:
- text: |
The Navigation_Beacon shall provide
Augmentation_Data to each Maritime_User engaged
in Harbor_Harbor_Approach_maneuvering (HHA), at
an accuracy of 20 meters or less.
reasoning: |
This is conforming because it separates the main
action ("provide Augmentation_Data") from the
performance condition ("at an accuracy of 20
meters or less"), making the sentence clear and
easily verifiable. The qualification is kept
distinct, ensuring the clarity of the
requirement.
Note that:
- "Navigation_Beacon," "Maritime_User," and
"Harbor_Harbor_Approach_maneuvering (HHA)"
must be defined in the glossary.
- The two quantities (accuracy and data
availability) are not independently verifiable,
and therefore remain together in a single
requirement.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.2.2"
# -----------------------------------------------------------------------------
# qr0013 – /NonAmbiguity/CorrectGrammar
#
qr0013_nonambiguity_correctgrammar:
definition: >
Use correct grammar.
description: |
We interpret language based on the rules of
grammar. Incorrect grammar leads to ambiguity
and clouds understanding. This is especially
true when the recipient of the requirement
learned the language as a second language using
specific rules of grammar. If these rules are
not followed, that person may misinterpret the
meaning of the requirement.
Particular care must be taken when translating
requirements from one language to another and
when sentence structure differs depending on
the language in which the original requirement
was written. Punctuation varies from language
to language and even between dialects of a
given language. Be very cautious when
requirements must be translated.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0013: "Use correct grammar to avoid ambiguity."
1. Look for grammatical errors that may create
confusion (verb tense, subject-verb
agreement, etc.).
2. If errors could change the requirement's
meaning, mark it nonconforming.
3. Briefly state why.
example:
- nonconforming:
text: |
The Weapon_Subsystem shall storing the location
of all ordnance.
reasoning: |
This is nonconforming because the grammatical
error ("storing" instead of "store") creates
uncertainty in the meaning. The incorrect verb
tense undermines clarity and could lead to
misinterpretation of the requirement.
evaluation: nonconforming
conforming:
- text: |
The Weapon_Subsystem shall store the location of
all Ordnance.
reasoning: |
This is conforming because it uses correct
grammar, which ensures clarity and avoids
ambiguity. The term "Ordnance" should be defined
in the glossary to ensure consistent
interpretation of the types of weapons and
ammunition.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0009_conforming"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.3.1"
# -----------------------------------------------------------------------------
# qr0014 – /NonAmbiguity/CorrectSpelling
#
qr0014_nonambiguity_correctspelling:
definition: >
Use correct spelling.
description: |
Incorrect spelling can lead to ambiguity and
confusion. Some words may sound the same but
depending on the spelling will have entirely
different meaning. For example "red" vs. "read"
or "ordinance" vs "ordnance." In these cases a
spell checker will not find an error.
In addition to misspelling, this rule also
refers to the proper use of:
* Capital letters in acronyms: avoid "SYRD"
and "SyRD" in the same specification.
* Capital letters in other non-acronyms
concepts: avoid "Requirements Working Group"
and "Requirements working group" in the same
specification.
* Proper use of hyphenation: avoid
"non-functional" and "nonfunctional."
instruction:
evaluate: |
Evaluate the requirement statement against
qr0014: "Use correct spelling to avoid ambiguity."
1. Identify any misspellings that could alter
the requirement's meaning (e.g., 'ordinance'
vs. 'ordnance').
2. If present, it is nonconforming.
3. Summarize your reasoning.
example:
- nonconforming:
text: |
The Weapon_Subsystem shall store the location of
all ordinance.
reasoning: |
This is nonconforming because "ordinance" refers
to regulations or laws, which is not the intended
meaning. In this context, the correct term is
"ordnance," which refers to weapons and
ammunition. Incorrect spelling leads to confusion
and misinterpretation of the requirement.
evaluation: nonconforming
conforming:
- text: |
The Weapon_Subsystem shall store the location of
all Ordnance.
reasoning: |
This is conforming because "Ordnance" is spelled
correctly, ensuring clarity and accuracy. The
term "Ordnance" must be defined in the glossary
to specify the types of weapons and ammunition
being referred to.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.3.2"
# -----------------------------------------------------------------------------
# qr0015 – /NonAmbiguity/CorrectPunctuation
#
qr0015_nonambiguity_correctpunctuation:
definition: >
Use correct punctuation.
description: |
Incorrect punctuation can cause confusion between
sub-clauses in a requirement. Note also that the
more punctuation in the requirement statement,
the greater the opportunity for ambiguity.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0015: "Use correct punctuation to ensure
clarity."
1. Check for misplaced commas, colons, or other
punctuation that could alter the meaning.
2. If punctuation causes ambiguity, the
statement is nonconforming.
3. Provide a concise explanation.
example:
- nonconforming:
text: |
The Navigation_Beacon shall provide
Augmentation_Data to each Maritime_User, engaged
in Harbor_Harbor_Approach_maneuvering (HHA) at
an accuracy of 20 meters or less at least 99.7%
of the time.
reasoning: |
This is nonconforming because the incorrectly
placed comma causes confusion about the meaning.
The sentence reads as though the accuracy is
tied to the maneuvering rather than to the
augmentation data, which leads to an ambiguous
requirement.
evaluation: nonconforming
conforming:
- text: |
The Navigation_Beacon shall provide
Augmentation_Data to each Maritime_User engaged
in Harbor_Harbor_Approach_maneuvering (HHA), at
an accuracy of 20 meters or less at least 99.7%
of the time.
reasoning: |
This is conforming because the comma is correctly
placed, making it clear that the accuracy and
availability apply to the data, not the
maneuvering. The punctuation improves clarity
and removes ambiguity.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.3.3"
# -----------------------------------------------------------------------------
# qr0016 – /NonAmbiguity/Conjunction
#
qr0016_nonambiguity_conjunction:
definition: >
Use the logical construct "[X and Y]" instead of
"both X and Y."
description: |
The logical expression "[X and Y]" should be
understood to mean both of them without having
to add the word 'both'. Adding the word 'both'
may lead the reader to think that something
different is meant.
As with the other rules and characteristics,
we want to keep requirement statements as one
thought with singular statements. Thus we avoid
using "and" when it involves tying two thoughts
together. However, it is acceptable to use "and"
in a logical sense when talking about multiple
conditions that apply to when the verb applies.
Examples of conventions:
- Place conjunctions in italics or in all
capitals (AND, OR, NOT) to indicate that the
author intends the conjunction to play a role
in a condition.
- Place conditions within square brackets, also
using the brackets to control their scope. For
example "[x AND y]."
Also see qr0020_singularity_avoidcombinators and
qr0021_singularity_avoidcombinators_exceptinconditions.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0016: "Use the logical construct '[X AND Y]'
instead of 'both X and Y.'"
1. Check if the phrase 'both X and Y' is used
instead of a direct logical statement.
2. If the statement uses 'both' in a way that
introduces ambiguity, it is nonconforming.
3. Conclude with your classification and a short
explanation.
example:
- nonconforming:
text: |
The Engine_Management_System shall disengage the
Speed_Control_Subsystem when both the
Cruise_Control is engaged AND the Driver applies
the Accelerator.
reasoning: |
This is nonconforming because the use of "both"
is unnecessary and may introduce ambiguity. The
word "both" could mislead the reader into
thinking that something different is meant. A
logical expression should be used instead.
evaluation: nonconforming
conforming:
- text: |
The Engine_Management_System shall disengage the
Speed_Control_Subsystem, when [the Cruise_Control
is engaged AND the Driver is applies the
Accelerator].
reasoning: |
This is conforming because the logical expression
"[x AND y]" is used, which is clearer and more
precise than using "both." This ensures there is
no ambiguity in the requirement.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.3.4"
# -----------------------------------------------------------------------------
# qr0017 – /NonAmbiguity/AvoidAndOr
#
qr0017_nonambiguity_avoidandor:
definition: >
Avoid the use of "X and/or Y."
description: |
Use of "and/or" is ambiguous. The most common
interpretation of the expression "and/or" is as
an inclusive or: either X or Y or both. If that
is the intention, it should be written as two
requirements, each of which can be verified
separately.
If logical "and" is meant, then see
qr0016_nonambiguity_conjunction.
If logical exclusive "or" is meant (either X or
Y, but not both), then write the logical
statement [X OR Y].
Note: make clear in your glossary that when
[X or Y] is used, it means the exclusive version
of "or."
Also see qr0020_singularity_avoidcombinators and
qr0021_singularity_avoidcombinators_exceptinconditions.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0017: "Avoid the use of 'X and/or Y' because
it is ambiguous."
1. Determine whether 'and/or' is used. If it is,
you must decide if the intended meaning is
AND, OR, or separate statements.
2. If 'and/or' appears, mark nonconforming.
3. Summarize briefly.
example:
- nonconforming:
text: |
The Engine_Management_System shall disengage the
Speed_Control_Subsystem when the Clutch is
disengaged and/or the Driver applies the Brake.
reasoning: |
This is nonconforming because the use of "and/or"
introduces ambiguity. If "and" is meant, the two
thoughts should be separated into distinct
requirements. If "or" is meant, it should be
written as an exclusive "or," not as an ambiguous
"and/or."
evaluation: nonconforming
conforming:
- text: |
- The Engine_Management_System shall disengage
the Speed_Control_Subsystem when the Clutch
is disengaged.
- The Engine_Management_System shall disengage
the Speed_Control_Subsystem when the Driver
is applying the Brake.
reasoning: |
This is conforming if "and" was intended by the
original use of "and/or." The two conditions are
now clearly separated into distinct requirements,
making the intent explicit and verifiable.
evaluation: conforming
- text: |
The Engine_Management_System shall disengage
the Speed_Control_Subsystem when [the Clutch
is disengaged OR Driver is applying the Brake].
reasoning: |
This is conforming if "or" was intended by the
original use of "and/or." The logical "or" is
now used explicitly in a clear and verifiable
form, removing ambiguity.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.3.5"
# -----------------------------------------------------------------------------
# qr0018 – /NonAmbiguity/Oblique
#
qr0018_nonambiguity_oblique:
definition: >
Avoid the use of the oblique ("/") symbol.
description: |
The oblique symbol (or "slash") has so many
possible meanings that it should be avoided.
The slash symbol (like the construct "and/or"
discussed in R17) can lead to ambiguous
requirements that do not reflect accurately the
true customer needs.
An exception to this rule is where the oblique
symbol is used in SI units (for example "km/h").
Also see qr0020_singularity_avoidcombinators
instruction:
evaluate: |
Evaluate the requirement statement against
qr0018: "Avoid the use of the oblique slash
'/' unless it is part of an SI unit."
1. Look for any slashes that combine concepts
(e.g., 'start/stop').
2. If found outside of standardized units
(like 'km/h'), the requirement is
nonconforming.
3. Provide a short explanation.
example:
- nonconforming:
text: |
The User_Management_System shall Open/Close the
User_Account in less than 1 second.
reasoning: |
This is nonconforming because the use of the
oblique symbol introduces ambiguity. It is
unclear whether the system should perform both
actions ("Open" and "Close") or just one of
them. The meaning is not explicit, leading to
confusion about the requirement.
evaluation: nonconforming
conforming:
- text: |
- The User_Management_System shall Open the
User_Account in less than 1 second.
- The User_Management_System shall Close the
User_Account in less than 1 second.
reasoning: |
This is conforming because the requirement has
been split into two distinct statements, removing
ambiguity. Each requirement is now clear,
specific, and verifiable.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.3.6"
# -----------------------------------------------------------------------------
# qr0019 - /Singularity/SingleSentence
#
qr0019_singularity_singlesentence:
definition: >
Write a single, simple, single-thought,
affirmative, declarative sentence, conditioned
and qualified by relevant sub-clauses.
description: |
Write a simple affirmative declarative sentence
with a single subject, a single main action verb
and a single object, framed and qualified by one
or more sub-clauses.
ISO/IEC 29148 states that a typical sentence
form for a functional requirements is 'When
<condition clause>, the <subject clause> shall
<action verb clause> <object clause> <optional
qualifying clause>.
The use of this style, however, means that all
requirements do not start with the standard
construct "The <subject clause> shall ...." To
retain that structure, therefore, there are
other styles in common use:
1. Some styles retain the standard construct
"The <subject clause> shall ...." and place
the condition immediately after the verb
clause ('The <subject clause> shall, when
<condition clause>, <action verb clause>
<object clause> <optional qualifying
clause>.") because the condition is a
qualification of the verb and should
therefore occur immediately after it. Some
styles allow the condition to occur between
the subject and the verb ("The <subject
clause>, when <condition clause>, shall
<action verb clause> <object clause>
<optional qualifying clause>."). Other types
of requirements (e.g., reference
qa0036_type_or_category) may be of a slightly
different form-a <single subject clause>, a
<main verb clause>, a <single object clause>
and any qualifying subclauses.
2. Some style guides eschew this format, however,
preferring to start all requirements without
interruption of the sequence of
<subject clause>, <verb clause>, and
<object clause>, therefore retaining the
construct "The <subject clause> shall ....",
and place the condition at the end of the
sentence ('The <subject clause> shall
<action verb clause> <object clause>
<optional qualifying clause>, when
<condition clause>."). While this retains the
intimacy between the subject, verb and object
clauses, some styles prefer not to have such
a large separation between the verb clause
and the condition that relates to it.
3. Some style guides allow a conditional clause
at the beginning of the requirement: "When
<condition clause>, the <subject clause> shall
<verb clause> <object clause>
<optional qualifying clause>." The
<verb clause> may be of the form "presents"
and the "object clause" is the quality being
presented. For example, "shall have the
reliability of xxx' or "shall be in
compliance with all EPA restrictions on
material usage."
Although the ISO/IEC 29148 style is preferred
for consistency internationally, any one of the
styles is acceptable so long as the same
construct is used consistently throughout the
requirement set. To ensure consistency within
your organization and domain, your organization's
processes for requirement development and
management needs to include a definition of
allowable form for individual requirement
statements.
A requirement that communicates a constraint is
structured as defined above.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0019: "Write a single, simple, single-thought,
affirmative, declarative sentence, conditioned
and qualified by relevant sub-clauses."
1. Check if the requirement tries to convey more
than one action or condition in a single
statement.
2. If it includes multiple distinct actions or
multiple sentences, it may be nonconforming.
3. Conclude conforming or nonconforming with a
brief justification.
example:
- nonconforming:
text: |
The Control_Subsystem will close the Inlet_Valve
until the temperature has reduced to 85 °C, when
it will reopen it.
reasoning: |
This is nonconforming because the sentence
contains two requirements, and the pronoun
"it" is ambiguously referring to different
objects (see qr0026_completeness_avoidpronouns).
Additionally, the use of "has reduced" is vague,
and the modal verb should be "shall" instead
of "will."
evaluation: nonconforming
conforming:
- text: |
- The Control_Subsystem shall close the
Inlet_Valve in less than 3 seconds when the
temperature of water in the Boiler is greater
than 85 °C.
- The Control_Subsystem shall open the
Inlet_Valve in less than 3 seconds when the
temperature of water in the Boiler is less
than or equal to 85 °C.
reasoning: |
This is conforming because the original
ambiguous statement has been split into two
distinct, testable requirements, each with a
clear subject, verb, and object. The performance
is also quantified, making the requirements more
precise and verifiable. Note the use of the
glossary to define terms.
evaluation: conforming
- text: |
When the temperature of water in the Boiler
is less than or equal to 85 °C the
Control_Subsystem shall open the Inlet_Valve
in less than 3 seconds.
reasoning: |
This is conforming because it is a singular
sentence that conveys a single, testable, atomic
requirement. It maintains clarity by presenting
a condition followed by a clear action, making
it easily verifiable.
evaluation: conforming
- text: |
The Control_Subsystem shall, when the
temperature of water in the Boiler is less
than or equal to 85 °C, open the Inlet_Valve
in less than 3 seconds.
reasoning: |
This is conforming because it is a singular
sentence that conveys a single, testable, atomic
requirement. The condition is clearly tied to
the action, making the requirement verifiable
and understandable.
evaluation: conforming
- text: |
The Control_Subsystem shall open the
Inlet_Valve in less than 3 seconds when the
temperature of water in the Boiler is less
than or equal to 85 °C.
reasoning: |
This is conforming because it is a singular
sentence that conveys a single, testable, atomic
requirement. The condition is presented clearly
and is directly tied to the action, ensuring the
requirement is easily understood and verifiable.
evaluation: conforming
exceptions:
- description: |
Every requirement should have a main clause with
a main verb. However, additional sub-clauses with
auxiliary verbs may be used to qualify the
requirement with performance attributes.
Such sub-clauses cannot be verified in isolation,
since they are incomprehensible without the main
clause. Sub-clauses that need to be verified
separately from others should be expressed as
separate requirements.
For example, "The Ambulance_Control_System shall
communicate Incident_Details to the Driver" is a
complete, comprehensible statement with a single
main verb. An auxiliary clause may be added to
provide a constraint
"The Ambulance_Control_System shall communicate
Incident_Details to the Driver while
simultaneously maintaining communication with
the Caller."
Note that, if performance attributes need to be
verified separately, they should be expressed as
sub-clauses in separate requirements.
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0005_singular"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0009_conforming"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0013_comprehensible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.4.1"
# -----------------------------------------------------------------------------
# qr0020 – /Singularity/AvoidCombinators
#
qr0020_singularity_avoidcombinators:
definition: >
Avoid combinators.
description: |
Combinators are words that join clauses, such as
"and," "or," "then," "unless," "but," "/,"
"as well as," "but also," "however," "whether,"
"meanwhile," "whereas," "on the other hand," and
"otherwise." Their presence in a requirement
usually indicates that multiple requirements
should be written.
Exception: AND, OR, NOT can be used in
requirements as logical conditions and
qualifiers.
See also:
- qr0016_nonambiguity_conjunction
- qr0017_nonambiguity_avoidandor
- qr0018_nonambiguity_oblique
- qr0021_singularity_avoidcombinators_exceptinconditions
instruction:
evaluate: |
Evaluate the requirement statement against
qr0020: "Avoid combinators (and, or, then,
unless, but, /, etc.) that tie multiple
thoughts together."
1. Check if the statement uses such words to
merge multiple requirements into one.
2. If so, it is likely nonconforming unless
used in a clearly logical condition
(e.g., [X AND Y]) as per other rules.
3. Justify your verdict.
example:
- nonconforming:
text: |
The user shall either be trusted or not trusted.
reasoning: |
This is nonconforming because the sentence
contains a combinator ("either... or") and
expresses two possible outcomes in a single
requirement. It also uses passive voice
(qr0002_precision_useactivevoice) and is
ambiguous: the requirement would still be met
if the system took the option of treating all
users as trusted. The requirement should specify
one condition or the other explicitly, and should
avoid using combinators that join multiple
thoughts in the same sentence.
evaluation: nonconforming
conforming:
- text: |
The Security_System shall categorize each User
as [EITHER Trusted OR Not_Trusted]
reasoning: |
This is conforming because it uses an explicit
logical condition ("EITHER Trusted OR
Not_Trusted") rather than a combinator, making
the requirement clear and verifiable.
evaluation: conforming
- text: |
The Security_System shall categorize each User
as one of the following: Trusted, Not_Trusted.
reasoning: |
This is conforming because it uses an explicitly
enumerated list instead of a combinator, removing
ambiguity and ensuring clarity.
evaluation: conforming
- nonconforming:
text: |
The function "command the sidelights" knows the
demands of the lights, front and back fog lights,
to ensure the regulatory consistency of lights
ignition: the ignition of sidelights is
maintained during the ignition of the side lamps,
or the lights, or the fog lights or the back fog
lights or a combination of these lights.
reasoning: |
This is nonconforming because it uses multiple
combinators ("or" and "or") and is generally
unclear. The sentence expresses more than one
requirement in a single, complex structure,
making it difficult to verify. It also contains
grammar issues and is unnecessarily complicated.
evaluation: nonconforming
conforming:
- text: |
The Control_Sidelights function shall illuminate
the Sidelights while any combination of the
following conditions holds true: the Side_Lamps
are illuminated, the Head_Lamps are illuminated,
the Front_Fog_Lamps are illuminated, the
Rear_Fog_Lamps are illuminated.
reasoning: |
This is conforming because it clarifies the
conditions using a single, comprehensible
sentence. The conditions are listed explicitly,
and the combinators are avoided by applying rule
qr0021_singularity_avoidcombinators_exceptinconditions.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0005_singular"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.4.2"
# -----------------------------------------------------------------------------
# qr0021 – /Singularity/AvoidCombinators/ExceptInConditions
#
qr0021_singularity_avoidcombinators_exceptinconditions:
definition: >
Use an agreed typographical device to indicate
the use of propositional combinators for
expressing a logical condition within a
requirement.
description: |
Sometimes the use of "and" or "or" is
unavoidable. This is because there are times
when several things need to be present to
achieve a correct or desired result. This is
often the case when compound conditions have to
be defined.
If such combinators have to be used, then a
convention for this use should be agreed upon
and stated explicitly at the start of the
requirement document or in the glossary.
Normally when combinators need to be used, the
use can be expressed as a logical expression as
discussed in qr0016_nonambiguity_conjunction and
qr0017_nonambiguity_avoidandor.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0021: "Use an agreed typographical device
(e.g., brackets) for logical combinators when
necessary."
1. Identify if the requirement uses logical
constructs like AND/OR.
2. Check whether it follows a clear convention
(e.g., '[EITHER X OR Y]') to avoid ambiguity.
3. If it does not follow such conventions, mark
as nonconforming and explain why.
example:
- nonconforming:
text: |
The Controller shall close values Valv1 and Valv2
or Valv3, when the temperature of water in the
Boiler exceeds 95 ºC.
reasoning: |
This is nonconforming because combinators are
used ambiguously. The use of "and" and "or" in
this sentence is not clearly defined. To remove
the ambiguity, the requirement should express
the condition as a logical expression, as
recommended in qr0016_nonambiguity_conjunction
and qr0017_nonambiguity_avoidandor.
evaluation: nonconforming
conforming:
- text: |
The Controller shall, when the temperature of
water in the Boiler is greater than 95 ºC, close
the following valves: [EITHER [Valv1 AND Valv2]
OR Valv3].
reasoning: |
This is conforming because the logical condition
has been clearly expressed using an agreed
typographical device. The use of brackets and
"EITHER... OR" makes the requirement unambiguous
and verifiable. The glossary should define the
terms for clarity.
evaluation: conforming
exceptions:
- description: |
While rule qr0020_singularity_avoidcombinators
states that "and" and "or" are to be
avoided, such words may be used to express
a logical condition within a single
requirement, as described in this rule
as well as qr0016_nonambiguity_conjunction
and qr0017_nonambiguity_avoidandor.
- description: |
While rule qr0023_singularity_avoidparentheses
states that parentheses or brackets are to be
avoided, this rule suggests that brackets may
be used as part of a convention for avoiding
ambiguity in logical conditions.
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0005_singular"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.4.3"
# -----------------------------------------------------------------------------
# qr0022 – /Singularity/AvoidPurpose
#
qr0022_singularity_avoidpurpose:
definition: >
Avoid phrases that indicate the purpose of the
requirement.
description: |
The text of a requirement does not have to carry
around extra baggage such as the purpose for its
existence. Expressions of purpose are often
indicated by the presence of phrases such as
"in order to," "so that," "thus allowing."
This extra information should be included in
the requirement attribute qa0001_rationale.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0022: "Avoid phrases that indicate the purpose
of the requirement (e.g., 'in order to,'
'so that,' 'thus allowing')."
1. See if the requirement includes rationale or
purpose within the statement rather than in
a separate rationale attribute.
2. If yes, it is nonconforming; otherwise,
it's conforming.
3. Provide a succinct reasoning.
example:
- nonconforming:
text: |
The Database shall store Account_Balance
information until it is at least 10 years old
in order to satisfy the demands of the auditors.
reasoning: |
This is nonconforming because the phrase
"in order to" introduces unnecessary purpose
related information, which should not be part
of the requirement. The purpose of the
requirement should be expressed separately in
the rationale, not within the requirement
statement itself.
evaluation: nonconforming
conforming:
- text: |
The Audit_System shall store Account_Balance
information relating to at least the last 10
years.
reasoning: |
This is conforming because the purpose is not
included in the requirement. The requirement is
focused on the necessary actions, and the purpose
should be conveyed in the rationale attribute
instead of the main requirement statement.
evaluation: conforming
reference:
- id_ref: "qc0005_singular"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.4.4"
# -----------------------------------------------------------------------------
# qr0023 – /Singularity/AvoidParentheses
#
qr0023_singularity_avoidparentheses:
definition: >
Avoid parentheses and brackets containing
subordinate text.
description: |
If the text of a requirement contains parentheses
or brackets, it usually indicates the presence of
superfluous information that can simply be
removed or communicated in the rationale. Other
times, brackets introduce ambiguity.
If the information in the parentheses or brackets
aids in the understanding of the intent of the
requirement, then that information should be
included in the requirement attribute
qa0001_rationale.
Conventions for the use of parentheses or
brackets may be agreed upon for specific
purposes, but such conventions should be
documented at the start of the requirements
document.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0023: "Avoid parentheses or brackets
containing subordinate text, unless there is
a justified convention (such as alternate SI
units)."
1. Check any parenthetical expressions. If
they add extra, nonessential info that
could be confusing, it is nonconforming.
2. If parentheses are used only for accepted
conventions (e.g., temperature conversions),
it may be conforming.
3. State your conclusion and reason.
example:
- nonconforming:
text: |
The Control_Unit shall disconnect power from the
Boiler when the water temperature exceeds 85 °C
(usually towards the end of the boiling cycle.)
reasoning: |
This is nonconforming because the parenthetical
phrase introduces superfluous information that
should be communicated separately in the
rationale. Additionally, the use of the word
"usually" is ambiguous, making the requirement
difficult to verify.
evaluation: nonconforming
conforming:
- text: |
The Control_Unit shall disconnect power from
the Boiler when the water temperature exceeds
85 °C.
reasoning: |
This is conforming because the parenthetical
phrase has been removed, and the requirement
now expresses a clear, testable condition.
evaluation: conforming
- text: |
The Control_Unit shall disconnect power from
the Boiler when the water temperature exceeds
85 °C (185 °F).
reasoning: |
This is conforming because the use of parentheses
is acceptable when displaying alternate units or
other similar agreed-upon conventions for this
requirement set. Parentheses used in this way
do not introduce ambiguity or unnecessary
information.
evaluation: conforming
reference:
- id_ref: "qc0005_singular"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.4.5"
# -----------------------------------------------------------------------------
# qr0024 – /Singularity/Enumeration
#
qr0024_singularity_enumeration:
definition: >
Enumerate sets of entities explicitly instead
of using generalizations.
description: |
If lists of items are given, a requirement should
be written for each item. Generalizations are
ambiguous.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0024: "Enumerate sets of entities explicitly
instead of using generalizations."
1. Look for general terms like 'manage,'
'handle,' or vague lists (e.g., 'etc.').
2. If they are not broken into explicit,
testable sub-requirements, classify as
nonconforming.
3. Summarize your verdict briefly.
example:
- nonconforming:
text: |
The thermal control system shall manage the
system temperature (e.g., update the display
of current temperature, maintain the system
temperature, and store a history of system
temperatures.)
reasoning: |
This is nonconforming because the verb "manage"
is ambiguous, and the items listed in the
parenthetical phrase (e.g., "update the display,"
"maintain the temperature," "store the history")
should be expressed as individual, explicit
requirements. The generalization "manage" should
be avoided, and each action should be described
as a separate, testable requirement.
evaluation: nonconforming
conforming:
- text: |
- The Thermal_Control_System shall update the
display of Current_System_Temperature every
10 +/- 1 seconds.
- The Thermal_Control_System shall maintain the
Current_System_Temperature between 95°C to
98°C.
- The Thermal_Control_System shall store the
history of Current_System_Temperature.
reasoning: |
This is conforming because the generalization
has been replaced with specific, individual
requirements. Each action is now clearly
defined and verifiable, and the use of
the glossary ensures that terms like
"Current_System_Temperature" are explicitly
defined.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0005_singular"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.4.6"
# -----------------------------------------------------------------------------
# qr0025 – /Singularity/Context
#
qr0025_singularity_context:
definition: >
When a requirement is related to complex
behavior, refer to the supporting diagram
or model.
description: |
Sometimes you can tie yourself in knots trying
to express a complicated requirement in words,
and it is better simply to refer to a diagram
or model.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0025: "When a requirement is related to complex
behavior, refer to the supporting diagram or
model rather than overcomplicating the text."
1. Determine if the text is overly complex or
ambiguous when a simple reference to a
diagram/model could clarify it.
2. If yes, mark nonconforming; if it uses or
clearly references a diagram for clarity,
mark conforming.
3. Conclude with a short explanation.
example:
- nonconforming:
text: |
The control system shall close Valves A and B
within 5 seconds of the temperature exceeding
95 °C and within 2 seconds of each other.
reasoning: |
This is nonconforming because the requirement
contains a confusing set of conditions that
are difficult to interpret and verify in
text. The meaning is clearer and more easily
verifiable when expressed with the aid of a
diagram or model that depicts the timing and
relationships between actions.
evaluation: nonconforming
conforming:
- text: |
When the Product temperature exceeds 95 °C,
the Control_System shall close Input_Valves
as specified in timing diagram 6.
reasoning: |
This is conforming because it refers to a diagram
that clarifies the timing of the actions. The
diagram ensures that the requirements are clear
and verifiable, provided the diagram itself is
unambiguous.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0005_singular"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.4.7"
# -----------------------------------------------------------------------------
# qr0026 – /Completeness/AvoidPronouns
#
qr0026_completeness_avoidpronouns:
definition: >
Avoid the use of pronouns.
description: |
Repeat nouns in full instead of using pronouns to
refer to nouns in other requirement statements.
Pronouns are words such as "it," "this," "that,"
"he," "she," "they," and "them." When writing
stories, pronouns are a useful device for
avoiding the repetition of words; but when
writing requirements, pronouns are effectively
cross-references to nouns in other requirements
and, as such, are ambiguous and should be
avoided. Repeat the proper nouns where necessary.
This is especially true when requirements are
stored in a requirement management tool where
they exist as single statements that may not be
in order.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0026: "Avoid pronouns (it, this, that, he,
she, they) that can cause ambiguity."
1. Check for pronouns referring to nouns in
previous statements or headings.
2. If pronouns cause confusion, it is
nonconforming. If nouns are repeated clearly,
it is conforming.
3. Provide a concise reasoning.
example:
- nonconforming:
text: |
The controller shall send the driver his
itinerary for the day. It shall be delivered
at least 8 hours prior to his Shift.
reasoning: |
This is nonconforming because the requirement is
expressed as two sentences and the second
sentence uses the pronouns "it" and "his." These
pronouns create ambiguity because it is unclear
which noun they refer to. Each noun should be
explicitly repeated to ensure clarity and avoid
ambiguity, as per qr0019_singularity_singlesentence.
evaluation: nonconforming
conforming:
- text: |
The Controller shall send the Driver_Itinerary
for the day to the Driver at least 8 hours prior
to the Driver_Shift.
reasoning: |
This is conforming because the pronouns have been
removed and the nouns are explicitly repeated,
ensuring clarity. The use of the glossary to
define terms like "Driver_Itinerary" and
"Driver_Shift" further clarifies the
relationships between the entities in the
requirement.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.5.1"
# -----------------------------------------------------------------------------
# qr0027 – /Completeness/UseOfHeadings
#
qr0027_completeness_useofheadings:
definition: >
Avoid using headings to support explanation
of subordinate requirements.
description: |
It is a common mistake in document-centric
requirements processes to use the heading under
which the requirement falls to contribute to the
explanation of the requirement. The requirement
should be complete in and of itself and not
require the heading for it to make sense.
This issue occurs less frequently when using a
requirements management tool (RMT).
instruction:
evaluate: |
Evaluate the requirement statement against
qr0027: "Avoid depending on headings for clarity;
each requirement must be self-contained."
1. See if the statement references something like
'it' or 'this device' where only the heading
clarifies the subject.
2. If it does, it is nonconforming. If the
statement is clear on its own, it is
conforming.
3. Conclude briefly.
example:
- nonconforming:
text: |
The system shall sound it for no longer than 20
minutes.
reasoning: |
This is nonconforming because the requirement
uses the pronoun "it," which is ambiguous and
depends on the section heading "to clarify what"
"it" refers to. Requirements should be
self-contained, and the use of a heading to
clarify meaning introduces unnecessary
dependencies and reduces clarity.
evaluation: nonconforming
conforming:
- text: |
The system shall sound the Alert Buzzer for no
longer than 20 minutes.
reasoning: |
This is conforming because the requirement is now
self-contained and does not rely on the heading
to provide context or meaning. The requirement
is clear, complete, and unambiguous.
evaluation: conforming
reference:
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.5.2"
# -----------------------------------------------------------------------------
# qr0028 – /Realism/AvoidAbsolutes
#
qr0028_realism_avoidabsolutes:
definition: >
Avoid using unachievable absolutes.
description: |
An absolute, such as '100% reliability', is
hardly ever achievable. Think ahead to
verification: how would you prove 100%
reliability? Even if you could build such a
system, could you afford to do so?
instruction:
evaluate: |
Evaluate the requirement statement against
qr0028: "Avoid using unachievable absolutes
(e.g., '100% availability')."
1. Determine whether the statement includes an
absolute like '100% reliability' or
'zero downtime.'
2. If so, it is likely nonconforming unless it
is genuinely feasible and verifiable.
3. Summarize your conclusion.
example:
- nonconforming:
text: |
The system shall have 100% availability.
reasoning: |
This is nonconforming because the use of "100%"
represents an unachievable absolute. Achieving
and verifying 100% availability is virtually
impossible and would be prohibitively expensive.
Requirements should reflect realistic, achievable
performance levels.
evaluation: nonconforming
conforming:
- text: |
The system shall have an Availability of greater
than or equal to 98%.
reasoning: |
This is conforming because the requirement
specifies a realistic target (≥98%) that is both
feasible and verifiable. The use of the glossary
to define "Availability" further clarifies the
requirement.
evaluation: conforming
reference:
- id_ref: "qc0006_feasible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0012_feasible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.6.1"
# -----------------------------------------------------------------------------
# qr0029 – /Conditions/Explicit
#
qr0029_conditions_explicit:
definition: >
State applicability conditions explicitly.
description: |
State applicability conditions explicitly instead
of leaving applicability to be inferred from the
context.
Sometimes requirements are only applicable under
certain conditions. If so, the condition should
be repeated in the text of each requirement,
rather than stating the condition and then
listing the actions to be taken.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0029: "State applicability conditions explicitly
rather than implying them."
1. See if the condition for applicability is
clearly spelled out for each action.
2. If the requirement depends on some scenario
or condition but that condition is not
repeated clearly, it is nonconforming.
3. Provide a short explanation of your judgment.
example:
- nonconforming:
text: |
In the event of a fire:
- Power to all electromagnetic magnetic fire
door catches shall be turned off.
- All security entrances shall be set to
Free_Access_Mode.
- All fire escape doors shall be unlocked.
reasoning: |
This is nonconforming because the condition "in
the event of a fire" is stated once, and the
actions are listed afterwards. Each action
requiring the condition should restate the
condition explicitly to ensure clarity and
verifiability. Additionally, the actions are
written in passive voice, which violates the
requirement for active voice
(qr0002_precision_useactivevoice).
evaluation: nonconforming
conforming:
- text: |
- In the event of a fire, the Security_System
shall turn off power to all electromagnetic
magnetic fire door catches.
- In the event of a fire, the Security_System
shall set all security entrances to the
Free_Access_Mode.
- In the event of a fire, the Security_System
shall unlock all fire escape doors.
reasoning: |
This is conforming because each action clearly
states the condition "in the event of a fire"
within the requirement statement, making the
requirement explicit, testable, and verifiable.
The use of the active voice also ensures clarity
and correctness.
evaluation: conforming
reference:
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.7.1"
# -----------------------------------------------------------------------------
# qr0030 – /Conditions/ExplicitLists
#
qr0030_conditions_explicitlists:
definition: >
Express the propositional nature of a condition
explicitly instead of giving lists of conditions.
description: |
When a list of conditions is given in a
requirement, it may not be clear whether all the
conditions must hold (a conjunction) or any one
of them (a disjunction). The wording of the
requirement should make this clear.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0030: "Express the propositional nature of a
condition explicitly rather than listing
conditions ambiguously."
1. Check if the statement lists multiple
conditions without specifying whether
it's AND or OR (any vs. all).
2. If the logic is ambiguous, mark it
nonconforming.
3. State your conclusion briefly.
example:
- nonconforming:
text: |
The Audit _Clerk shall be able to change the
status of the action item when:
- the Audit _Clerk originated the item;
- the Audit _Clerk is the actionee;
- the Audit _Clerk is the reviewer.
reasoning: |
This is nonconforming because the requirement
does not clarify whether all the conditions must
hold (conjunction) or any one of them must hold
(disjunction). The wording of the condition must
be explicit to avoid ambiguity. Additionally, the
phrase "be able to" is used, which violates the
rule against superfluous infinitives
(qr0011_concision_noinfinitives).
evaluation: nonconforming
conforming:
- text: |
The Audit_System shall allow the Audit_Clerk
to change the status of the action item when
any one of the following conditions hold:
- the Audit _Clerk originated the item;
- the Audit _Clerk is the actionee;
- the Audit _Clerk is the reviewer.
reasoning: |
This is acceptable because the word "any"
explicitly indicates that the conditions are
interpreted as a disjunction, meaning only one
condition needs to hold for the requirement to
be met.
evaluation: conforming
- text: |
The Audit_System shall allow the Audit_Clerk to
change the status of the action item when the
following conditions are simultaneously true:
- the Audit _Clerk originated the item;
- the Audit _Clerk is the actionee;
- the Audit _Clerk is the reviewer.
reasoning: |
This is acceptable because the word
"simultaneously" makes it clear that the
conditions are interpreted as a conjunction,
meaning all conditions must hold for the
requirement to be met.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.7.2"
# -----------------------------------------------------------------------------
# qr0031 – /Uniqueness/Classify
#
qr0031_uniqueness_classify:
definition: >
Classify the requirement according to the aspects
of the problem or system it addresses.
description: |
By classifying requirements in various ways, it
is possible to regroup requirements to help
identify potential duplications and conflicts.
The ability to view groups of requirements can
also assist in identifying what requirements may
be missing.
instruction:
evaluate: |
Evaluate the requirement set (or statement)
against qr0031: "Classify the requirement
according to the aspect of the system it
addresses."
1. Determine if the requirement has an
appropriate classification (e.g., Functional,
Performance, Interface).
2. If it is missing or unclear, it is
nonconforming.
3. Provide a short note on how classification
could help verify uniqueness or completeness.
example:
- note: |
Classification can be undertaken in a number of
ways. In a requirements management system, a
field in the database (attribute) can be used to
classify each requirement as one or more types;
a report can then be obtained for all
requirements of a certain type, allowing the
identification of duplication, conflict, or
absence of requirements.
Example classifications:
- Functional
- Performance
- Operational,
- Quality "-ilities" (reliability, availability,
safety, security, etc.)
- Design and Construction Standards
- Physical Characteristics.
See Attribute qa0036_type_or_category for more
detailed examples.
See also qr0043_modularity_relatedrequirements
reference:
- id_ref: "qc0010_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0012_feasible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.8.1"
# -----------------------------------------------------------------------------
# qr0032 – /Uniqueness/ExpressOnce
#
qr0032_uniqueness_expressonce:
definition: >
Express each requirement once and only once.
description: |
Care should be taken to avoid including the same
requirement more than once, either as a duplicate
or in similar form. Exact duplicates are
relatively straightforward to identify; finding
similar requirements with slightly different
wording is much more difficult, but is aided by
the consistent use of defined terms and by
classification.
instruction:
evaluate: |
Evaluate the requirement set against qr0032:
"Express each requirement once and only once."
1. Check whether this statement duplicates or
overlaps with another requirement.
2. If it is a duplicate or near-duplicate, it
is nonconforming.
3. Conclude with a brief rationale.
example:
- note: |
Exact duplicates can be found by matching of
text strings. The main problem is to identify
similarities with different expressions. For
example: "The system shall provide a report of
financial transactions" and "The system shall
provide a financial report" are overlapping in
that the first is a subset of the second.
Avoidance of repetition can be assisted by
classification so that a subset of requirements
can be compared.
reference:
- id_ref: "qc0001_necessary"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0009_conforming"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0012_feasible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.8.2"
# -----------------------------------------------------------------------------
# qr0033 – /Abstraction/SolutionFree
#
qr0033_abstraction_solutionfree:
definition: >
Avoid stating a solution.
description: |
Focus on the problem "what" rather than the
solution "how."
Every system endeavor should have a layer of
requirements that captures the problem to be
solved without involving solutions. System
requirements should provide a high-level
specification of the overall solution. The first
layer of architecture may be laid out, but
subsystems are considered as black-boxes to be
elaborated at the next layer down.
When reviewing a requirement that states a
solution, again ask yourself "for what purpose?"
The answer will reveal the real requirement.
(Notice that this question is subtly different
from simply asking "Why?", and encourages a
teleological rather than causal response.) The
answer to this question has the potential to
help you do three things:
1. Rephrase the requirement in terms of the
problem being solved.
2. Determine if the requirement is at the right
layer.
3. Identify which higher-layer requirement(s) or
need(s) this one addresses.
Often when rationale is provided with a
requirement, for requirements that state a
solution, the rationale should answer the "for
what purpose?" question, and thus the real
requirement may be extracted from the rationale.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0033: "Avoid stating a solution; focus on the
'what' not the 'how.'"
1. Check if the statement specifies the
implementation details or prescribes a
design solution, rather than stating the
intended outcome.
2. If it prescribes a specific technology or
detailed mechanism, it is nonconforming at
this level of abstraction.
3. Provide your rationale briefly.
example:
- nonconforming:
text: |
Traffic lights shall be used to control traffic
at the junction.
reasoning: |
This is nonconforming because "Traffic lights"
describe a solution rather than a requirement.
The requirement should focus on what needs to be
achieved rather than the specific means or method
of achieving it.
evaluation: nonconforming
conforming:
- text: |
- The Traffic_Control_System shall signal "Walk"
when the Pedestrian is permitted to cross the
road at the junction.
- The Traffic_Control_System shall limit the
Wait_Time of Vehicles traversing the Junction
to less than 2 minutes during normal daytime
traffic conditions.
reasoning: |
This is conforming because the requirements
describe the objectives that must be achieved
without prescribing a particular solution. The
solution could vary as long as these objectives
are met.
evaluation: conforming
- nonconforming:
text: |
By pressing a button on the traffic-light
pillar, the Pedestrian signals his presence,
and the light turns red for the traffic to
stop.
reasoning: |
This is nonconforming because it specifies a
solution (button pressing) instead of describing
the desired outcome (signaling the Pedestrian's
presence).
evaluation: nonconforming
conforming:
- text: |
The Traffic_Control_System shall allow the
Pedestrian to signal intent to cross the road.
reasoning: |
This requirement is conforming because it focuses
on the objective (signaling intent) and allows
for flexibility in how the objective is achieved.
It avoids prescribing a specific solution, such
as the use of a button.
Note that glossary definitions should be used
for "Pedestrian," "Vehicle," and "Junction."
evaluation: conforming
reference:
- id_ref: "qc0002_appropriate"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.9.1"
# -----------------------------------------------------------------------------
# qr0034 – /Quantifiers/Universals
#
qr0034_quantifiers_universals:
definition: >
Use "each" instead of "all," "any," or "both"
when universal quantification is intended.
description: |
The use of "all," "both," or "any" is confusing
because it is hard to distinguish whether the
action happens to the whole set or to each
element of the set. "All" can also be hard to
verify unless "all" can be clearly defined in
a closed set.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0034: "Use 'each' instead of 'all,' 'any,' or
'both' when universal quantification is
intended."
1. Look for 'all,' 'any,' 'both' and see if the
intention is truly universal quantification
across individual entities.
2. If so, check whether it should be replaced
with 'each.'
3. Mark conforming or nonconforming with a short
explanation.
example:
- nonconforming:
text: |
The Operation_Logger shall record any warning
messages produced by the system.
reasoning: |
This is nonconforming because the word "any" is
ambiguous. It does not clearly specify whether
the action applies to each individual warning
message or the entire set of messages. This can
lead to confusion in verification.
evaluation: nonconforming
conforming:
- text: |
The Operation_Logger shall record each
Warning_Message produced by the system.
reasoning: |
This is conforming because "each" clearly
indicates that the action applies to every
individual warning message, making the
requirement unambiguous and verifiable.
Additionally, "Warning_Message" must be defined
to ensure clarity regarding what constitutes a
warning message in the system.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0008_correct"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.10.1"
# -----------------------------------------------------------------------------
# qr0035 – /Tolerance/ValueRange
#
qr0035_tolerance_valuerange:
definition: >
Define the range of acceptable values associated
with quantities.
description: |
When it comes to defining performance,
single-point values are seldom sufficient and
are difficult to test. Ask yourself the
question: "if the performance was a little less
(or more) than this, would I still buy it?" If
the answer is yes, then change the requirement
to reflect this.
It also helps to consider the underlying goal:
are you trying to minimize, maximize or optimize
something? The answer to this question will help
determine whether there is an upper bound, lower
bound, or both.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0035: "Define the range of acceptable values
associated with quantities."
1. Look for single-point values that might need
a range or tolerance (e.g., '120 liters per
second' without +/- or range).
2. If no acceptable range or tolerance is given
(and it is relevant), the statement is
nonconforming.
3. Summarize briefly.
example:
- nonconforming:
text: |
The Pumping_Station shall maintain the flow of
water at 120 liters per second for 30 minutes.
reasoning: |
This is nonconforming because it specifies a
single-point value (120 liters per second)
without providing a range of acceptable values.
This makes the requirement difficult to verify,
and it does not account for variations in
performance that may still be acceptable.
evaluation: nonconforming
conforming:
- text: |
The Pumping_Station shall maintain a flow of
water at 120 +/- 10 liters per second for at least
30 minutes.
reasoning: |
This is conforming because it defines a range of
acceptable flow (120 +/- 10 liters per second),
which allows for variability while still ensuring
the system meets the performance criteria. The
30-minute duration is also defined as a minimum
acceptable performance time, making the
requirement more measurable and verifiable.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0006_feasible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0008_correct"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0012_feasible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.11.1"
# -----------------------------------------------------------------------------
# qr0036 – /Quantification/Measurable
#
qr0036_quantification_measurable:
definition: >
Provide specific measurable performance targets.
description: |
Some words signal unmeasured quantification, such
as "prompt," "fast," "routine," "maximum,"
"minimum," "optimum," "nominal," "easy to use,"
"close quickly," "high speed," "medium-sized,"
"best practices," and "user-friendly." These are
ambiguous and need to be replaced by specific
quantities that can be measured.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0036: "Provide specific measurable performance
targets; avoid terms like 'fast,' 'efficient,'
'best practices.'"
1. Identify any vague language indicating
performance levels.
2. If it lacks a measurable metric or
threshold, it is nonconforming.
3. Provide a succinct explanation.
example:
- nonconforming:
text: |
The system shall use minimum power.
reasoning: |
This is nonconforming because the term "minimum"
is ambiguous. It does not specify a clear,
measurable value and is open to interpretation,
making the requirement difficult to verify and
implement.
evaluation: nonconforming
conforming:
- text: |
The system shall limit the power consumption to
less than 50% of the current solution.
reasoning: |
This is conforming because it defines a specific,
measurable performance target. By limiting the
power consumption to less than 50%, the
requirement is clear, verifiable, and
quantifiable, aligning with the goal of
minimizing power usage.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0012_feasible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.12.1"
# -----------------------------------------------------------------------------
# qr0037 – /Quantification/TemporalIndefinite
#
qr0037_quantification_temporalindefinite:
definition: >
Define temporal dependencies explicitly instead
of using indefinite temporal keywords.
description: |
Some words and phrases signal non-specific
timing, such as "eventually" and "at last,"
which are ambiguous. These should be replaced
by specific timing constraints.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0037: "Define temporal dependencies explicitly;
avoid indefinite temporal words
(e.g., 'eventually')."
1. Check for words like 'eventually,' 'someday,'
or 'at some point' that fail to specify a
timeframe or trigger condition.
2. If such wording exists, it is nonconforming.
3. Conclude your evaluation briefly.
example:
- nonconforming:
text: |
Continual operation of the pump shall eventually
result in the tank being empty.
reasoning: |
This is nonconforming because the word
"eventually" is ambiguous. It lacks a clear,
measurable, or verifiable timeframe, making it
difficult to understand or verify when the
requirement will be met. Additionally, the
statement is improperly framed around
"operation" rather than as a specific
requirement on the pump, violating
qr0003_precision_subject.
evaluation: nonconforming
conforming:
- text: |
The Pump shall remove at least 99% of the Fluid
from the Tank in less than 3 days of continuous
operation.
reasoning: |
This is conforming because it replaces the
ambiguous "eventually" with a specific time frame
(less than 3 days) and provides measurable
conditions (at least 99% of the fluid removed),
making the requirement both clear and verifiable.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0004_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0007_verifiable"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0000_requirement_statement"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.12.2"
# -----------------------------------------------------------------------------
# qr0038 – /UniformLanguage/DefineTerms
#
qr0038_uniformlanguage_defineterms:
definition: >
Define a consistent set of terms to be used in
requirement statements.
description: |
Define and use just one term per concept in the
whole set of requirements. Synonyms are not
acceptable.
Each term in the requirements set used in a
special manner, rather than the normal natural
language sense, must be defined in a Glossary
or Data Dictionary within the specification.
instruction:
evaluate: |
Evaluate the requirement statement set against
qr0038: "Use a consistent set of defined terms;
do not introduce synonyms."
1. Check if the same concept is referred to by
multiple terms, leading to confusion.
2. If duplication or undefined terms appear,
mark it nonconforming.
3. Explain in brief.
example:
- nonconforming:
text: |
- The radio shall <X>
- The receiver shall <Y>
- The terminal shall <Z>
reasoning: |
This is nonconforming because different terms are
used to refer to the same system. Using different
terms for the same concept introduces ambiguity
and inconsistency, making the requirements harder
to understand and potentially conflicting.
evaluation: nonconforming
conforming:
- text: |
- The radio shall <X>
- The radio shall <Y>
- The radio shall <Z>
reasoning: |
This is conforming because a single term is used
consistently for the system. The term should be
defined in the glossary and applied uniformly
across all requirements to ensure clarity and
consistency.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0008_correct"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0009_conforming"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0013_comprehensible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0014_able_to_be_validated"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0001_requirement_statement_set"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.13.1"
# -----------------------------------------------------------------------------
# qr0039 – /UniformLanguage/DefineAcronyms
#
qr0039_uniformlanguage_defineacronyms:
definition: >
If acronyms are used in requirement statements,
use a consistent set of acronyms.
description: |
As with the glossary, the same acronym must be
used in each requirement; various versions of
the acronym are not acceptable. The use of
different acronyms implies that the two items
being referred to are different. Inconsistency
in the use of acronyms can lead to ambiguity.
In paper-based specifications, a common rule is
to use the full term and the abbreviation or
acronym (in brackets) the first time and then
use just the abbreviation or acronym from then
on. In requirement sets that are generated from
databases, there is no guarantee that the set
will be extracted in any particular order so the
old practice is not useful. To address this
issue, make sure all acronyms are defined in an
acronym list or glossary.
Acronyms must be written in a consistent way in
terms of capitalization and periods. For
example, always "CMDP" and not "C.M.D.P." nor
"CmdP."
instruction:
evaluate: |
Evaluate the requirement statement set against
qr0039: "Use a consistent set of acronyms,
defined in a glossary."
1. Check if the acronym usage is consistent
(same spelling, same capitalization).
2. If multiple versions of the same acronym
appear or definitions are missing, it is
nonconforming.
3. Summarize your conclusion.
example:
- nonconforming:
text: |
- The system shall enable the C.M.D.P to <X>
- The system shall enable the CMDP to <Y>
- The system shall enable the CmdP <Y>
reasoning: |
This is nonconforming because it uses different
forms of the acronym "CMDP" in multiple
requirements. This inconsistency in acronym
usage introduces ambiguity by implying that the
two system elements are different when they
refer to the same entity.
evaluation: nonconforming
conforming:
- text: |
- The system shall enable the CMDP to <X>
- The system shall enable the CMDP to <Y>
- The system shall enable the CMDP to <Y>
reasoning: |
This is conforming because all requirements use
the acronym "CMDP" consistently, as defined in
the glossary. Consistent acronym usage ensures
clarity and eliminates ambiguity.
evaluation: conforming
- nonconforming:
text: |
- The system shall provide Global Positioning
System data to <X>
- The system shall provide GPS data to <Y>
reasoning: |
This is nonconforming because it inconsistently
uses "Global Positioning System" in one
requirement and "GPS" in another. This
inconsistency could cause confusion about
whether the two terms refer to the same concept.
evaluation: nonconforming
conforming:
- text: |
- The system shall provide GPS data to <X>
- The system shall provide GPS data to <Y>
reasoning: |
This is conforming because it uses the acronym
"GPS" consistently across all requirements. By
defining "GPS" in the glossary or acronyms list
and using it consistently, the requirements are
clearer and free from ambiguity.
evaluation: conforming
reference:
- id_ref: "qc0003_unambiguous"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0009_conforming"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0013_comprehensible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0014_able_to_be_validated"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0001_requirement_statement_set"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.13.2"
# -----------------------------------------------------------------------------
# qr0040 – /UniformLanguage/AvoidAbbreviations
#
qr0040_uniformlanguage_avoidabbreviations:
definition: >
Avoid the use of abbreviations in requirement
statements.
description: |
The use of abbreviations adds ambiguity and needs
to be avoided.
instruction:
evaluate: |
Evaluate the requirement statement against
qr0040: "Avoid abbreviations unless they are
well-defined and unambiguous."
1. Check if abbreviations are used without
definition or if they could mean multiple
things.
2. If so, it is nonconforming.
3. Provide a short explanation.
example:
- nonconforming:
text: |
- The system shall complete the op within 5
seconds of receiving the command.
- The system shall allow the op to monitor
the status of all processes.
reasoning: |
This is nonconforming because it uses the
abbreviation "op" inconsistently and without
defining it. The ambiguity arises because "op"
could refer to "operation" or "operator," leading
to confusion in interpretation.
evaluation: nonconforming
conforming:
- text: |
- The system shall complete the operation within
5 seconds of receiving the command.
- The system shall allow the operator to monitor
the status of all processes.
reasoning: |
This is conforming because it uses the full terms
"operation" and "operator" instead of the
ambiguous abbreviation "op." Using the full terms
ensures clarity and avoids potential confusion.
evaluation: conforming
reference:
- id_ref: "qc0009_conforming"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0013_comprehensible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0014_able_to_be_validated"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0001_requirement_statement_set"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.13.3"
# -----------------------------------------------------------------------------
# qr0041 – /UniformLanguage/StyleGuide
#
qr0041_uniformlanguage_styleguide:
definition: >
Use a project-wide style guide.
description: |
The style guide provides a template for
organizing requirements, defines the attributes
that the organization chooses to document with
each requirement, and defines what other
information needs to be included (such as the
glossary). The style guide should also list the
rules the organization wants to use (based on
this guide).
instruction:
evaluate: |
Evaluate the requirement set against qr0041:
"Use a project-wide style guide and ensure
each requirement follows it."
1. Determine whether the requirement matches
the organization's style guide (layout,
attributes, glossary references, etc.).
2. If it deviates without justification, it is
nonconforming.
3. Conclude briefly.
example:
- desc: |
For example, each organization should have a
style guide to address such issues as the
template for a requirement statement, the use of
priority, standard abbreviations and acronyms,
layout and use of figures and tables, layout of
requirements documents, requirement numbering,
and use of databases.
reference:
- id_ref: "qc0005_singular"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0009_conforming"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0013_comprehensible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0014_able_to_be_validated"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0001_requirement_statement_set"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.13.4"
# -----------------------------------------------------------------------------
# qr0042 – /Modularity/Dependents
#
qr0042_modularity_dependents:
definition: >
Group mutually dependent requirements together.
description: |
This will often mean that requirements are
grouped by feature, bringing a functional
requirement together with a number of related
constraints and performance requirements.
instruction:
evaluate: |
Evaluate the requirement set against qr0042:
"Group mutually dependent requirements together."
1. Identify if a set of requirements that
logically depend on each other is scattered
or inconsistent.
2. If they are not grouped, it is nonconforming
for this rule.
3. Provide a brief rationale.
example:
- desc: |
Performance requirements should be grouped with
their related functional requirement.
reference:
- id_ref: "qc0009_conforming"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0013_comprehensible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0001_requirement_statement_set"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.14.1"
# -----------------------------------------------------------------------------
# qr0043 – /Modularity/RelatedRequirements
#
qr0043_modularity_relatedrequirements:
definition: >
Group related requirements together.
description: |
Requirements that belong together should be
grouped together. This is a good principle for
structuring a requirements document. One
approach is to put requirements into groups
based on their classification.
See also qr0031_uniqueness_classify
instruction:
evaluate: |
Evaluate the requirement set against qr0043:
"Group related requirements together for
clarity (e.g., by feature or classification)."
1. Check if obviously related requirements are
isolated in different sections "or labeled"
inconsistently.
2. If so, classify it as nonconforming for this
rule.
3. Briefly explain.
example:
- desc: |
Requirements may be related by:
- type (e.g., all safety requirements);
- scenario (e.g., requirements arising from a
single scenario).
Example classifications: Functional, Performance,
Operational, - ilities (reliability,
availability, safety, security, etc.), Design
and Construction Standards, Physical
Characteristics.
See qa0036_type_or_category for more detailed
examples.
reference:
- id_ref: "qc0009_conforming"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0013_comprehensible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0001_requirement_statement_set"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.14.2"
# -----------------------------------------------------------------------------
# qr0044 – /Modularity/Structured
#
qr0044_modularity_structured:
definition: >
Conform to a defined structure or template.
description: |
A well-structured set of requirements allows an
understanding of the whole set of requirements
to be assimilated without undue cognitive
loading on the reader.
Despite what has been stated about the
completeness of individual requirement
statements, it is often easier to understand a
requirement when it is placed in context with
other related requirements.
Whether presented in document structure or as
the result of database queries, the ability to
draw together related groups of requirements is
a vital tool in identifying repetition and
conflict between requirement statements.
Templates help ensure consistency and
completeness of your requirement set.
instruction:
evaluate: |
Evaluate the requirement set against qr0044:
"Conform to a defined structure or template
for clarity and consistency."
1. Check whether each requirement and its
associated metadata follow the prescribed
template or schema.
2. If not, mark as nonconforming.
3. Provide a concise explanation.
example:
- desc: |
In order to ensure requirements are consistently
structured, the organization needs to include
templates in their requirement development and
management process. The template can come from
an international standard or an organizational
standard template for organizing your
requirements. If using a requirement management
tool, a standard schema should be defined as
part of your requirement development and
management process. The templates need to be
tailored to the organization's domain and the
different types of products within that domain.
reference:
- id_ref: "qc0010_complete"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0011_consistent"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0013_comprehensible"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "qc0014_able_to_be_validated"
id_class: "id0031_quality_characteristic"
id_rel: "ir0003_partially_establishes"
- id_ref: "dic0001_requirement_statement_set"
id_class: "id0037_data_item_collection"
id_rel: "ir0011_regulates"
- id_ref: "doc000000_incose_guide_to_writing_requirements_v2"
id_class: "id0034_document"
id_rel: "ir0010_is_derived_from"
section: "4.14.3"
...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment