Why a requirement exists, and the consequence of its absence.
See also: Requirement, Requirement source
Interim definition. BLORP takes this term over when the global ontology lifts from Phase-0.
Rationale
Why a requirement exists, and the consequence of its absence.
Nov 5, 2026
NOWAITN
More in Requirements and design
Continue exploring our knowledge base
Requirement
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.
Requirement attribute
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.
Requirement type
The kind of a requirement. One of: business, stakeholder, functional, quality, service-level, security, regulatory, constraint, architecture, interface, data, operation or risk-control.
Requirement level
Where a requirement sits in the decomposition. One of: business, stakeholder, system or software.
Owner role (requirement owner)
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.