Stakeholder and system requirements procedure

Stakeholder and system requirements procedure

RE-01 — Requirements policy

[Organisation] records and maintains the requirements governing each system in scope. Requirements express agreed stakeholder needs, applicable obligations, protection needs and constraints in a form that can guide design and support verification or validation. Each requirement has an identifier, source, owner, status and acceptance method. Proposed requirements remain distinguishable from approved requirements.

The requirements owner maintains the relationship between stakeholder needs, system requirements, allocated component requirements and evidence. The record preserves why a requirement exists, not only its final wording. Security, privacy, resilience and supplier requirements are integrated with functional and operational requirements. Requirements arising from an AI component or automated actor are governed through the same process.

RE-02 — Elicit and analyse

The analyst reviews the business need, stakeholder register, system context, operating scenarios, agreements, risk assessments and applicable policies. The analyst records the outcome required and the conditions under which it must hold. Ambiguous terms are clarified with the source stakeholder. Requirements identify relevant inputs, outputs, states, actors, limits and failure behaviour where those details affect acceptance.

The analyst checks whether a statement describes a need, a design choice, a constraint or an activity. A design constraint can be valid, but its authority and rationale are recorded. The analyst identifies conflicts, missing information and assumptions requiring confirmation. Unsupported assumptions remain labelled as assumptions and are assigned for resolution; they are not silently converted into an organisational requirement.

RE-03 — Define protection requirements

The security and privacy leads work with stakeholders to turn protection needs into requirements. The analysis considers permitted access, identity and authority, information processing, integrity of decisions and outputs, essential service availability, recovery and the ability to establish what occurred. Requirements cover normal operation, error conditions, misuse, maintenance, degraded operation and retirement.

Where a selected control supports a requirement, the control reference and organisation-defined parameters are recorded. A control title alone does not describe the system behaviour expected. Requirements address dependencies and interfaces so that a system does not rely on an unstated security property of a supplier, operator or connected service. The owner records requirements that remain outside SP 800-53’s vocabulary using local identifiers.

RE-04 — Allocate and agree

The engineering lead allocates system requirements to architecture elements, interfaces, procedures or agreements. Allocation identifies who implements the requirement and who verifies the result. Requirements shared across components identify the integration evidence needed. Derived requirements retain the engineering rationale and parent relationship so that their necessity can be reviewed when the design changes.

The owner reviews the proposed baseline with affected stakeholders and decision authorities. Review checks consistency, feasibility, completeness relative to the agreed scope, and whether acceptance can be demonstrated. Approval identifies the version and any unresolved matters. A baseline can contain explicitly unresolved items where the authority accepts that planning position; those items remain visible with their consequences and decision dates.

RE-05 — Verification and validation arrangements

The verification lead identifies how each approved requirement will be checked: examination, analysis, demonstration, test or a combination. The record specifies the expected result, applicable environment and evidence to retain. Where a threshold or tolerance is needed, the responsible authority establishes it before the result is judged. A test that was never capable of observing the requirement is not credited as verification of it.

Validation arrangements establish whether the delivered system meets stakeholder needs in its intended use. The plan identifies stakeholder participation and representative operating conditions. Verification and validation results may use related evidence, but their questions remain distinct. A system can satisfy a written requirement while still failing the need from which it was derived; that finding returns to the requirements process.

RE-06 — Change and traceability

A requirement change identifies the source of the change, proposed wording, rationale and affected needs, architecture, controls, tests, suppliers and operating instructions. The owner assesses impact before the designated authority approves the new baseline. The change record preserves the previous wording and decisions. Deleted requirements retain their history and disposition rather than being removed from traceability without explanation.

At each relevant review, the owner checks for approved requirements with no implementation or acceptance evidence and for implemented capabilities with no recorded requirement or authorised change. The review distinguishes omissions, traceability defects and authorised exploratory work. The appropriate authority decides what to do with an unexplained capability; the analyst does not invent a retrospective need to justify it.

RE-07 — Requirements assurance

The assurance reviewer samples requirements from different sources and life-cycle stages and follows their trace to decisions and evidence. The reviewer also samples released capabilities and traces backwards to authority and need. Findings identify ambiguity, missing acceptance criteria, unsupported assumptions and broken relationships. The requirements owner assigns corrective actions and confirms whether affected assurance or release decisions require reconsideration.