8 Wording that may not be verifiable
The requirement text carries a word or phrase that usually leaves no measurable criterion: a placeholder, a relative term, or a choice left open. It is a question, not a ruling: the criterion may sit in a linked specification, or the word may be used in a defined sense.
- the test
- only when requirement text is pasted: a word or phrase from the published list (TBD, as appropriate, user-friendly, sufficient and the rest), word-bounded
- the question
- What is the measurable criterion here, and where is it written down? If the word is used in a defined sense, record the reason on the review sheet.
- asked of
- the requirement owner
- columns it reads
- Requirement Text
Each line shows the exact word and a few words either side. A number with a unit, a percentage or a stated time in the same sentence answers a relative word, so it is not raised; a placeholder (TBD, TBC, XXX) or "approximately" is raised even beside a number. The review sheet has a column for the reason a word is kept.
Only when the requirement text is pasted. With IDs and links only, this finding is not checked and the page says so; every other finding still runs. The word list: to be determined, to be confirmed, to be reviewed, to be agreed, as appropriate, as required, if possible, user-friendly, intuitive, easy, sufficient, adequate, appropriate, reasonable, fast or quickly, minimal or minimise, maximal or maximise, optimal or optimise, robust, flexible, efficient, seamless, and/or, etc., including but not limited to, state of the art, best effort, approximately with a number, under normal conditions, shall support, should (not shall), some, several or many, a placeholder (??? or XXX).
The clauses behind it, by standard
each shown when you tick its standard- ISO 26262: Part 8, 6.4.2
- IEC 62304: 5.2.6
- ISO 13485: 7.3.3
- DO-178C: A-3.4 (high-level requirements) and A-4.4 (low-level requirements)
- AS9100D: 8.3.3
The clause text
Every high-level requirement can be verified. Table A-3 objective 4, described in 6.3.1.d; applies at levels A, B, C, no independence required; activities 6.3.1; outputs Software Verification Results.
Applies at software level A, B, C: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Review records showing each high-level requirement can be verified
where it usually breaks Requirements phrased so no test can pass or fail them
Every low-level requirement can be verified. Table A-4 objective 4, described in 6.3.2.d; applies at levels A, B, no independence required; activities 6.3.2; outputs Software Verification Results.
Applies at software level A, B: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Review records showing each low-level requirement is verifiable
where it usually breaks Unverifiable low-level requirements
Each safety requirement carries a unique identifier, a status and an ASIL, and the requirements are unambiguous, comprehensible, atomic, internally consistent, feasible, verifiable, necessary, implementation-free and, as a set, hierarchical, complete, externally consistent, non-redundant and maintainable. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements attributes (identifier, status, ASIL) and characteristic checks
where it usually breaks Requirements with no ASIL attribute; Compound requirements that cannot be verified individually
The manufacturer verifies and documents that the software requirements implement the system requirements including those for risk control, do not contradict one another, avoid ambiguity, are stated so that test criteria can be established and tests performed, can be uniquely identified, and are traceable to system requirements or another source; no formal specification language is required. Applies to classes A, B and C.
Applies to software safety class A, B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements review record against the six criteria; traceability matrix.
where it usually breaks Requirements that cannot be tested as written.; Unnumbered requirements.
The organization determines and records the design and development inputs that relate to product requirements. These include the functional, performance, usability and safety needs arising from the intended use; applicable regulatory requirements and standards; relevant risk management outputs; information from earlier similar designs where appropriate; and any further requirements essential to designing the product and its processes. The inputs are reviewed for adequacy and approved. Requirements must be complete and unambiguous, must be capable of verification or validation, and must not contradict each other.
Held text: ISO 13485:2016, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Design input specification covering functional, performance, usability, safety, regulatory and standards requirements; Risk management outputs incorporated as inputs; Record of input review for adequacy and approval; Evidence each input is verifiable or validatable and free of conflict
where it usually breaks Usability requirements absent from inputs; Risk controls identified in the risk file never entered as design inputs; Inputs approved without a check for ambiguity or conflict
Inputs to design and development are identified as the requirements that matter for the particular kind of product or service, taking account of: functional and performance requirements; what was learned from earlier, similar work; statutory and regulatory requirements; codes of practice or standards the organization has undertaken to apply; what could result from failure; and, under 9100, what could result if materials, processes, components, equipment or products become obsolete. Inputs must be adequate, complete and unambiguous, conflicts among them must be settled, and records kept. Benchmarking, feedback from providers, internal data and data from products in service may also serve as inputs.
Held text: AS9100D, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Design input records including obsolescence consequences and resolution of conflicting inputs.
where it usually breaks Obsolescence of components not considered at design input.; Conflicting inputs unresolved at release.