Write verifiable acceptance criteria

المؤلف: AILesson6 دقائق للإعدادتم اختباره مع:ChatGPTتمت المراجعة: 2026-08-28

إجابة سريعة

Translate requirements into observable pass conditions, edge cases, exclusions, and evidence. قدّم: Requirement and user outcome, Business and quality rules, Scope and unknowns. النتيجة المتوقعة: A testable acceptance set with traceability, examples, and unresolved decisions.

1

أضف سياقك

يبقى نصك في هذا المتصفح. لا يرسله AILesson Prompts إلى نموذج أو خادم.

2

الأمر الخاص بك

تبقى الحقول غير المعبأة ظاهرة كعناصر نائبة، لذا يمكنك نسخ الأمر وتحريرها

Write verifiable acceptance criteria for the requirement.

Approved requirement, user, purpose, and source:
[requirement]

Business, data, permission, state, threshold, accessibility, performance, and error rules:
[rules]

Scope, exclusions, platforms, dependencies, unresolved terms, and approver:
[boundaries]

Use only supplied rules. Split compound behavior into atomic criteria. For each criterion provide ID, source requirement, precondition, action or event, observable expected result, test data or boundary example, evidence, and priority. Cover happy path, empty/invalid/duplicate input, permission boundaries, interrupted or partial completion, time and locale behavior, recovery, accessibility, and non-functional thresholds only where relevant and specified. Mark ambiguous requirements as Decision needed; do not invent a threshold or implementation. Detect conflicts and untestable words such as fast, intuitive, appropriate, or real time. Finish with out-of-scope checks and a traceability matrix.
جرّب في المختبر
خاص افتراضيًايتم تجميع الأمر محليًا في متصفحك. تجنب وضع معلومات سرية في أي خدمة ذكاء اصطناعي ما لم تسمح مؤسستك بذلك.

من المدخلات إلى النتيجة

مثال عملي

شاهد كيف يحول السياق الملموس هذه الوصفة إلى نتيجة قابلة للاستخدام

المدخل الفعلي

Requirement and user outcome
REQ-12: An authenticated employee can save a draft expense claim and return later without submitting it, so incomplete work is not lost.
Business and quality rules
A claim has ClaimID, employee ID, currency, line items, receipt attachments, status, created/updated timestamps. Draft may omit receipts and cost center. Only the employee who created it may view/edit. Submit validates required fields and is out of this story. Autosave is requested as 'quickly' but no interval is approved. Supported web locales are en-GB and zh-CN. Attachments must use existing upload rules.
Scope and unknowns
Web only. Offline editing and manager access are out of scope. Identity and upload services are dependencies. Product owner approves criteria. Session-expiry behavior and draft retention period are unresolved.

مثال على المخرجات

AC-01 | REQ-12 | authenticated employee starts a claim | selects Save draft | a unique ClaimID is stored with creator, Draft status, currency, existing line data, and updated timestamp; no submission occurs | evidence: persisted record and UI confirmation | Must. AC-02 | REQ-12 | draft lacks receipt and cost center | Save draft | save succeeds because those fields are optional for Draft | boundary example: one line item, no attachment/cost center | Must. AC-03 | ownership rule | employee B requests employee A's draft by UI or direct URL | access denied and no claim details exposed | evidence: authorization test/log | Must. AC-04 | return later | creator signs in later in en-GB or zh-CN | draft appears with stored values and locale-appropriate presentation; underlying amounts/timestamps remain unchanged | Must. AC-05 | upload dependency | attachment save fails under existing upload rules | draft behavior and recoverable message require confirmation; do not claim attachment persisted | Decision needed.

Decisions needed: autosave interval replacing “quickly”; session-expiry behavior for unsaved edits; retention period and deletion notice. Out of scope: submission validation, manager access, offline editing. Traceability: REQ-12→AC-01/02/04; ownership→AC-03; upload dependency→AC-05.

لماذا يعمل هذا

  1. 1

    Observable results and boundary examples make agreement testable before implementation starts.

  2. 2

    Decision-needed labels keep product ambiguity from being hidden inside a test case.

تحقق من النتيجة

  • Is each criterion atomic, observable, and traceable to a supplied requirement?

  • Are edge conditions relevant rather than generic boilerplate?

  • Were missing thresholds and undefined terms left as decisions?

استخدمها بثقة

الأسئلة الشائعة

إجابات عملية حول متى تستخدم هذه الوصفة، وما الذي تقدمه، وأين لا تزال المراجعة البشرية مهمة

What should I prepare before using “Write verifiable acceptance criteria”?

For “Write verifiable acceptance criteria,” prepare Requirement and user outcome, Business and quality rules, and Scope and unknowns. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Write verifiable acceptance criteria” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A testable acceptance set with traceability, examples, and unresolved decisions—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Write verifiable acceptance criteria”?

The published test record for “Write verifiable acceptance criteria” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

المزيد من طرق الاستكشاف

أين تندرج هذه الوصفة

حافظ على استمرار العمل