The form of a quality or architecture requirement, in six parts: source, stimulus, environment, artifact (named at requirement level, not as a component), response, and a numeric response measure that gives pass or fail.
The form of a quality or architecture requirement, in six parts: source, stimulus, environment, artifact (named at requirement level, not as a component), response, and a numeric response measure that gives pass or fail.
See also: Requirement, Requirement type, Acceptance criteria
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.