Requirements extraction
Every requirement the project has extracted, with its source, its classification and whether anybody has accepted it.
Why
Requirements are read from the project's specifications and contract appendices. A clause from an unlicensed standard is cited and never reproduced.
Writes are validated against the engineering rules and then refused, because no database has been configured for this environment.
Requirements
9
Mandatory
8
Suggested by the model
1
never verified on arrival
Accepted
6
In conflict
1
| Reference | Requirement | Source | Class | |
|---|---|---|---|---|
| REQ-SUG-001 | Consider recording ambient temperature at the start and end of the hold period, to explain a pressure change that is thermal rather than a leak. | ZRF-SPC-3300 | informative | Suggested |
Showing 1 to 1 of 1 requirements
A model suggestion is not a requirement
Accept a requirement
Cited, never quoted
A requirement from a standard the project holds no licence for shows its reference, clause and applicability, and the clause text is marked as not reproduced. The reference is the project’s own work; the text belongs to the standards body, and reproducing it in a deliverable is a copyright problem the client inherits.
Applicability is not classification
“Mandatory” says how the source phrases it. Whether it applies to a particular deliverable is a separate judgement, made per deliverable, and shown on the traceability matrix.