Non-Functional Requirement to Acceptance Criteria Prompt

This prompt is designed for performance engineers, QA architects, and platform reliability leads who need to convert ambiguous non-functional requirements (NFRs)—such as SLAs, latency budgets, throughput targets, and availability guarantees—into precise, verifiable, and automation-ready acceptance criteria. The core job-to-be-done is bridging the gap between a high-level operational mandate like 'the system must be fast' and a concrete, measurable behavior contract that can be instrumented, tested in a CI/CD pipeline, and validated against a specific environment. The ideal user is someone who already understands the system's architecture and has access to the original NFR documents, monitoring dashboards, or infrastructure-as-code configurations. They are not starting from zero; they are translating known constraints into a testable format.

You should use this prompt when you have a specific NFR artifact in hand—a latency percentile from an SLA, a throughput requirement from a capacity plan, a recovery time objective (RTO) from a disaster recovery runbook, or a resource limit from a cloud cost model. The prompt excels at producing Gherkin-style scenarios with explicit instrumentation hooks (e.g., 'Given a steady load of 5000 RPS, when a new deployment is rolled out, then the p99 latency measured at the load balancer must remain below 200ms for 5 consecutive minutes'). It also generates the necessary test environment preconditions, such as instance types, database scaling configurations, and network emulation settings, which are critical for making the criteria reproducible. The output is not just a list of thresholds; it's a specification that includes the measurement tool (e.g., prometheus, k6), the aggregation window, and the failure condition.

Do not use this prompt for defining functional behavior, user interface interactions, or business logic rules. It is not a replacement for a user story refinement session. If your input is a vague statement like 'the app should handle a lot of users,' the prompt will produce an unreliable and unverifiable specification because the core measurability constraint is missing. Similarly, avoid this prompt when the target environment is completely undefined; the output will be filled with unresolvable placeholders that provide a false sense of precision. For high-risk domains like healthcare or finance, always pair the generated criteria with a human review step to validate that the thresholds align with regulatory requirements and that the specified instrumentation does not introduce unacceptable overhead or side effects. The next step after generating these criteria is to feed them into your test automation framework and observability platform, not to treat them as a final, unreviewed contract.

This template converts performance, availability, and scalability SLAs into executable acceptance criteria. It forces the model to produce output that can be validated by monitoring systems and test harnesses, not just human reviewers. Use it when you have concrete NFR targets—latency budgets, throughput floors, uptime percentages—and need them expressed as behavior specs your CI/CD pipeline can enforce. Do not use this prompt for vague aspirational goals like 'the system should be fast'; it requires numeric thresholds and measurable dimensions to produce useful output.

textCopy
You are a performance engineering specialist translating non-functional requirements into verifiable acceptance criteria. Your output must be directly usable by automated test frameworks and monitoring dashboards.

INPUT NFR DOCUMENT:
[INPUT]

ADDITIONAL SYSTEM CONTEXT (architecture, dependencies, known bottlenecks):
[CONTEXT]

REQUIRED OUTPUT SCHEMA:
[OUTPUT_SCHEMA]

CONSTRAINTS:
- Every criterion must include a numeric threshold, measurement method, and observation window.
- Specify required test environment preconditions (instance types, data volumes, concurrency profiles).
- Flag any criterion that cannot be verified in a pre-production environment and requires production observation.
- For each criterion, state the risk of false-pass (test passes but production fails) and how to mitigate it.
- If the input lacks a required threshold, do not invent one. Instead, mark it as [NEEDS THRESHOLD] and explain why it matters.

EXAMPLES OF GOOD OUTPUT:
[EXAMPLES]

AVAILABLE TOOLS (for instrumentation reference):
[TOOLS]

RISK LEVEL OF THIS SYSTEM:
[RISK_LEVEL]

Generate acceptance criteria following the output schema exactly. Include an "Unverifiable Items" section at the end for anything that cannot be measured with the available tools.

Adapt this template by replacing each square-bracket placeholder with concrete values. The [INPUT] should contain raw SLA text, latency budgets, or availability targets. [CONTEXT] is critical for environment preconditions—without it, the model may assume ideal conditions that mask real-world bottlenecks. [OUTPUT_SCHEMA] should define the exact JSON or markdown structure your test harness expects. For high-risk systems, set [RISK_LEVEL] to high to trigger stricter validation language and explicit false-pass warnings. After generating criteria, validate that every measurable item has a corresponding instrumentation hook in your observability stack before accepting the output.

This prompt is designed to be a deterministic step in a quality gate pipeline, not a free-form assistant. It takes a structured NFR specification as input and produces a machine-readable set of acceptance criteria. The primary integration points are a CI/CD system (e.g., GitHub Actions, GitLab CI), a test management tool (e.g., TestRail, Xray), and a performance test harness (e.g., k6, Locust). The goal is to ensure that every performance SLA, latency budget, or availability target is automatically translated into a verifiable, executable test contract before a release candidate is built.

To wire this into a pipeline, wrap the prompt in a scripted API call. The input [NFR_SPECIFICATION] should be a structured JSON or YAML object containing fields like max_p95_latency_ms, target_availability_percent, and throughput_rps. The script should validate the input schema before sending it to the model. On receiving the output, a strict JSON schema validator must confirm that every generated criterion has a numeric threshold, a measurement_method, and a test_environment_precondition. If validation fails, the pipeline must fail the build and log the raw output for debugging. For test management integration, the script should parse the validated output and create or update test cases via the tool's API, mapping each criterion's id to an external test key for traceability. A retry loop with exponential backoff (max 3 attempts) should be implemented for model calls that return malformed JSON, with a final fallback to a human review queue.

Do not treat this prompt as a one-shot solution for unconstrained natural language. The harness must enforce that the input NFR is quantitative. If a user provides a vague requirement like 'the system should be fast,' the pre-processing script should reject it and request a specific threshold. For high-risk deployments, always route the generated criteria to a human for approval before they are committed to the test repository. The approval step should display a diff of the proposed criteria against any existing ones. Finally, log the full prompt, response, validation result, and reviewer decision as an audit trail to satisfy governance requirements for performance and reliability standards.