A requirement whose purpose is to control an identified hazard or threat. It links the risk id and a control type: inherent safety by design, protective measure or information for safety. For a medical product each hazard in the risk section lists the requirement ids that control it.
A requirement whose purpose is to control an identified hazard or threat. It links the risk id and a control type: inherent safety by design, protective measure or information for safety. For a medical product each hazard in the risk section lists the requirement ids that control it.
See also: Requirement type, PHI flag, Traceability
Interim definition. BLORP takes this term over when the global ontology lifts from Phase-0.
Continue exploring our knowledge base
A statement of what the system must do, or the constraint it must respect, in the target state. It is written with one "shall", one subject (the system or a role) and one behavior, and carries an id, a type, a level, an owner role, a scope, a rationale, a source, a verification method with acceptance criteria, a priority, a phase and a lifecycle status.
A named field every requirement carries: id, title, statement, type, level, owner, scope, rationale, source, priority, phase, status, verification, validation, risk, medical flags, trace, and change history and baseline. Together the attributes are the requirement ontology of the Analysis Document Standard.
The kind of a requirement. One of: business, stakeholder, functional, quality, service-level, security, regulatory, constraint, architecture, interface, data, operation or risk-control.
Where a requirement sits in the decomposition. One of: business, stakeholder, system or software.
The requirement owner is a role taken from the role register, never a person. Every requirement has an owner role, such as the business owner, the PHI owner or the platform owner. A person's name appears only in the role register, as the current holder of the role.