صياغة قصص المستخدم ومعايير قبول قابلة للتحقق

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

إجابة سريعة

حوّل احتياجات المستخدم والعمل المؤكدة إلى قصص محددة النطاق وسلوك يمكن ملاحظته دون اختلاق قرارات تخص المنتج. قدّم: الحاجة والأدلة, قرارات المنتج المعتمدة, التسليم والتحقق. النتيجة المتوقعة: مجموعة قصص تتضمن الأدلة والحدود والسيناريوهات ومعايير القبول والمتطلبات غير الوظيفية والتبعيات والقرارات المفتوحة.

أضف سياقك

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

الحاجة والأدلةقرارات المنتج المعتمدةالتسليم والتحقق

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

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

صِغ قصص مستخدم ومعايير قبول قابلة للتحقق استنادًا إلى الاحتياجات المؤكدة وقرارات المنتج المعتمدة.

حالات المستخدم وأدواره وأهدافه وسلوكياته والأدلة والسبب التجاري وحدود البحث والحالات السلبية:
[evidence]

النطاق المختار وسير العمل والحالات والقواعد والأذونات والبيانات وعمليات التكامل والمنصات والمتطلبات غير الوظيفية والاستثناءات:
[product]

الإصدار والفرق والتبعيات والتحليلات وإمكانية الوصول والخصوصية والأمان والبيئات وتعريف الاكتمال والقرارات المفتوحة:
[delivery]

افصل بين الحاجة المسندة بالأدلة وفرضية المنتج والقرار المعتمد وافتراض التنفيذ والخيار غير المحسوم. قسّم القصص بحسب المنفذ والنتيجة المستقلة، لا بحسب الطبقة التقنية أو الملحمة المفرطة في الحجم. استخدم جملة قصة المستخدم كملخص فقط؛ وأضف السياق وموضع الدليل وما يقع داخل النطاق وخارجه والشروط السابقة والمحفز والمسار الرئيسي والمسارات البديلة ومسارات الخطأ والأذونات ومعالجة البيانات وقواعد العمل والتبعيات. اكتب معايير القبول في صورة سيناريوهات Given/When/Then قابلة للملاحظة أو ما يعادلها، بحيث تغطي المسار الناجح والحدود والبيانات المفقودة أو غير الصالحة ورفض الإذن والتزامن أو تكرار الإجراء والاسترداد وإمكانية الوصول والخصوصية/الأمان والتحليلات والتوافق، وذلك فقط حيث تكون معتمدة. لا تختلق نصًا لواجهة المستخدم أو حالة أو حدًا أو تكاملًا أو دورًا أو مدة احتفاظ بالبيانات أو هدف أداء أو إشعارًا أو سلوك خطأ أو مقياسًا. ضع القرارات غير المحسومة في صورة أسئلة تعوق المعايير المتأثرة. استبعد أفكار الحلول عندما لا يكون هناك حل معتمد. اختتم بالتتبع من الدليل إلى القصة إلى المعيار، وبتدقيق قابلية الاختبار والنطاق والتعارض والجاهزية.

جرّب في المختبر

خاص افتراضيًايتم تجميع الأمر محليًا في متصفحك. تجنب وضع معلومات سرية في أي خدمة ذكاء اصطناعي ما لم تسمح مؤسستك بذلك.

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

مثال عملي

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

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

الحاجة والأدلة: أدلة البحث من جلسات UX ‏P01/P03: عندما يخلو تسليم بحالة Ready من مسؤولية قبول ظاهرة، بحث المالكون بين الأشخاص أو فاتهم ذكر متوقع. توضح الحالات السلبية P02/P04 أن بعض فترات الانتظار مقصودة أو تنتظر موافقة معروفة. السبب التجاري المعتمد: تقليل عدم اليقين الممكن تجنبه دون زيادة عبء الإشعارات. لا تثبت الأدلة مدى الانتشار أو وجود طلب على البريد الإلكتروني.
قرارات المنتج المعتمدة: حل معتمد في مرحلة الاستكشاف للنموذج الأولي: إظهار حقل accepter اختياري في عملية التسليم؛ لا يستطيع تعيينه أو تغييره إلا requester أو workspace coordinator؛ ويمكن لـowner وaccepter رؤيته. تظل الحالات الحالية Draft وActive وReady وAccepted كما هي. إذا لم يُعيّن accepter، فاعرض الحالة على أنها غير مسندة باستخدام design token المعتمد، مع انتظار النص الدقيق لواجهة المستخدم. لا بريد إلكتروني ولا إشعار فوري. يجب أن يكون accepter عضوًا نشطًا في مساحة العمل. يسجل audit log المنفذ وaccepter القديم/الجديد والوقت. تطبيق الويب وحده مدعوم. لم يُعتمد أي تغيير في الاحتفاظ.
التسليم والتحقق: إصدار نموذج أولي لاختبار قابلية الاستخدام، وليس للإنتاج. يتولى Design النص؛ ويتحقق Engineering من العضوية وaudit event؛ وتتطلب Accessibility التشغيل بلوحة المفاتيح وتسمية برمجية وحالة لا تعتمد على اللون وحده. اكتملت مراجعة الخصوصية لاستخدام member IDs الحالية. أسماء analytics event وحد الأداء غير محسومة. تعريف الاكتمال: تصميم مراجع، ونموذج أولي عامل، واختبارات وحدات، وفحص إمكانية الوصول، ونص بحث. لا تكتب SLA للإنتاج.

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

