The design output. It takes each requirement of the analysis document and states how it is met, with its decisions, interfaces and tests, and it references the requirement ids. For medical products it starts only after the analysis document passes its gate.
The design output. It takes each requirement of the analysis document and states how it is met, with its decisions, interfaces and tests, and it references the requirement ids. For medical products it starts only after the analysis document passes its gate.
See also: Analysis document, Architecture decision, 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.