كيف تراجع المتطلبات
مراجعة المتطلبات (Requirements review) اختبار ساكن لأساس الاختبار (Test basis): قبل أن يصمم أحد أو يبرمج أو يختبر، تقرأ مجموعة صغيرة المتطلب أو قصة المستخدم وتسأل: هل هو واضح، ومكتمل، ومتسق، وصحيح، وقابل للاختبار، وقابل للتنفيذ، وقابل للتتبع، وصريح في الاحتياجات غير الوظيفية؟ كل سؤال يُجاب عنه هنا قرار لن يضطر المطور إلى تخمينه، وعيب لن يضطر المختبر إلى اكتشافه لاحقاً.
يقدّم هذا الدليل عملية يستطيع أي مختبر تشغيلها في أي فريق، وقائمة تحقق بالأسئلة الواجب طرحها لكل معيار، والكلمات التي تنذر بمشكلة، ومثالاً عملياً كاملاً — قصة مستخدم، وتعليقات المراجعة التي تلقتها، والقصة بعد إعادة صياغتها. ويختم بموقع أدوات متقن للذكاء الاصطناعي الخاصة بالمتطلبات: هي تصوغ مسودات الملاحظات، والقرار للإنسان.
ما هي مراجعة المتطلبات ولماذا تستحق الجهد
في مفردات ISTQB، المتطلبات وقصص المستخدم جزء من أساس الاختبار — المادة التي تُشتق منها الاختبارات. ومراجعتها اختبار ساكن، ويعدّ CTFL v4.0 عيوب المتطلبات — عدم الاتساق والغموض والتناقض والإغفال وعدم الدقة والتكرار — من العيوب التي يكتشفها الاختبار الساكن بسهولة وكلفة أقل من الاختبار الديناميكي. وعيب المتطلبات الذي ينجو يصبح كوداً، ثم اختبارات مكتوبة على سوء الفهم نفسه، ثم يكتشفه مستخدم في النهاية.
وتنتج مراجعة المتطلبات كذلك فهماً مشتركاً لا تحققه أي وثيقة وحدها. فحين يقرأ مالك المنتج ومطور ومختبر القصة نفسها معاً — وهي الممارسة التي تسميها فرق رشيقة كثيرة «الأصدقاء الثلاثة» (Three amigos) — يأتي كلٌّ منهم بأسئلة مختلفة: ما الذي يحتاجه العمل، وكيف يمكن بناؤه، وكيف يمكن أن يفشل. ونوع المراجعة عادةً غير رسمي أو مراجعة فنية قصيرة؛ أما القواعد التنظيمية أو المالية فيبرر فيها التفتيش بقائمة تحقق. وتُقارَن أنواع المراجعة وأدوارها في صفحتها الخاصة.
كيف تجري مراجعة المتطلبات خطوة بخطوة
- اختر التوقيت. راجع القصة قبل قبولها في السبرنت (كثير من الفرق تجعل «تمت مراجعتها» جزءاً من تعريف الجاهزية Definition of Ready)، وراجعها مجدداً حين تتغير.
- اجمع السياق. افتح الملحمة (Epic)، وقواعد العمل المرتبطة، وعقد API، والتصاميم، وأي نظام تنظيمي تمسّه القصة. كثير من التناقضات يقع بين الوثائق لا داخل وثيقة واحدة.
- اقرأ فردياً أولاً. يقرأ كل مراجع بقائمة التحقق أدناه ويكتب ملاحظاته قبل أي نقاش، كي لا يرتكز الجميع على أول رأي يُقال.
- اكتب الملاحظات كتعليقات مراجعة. ملاحظة واحدة لكل تعليق: الموضع، وما الخطأ، ولماذا يهم، وصياغة مقترحة أو سؤال، ومن يجب أن يقرر.
- ناقشوا وقرروا. في جلسة التنقيح أو اجتماع قصير، يقبل المؤلف كل ملاحظة أو يرفضها أو يعدّلها. والأسئلة المفتوحة يُحدد لها مالك وموعد؛ ولا يُترك شيء كافتراض صامت.
- أعد الصياغة وتحقق مجدداً. يحدّث المؤلف القصة ومعايير القبول؛ ويتأكد مراجع من حل كل ملاحظة مقبولة قبل وسم القصة بالجاهزية.
- احتفظ بالملاحظات. سجل أنواع الملاحظات (غموض، مسار خطأ مفقود، قاعدة متعارضة) يبيّن بنود قائمة التحقق وعناوين القوالب التي يحتاجها فريقك أكثر.
جرّبها: كاشف غموض المتطلبات بالذكاء الاصطناعي جرّبها: محلّل فجوات المتطلبات بالذكاء الاصطناعي
قائمة التحقق لمراجعة المتطلبات
استخدم المعايير الثمانية عناوينَ لملاحظاتك. والأسئلة تحت كل معيار هي الأكثر كشفاً للعيوب.
- الغموض (Ambiguity) — هل يمكن لقارئين أن يبنياه أو يختبراه بشكل مختلف؟ هل فيه كلمات مبهمة (سريع، سهل، مناسب)، أو مصطلحات غير معرّفة، أو ضمائر مرجعها غير واضح، أو «و/أو»؟
- الاكتمال (Completeness) — هل تُغطى مسارات الخطأ والحالات الفارغة والحدود والصلاحيات والأدوار؟ ماذا يحدث عند انتهاء المهلة، أو الإرسال المكرر، أو الإلغاء، أو البيانات غير الصالحة؟ من يستطيع فعل ذلك ومن لا يستطيع؟
- الاتساق (Consistency) — هل يتعارض مع قصة أخرى، أو قاعدة عمل، أو عقد API، أو تصميم الواجهة، أو مع نفسه؟ هل تُسمّى الأشياء نفسها بالأسماء نفسها؟
- الصحة (Correctness) — هل هو ما يحتاجه العمل والمستخدم فعلاً؟ هل هو صحيح بالنسبة للمجال والأنظمة والسياسة الحالية؟ هل الأرقام (الرسوم والحدود وضريبة القيمة المضافة والتواريخ) صحيحة وموثّقة المصدر؟
- قابلية الاختبار (Testability) — هل يصف كل معيار قبول نتيجة قابلة للملاحظة بنجاح أو فشل واضح؟ هل تستطيع اليوم أن تكتب منه النتيجة المتوقعة لحالة اختبار؟
- قابلية التنفيذ (Feasibility) — هل يمكن بناؤه بالتقنية والبيانات والخدمات الخارجية والوقت والميزانية المتاحة؟ هل يعتمد على شيء لا يتحكم فيه الفريق؟
- قابلية التتبع (Traceability) — هل له معرّف فريد، وربط صاعد بملحمته أو هدف العمل وبالقواعد المرتبطة، وهل ستستطيع حالات الاختبار الإشارة إليه؟
- الاحتياجات غير الوظيفية (Non-functional) — هل الأداء والأمان والخصوصية وإمكانية الوصول والتوطين والموثوقية ومتطلبات التدقيق مذكورة بمعايير قابلة للقياس، أو على الأقل موسومة بأنها محسومة في موضع آخر؟
كلمات منذرة وما تسأل عنه بدلاً منها
بعض الكلمات تخفي في الغالب متطلباً لم يُحسم. ابحث عنها في النص قبل القراءة المتعمقة؛ فكل واحدة إما ملاحظة وإما تأكيد سريع أن معناها معرّف في موضع آخر.
الكلمة في المتطلب اسأل بدلاً منها
سريع، بسرعة، فوراً خلال كم ثانية أو دقيقة، وعند أي نسبة مئوية، وتحت أي حمل؟
سهل الاستخدام، بديهي، سلس أي مهمة، لأي مستخدم، وكيف تُقاس؟
مناسب، معقول، كافٍ ما هو بالضبط؟ اذكر الحالات أو أعطِ الرقم
إلخ، وغيرها، مثل ما القائمة الكاملة؟
ينبغي، قد، يمكن إلزامي أم اختياري؟
كل، دائماً، أبداً، جميع حقاً الكل؟ وما الاستثناءات؟
يدعم، يعالج، يدير ما السلوك القابل للملاحظة؟
و/أو كلاهما أم أحدهما؟
آمن، متين، قابل للتوسع ضد أي تهديد أو إخفاق أو حمل؟مثال عملي: قصة مستخدم وتعليقات مراجعتها
مثال: متجر إلكتروني خيالي لديه هذه القصة في قائمة العمل. ولدى الفريق أيضاً قاعدة عمل، BR-4 في وثيقة قواعد الحسابات: الحسابات غير الموثّقة لا يمكنها تسجيل الدخول.
التعليقات أدناه مكتوبة كما تظهر في أداة المراجعة أو على التذكرة: مشكلة واحدة لكل تعليق، بموضعها، مع السبب ومقترح أو سؤال. لاحظ أن المراجع يقترح قيماً لكنه لا يحسمها — القرار لمالك المنتج، ولفريق الأمان حيث يتعلق الأمر بالأمان.
US-231 إعادة تعيين كلمة المرور عبر البريد الإلكتروني
بصفتي عميلاً مسجلاً
أريد إعادة تعيين كلمة المرور من صفحة تسجيل الدخول
كي أستعيد الوصول إلى حسابي حين أنساها.
AC1 يُدخل العميل بريده الإلكتروني ويتلقى رابط إعادة التعيين.
AC2 تنتهي صلاحية الرابط بعد وقت معقول.
AC3 يجب أن تكون كلمة المرور الجديدة قوية.
AC4 بعد إعادة التعيين يُسجَّل دخول العميل تلقائياً.
AC5 ينبغي أن تكون الصفحة سريعة وسهلة الاستخدام.
AC6 يمكن للعملاء ذوي الحسابات غير الموثّقة أيضاً إعادة تعيين كلمة المرور.
--- تعليقات المراجعة ---
RC-01 [قابلية الاختبار · رئيسية] AC2
«وقت معقول» غير قابل للاختبار: سيختار مختبران رقمين مختلفين.
مقترح: «تنتهي صلاحية الرابط بعد 30 دقيقة من إرساله». @مالك_المنتج هل 30 دقيقة مناسبة؟
RC-02 [غموض · رئيسية] AC3
«قوية» غير معرّفة هنا. هل المقصود سياسة كلمات المرور الحالية SEC-12؟
إن كان كذلك فأشر إليها. وهل يجوز أن تطابق الجديدةُ الحاليةَ؟
RC-03 [اكتمال · رئيسية] AC1
لا سلوك محدداً لبريد غير مسجل. إن اختلفت الرسالة فسيكشف النموذج أي
العناوين لها حسابات. مقترح: الرسالة نفسها في الحالتين. @الأمان يرجى التأكيد.
RC-04 [اكتمال · ثانوية] AC1, AC2
هل الرابط للاستخدام مرة واحدة؟ إن طلب العميل رابطين فهل يبقى الأول صالحاً؟
RC-05 [اتساق · رئيسية] AC4 + AC6
معاً يسمحان لحساب غير موثّق بتسجيل الدخول، وهذا يناقض BR-4
(«الحسابات غير الموثّقة لا يمكنها تسجيل الدخول»). يجب تغيير أحد الثلاثة.
RC-06 [صحة · سؤال] AC4
هل يجب أن تُنهي إعادة التعيين الجلسات القائمة على الأجهزة الأخرى؟ تسجيل الدخول
التلقائي مباشرة بعد إعادة التعيين يحتاج إلى قرار أمني.
RC-07 [غير وظيفي · رئيسية] AC5
«سريعة وسهلة الاستخدام» متطلبان وكلاهما غير قابل للقياس. افصلهما إلى هدف
لزمن الاستجابة وإلى قائمة تحقق إمكانية الوصول لدى الفريق. وأيضاً: بأي لغة
يُرسل البريد، العربية أم الإنجليزية؟
RC-08 [قابلية التنفيذ · سؤال] AC1
هل هناك حد لطلبات إعادة التعيين؟ من دونه يمكن استخدام النموذج لإغراق بريد
العميل ورفع تكاليف مزوّد البريد.
RC-09 [قابلية التتبع · ثانوية] القصة
غير مرتبطة بملحمتها ولا بـ SEC-12 وBR-4. أضف الروابط كي ترتبط حالات الاختبار
بالقواعد التي تتحقق منها.جرّبها: كاشف غموض المتطلبات بالذكاء الاصطناعي جرّبها: مراجع معايير القبول بالذكاء الاصطناعي
القصة بعد إعادة الصياغة
في هذا المثال الخيالي أجاب مالك المنتج وقائد الأمان عن الأسئلة، وأعاد المؤلف كتابة المعايير. الأرقام قرارات الفريق وليست توصيات. ولكل معيار الآن نتيجة قابلة للملاحظة، والقصة مرتبطة بالقواعد التي تعتمد عليها.
US-231 إعادة تعيين كلمة المرور عبر البريد الإلكتروني (v2، بعد المراجعة)
الروابط: EPIC-AUTH-3 · سياسة كلمات المرور SEC-12 · الحسابات الموثّقة BR-4 · زمن الاستجابة PERF-2
AC1 بافتراض نموذج «نسيت كلمة المرور»، عند إرسال أي عنوان بريد،
تظهر رسالة التأكيد نفسها سواء كان العنوان مسجلاً أم لا.
AC2 بافتراض عنوان مسجل وموثّق، يُرسل رابط إعادة تعيين للاستخدام مرة واحدة
تنتهي صلاحيته بعد 30 دقيقة من إرساله. والطلب الجديد يُبطل كل الروابط السابقة.
AC3 يجب أن تستوفي كلمة المرور الجديدة SEC-12 وأن تختلف عن الحالية.
AC4 بعد نجاح إعادة التعيين تُنهى كل الجلسات القائمة ويُنقل العميل إلى
صفحة تسجيل الدخول مع رسالة نجاح.
AC5 للحساب غير الموثّق يُرسل بريد التوثيق بدلاً من رابط إعادة التعيين (BR-4).
AC6 خمسة طلبات إعادة تعيين كحد أقصى لكل حساب في الساعة. الطلبات الإضافية تُظهر
رسالة التأكيد نفسها ولا تُرسل شيئاً.
NFR1 يُرسل بريد إعادة التعيين بلغة الحساب (العربية أو الإنجليزية).
NFR2 يجتاز النموذج قائمة تحقق إمكانية الوصول لدى الفريق: حقول موسومة،
ورسائل خطأ يُعلَن عنها، وتشغيل كامل بلوحة المفاتيح.
NFR3 زمن الاستجابة: ينطبق الهدف العام للموقع PERF-2 (p95 أقل من ثانيتين عند إرسال
النماذج عند الحمل المرجعي المحدد في PERF-2)؛ ولم يحدد مالك المنتج
هدفاً خاصاً بهذه القصة.جرّبها: مولّد معايير القبول بالذكاء الاصطناعي جرّبها: مولّد معايير القبول
مراجعة المتطلبات غير الوظيفية
الاحتياجات غير الوظيفية أكثر ما يغيب عن القصص، لأن قالب القصة يسأل عن السلوك فقط. ويصف ISO/IEC 25010 خصائص جودة المنتج — ومنها كفاءة الأداء والأمان والموثوقية والتوافق وقابلية التفاعل (قابلية الاستخدام) — وهي قائمة تذكير مفيدة: لكل خاصية اسأل هل تؤثر فيها القصة، وإن كان كذلك فأين كُتب المعيار؟
- الأداء — رقم ونسبة مئوية وحمل: «زمن الاستجابة p95 أقل من ثانيتين عند 200 مستخدم متزامن» قابل للاختبار؛ و«سريع» ليس كذلك.
- الأمان والخصوصية — من يرى ماذا ومن يغيّره، وأي البيانات شخصية، ومدة الاحتفاظ بها، وما الذي يُسجَّل. ومعيار OWASP ASVS فهرس لمتطلبات أمنية قابلة للتحقق يمكن الاستعانة به.
- إمكانية الوصول — التشغيل بلوحة المفاتيح، والتسميات، والإعلان عن الأخطاء، والتباين، وعادةً بالإحالة إلى قائمة تحقق الفريق المبنية على WCAG.
- التوطين — اللغات، والتخطيط من اليمين إلى اليسار، وصيغ التاريخ والأرقام والعملة، واللغة التي تُكتب بها الرسائل والبريد.
- الموثوقية والتشغيل — السلوك عند تعطل إحدى التبعيات، وإعادة المحاولة، والمهل الزمنية، وما الذي يُراقَب ويُطلق التنبيهات.
كيف تساعد أدوات متقن للذكاء الاصطناعي — وأين تتوقف
أدوات الذكاء الاصطناعي مفيدة كمراجع إضافي سريع جداً في خطوة المراجعة الفردية. الصق قصة أو مجموعة متطلبات فتعيد ملاحظات مرشّحة في ثوانٍ؛ ثم تعامل مع كل اقتراح كمسودة تعليق تقبلها أو تعيد صياغتها أو تستبعدها. هي تصوغ المسودات، والقرار للإنسان.
وحدودها حدود أي مراجع بلا سياق. فهي لا تعرف وثائقك الأخرى ما لم تزوّدها بها، ولا القرارات المتخذة في اجتماع الأسبوع الماضي، ولا أنظمتك ولا مستخدميك؛ وقد تطرح فجوات أُجيب عنها في موضع آخر، أو تفوّت تناقضاً مع قاعدة لم ترها قط. اتبع سياسة مؤسستك فيما يجوز مشاركته مع خدمة خارجية، واستخدم بيانات مجهّلة أو خيالية في الأمثلة.
- AI Requirement Ambiguity Detector — يكتشف العبارات الغامضة أو المبهمة أو المتناقضة ويقترح أسئلة توضيحية؛ جولة أولى سريعة لملاحظات من نوع RC-01 وRC-02.
- AI Requirement Gap Analyzer — يبحث عن المتطلبات المفقودة مثل معالجة الأخطاء والصلاحيات والحالات الحدّية والاحتياجات غير الوظيفية؛ من نوع RC-03 وRC-04 وRC-08.
- AI Acceptance Criteria Reviewer — يراجع معايير القبول من حيث قابلية الاختبار والاكتمال والغموض، ويقترح صياغات بديلة يمكنك تكييفها.
- AI Acceptance Criteria Generator — يصوغ مسودة معايير Given/When/Then من قصة مستخدم، وهو مفيد حين تصل قصة بلا معايير.
- Requirements → Test Cases وAI Test Coverage Analyzer — الأولى تحوّل المتطلبات المرقّمة إلى حالات اختبار قابلة للتتبع مع مصفوفة ربط المتطلبات بالاختبارات؛ والثانية تقارن المتطلبات بحالات الاختبار الموجودة لإيجاد المناطق غير المختبرة.
جرّبها: كاشف غموض المتطلبات بالذكاء الاصطناعي جرّبها: محلّل فجوات المتطلبات بالذكاء الاصطناعي جرّبها: مراجع معايير القبول بالذكاء الاصطناعي
من المراجعة إلى تصميم الاختبارات
القصة المراجَعة أساس اختبار أفضل: كل معيار قبول يصبح شرط اختبار أو أكثر، ومسارات الخطأ المضافة في المراجعة تصبح حالات اختبار سلبية، والأرقام المحسومة في المراجعة (30 دقيقة، و5 طلبات في الساعة) تصبح قيماً حدّية. احتفظ بالربط بين كل اختبار والمعيار الذي يغطيه، كي يبيّن المعيار المعدَّل بالضبط أي الاختبارات تحتاج إلى تحديث. أما تحويل المعايير إلى حالات اختبار جيدة البنية فيشرحه دليل كتابة حالات الاختبار.
جرّبها: المتطلبات ← حالات اختبار جرّبها: محلّل تغطية الاختبار بالذكاء الاصطناعي جرّبها: قصة المستخدم ← سيناريوهات اختبار
الأسئلة الشائعة
متى يجب مراجعة المتطلبات؟
قبل بدء التطوير عليها — عادةً خلال تنقيح قائمة العمل، قبل قبول القصة في السبرنت — ومجدداً كلما تغيرت. ومراجعة المسودات المبكرة أرخص من مراجعة مواصفة مكتملة، لأن ما بُني على الصياغة أقل.
من يجب أن يشارك في مراجعة المتطلبات؟
على الأقل المؤلف (مالك المنتج أو محلل الأعمال) ومطور ومختبر. وأضف الأمان أو تجربة المستخدم أو العمليات أو خبير المجال حين تمسّ القصة مجالهم. فالمنظورات المختلفة تكشف عيوباً مختلفة.
كيف أجعل المتطلب قابلاً للاختبار؟
استبدل كل كلمة مبهمة بنتيجة قابلة للملاحظة، وبرقم حيث يلزم: من يفعل ماذا، وتحت أي شرط، وما الذي يفعله النظام بشكل مرئي. إن استطعت أن تكتب من الجملة النتيجة المتوقعة لحالة اختبار، فهي قابلة للاختبار.
ماذا لو لم يستطع مالك المنتج الإجابة عن سؤال المراجعة بعد؟
سجّله سؤالاً مفتوحاً له مالك وموعد، ولا تسِم القصة بالجاهزية ما دام يعطّل أحد المعايير. وإن كان على الفريق المضي قدماً، فاكتب الافتراض صراحةً في القصة كي يمكن اختباره والعودة إليه.
هل يمكن للذكاء الاصطناعي مراجعة المتطلبات بدلاً مني؟
تستطيع أدوات الذكاء الاصطناعي إنتاج قائمة أولى سريعة بالغموض والفجوات ومعايير القبول الضعيفة. لكنها تفتقر إلى سياق مجالك ووثائقك الأخرى وقراراتك، لذلك يجب أن يحكم إنسان على كل اقتراح. استخدمها كمراجع واحد بين عدة مراجعين، لا كالمراجعة نفسها.
هل كتابة معايير القبول هي نفسها مراجعة المتطلبات؟
لا. كتابة معايير القبول تحوّل المتطلب إلى عبارات قابلة للتحقق؛ والمراجعة تفحص المتطلب ومعاييره بحثاً عن العيوب. وكثيراً ما تنتج المراجعة معايير أفضل، والمعايير الجديدة يجب أن تُراجَع هي الأخرى.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISO/IEC 20246:2017 — Software and systems engineering — Work product reviewsإطار عام لمراجعة مخرجات العمل — عملية المراجعة وأدوارها وتقنياتها.
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelنموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)أرباع الاختبار الرشيق وكيف يعمل المختبرون داخل فريق التسليم — أساس «الاختبار في الطبقة الصحيحة».
- OWASP Application Security Verification Standard (ASVS)قائمة تحقق بمتطلبات أمنية قابلة للتحقق لتطبيقات الويب، مصنّفة في ثلاثة مستويات ضمان.
تمرين عملي
راجع قصة مستخدم لحجز المواعيد في مراكز الخدمة
تضيف بوابة خدمات بلدية (خيالية) حجز المواعيد إلكترونياً في مراكز الخدمة التابعة لها. وقصة المستخدم US-77 تُعرض غداً في جلسة تنقيح قائمة العمل (Backlog refinement)، وأنت المختبِر في مراجعة «الأصدقاء الثلاثة» (Three amigos) مع مالك المنتج ومطوّر. تجد أدناه القصة، وسياسة المواعيد المعتمدة POL-APPT التي يجب أن تلتزم بها، وملاحظة عن مصدر بيانات الفترات المتاحة.
نفّذ خطوة المراجعة الفردية كما في الدليل: اقرأ وحدك بقائمة التحقق ذات المعايير الثمانية قبل أي نقاش. اكتب ستة تعليقات مراجعة على الأقل بصيغة المثال العملي في الدليل — المعرّف، والمعيار ودرجة الخطورة: رئيسية (Major) أو ثانوية (Minor) أو سؤال (Question)، والموضع، وما الخطأ ولماذا يهم، ومقترح أو سؤال، ومن يجب أن يقرر — تغطي خمسة معايير على الأقل من الثمانية. ثم أعد صياغة ثلاثة معايير قبول على الأقل من التي تلقت ملاحظة رئيسية، وأضف المعايير التي تكشف المراجعة أنها مفقودة، واكتب الأسئلة المفتوحة مع مالك لكل منها، وحدّد القيم الحدّية التي تنشأ عن الأرقام بعد المراجعة. اقترح القيم حيث تحتاج إليها، لكن ضع عليها علامة للتأكيد: المراجِع يقترح، ومالك المنتج يقرر.
تكفي الورقة والقلم؛ وخصّص لذلك نحو 30 دقيقة. وإن أردت مراجعاً ثانياً بعد ذلك، فالصق القصة والسياسة في أداة «كاشف غموض المتطلبات بالذكاء الاصطناعي» من قائمة أدوات الدليل (تتطلب تسجيل الدخول)، واحكم أنت على كل اقتراح، ولا تفعل ذلك إلا بعد جولتك الخاصة.
بوابة خدمات بلدية (خيالية)، يستخدمها المستفيدون بعد تسجيل الدخول إلى حساباتهم.
بيانات الفترات المتاحة تأتي من نظام إدارة الطوابير في مراكز الخدمة، وتشغّله جهة
موردة أخرى، وتقرؤها البوابة عبر واجهة API الخاصة بالمورّد.
US-77 حجز موعد في مركز خدمة
بصفتي مستفيداً
أريد حجز موعد في مركز خدمة عبر الإنترنت
كي لا أنتظر في الطابور.
AC1 يختار المستفيد خدمةً ومركزاً وتاريخاً وفترة زمنية، ويتلقى تأكيداً.
AC2 يُتاح حجز الموعد قبل تاريخه بمدة تصل إلى 60 يوماً.
AC3 يستطيع المستفيد إلغاء الموعد أو إعادة جدولته في أي وقت.
AC4 ينبغي أن يتلقى المستفيد تذكيراً قبل الموعد.
AC5 تُحدَّث الفترات المتاحة في الوقت الحقيقي.
AC6 يستطيع المستفيد أيضاً الحجز لأفراد أسرته، إلخ.
AC7 يجب أن تكون صفحة الحجز سريعة وأن تعالج طلبات عدد كبير من المستخدمين.
POL-APPT سياسة المواعيد (معتمدة، ويملكها فريق العمليات في المراكز)
R1 يُحجز الموعد قبل تاريخه بمدة من يوم واحد إلى 30 يوماً، ولا يُتاح الحجز
لليوم نفسه.
R2 لا يكون للشخص أكثر من موعد نشط واحد للخدمة الواحدة.
R3 يُسمح بإلغاء الموعد أو نقله حتى 24 ساعة قبل بدايته. وبعد ذلك يبقى
الموعد محجوزاً، ويُحتسب تغيّباً إن لم يحضر صاحبه.
R4 ثلاث حالات تغيّب خلال 90 يوماً توقف الحجز الإلكتروني مدة 30 يوماً.- ابحث في القصة عن الكلمات المنذرة الواردة في جدول الدليل، وضع علامة على كل واحدة منها.
- اقرأ القصة جنباً إلى جنب مع القواعد من R1 إلى R4 في POL-APPT ومع الملاحظة عن مصدر بيانات الفترات. ضع علامة على كل تناقض، وكل قاعدة تتجاهلها القصة، وكل شيء يُسمّى باسمين.
- مرّ على معايير قائمة التحقق الثمانية واحداً واحداً. لكل معيار اكتب ملاحظة، أو سطراً قصيراً يفيد أنك فحصته ولم تجد شيئاً.
- اكتب كل ملاحظة تعليقَ مراجعة واحداً: المعرّف، والمعيار ودرجة الخطورة، والموضع، وما الخطأ ولماذا يهم، ومقترح أو سؤال، ومن يقرر.
- أعد صياغة ثلاثة معايير قبول على الأقل من التي تلقت ملاحظة رئيسية، بحيث تكون لكل منها نتيجة قابلة للملاحظة بنجاح أو فشل واضح، وأضف المعايير التي تشترطها السياسة وتفتقدها القصة، واكتب الأسئلة المفتوحة مع مالك وموعد لكل منها.
- اكتب القيم الحدّية التي تنشأ عن الأرقام في القصة بعد المراجعة — عدد الأيام مقدماً (R1)، ومهلة الساعات الأربع والعشرين (R3)، وقاعدة التغيّب (R4). ولكل حدّ، اكتب آخر قيمة مسموح بها وأول قيمة غير مسموح بها، مع النتيجة المتوقعة لكل منهما. ويمكنك التحقق من مجموعتك للقاعدة R1 بأداة «تحليل القيم الحدّية».
إظهار الإجابة النموذجية
الكلمات المنذرة (الخطوة 1): «في أي وقت» في AC3 صيغة مقنّعة من «دائماً»: ما الاستثناءات؟ والقاعدة R3 تذكر واحداً منها. و«ينبغي» في AC4: إلزامي أم اختياري؟ وعبارة «قبل الموعد» في AC4 كمية مبهمة: قبله بكم؟ و«في الوقت الحقيقي» في AC5: خلال كم ثانية؟ و«إلخ» في AC6: ما القائمة الكاملة؟ وفي AC7: «سريعة» (ما مدى السرعة، وعند أي نسبة مئوية، وتحت أي حمل؟)، و«تعالج» (ما السلوك القابل للملاحظة؟)، و«عدد كبير من المستخدمين» (كم بالضبط؟). ولا واحدة منها معرّفة في موضع آخر، لذلك تقود كلٌّ منها إلى ملاحظة أدناه.
تعليقات المراجعة أدناه، تعليق في كل فقرة. قد تختلف معرّفاتك وصياغتك ودرجات الخطورة لديك؛ وستة منها أو أكثر تغطي خمسة معايير على الأقل إجابة كاملة. RC-01 [اتساق · رئيسية] AC2: «تصل إلى 60 يوماً» تناقض القاعدة R1 في POL-APPT (من يوم واحد إلى 30 يوماً، ولا حجز لليوم نفسه). والسياسة معتمدة، لذا يُقترح مواءمة AC2 مع R1. @مالك_المنتج ومالك السياسة (العمليات): أيهما الساري، وهل هي أيام تقويمية أم أيام عمل؟
RC-02 [اتساق · رئيسية] AC3: «في أي وقت» تناقض R3 (حتى 24 ساعة قبل البداية فقط). مقترح: زرّا «إلغاء» و«إعادة جدولة» متاحان حتى 24 ساعة قبل البداية، ثم يُعطَّلان مع رسالة تشرح القاعدة. @مالك_المنتج
RC-03 [صحة · سؤال] AC2 + AC3 (R1 + R3): المستفيد الذي يحجز في الساعة 22:00 موعداً في الساعة 08:00 من اليوم التالي يكون داخل الساعات الأربع والعشرين السابقة للموعد لحظة الحجز. فلا يستطيع الإلغاء ولا إعادة الجدولة أبداً، وإن لم يحضر احتُسب التغيّب ضمن إيقاف R4. هل هذا ما يريده العمل؟ خيارات أمام @مالك_المنتج، مثلاً: احتساب «يوم واحد مقدماً» على أنه 24 ساعة مقدماً على الأقل، أو السماح بالإلغاء خلال مدة قصيرة بعد الحجز.
RC-04 [قابلية الاختبار · رئيسية] AC4: «ينبغي» و«قبل الموعد» لا تعطيان نجاحاً أو فشلاً: هل التذكير إلزامي، وقبل الموعد بكم، وبأي قناة، وماذا يحدث بعد الإلغاء أو إعادة الجدولة؟ مقترح: «تُرسل رسالة نصية (SMS) للتذكير قبل البداية بـ48 ساعة؛ ولا تُرسل لموعد ملغى، والموعد المعاد جدولته يتلقى تذكيره بحسب وقته الجديد». والمقترح 48 ساعة لا 24، لأن التذكير المرسل قبل البداية بـ24 ساعة يصل في اللحظة نفسها التي يتوقف فيها الإلغاء بموجب R3، فيفوت الأوان على مستفيد علم للتو أنه لن يستطيع الحضور. @مالك_المنتج هل 48 ساعة عبر SMS مناسبة؟
RC-05 [قابلية التنفيذ · سؤال] AC5: الفترات تأتي من نظام الطوابير لدى المورّد، وهو خارج سيطرة الفريق، و«في الوقت الحقيقي» غير قابلة للقياس. هل تستطيع واجهة API لدى المورّد الإبلاغ عن التغييرات خلال عدد محدد من الثواني، وهل تستطيع حجز الفترة لحظة التأكيد؟ وماذا يرى المستفيد حين لا تستجيب هذه الواجهة؟ @قائد_التطوير يتأكد من المورّد قبل وسم القصة بالجاهزية.
RC-06 [اكتمال · رئيسية] AC1 وAC3 وAC5: لا تحدد القصة ما يحدث حين يأخذ شخص آخر الفترة المختارة بين اختيارها وتأكيدها، ولا حين يُضغط زر «تأكيد» مرتين، ولا هل تُفرج إعادة الجدولة عن الفترة القديمة قبل تأكيد الجديدة أم بعده. مقترح: لا تُحجز الفترة إلا عند التأكيد؛ وإن لم تعد متاحة يرى المستفيد رسالة «لم تعد هذه الفترة متاحة» والقائمة المحدّثة؛ والتأكيد الواحد ينشئ موعداً واحداً بالضبط؛ وتبقى الفترة القديمة محجوزة إلى أن تُؤكَّد الجديدة. @مالك_المنتج
RC-07 [غموض · رئيسية] AC6: «لأفراد أسرته، إلخ» لا تحدد أي صلات القرابة تُقبل، ولا كيف يُتحقق من الصلة، ولا موعدَ من يُحتسب بموجب R2، ولا من يتلقى التأكيد والتذكير، ولا من يحق له الإلغاء. @مالك_المنتج اذكر صلات القرابة والقواعد.
RC-08 [غير وظيفي · رئيسية] AC6: الحجز لشخص آخر يعني معالجة بياناته الشخصية. من يحق له رؤية مواعيده وبياناته، وهل تلزم موافقته؟ @الخصوصية تقرر قبل أن يمكن كتابة المعيار.
RC-09 [اكتمال · رئيسية] القصة: القاعدتان R2 وR4 غائبتان. ماذا يرى مستفيد لديه موعد نشط للخدمة نفسها، أو مستفيد موقوف بعد ثلاث حالات تغيّب؟ مقترح: يُرفض الحجز برسالة تذكر الموعد القائم (R2) أو تاريخ انتهاء الإيقاف (R4). وغائب أيضاً: ما الذي يظهر حين لا توجد أي فترة متاحة في نافذة الحجز كلها، وهل تُعرض الأيام التي يكون فيها المركز مغلقاً. @مالك_المنتج
RC-10 [غير وظيفي · رئيسية] AC7: «سريعة» و«تعالج طلبات عدد كبير من المستخدمين» متطلبان، وكلاهما غير قابل للقياس. مقترح: هدف لزمن الاستجابة برقم ونسبة مئوية وحمل، مثل «p95 أقل من ثانيتين عند ذروة الحمل المتوقعة». @مالك_المنتج و@العمليات: كم ذروة الحمل المتوقعة، ومتى تحدث؟
RC-11 [غير وظيفي · ثانوية] القصة: خدمة عامة بلا معايير للتوطين ولا لإمكانية الوصول، ولا إشارة إلى الموضع الذي حُسمت فيه. بأي لغة يُرسل التأكيد والتذكير (لغة الحساب؟)، وكيف تُعرض التواريخ والأوقات، وهل يجتاز منتقي الفترات قائمة تحقق إمكانية الوصول لدى الفريق (التشغيل بلوحة المفاتيح، والحقول الموسومة، والإعلان عن الأخطاء)؟ @مالك_المنتج
RC-12 [قابلية التتبع · ثانوية] القصة: غير مرتبطة بملحمتها ولا بالقواعد من R1 إلى R4 في POL-APPT. أضف الروابط كي ترتبط حالات الاختبار بالقواعد التي تتحقق منها، وكي يبيّن أي تعديل في السياسة القصةَ والاختبارات التي تحتاج إلى تحديث.
RC-13 [اتساق · ثانوية] AC3 وR3: القصة تقول «إعادة جدولة» حيث تقول السياسة «نقل». يجب أن يكون للإجراء الواحد اسم واحد في القصة والشاشات والسياسة، وإلا وصفته حالات الاختبار وتقارير العيوب بطريقتين. مقترح: استخدام «إعادة جدولة» والتنويه في القصة بأنها «النقل» الوارد في R3. @مالك_المنتج مع مالك السياسة
معايير القبول بعد إعادة الصياغة (الخطوة 5؛ ثلاثة منها أو أكثر إجابة كاملة، والقيم الموسومة بكلمة «مقترح» تنتظر قرار مالك المنتج): AC1 بافتراض مستفيد مسجّل الدخول، عندما يختار خدمةً ومركزاً وتاريخاً وفترة متاحة ويؤكد، يُنشأ موعد واحد بالضبط، ويظهر تأكيد فيه رقم مرجعي والمركز والتاريخ والوقت، ويُرسل برسالة نصية (القناة مقترحة). AC2 لا تُعرض للاختيار إلا التواريخ من يوم واحد إلى 30 يوماً تقويمياً بعد اليوم (R1؛ الأيام التقويمية مقترحة)؛ ولا يُعرض اليوم نفسه ولا أي تاريخ بعد 30 يوماً. AC3 زرّا «إلغاء» و«إعادة جدولة» (وتسمّيها R3 «نقلاً») متاحان حتى 24 ساعة قبل البداية، ثم يُعطَّلان وتشرح الصفحة القاعدة. وإعادة الجدولة تُبقي الموعد نفسه برقمه المرجعي، ولا تُفرج عن الفترة القديمة إلا بعد تأكيد الجديدة. AC4 تُرسل رسالة نصية للتذكير قبل البداية بـ48 ساعة، أي حين يكون الإلغاء ما زال مسموحاً بموجب R3، بلغة الحساب، وبحسب الوقت الجديد بعد إعادة الجدولة؛ والموعد المحجوز قبل بدايته بأقل من 48 ساعة لا يتلقى تذكيراً منفصلاً، والموعد الملغى لا يتلقى أي تذكير (مقترح). AC5 تُحجز الفترة عند التأكيد؛ وإن أُخذت في الأثناء تظهر رسالة «لم تعد هذه الفترة متاحة» والقائمة المحدّثة، ولا يُنشأ موعد. أما المدة التي يظهر خلالها تغيير نظام الطوابير في القائمة فهي الرقم الذي يؤكده المورّد (RC-05).
معايير تضيفها المراجعة أو تنقلها: AC8 المستفيد الذي لديه موعد نشط للخدمة نفسها لا يستطيع حجز موعد آخر لها، وتذكر الرسالة الموعد القائم وتعرض إعادة جدولته (R2). AC9 المستفيد الموقوف بموجب R4 لا يستطيع الحجز، ويرى تاريخ انتهاء الإيقاف. AC10 حين لا يستجيب نظام الطوابير، تبيّن الصفحة أن الحجز غير متاح مؤقتاً، ولا يُنشأ موعد (الصياغة مقترحة، بعد الإجابة عن RC-05). ويخرج AC6 من هذه القصة: يصبح الحجز لأفراد الأسرة قصة مستقلة بعد الإجابة عن RC-07 وRC-08، لأن «إلخ» لا يمكن اختبارها. ويصبح AC7 المتطلب NFR1، وهو هدف لزمن الاستجابة بالأرقام التي يحددها مالك المنتج والعمليات، ويغطي NFR2 اللغة (التأكيد والتذكير وصيغ التاريخ والوقت) وقائمة تحقق إمكانية الوصول لدى الفريق. وأضف الروابط المذكورة في RC-12.
الأسئلة المفتوحة، ولكل منها مالك وموعد. وفي هذه الإجابة موعد كل سؤال قبل جلسة التنقيح التالية، باستثناء Q4 الذي يحدد قائد التطوير موعده مع المورّد، وQ3 الذي ينتقل مع AC6 إلى القصة الجديدة الخاصة بالحجز لأفراد الأسرة. Q1 @مالك_المنتج والعمليات: 30 أم 60 يوماً، وأيام تقويمية أم أيام عمل (RC-01). Q2 @مالك_المنتج: الحجوزات التي تتم قبل الموعد بأقل من 24 ساعة (RC-03)، وهل يُسمح بالإلغاء قبل البداية بـ24 ساعة تماماً (R3). Q3 @مالك_المنتج و@الخصوصية: الحجز لأفراد الأسرة (RC-07 وRC-08). Q4 @قائد_التطوير مع المورّد: مدى حداثة بيانات الفترات، وحجز الفترة عند التأكيد، والسلوك حين تتعطل واجهة المورّد (RC-05). Q5 @العمليات: ذروة الحمل المتوقعة (RC-10). Q6 @مالك_المنتج: قناة التذكير وتوقيته (RC-04). Q7 @مالك_المنتج والعمليات: هل يدخل اليومان الأول والأخير في نافذة الأيام التسعين وفي الإيقاف الممتد 30 يوماً (R4)؟ وما دام سؤال بلا جواب، تبقى المعايير التي تعتمد عليه موسومة بكلمة «مقترح»، ولا تُوسم القصة بالجاهزية؛ وإن كان على الفريق المضي قدماً، يُكتب الافتراض صراحةً في القصة.
القيم الحدّية (الخطوة 6): عدد الأيام مقدماً وفق R1: 0 (اليوم نفسه، لا يُعرض) و1 (يُعرض) عند الحد الأدنى، و30 (يُعرض) و31 (لا يُعرض) عند الحد الأعلى. وسيحوّل درس تحليل القيم الحدّية في وحدة تصميم الاختبار هذا إلى تقنية كاملة. والساعات قبل البداية وفق R3، بدقة الدقيقة: 24 ساعة ودقيقة (الإلغاء مسموح)، و23 ساعة و59 دقيقة (مرفوض)، و24 ساعة تماماً، ونتيجتها المتوقعة هي جواب Q2؛ واختبار القيم الثلاث يغطي القراءتين إلى أن يُجاب عن Q2. وعدد المواعيد النشطة للخدمة نفسها وفق R2: 0 (يُسمح بالحجز) و1 (مرفوض)؛ واختبر أيضاً موعداً نشطاً لخدمة أخرى (يُسمح بالحجز) — وهذه ليست قيمة حدّية، لكنها أرجح سوء فهم للقاعدة R2. وحالات التغيّب وفق R4: حالتان خلال 90 يوماً (لا إيقاف)، وثلاث حالات (إيقاف). وأطراف نافذة الأيام التسعين (أقدم تغيّب وقع قبل 90 يوماً تماماً) وأطراف الإيقاف (يومه الأخير واليوم الذي يليه) حدود أيضاً، ونتائجها المتوقعة تنتظر جواب Q7.
راجع عملك: المهم أنك وجدت التناقضين مع POL-APPT (AC2 مع R1، وAC3 مع R3) وقاعدة واحدة على الأقل تتجاهلها القصة (R2 أو R4)؛ وأن كل تعليق يحمل ملاحظة واحدة بموضعها وسببها ومقترح أو سؤال ومن يقرر؛ وأنك اقترحت الأرقام دون أن تحسمها؛ وأنك تستطيع اليوم أن تكتب النتيجة المتوقعة لحالة اختبار من كل معيار أعدت صياغته. وإن فاتتك RC-03، فاقرأ R1 وR3 معاً مرة أخرى: بعض العيوب لا يظهر إلا حيث تلتقي قاعدتان تبدو كل منهما صحيحة. وإن استخدمت أداة ذكاء اصطناعي أيضاً، فتحقق هل وجدت التناقضين مع السياسة: فهي لا ترى POL-APPT ما لم تلصقها مع القصة.
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.
جزء من مسار تعلم ضمان الجودة
قبل هذا الموضوع
الموضوعات التالية
الأدوات المذكورة في هذا الدليل
اكتشف العبارات الغامضة أو المبهمة أو المتناقضة في المتطلبات واحصل على أسئلة توضيحية من الذكاء الاصطناعي من متقن.
اعثر على المتطلبات المفقودة — معالجة الأخطاء والصلاحيات والظروف الحدّية والاحتياجات غير الوظيفية — باستخدام الذكاء الاصطناعي من متقن.
راجع معايير القبول من حيث قابلية الاختبار والاكتمال والغموض، مع اقتراحات صياغة معاد كتابتها من الذكاء الاصطناعي من متقن.
ولّد معايير قبول واضحة بصيغة Given/When/Then من قصة مستخدم باستخدام الذكاء الاصطناعي من متقن.
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
قارن المتطلبات أو قصة مستخدم بحالات الاختبار الموجودة للعثور على المجالات غير المختبَرة، باستخدام الذكاء الاصطناعي من متقن.
ولّد معايير قبول بصيغة Given/When/Then وقائمة تحقق لتعريف الإنجاز (Definition of Done) من قصة مستخدم.
حلّل عقد OpenAPI بحثاً عن مخاطر التصميم: تسمية غير متسقة، واستجابات خطأ مفقودة، ومصادقة ضعيفة، ومخاطر التغييرات الكاسرة، وفجوات التقسيم إلى صفحات والتحقق.
اشتق سيناريوهات اختبار شاملة (end-to-end) من قصة مستخدم، بما فيها التدفقات البديلة والاستثنائية.