القصة 1 — تعيين مسؤولية القبول بصفتي requester أو workspace coordinator، أحتاج إلى تعيين عضو نشط في مساحة العمل بوصفه accepter لعملية تسليم كي يتمكن المعنيون من رؤية الشخص المخول بقبولها. الدليل: P01/P03؛ النطاق فرضية لنموذج أولي، وليس طلبًا مثبتًا.

معايير القبول • Given عملية تسليم على الويب وrequester/coordinator مؤهل، When يختار عضوًا نشطًا في مساحة العمل ويؤكد، Then يُحفظ ذلك العضو بوصفه accepter ويظهر لـrequester وowner وaccepter. واجهة التأكيد الدقيقة غير محسومة ويجب أن تأتي من التصميم المعتمد. • Given شخص ليس requester/coordinator، When يعرض عملية التسليم، Then يستطيع رؤية accepter لكنه لا يستطيع تغييره. سلوك رفض الإجراء المعتمد مفقود ويعوق تحديد معياره الدقيق. • Given حساب غير نشط أو ليس عضوًا، When يُقدَّم بوصفه accepter، Then لا يحفظه النظام. نص الخطأ الدقيق في انتظار Design؛ فلا تختلقه. • Given وجود accepter حالي، When يغيره منفذ مخول أو يمسحه، Then تسجل audit data المنفذ والقيمة القديمة والقيمة الجديدة والوقت. يتبع الاحتفاظ السياسة الحالية؛ ولا تُحدد فترة جديدة.

القصة 2 — فهم عملية تسليم غير مسندة بصفتي owner أو requester، أحتاج إلى إدراك عدم تعيين accepter كي أقرر ما إذا كنت سأحدد شخصًا أم أواصل عمدًا من دونه. تحافظ هذه الصياغة على الحالات السلبية P02/P04 ولا توحي بأن كل انتظار خطأ.

المعايير: عندما يغيب accepter، يظهر visual token المعتمد للحالة غير المسندة؛ وتظل الحالة Ready بدلًا من إنشاء حالة جديدة. للمؤشر تسمية برمجية، ويمكن تمييزه من دون اللون. يستطيع مستخدمو لوحة المفاتيح الوصول إلى الحقل وتنفيذ كل إجراء مسموح به بترتيب منطقي. النص الدقيق الظاهر ونص إمكانية الوصول في انتظار Design ويعوق تأكيدات النص النهائية.

خارج النطاق: البريد الإلكتروني/الإشعارات الفورية، والطرح في الإنتاج، وفترة احتفاظ جديدة، والادعاء بالانتشار أو بالنتيجة، والتعيين التلقائي، وSLA للإنتاج. يظل معيار Analytics معوقًا حتى اعتماد أسماء event والغرض منها. يربط التتبع P01/P03 بقصص الرؤية، بينما تتطلب P02/P04 تعيينًا اختياريًا وعدم وجود تنبيه تلقائي.

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

1
تمنع قابلية التتبع جملة القصة الموجزة من إخفاء سلوك غير مسند للمنتج.
2
تجعل سيناريوهات الحدود والإخفاق معايير القبول مفيدة خارج نطاق المسار الناجح في العرض التوضيحي.

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

هل ترتبط كل قصة بأدلة مؤكدة على الحاجة وبقرار منتج معتمد؟
هل المعايير قابلة للملاحظة وغير ملتبسة وخالية من واجهات أو حدود مختلقة؟
هل تُغطى الحدود والأذونات والأخطاء والاسترداد وإمكانية الوصول والخصوصية والقرارات المفتوحة حيثما كان ذلك ذا صلة؟

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

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

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

ما الذي ينبغي أن أُعدّه قبل استخدام «صياغة قصص المستخدم ومعايير قبول قابلة للتحقق»؟

لاستخدام «صياغة قصص المستخدم ومعايير قبول قابلة للتحقق»، أعدّ الحاجة والأدلة، وقرارات المنتج المعتمدة، والتسليم والتحقق. لا تستبدل العناصر النائبة إلا بمعلومات يمكنك التحقق منها. إذا كان أحد التفاصيل مجهولًا، فصرّح بعدم اليقين بوضوح بدلًا من مطالبة النموذج باستنتاجه.

متى لا تكون نتيجة «صياغة قصص المستخدم ومعايير قبول قابلة للتحقق» جاهزة للاستخدام؟

لا تكون النتيجة جاهزة إذا لم تحقق بعدُ الناتج المعلن—مجموعة قصص تتضمن الأدلة والحدود والسيناريوهات ومعايير القبول والمتطلبات غير الوظيفية والتبعيات والقرارات المفتوحة—استنادًا إلى الأدلة المقدمة، أو إذا اعتمدت على افتراضات غير محسومة أو موافقات مفقودة أو تفاصيل مختلقة. استخدم عناصر التحقق بوصفها شروطًا للإجازة: راجع المدخلات المصدرية أو عيّن مراجعًا مسمى ومخولًا بدلًا من تنميق مخرجات بلا سند.

ما أدوات الذكاء الاصطناعي التي لديها اختبارات مسجلة لوصفة «صياغة قصص المستخدم ومعايير قبول قابلة للتحقق»؟

يدرج سجل الاختبار المنشور لوصفة «صياغة قصص المستخدم ومعايير قبول قابلة للتحقق» أداة ChatGPT حتى 2026-08-28. يؤكد ذلك وجود عمليات تشغيل مسجلة، ولا يضمن التوافق أو تطابق النتائج في إصدارات المنتج اللاحقة. عند استخدام أداة أو إصدار آخر، أبقِ جميع القيود ظاهرة وكرر عمليات التحقق من النتيجة قبل الاستخدام.

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