Encode Nonfunctional Requirements
encode-nonfunctional-requirements
Summary
Performance, security, accessibility, privacy, and reliability expectations are easy to lose when they live only in prose. Encode important requirements in tests, budgets, schemas, automation, or review gates where the system can keep enforcing them.
Problem
Quality often depends on requirements that are not visible in the feature prompt: reliability, performance, security, accessibility, architecture boundaries, observability, maintainability, and operational constraints. Agents miss these when they live only as human taste.
Preferred Move
Write nonfunctional requirements down and encode the stable ones into checks, architecture rules, templates, review gates, or examples. Make the invisible bar visible before the agent has to infer it from rejection.
Tradeoff
Do not freeze every preference too early. Start with docs and examples while the rule is forming; promote it to mechanical enforcement when it is stable and repeatedly valuable.
Agent Instruction
When a task has hidden quality requirements, name them before implementation. If a requirement is
stable and checkable, propose the smallest durable check that enforces it.Examples
Bad: the prompt implies performance without defining the bar.
Make startup faster.
Good: the nonfunctional requirement is measurable.
Make startup complete under 800 ms for the local development path and report the measured command.
References
| Source | Use | Note |
|---|---|---|
| OpenAI architecture enforcement | supports |
Architecture and taste can be encoded as mechanical constraints. |