A stakeholder is a role with an interest in the system, listed with its concerns and its authority over the analysis (approve, consult or inform). A concern is something a stakeholder needs the system or its design to address. An external organization appears as a stakeholder with its concerns, not its sales position.
A stakeholder is a role with an interest in the system, listed with its concerns and its authority over the analysis (approve, consult or inform). A concern is something a stakeholder needs the system or its design to address. An external organization appears as a stakeholder with its concerns, not its sales position.
See also: Role register, System context, Analysis document
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.