Engineering guide
Make quality requirements measurable
A quality requirement becomes useful when it states the conditions and observation that determine whether the quality is acceptable. “Fast,” “reliable,” and “secure” leave too much undecided.
Turn an adjective into an observable promise
For an import service, “use little memory” does not define a test. A candidate requirement could bound peak resident memory while importing a specified input size on a defined runtime configuration. The bound must come from the project's needs and feasibility work, not from whichever number the implementation currently achieves.
Illustrative target. Import a 1 GiB input containing the defined record mix with peak resident memory below 256 MiB on the reference deployment. Exclude test-runner memory from the process measurement and state whether compressed input is in scope.
The quantities are examples of decisions to resolve. They are not recommended universal targets or measured Proof results.
Define the measurement before accepting the number
| Concern | Define explicitly |
|---|---|
| Latency | Timing points, percentile, load, request mix, and run duration. |
| Memory | Process boundary, peak metric, input size, and runtime limits. |
| Recovery | Failure injection, permitted data loss, restoration time, and state checks. |
| Security | The prohibited action, adversary capability, protected asset, and tested boundary. |
Some qualities need several requirements. Availability, for example, cannot be represented adequately by one unit test of a restart function. The evidence must match the system boundary and operating assumptions.
Keep tradeoffs and ownership visible
A durability guarantee may increase latency; a memory bound may change buffering strategy. Review competing promises together and allocate responsibilities to the relevant components. An implementation team must not quietly raise a bound to make a benchmark pass.
Proof can categorize requirements and relate them to implementations and evidence. A category label such as performance is useful organization, but it does not create a benchmark, run a load test, or establish coverage of every quality concern.
Review the result in its environment
proof req show SYS-REQ-042 --with lineage,traces
proof review req SYS-REQ-042Inspect the requirement and available evidence, then use the project's configured producer for the actual measurement. Retain code revision, environment, workload, tool version, and result. A passing historical measurement should reopen when relevant code, deployment configuration, or assumptions change.
If a bound is missed, distinguish a measurement problem from a product defect or an infeasible target. Record the decision and any accepted risk explicitly rather than relabeling the requirement.
Continue from here
Record the operating boundary. Choose evidence for the promise.
Bring a quality target that cannot yet be measured consistently by two engineers. Bring a change to Proof.