Skip to content

Non-Functional Requirements

Template Library

Non-Functional Requirements Template

Define the quality attributes, trust properties, operational expectations, and governance requirements the system must satisfy.

ES-102 NFRs Trust Properties

Template purpose

Use this template to define how well the system must behave and under what quality, trust, operational, and governance expectations.

In the AI era, non-functional requirements are where many trustworthiness concerns become engineering obligations: human oversight, transparency, auditability, AI verification, privacy, security, observability, maintainability, recoverability, and operational readiness.

Project

<Project name>

Document control

Field Value
Artifact owner <owner>
Primary reviewers <reviewers>
Status <draft / in review / accepted / revised>
Last updated <YYYY-MM-DD>
Related Engineering Stage ES-102 — Requirements and Constraints
Project workspace target docs/project-workspace/requirements/non_functional_requirements.md

Requirement areas

Consider:

  • security;
  • privacy;
  • reliability;
  • availability;
  • performance;
  • usability;
  • accessibility;
  • auditability;
  • maintainability;
  • observability;
  • recoverability;
  • human oversight;
  • AI verification;
  • operations;
  • governance;
  • compliance;
  • safety.

Non-functional requirement register

ID Quality Attribute Requirement Summary Target / Standard Verification Status
NFR-001 <attribute> <summary> <target if known> <verification approach> <draft / reviewed / accepted / deferred>

Detailed non-functional requirements

NFR-001 — <Requirement Name>

Field Value
Quality Attribute <attribute>
Requirement The system shall <quality expectation>.
Source <source evidence>
Rationale <why this matters>
Target / Standard <target, threshold, policy, service level, or "to be defined">
Scope of Application <system-wide / component / workflow / data class / user group>
Related FRs <FR-ID or none>
Related Constraints <C-ID or none>
Verification <test / review / inspection / monitoring / analysis / audit>
Evidence Expected Later <test result, audit record, monitoring signal, review note, incident record>
Status <draft / reviewed / accepted / deferred>

Trustworthiness requirements

ID Trust Dimension Requirement Evidence Expected
TR-001 <human oversight / transparency / accountability / auditability / safety / fairness / privacy / security> <requirement> <evidence>

AI verification requirements

Use this section if AI is part of the product or materially used in engineering.

ID Requirement Human Review Expectation Evaluation / Monitoring Evidence Status
AINFR-001 <AI quality, safety, review, guardrail, evaluation, prompt, output, or escalation requirement> <expectation> <evidence> <draft / reviewed / accepted / deferred>

Operational requirements

ID Requirement Target / Expectation Evidence Expected
OPNFR-001 <availability, support, monitoring, logging, incident, rollback, recoverability, serviceability> <target> <monitoring, runbook, incident record, readiness review>

Accessibility and usability requirements

ID Requirement Affected Users Verification
UXNFR-001 <requirement> <users> <review, test, accessibility check, usability test>

Security and privacy requirements

ID Requirement Data / Asset Affected Verification
SPNFR-001 <requirement> <data or asset> <security review, privacy review, test, audit>

Open non-functional requirement questions

ID Question Owner Needed By
NFRQ-001 <question> <owner> <date or stage>

Review checklist

  • [ ] Quality attributes are explicit.
  • [ ] Trustworthiness requirements are included.
  • [ ] AI verification requirements are included if relevant.
  • [ ] Operational expectations are included.
  • [ ] Security, privacy, accessibility, and usability are considered.
  • [ ] Targets or standards are stated where known.
  • [ ] Verification approach and evidence expectations are identified.

Continue to Constraints

Record technical, data, legal, operational, AI, and governance constraints.

Open Constraints →