هندسة المتطلبات Requirements Engineering من الطلب إلى ما يبنى

يصلك من العميل سطر واحد في رسالة: «نبغى نظام حجز مواعيد لعيادتنا»، فيفهم كل شخص في الفريق السطر بطريقته، ويبدأ المطور في بناء ما تخيله، وبعد شهرين من العمل يجلس الجميع في اجتماع العرض فيقول العميل الجملة التي يعرفها كل مطور: «ليس هذا ما طلبناه»، والمشكلة هنا ليست في الكود، فقد يكون الكود نظيفاً ومختبراً، وإنما في أن أحداً لم يسأل ماذا يحتاج العميل فعلاً، وما الذي يقصده بكلمة «حجز»، ومن الذي سوف يستخدم النظام كل يوم، وما الذي يحدث إذا ألغى المريض قبل موعده بساعة. وهذا السؤال المنظم له اسم في هندسة البرمجيات هو هندسة المتطلبات Requirements Engineering، وهو أول ما يحدث في أي مشروع حتى لو لم يسمه الفريق بهذا الاسم.

وهذا المقال هو بداية مرحلة «معمارية البرمجيات وتصميمها» في خارطة الطريق، لأن المعمارية كلها تبنى على المتطلبات، وخصوصاً المتطلبات غير الوظيفية كما شرحنا في خصائص الجودة Quality Attributes، ويتبعه مقال عملي يأخذ طلب العيادة نفسه ويحوله خطوة بخطوة إلى متطلبات مكتوبة مع قوالب جاهزة للنسخ. وسوف نناقش في هذا المقال ما يلي:

• لماذا يفشل كثير من المشاريع قبل أن يكتب سطر كود واحد، وما الذي يختفي تحت كلام العميل.
• ما هو المتطلب Requirement، والفرق بين الحاجة Need والحل Solution.
• مستويات المتطلبات وأنواعها: الوظيفية Functional وغير الوظيفية Non-functional والقيود Constraints والافتراضات Assumptions.
• أصحاب المصلحة Stakeholders: من تسأل، ومن يقرر.
• أنشطة هندسة المتطلبات كما يصفها المعيار ISO/IEC/IEEE 29148:2018 ودليل SWEBOK v4: الجمع والتحليل والتوثيق والتحقق والإدارة.
• طرق جمع المتطلبات Elicitation Techniques، ومتى تنجح كل طريقة ومتى تفشل.
• صيغ كتابة المتطلبات: وثيقة SRS وقصص المستخدم User Stories ومعايير القبول Acceptance Criteria بصيغة Given/When/Then وحالات الاستخدام Use Cases.
• ترتيب الأولويات بطريقة MoSCoW ونموذج Kano، وتتبع المتطلبات Traceability، وإدارة التغيير وزحف النطاق Scope Creep.
• هندسة المتطلبات في Agile وفي المشاريع المخططة مسبقاً Plan-driven.
• المشكلات الشائعة وحلولها، وثلاث قصص موثقة من تقارير رسمية لمشاريع حكومية كبيرة فشلت بسبب المتطلبات.

لماذا يفشل المشروع قبل أن يكتب سطر كود واحد؟

عندما يقول العميل «نبغى نظام حجز مواعيد» فهو يذكر لك جزءاً صغيراً مما في ذهنه، والباقي إما أنه يعتبره بديهياً فلا يذكره، مثل أن الموعد الواحد لا يحجزه مريضان، وإما أنه لم يفكر فيه أصلاً، مثل ما الذي يحدث لمواعيد الطبيب إذا أخذ إجازة مفاجئة، أو من يحق له رؤية رقم جوال المريض. ويصف دليل SWEBOK هذه الحالة بوضوح عندما يقول إن كثيراً من متطلبات المنتج ضمنية Tacit، أو موجودة في معلومات لم تجمع بعد، وإن المستخدمين قد يجدون صعوبة في وصف عملهم ويتركون معلومات مهمة دون أن يقولوها، لذلك فجمع المتطلبات ليس نشاطاً سلبياً تنتظر فيه أن يملي عليك العميل ما يريد، وإنما عمل تبحث فيه بنفسك.

والصورة التالية تبين الفكرة بشكل جبل الجليد: ما يقوله العميل في الاجتماع الأول هو القمة فقط، وتحت الماء قواعد العمل Business Rules والاستثناءات Exceptions وخصائص الجودة Quality Attributes وأصحاب المصلحة الذين لم يحضروا الاجتماع والامتثال Compliance والتكامل Integration مع الأنظمة الأخرى وترحيل البيانات Data Migration القديمة والافتراضات التي لم يكتبها أحد:

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

ما هو المتطلب Requirement؟

التعريف الرسمي الذي ينقله دليل SWEBOK v4 من معايير IEEE أن المتطلب هو شرط أو قدرة يحتاجها المستخدم ليحل مشكلة أو يحقق هدفاً، أو شرط أو قدرة يجب أن يملكها النظام ليفي بعقد أو معيار أو مواصفة، أو الوصف المكتوب لأي منهما، ويضيف الدليل إلى هذا التعريف احتياجات المشروع وقيوده. وبكلام أبسط، المتطلب جملة تقول ما يجب أن يكون صحيحاً في النظام حتى يعتبر صاحب العمل أن مشكلته حلت، مثل «لا يمكن أن يحجز مريضان نفس الموعد مع نفس الطبيب».

الحاجة Need أم الحل Solution؟

أكثر ما يربك الفرق أن العميل نادراً ما يتكلم بلغة الحاجة، وإنما يتكلم بلغة الحل الذي تخيله: «نبغى زر يصدر المواعيد إلى Excel»، «نبغى تطبيق جوال»، «نبغى لوحة تحكم Dashboard». وهذه الجمل ليست متطلبات بعد، وإنما حلول مقترحة، والمتطلب الحقيقي خلفها. ويذكر SWEBOK في قسم تحليل المتطلبات أن بعض ما يجمع من أصحاب المصلحة يكون حلاً يراد تنفيذه وليس المشكلة الحقيقية، وأن هذا يعرض الفريق لبناء حل أضعف من الممكن، ويقترح تقنية لماذا الخمسة 5 Whys: تكرر السؤال «لماذا هذا المتطلب؟» حتى تصل إلى إجابة معناها «إذا لم يحدث هذا فمشكلة صاحب العمل لم تحل»، ويقول إن المشكلة الحقيقية تظهر غالباً بعد دورتين أو ثلاث.

الصورة التالية تبين مثالاً من العيادة: طلب العميل زر تصدير إلى Excel، وبعد سؤالين ظهر أن الحاجة الحقيقية هي أن يعرف كل طبيب مواعيد يومه وتغييراتها فوراً، وعندها ظهرت حلول أخرى أفضل من الزر:

لاحظ أن الهدف ليس أن ترفض ما طلبه العميل، فقد يكون التصدير إلى Excel هو الحل الأنسب في النهاية لأنه الأرخص، وإنما أن يكون الاختيار بين الحلول قراراً واعياً بعد أن تعرف الحاجة، وليس أول ما خطر على بال شخص في الاجتماع.

مستويات المتطلبات وأنواعها Levels and Types

المتطلبات تكتب على أكثر من مستوى، وكل مستوى يجيب عن سؤال مختلف ويقرؤه شخص مختلف، ويفرق المعيار ISO/IEC/IEEE 29148:2018 بين ثلاث وثائق لهذه المستويات: مواصفة متطلبات أصحاب المصلحة Stakeholder Requirements Specification واختصاراً StRS، ومواصفة متطلبات النظام System Requirements Specification واختصاراً SyRS، ومواصفة متطلبات البرمجيات Software Requirements Specification واختصاراً SRS. وفي مشروع صغير لا تحتاج ثلاث وثائق، ولكن تحتاج أن تعرف المستويات الثلاثة حتى لا تخلط بينها:

• متطلبات العمل Business Requirements: لماذا يدفع العميل في هذا المشروع أصلاً؟ «تقليل المكالمات الهاتفية على الاستقبال»، «تقليل المواعيد الضائعة التي لا يحضر أصحابها».
• متطلبات أصحاب المصلحة Stakeholder Requirements: ماذا يحتاج كل طرف من النظام؟ المريض يريد أن يحجز في أي وقت دون اتصال، والطبيب يريد أن يعرف جدوله، والاستقبال يريد أن يحجز لمن يتصل.
• متطلبات النظام والبرمجيات System and Software Requirements: ماذا يفعل البرنامج بالتحديد؟ «يعرض النظام الأوقات المتاحة للطبيب خلال الثلاثين يوماً القادمة فقط».

وداخل هذه المستويات تجد أنواعاً من المتطلبات، وأهمها:

• المتطلبات الوظيفية Functional Requirements: ماذا يفعل النظام، مثل الحجز والإلغاء والتذكير.
• المتطلبات غير الوظيفية Non-functional Requirements: كيف يجب أن يفعله، أي الأداء والتوافرية والأمن وسهولة الاستخدام وغيرها، وقد شرحنا في خصائص الجودة Quality Attributes قائمتها في نموذج ISO/IEC 25010 ولماذا يجب أن تكتب برقم يمكن قياسه وليس بكلمة، ولن نكررها هنا. ويسمي SWEBOK v4 جزءاً منها قيود جودة الخدمة Quality of Service Constraints.
• قواعد العمل Business Rules: قواعد تأتي من طبيعة العمل وليس من البرنامج، مثل «لا يحجز المريض أكثر من موعد واحد مفتوح مع نفس الطبيب»، وهي تعيش أطول من أي نظام يطبقها.
• القيود Constraints: قرارات محسومة قبل أن تبدأ، ويسميها SWEBOK قيود التقنية Technology Constraints، مثل «يجب أن يعمل النظام على سيرفرات داخل المملكة» أو «يجب أن يتكامل مع نظام الفوترة الحالي»، وأيضاً القيود القانونية والتنظيمية، والميزانية والموعد.
• الافتراضات Assumptions والاعتماديات Dependencies: أشياء نعتبرها صحيحة دون أن نتأكد منها، مثل «كل مريض لديه رقم جوال سعودي يستقبل الرسائل»، وكل افتراض غير مكتوب هو خطر غير مكتوب، لذلك اكتب كل افتراض ومن سوف يتأكد منه ومتى.

وقد يتساءل البعض: لماذا هذا التفصيل في الأنواع إذا كان الكل في النهاية سوف يتحول إلى كود؟ والإجابة أن كل نوع يعامل بطريقة مختلفة: المتطلب الوظيفي يتحول إلى قصة User Story وتختبره بسيناريو Scenario، وغير الوظيفي يحدد المعمارية ويختبر بالقياس مثل اختبار الأحمال Load Testing، والقيد لا يناقش وإنما يحترم، والافتراض يجب أن يتحقق منه أحد قبل أن يبنى عليه شيء، وإذا خلطت بينها فسوف تجد نفسك تناقش قيداً قانونياً كأنه رغبة، أو تبني على افتراض كأنه حقيقة.

أصحاب المصلحة Stakeholders: من تسأل ومن يقرر؟

صاحب المصلحة هو كل شخص أو جهة تتأثر بالنظام أو تؤثر فيه، ويعدد SWEBOK v4 أصنافاً منهم يسهل نسيانها: العملاء Clients الذين يدفعون، ومن يقرر هل يدخل المنتج الخدمة، والمستخدمون الذين يتعاملون معه مباشرة أو بشكل غير مباشر، وخبراء المجال Subject Matter Experts، وفريق التشغيل، والدعم الفني، والجهات التنظيمية Regulatory Agencies، والناس الذين قد يتضررون إذا نجح المشروع، والمطورون أنفسهم. ويقترح الدليل أن تعمل بأصناف من أصحاب المصلحة Stakeholder Classes بدل الأشخاص الأفراد، وأن تحلل أصحاب المصلحة في بداية المشروع حتى لا تميل المتطلبات نحو الطرف الأعلى صوتاً على حساب الطرف الغائب.

وأهم قاعدة هنا أن من يوقع العقد ليس بالضرورة من يستخدم النظام، فمالك العيادة يعرف أهداف العمل، لكن موظفة الاستقبال هي التي تعرف أن ثلث المكالمات في الصباح لتغيير موعد وليس لحجز جديد، وأن بعض كبار السن يحجز لهم أبناؤهم، وهذه المعلومات لن تسمعها من المالك أبداً. وسوف نرسم في المقال العملي خريطة أصحاب المصلحة Stakeholder Map للعيادة كاملة، ونحدد من نشركه في كل قرار ومن نكتفي بإبلاغه.

أنشطة هندسة المتطلبات Requirements Engineering Activities

المرجعان الأساسيان في هذا الموضوع هما المعيار الدولي ISO/IEC/IEEE 29148:2018، وعنوانه «هندسة النظم والبرمجيات، عمليات دورة الحياة، هندسة المتطلبات»، وهو يحدد العمليات المطلوبة لهندسة المتطلبات والوثائق التي تنتج عنها ومحتوى كل وثيقة، وصدر الإصدار الثاني منه في نوفمبر 2018 وتعمل ISO الآن على مراجعته، ودليل SWEBOK v4 الذي تنشره جمعية IEEE Computer Society، والفصل الأول فيه مخصص لمتطلبات البرمجيات Software Requirements، ويمكنك تنزيله كاملاً من ملف PDF الرسمي. ويقسم الدليل العمل إلى جزأين: تطوير المتطلبات Requirements Development، أي الجمع والتحليل والتوثيق والتحقق، ويصفه بأنه «الوصول إلى اتفاق على ما سيبنى»، وإدارة المتطلبات Requirements Management التي يصفها بأنها «المحافظة على هذا الاتفاق مع الوقت». والصورة التالية تبين الأنشطة الخمسة كدورة وليس كخط مستقيم:

جمع المتطلبات Elicitation

هو استخراج المتطلبات من مصادرها: الناس والوثائق والأنظمة الحالية والأنظمة المنافسة والقوانين، وكلمة Elicitation نفسها تعني أنك تستخرج شيئاً لا يقدم إليك جاهزاً، لذلك لن تحصل عليها من اجتماع واحد تسأل فيه «ماذا تريدون؟». وسوف نعرض طرقها في القسم التالي بالتفصيل.

التحليل Analysis

ما يجمع لا يأتي بصيغته النهائية أبداً، والتحليل هو أن تفهم كل متطلب وأثره وعلاقته بغيره، وأن تحل التعارض Conflict بين أصحاب المصلحة، فالطبيب يريد فترة راحة بين كل موعدين، والمالك يريد أكبر عدد من المواعيد في اليوم، والقرار هنا لصاحب الصلاحية وليس للمطور. ويعطي SWEBOK v4 قائمة بالخصائص التي يجب أن تتحقق في كل متطلب، وهي قائمة مفيدة جداً عند المراجعة:

• واضح لا يحتمل إلا تفسيراً واحداً Unambiguous.
• قابل للاختبار Testable، أي يمكن أن تثبت بشكل واضح أن النظام يحققه أو لا يحققه.
• ملزم Binding، أي أن العميل مستعد أن يدفع مقابله ولا يقبل أن يستغني عنه.
• مفرد Atomic، يمثل قراراً واحداً وليس ثلاثة قرارات في جملة.
• يمثل حاجة حقيقية لصاحب مصلحة، ومكتوب بمصطلحات أصحاب المصلحة أنفسهم، ومقبول من جميعهم.

ويضيف الدليل أن مجموع المتطلبات يجب أن يكون كاملاً Complete يغطي الحالات الحدية والاستثناءات واحتياجات الأمن، ومختصراً Concise لا يحمل محتوى زائداً، ومتسقاً Consistent لا يتعارض فيه متطلب مع آخر ولا مع مصادره، وممكناً Feasible يمكن بناؤه ضمن الكلفة والوقت والفريق المتاح. ولاحظ أن خاصية «مكتوب بمصطلحات أصحاب المصلحة» هي نفس فكرة اللغة المشتركة Ubiquitous Language في التصميم الموجه بالمجال، فالقاموس الذي يبدأ في وثيقة المتطلبات هو نفسه الذي يجب أن تجده في أسماء الكلاسات والاختبارات.

التوثيق Specification

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

التحقق Validation

التحقق من المتطلبات هو أن تسأل «هل هذا ما نحتاجه فعلاً؟» قبل أن تبني، وهو يختلف عن اختبار الكود أو ال Verification الذي يسأل «هل بنينا ما كتب؟». ويذكر SWEBOK ثلاث طرق: المراجعة Reviews التي يقرأ فيها أصحاب المصلحة المتطلبات ويعلقون عليها، والمحاكاة أو التنفيذ Simulation and Execution عندما تكون المتطلبات مكتوبة بصيغة يمكن تشغيلها، والنماذج الأولية Prototyping. وأصحاب المصلحة غير التقنيين نادراً ما يقرؤون وثيقة من ثلاثين صفحة بتركيز، لكنهم يلاحظون الخطأ فوراً عندما يرون شاشة مرسومة أو سيناريو بمثال حقيقي، وهذا ما يقوله الدليل أيضاً عن أصحاب المصلحة الذين لا يريدون قضاء الوقت في مراجعة مواصفة بالتفصيل.

إدارة المتطلبات Requirements Management

وهي ما يحدث بعد الاتفاق الأول: إعطاء كل متطلب رقماً وحالة وإصداراً، وتتبعه إلى الكود والاختبار، وإدارة التغيير عليه. ويذكر SWEBOK فيها نشاطاً يغفل عنه كثيرون اسمه تنقية المتطلبات Requirements Scrubbing، وهدفه الوصول إلى أصغر مجموعة من المتطلبات البسيطة التي تلبي حاجات أصحاب المصلحة، بحذف ما هو خارج النطاق Out of Scope، وما لا يعطي عائداً يستحق الكلفة، وما ليس مهماً، وتبسيط ما هو معقد دون داع، لأن كل متطلب تحذفه قبل البناء يوفر كوداً واختبارات وصيانة لسنوات. وسوف نعود إلى التتبع وإدارة التغيير في قسمين مستقلين.

طرق جمع المتطلبات Elicitation Techniques ومتى تنجح كل طريقة

يعدد SWEBOK v4 طرقاً كثيرة لجمع المتطلبات، منها المقابلات Interviews، والاجتماعات والعصف الذهني Brainstorming، وورش العمل الموجهة مثل Joint Application Development واختصاراً JAD، ومجموعات التركيز Focus Groups، والاستبيانات Questionnaires، والنماذج الأولية Prototypes منخفضة وعالية الدقة Low and High Fidelity، والملاحظة Observation التي يدرس فيها المهندس العمل في مكانه، والتتلمذ Apprenticing الذي يتعلم فيه المهندس العمل بأن يقوم به بنفسه، ومعها مصادر لا تأتي من الناس مثل وثائق الأنظمة السابقة وقاعدة الأعطال القديمة والأنظمة المنافسة. ولا توجد طريقة واحدة تكفي، فكل طريقة تكشف نوعاً من المتطلبات وتخفي نوعاً آخر، والجدول التالي يلخص متى تنجح كل طريقة ومتى تضللك:

والقاعدة العملية أن تبدأ بالوثائق لتعرف لغة المجال، ثم المقابلات لتعرف الأهداف، ثم الملاحظة لتعرف ما يحدث فعلاً، ثم النموذج الأولي لتتأكد أنك فهمت، والاستبيان إن احتجته في النهاية لتقيس، وسوف ترى هذه الخطوات مطبقة على العيادة مع قالب أسئلة المقابلة في المقال العملي.

كيف تكتب المتطلبات؟ الصيغ المشهورة Requirements Formats

لا توجد صيغة واحدة صحيحة، والصيغة المناسبة تحددها طبيعة المشروع والعقد والفريق، والمهم أن يحمل كل متطلب رقماً، وأن يكون له معيار قبول يمكن اختباره.

وثيقة مواصفة متطلبات البرمجيات SRS

الوثيقة التقليدية التي تجمع المتطلبات في مكان واحد: الهدف والنطاق Scope والتعريفات وأصحاب المصلحة والمتطلبات الوظيفية وغير الوظيفية والقيود والافتراضات، ويحدد المعيار ISO/IEC/IEEE 29148 المحتوى المطلوب فيها. وتكتب المتطلبات فيها عادة بجمل منظمة، ويذكر SWEBOK مثالاً لصيغة الفاعل والفعل Actor-Action: «عند شحن الطلب، يجب أن ينشئ النظام فاتورة، إلا إذا كانت شروط الطلب مدفوعة مسبقاً»، فالحدث المحفز في البداية، ثم الفاعل وهو النظام، ثم الفعل، ثم الشرط. وهذه الوثيقة ضرورية في العقود الحكومية والمناقصات والأنظمة التي تحتاج اعتماداً رسمياً، لكن لا تقم بكتابة وثيقة من مئة صفحة لفريق من ثلاثة أشخاص، والسبب أن لا أحد سيقرؤها بعد أسبوعها الأول، وفي المقال العملي قالب SRS من صفحة واحدة يكفي أغلب المشاريع الصغيرة والمتوسطة.

قصص المستخدم User Stories وقاعدة INVEST

قصة المستخدم وصف قصير لحاجة من وجهة نظر من يحتاجها، وتذكر Agile Alliance أنها ظهرت مع البرمجة القصوى Extreme Programming في 1998، وأن قالب «الدور، الميزة، الفائدة» Role-Feature-Benefit ظهر في 2001، وصيغته المشهورة:

As a patient,
I want to book a free slot with a doctor online,
So that I do not have to call the clinic during working hours.

بصفتي مريضاً،
أريد أن أحجز موعداً متاحاً مع الطبيب عبر الإنترنت،
حتى لا أضطر للاتصال بالعيادة أثناء الدوام.

لاحظ أن الجزء الأهم في القصة هو «حتى» أو So that، لأنه يحمل الحاجة، والقصة التي لا تحمل سبباً هي غالباً حل مقترح متنكر في شكل قصة. وتذكر Agile Alliance أيضاً فكرة Ron Jeffries من عام 2001 أن القصة ليست وثيقة، وإنما بطاقة Card ومحادثة Conversation وتأكيد Confirmation، أي أن البطاقة تذكير بحوار يجب أن يحدث، والتأكيد هو معايير القبول. ولكي تعرف أن القصة جيدة استخدم قاعدة INVEST التي وضعها Bill Wake في 2003:

• مستقلة Independent: يمكن بناؤها وتسليمها دون انتظار قصة أخرى قدر الإمكان.
• قابلة للتفاوض Negotiable: تصف الحاجة وتترك التفاصيل للحوار، ولا تفرض تصميم الشاشة.
• ذات قيمة Valuable: لها قيمة يراها المستخدم أو العميل، وليست مهمة تقنية مثل «إنشاء جدول في قاعدة البيانات».
• قابلة للتقدير Estimable: يفهمها الفريق بما يكفي ليقدر حجمها.
• صغيرة Small: تنتهي داخل دورة واحدة Sprint، وإلا فقسمها.
• قابلة للاختبار Testable: لها معايير قبول واضحة.

معايير القبول Acceptance Criteria وصيغة Given/When/Then

معايير القبول هي الشروط التي يجب أن تتحقق حتى يقبل صاحب العمل القصة، وهي التي تحول القصة من نية إلى عقد صغير يمكن اختباره. وأشهر صيغة لها Given/When/Then التي يذكر Martin Fowler أن Daniel Terhorst-North وChris Matts طوراها ضمن التطوير الموجه بالسلوك Behavior-Driven Development واختصاراً BDD: «بفرض» حالة البداية، «عندما» يحدث فعل، «إذاً» نتوقع نتيجة. ويذكر SWEBOK v4 هذا الأسلوب باسم المواصفة المبنية على معايير القبول، ومنه التطوير الموجه باختبارات القبول ATDD وBDD، حيث يتفق المهندسون وخبراء المجال على حالات الاختبار قبل أي تصميم أو كود. والصيغة المكتوبة لهذه المعايير اسمها Gherkin، وهي نص عادي يقرؤه صاحب العمل وتشغله أدوات مثل Cucumber وbehave كاختبار:

Feature: Online appointment booking

  Scenario: Two patients cannot take the same slot
    Given patient "P-100" has booked doctor "Dr. Huda" at "2026-10-14 10:00"
    When patient "P-200" books doctor "Dr. Huda" at "2026-10-14 10:00"
    Then the booking is rejected with "SLOT_TAKEN"

في المثال أعلاه لاحظ التالي:

• السيناريو يحمل مثالاً حقيقياً بقيم محددة، وليس وصفاً عاماً مثل «يجب منع الحجز المزدوج»، والمثال المحدد هو ما يكشف سوء الفهم.
• Gherkin تدعم كلمات مفتاحية بلغات كثيرة منها العربية، كما في قائمة اللغات الرسمية، لكن أغلب الفرق تكتب الكلمات المفتاحية والخطوات بالإنجليزية لأن الكود بالإنجليزية، وتكتب القصة نفسها بالعربية لأصحاب المصلحة.
• هذا النوع من المعايير هو نفسه ما تطلبه اختبارات القبول Acceptance Tests التي شرحناها في أنواع الاختبارات، وقد رأينا في متطلبات الأمان مع OWASP ASVS كيف تكتب المتطلبات الأمنية بنفس الصيغة، وفي المقال العملي سوف نشغل ملف Gherkin كامل لقواعد الحجز ونرى مخرجه الحقيقي.

حالات الاستخدام Use Cases

حالة الاستخدام تصف تفاعل فاعل Actor مع النظام لتحقيق هدف واحد، بخطوات السيناريو الأساسي Main Success Scenario، ثم الامتدادات Extensions التي تصف ما يحدث عند كل استثناء، ويعرض SWEBOK v4 قالباً منظماً لها بمثال حجز تذاكر طيران. وقوتها أنها تجبرك على التفكير في الاستثناءات خطوة بخطوة: ماذا لو كان الموعد قد حجز أثناء تعبئة المريض للبيانات؟ ماذا لو لم تصل رسالة التحقق؟ لذلك هي مناسبة للتدفقات الطويلة والمعقدة، بينما القصص أنسب للتسليم المتدرج.

أي صيغة تختار؟

وفي أغلب المشاريع الصغيرة والمتوسطة تعمل التركيبة التالية جيداً: صفحة SRS واحدة للصورة الكاملة والمتطلبات غير الوظيفية والقيود، وقصص مستخدم بمعايير قبول بصيغة Given/When/Then للتفاصيل، وحالة استخدام كاملة فقط للتدفق الأخطر.

ترتيب الأولويات Prioritization بطريقة MoSCoW ونموذج Kano

كل المتطلبات مهمة في نظر صاحبها، وإذا لم تضع لها ترتيباً فسوف يرتبها الموعد النهائي بدلاً منك، وبأسوأ طريقة. وأشهر طريقة بسيطة هي MoSCoW التي تشرحها Agile Business Consortium ضمن إطار DSDM:

• Must Have: الحد الأدنى الذي يضمن المشروع تسليمه، وبدونه لا معنى للإصدار، مثل الحجز ومنع الحجز المزدوج.
• Should Have: مهم لكن النظام يبقى صالحاً بدونه ولو مع حل مؤقت، مثل التذكير برسالة قبل الموعد.
• Could Have: مرغوب وأثر غيابه صغير، وهو أول ما يحذف إذا ضاق الوقت، مثل تقييم الطبيب بعد الزيارة.
• Won't Have this time: خارج هذا الإصدار صراحة، ويكتب حتى لا يعود من الباب الخلفي، مثل الدفع الإلكتروني.

وتوصي الطريقة بألا يزيد جهد Must Have على 60% من جهد الإصدار، وأن يكون Could Have في حدود 20%، والسبب أن المساحة المتبقية هي هامش الأمان Contingency الذي يحمي الموعد عندما يتأخر شيء، وإذا كان كل شيء Must فلا يوجد هامش.

أما نموذج Kano فهو من بحث Noriaki Kano وزملائه عام 1984 عن الجودة الجذابة Attractive Quality والجودة البديهية Must-be Quality، وفكرته أن الميزات لا تؤثر في رضا المستخدم بنفس الطريقة: ميزات أساسية Must-be لا يشكرك أحد عليها لكن غيابها يغضب الجميع، مثل أن الحجز يظهر بعد تأكيده، وميزات أداء One-dimensional كلما تحسنت زاد الرضا، مثل سرعة البحث عن موعد، وميزات جذابة Attractive لا يتوقعها أحد وتسعد من يراها، مثل إضافة الموعد إلى تقويم الجوال بنقرة. والفائدة العملية أن تتأكد أن الأساسيات كلها في Must قبل أن تنفق الوقت على الميزات الجذابة.

تتبع المتطلبات Traceability

التتبع هو أن تستطيع أن تمشي من حاجة العمل إلى المتطلب إلى القصة إلى الكود إلى الاختبار، وأن ترجع في الاتجاه المعاكس، ويخصص له SWEBOK v4 قسماً باسم Requirements Tracing. والصورة التالية تبين السلسلة في مثال العيادة:

والتتبع الأمامي Forward يجيب عن سؤال «هل بنينا واختبرنا كل ما طلب؟»، والخلفي Backward يجيب عن «لماذا يوجد هذا السطر؟»، وعندما يأتي طلب تغيير يجيب التتبع عن السؤال الأهم: ماذا يتأثر؟ والطريقة الثقيلة أن تبني مصفوفة تتبع Traceability Matrix في جدول كبير يحدثه شخص يدوياً، وهي تتقادم من أول أسبوع، أما الطريقة الخفيفة التي تعمل في الفرق الصغيرة فهي أن يظهر رقم المتطلب في كل مكان: في عنوان التذكرة Ticket، وفي رسالة ال Commit، وفي وسم Tag الاختبار، كما سنفعل في المقال العملي بوسوم مثل @BR-01 داخل ملف Gherkin، وعندها يصبح التتبع أمر بحث في المستودع. ولاحظ أن هذا ما فعلناه للمتطلبات الأمنية في مقال ASVS، حيث يحمل كل متطلب رقمه في المعيار من التذكرة إلى تعليق المراجعة.

إدارة التغيير وزحف النطاق Scope Creep

المتطلبات تتغير، وهذا طبيعي وصحي، لأن العميل يفهم حاجته أكثر كلما رأى النظام، والسوق والقوانين تتغير، ويخصص SWEBOK قسماً لاستقرار المتطلبات وتقلبها Stability and Volatility. والمشكلة ليست في التغيير نفسه، وإنما في التغيير الذي يدخل دون قرار، وهو ما يسمى زحف النطاق Scope Creep: طلب صغير هنا، و«إضافة بسيطة ما تأخذ ساعة» هناك، وكل طلب وحده معقول، لكن مجموعها يؤخر الإصدار شهرين ولا يعرف أحد متى تقرر ذلك. والصورة التالية تبين الفرق بين مشروع يدخل فيه كل طلب مباشرة، ومشروع يمر فيه كل طلب على قرار مكتوب:

وإدارة التغيير Change Control لا تعني لجنة ونماذج من خمس صفحات، وإنما أربع خطوات بسيطة: تسجيل الطلب برقم، ثم تحليل أثره على المتطلبات والكود والاختبارات والموعد والكلفة، وهنا يظهر فضل التتبع، ثم قرار من صاحب الصلاحية بقبوله أو تأجيله أو رفضه، ثم تحديث الوثيقة والاختبارات قبل الكود. وفي المقال العملي سوف نطبق هذه الخطوات على طلب تغيير حقيقي في قاعدة الإلغاء، ونرى كيف يفشل الاختبار القديم قبل أن نعدل الكود.

هندسة المتطلبات في Agile وفي المشاريع المخططة مسبقاً Plan-driven

يشرح SWEBOK v4 أن دورة حياة المشروع تحدد متى يحدث عمل المتطلبات وليس هل يحدث: في نموذج الشلال Waterfall يكتمل عمل المتطلبات تقريباً في مرحلة مستقلة قبل أي تصميم أو بناء، وفي النماذج التكرارية Iterative يحدث جزء منه في البداية ويستكمل التفصيل في مراحل لاحقة، وفي Agile يحدث تدريجياً وفي وقته Just in Time مع كل جزء جديد من الوظائف. وقد شرحنا الفرق بين هذه النماذج في دورة حياة تطوير البرمجيات.

وقد يتساءل البعض: هل يعني Agile أننا لا نكتب متطلبات؟ والإجابة لا، فالفرق في الكمية والتوقيت وليس في وجود المتطلبات، ففي Agile تكتب الصورة الكاملة والمتطلبات غير الوظيفية والقيود في البداية بشكل مختصر، ثم تفصل القصص قبل دخولها الدورة بقليل في جلسات تهذيب ال Backlog Refinement، وتبقى معايير القبول والتتبع وإدارة التغيير كما هي. والفريق الذي يستخدم Agile عذراً لعدم كتابة شيء يكتشف لاحقاً أن «المتطلبات» موجودة في رؤوس ثلاثة أشخاص ورسائل واتساب لا يجدها أحد. ولاحظ أن تقرير المفتش العام عن HealthCare.gov الذي سنعرضه بعد قليل ذكر صراحة أن أسلوب Agile سهل على صناع القرار طلب تغييرات متكررة ومتأخرة، وأن التغييرات في Agile يجب أن تدرس وتوثق وتبلغ مثل أي تغيير آخر.

وإذا كان فريقك يدير عمله على سيرفره الخاص، فأداة مثل Taiga التي شرحنا تثبيتها تعطيك قصص المستخدم ومعايير القبول وال Backlog والدورات في مكان واحد.

مشكلات شائعة وحلولها

كلمات غامضة Ambiguous Terms: سريع، سهل الاستخدام، آمن

جملة «يجب أن يكون النظام سريعاً وسهل الاستخدام» تبدو متطلباً، لكنها لا تقول للمطور ماذا يبني ولا للمختبر ماذا يختبر، والسبب أن كل شخص يفهم «سريع» بطريقته. وكلمات أخرى تحمل نفس المشكلة: مرن، قوي، حديث، بديهي، تقريباً، حسب الحاجة، وغيرها، إلخ. والحل أن تسأل «كيف سنعرف أننا حققناه؟» حتى تصل إلى رقم أو مثال: «95% من عمليات البحث عن موعد تعرض النتائج في أقل من ثانية»، «مريض يستخدم النظام لأول مرة يكمل الحجز في أقل من دقيقتين دون مساعدة».

المتطلبات غير الوظيفية Non-functional Requirements غائبة

العميل يذكر ما يريد أن يراه، ولا يذكر عدد المستخدمين في وقت الذروة Peak، ولا كم دقيقة توقف يقبلها، ولا أين تحفظ البيانات، ولا كم سنة يحتفظ بها، ثم تظهر هذه الأسئلة يوم الإطلاق. والحل قائمة ثابتة تمر عليها في كل مشروع، مبنية على خصائص الجودة التي شرحناها في مقال المعمارية، واختر منها الثلاث أو الأربع الأهم واكتبها بأرقام، ومعها النسخ الاحتياطي Backup وزمن الاستعادة Recovery Time كما في قاعدة 3-2-1.

سألت الشخص الخطأ

جمعت المتطلبات من المدير وحده، ثم رفض المستخدمون النظام لأنه لا يشبه عملهم، أو نسيت طرفاً لم يحضر أي اجتماع مثل المحاسب أو مسؤول الالتزام. والحل أن تبدأ بقائمة أصحاب المصلحة Stakeholders قبل أي مقابلة، وأن تلاحظ المستخدمين في عملهم بنفسك، وأن تسأل في نهاية كل مقابلة «من غيرك يجب أن أكلمه؟».

حل Solution مكتوب كأنه متطلب Requirement

«يجب أن يستخدم النظام React»، «نبغى زر تصدير»، «نبغى Microservices». بعض هذه الجمل قيود حقيقية لها سبب، مثل أن فريق الصيانة لا يعرف إلا تقنية معينة، وأغلبها حلول تخيلها شخص. والحل أن تسأل «لماذا؟» كما رأينا، فإذا كان للقيد سبب حقيقي فاكتبه كقيد مع سببه، وإذا لم يكن فاكتب الحاجة واترك الحل للتصميم.

التذهيب Gold Plating

هو أن يضيف المطور من عنده ما لم يطلبه أحد، لأنه «سيعجبهم» أو لأنه «لن يأخذ وقتاً»: تصدير إلى PDF، ووضع ليلي، وإعدادات لكل شيء. والمشكلة أن كل إضافة كود يجب أن يختبر ويصان ويؤمن، وقد تكسر شيئاً مطلوباً، وهي تأخذ وقتاً من المتطلبات الحقيقية، وهذا قريب مما يحذر منه مبدأ YAGNI الذي شرحناه في مبادئ التصميم. والحل قاعدة بسيطة: لا يدخل الكود شيء ليس له رقم متطلب، والفكرة الجيدة تكتب كطلب جديد وتمر على ترتيب الأولويات مثل غيرها.

افتراضات Assumptions لم يتحقق منها أحد

«كل المرضى عندهم جوال ذكي»، «النظام القديم يصدر البيانات بصيغة CSV»، «مزود الرسائل يدعم العربية». كل افتراض من هذه قد يكون صحيحاً، لكن إذا كان خطأ فسوف تكتشفه بعد أن بنيت عليه. والحل أن تكتب كل افتراض في قسم مستقل في الوثيقة، ومعه اسم من سيتأكد منه وموعد التأكد، وأن تتعامل مع الافتراض الذي لم يتأكد منه أحد كخطر في سجل المخاطر Risk Register.

المتطلبات في رسائل الواتساب

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

لا توجد معايير قبول Acceptance Criteria

القصة تقول «يستطيع المريض إلغاء موعده» وتنتهي، فيبني المطور الإلغاء في أي وقت، ويختبر المختبر الإلغاء قبل الموعد بيوم، ويكتشف المالك بعد الإطلاق أن المرضى يلغون قبل الموعد بخمس دقائق. والحل ألا تدخل قصة إلى الدورة دون معايير قبول بأمثلة، تشمل الحالة العادية والحالات الحدية والأخطاء، وأن يقرأها صاحب العمل ويوافق عليها قبل البناء.

الامتثال Compliance يكتشف في آخر يوم

يبنى النظام ثم يسأل أحدهم قبل الإطلاق: أين تحفظ بيانات المرضى؟ هل أخذنا موافقتهم على الرسائل؟ هل يطلب العميل الحكومي الالتزام بضوابط الهيئة الوطنية للأمن السيبراني؟ ويصبح التعديل في هذه المرحلة مكلفاً لأنه يمس قاعدة البيانات والاستضافة والصلاحيات. والحل أن يكون الامتثال سؤالاً في أول مقابلة وليس في آخرها: نظام حماية البيانات الشخصية PDPL الذي تنشر نصوصه ولوائحه منصة حماية البيانات الشخصية، والضابط 1-6-3 في ضوابط NCA ECC الذي يطلب أن تشمل متطلبات مشاريع التطبيقات متطلبات الأمن السيبراني، ومتطلبات الجهات الحكومية إن كان العميل جهة حكومية. وتحويل هذه المتطلبات إلى بنود قابلة للاختبار شرحناه في مرحلة المتطلبات الأمنية في Secure SDLC.

ثلاث قصص موثقة من تقارير رسمية

لا توجد مشكلة في المتطلبات لم تحدث في مشروع حكومي كبير وكتب عنها تقرير رقابي منشور، والقصص الثلاث التالية مأخوذة من تقارير جهات الرقابة نفسها، وليس من مقالات الرأي، ونذكر في كل واحدة مشكلة المتطلبات التي ذكرها التقرير بالتحديد.

موقع HealthCare.gov في الولايات المتحدة عام 2013

أطلقت الحكومة الأمريكية موقع HealthCare.gov في أكتوبر 2013 ليشتري الناس منه التأمين الصحي، وتعطل الموقع بشكل واسع من أول يوم. وتقرير مكتب المفتش العام في وزارة الصحة HHS OIG رقم OEI-06-14-00350 الصادر في فبراير 2016 يقول إن صياغة متطلبات العمل Business Requirements والمواصفات التقنية كانت بطيئة وكثيرة التكرار، وإن الجهة المسؤولة CMS كانت ما زالت تتخذ قرارات تنظيمية وسياسية أساسية بعد أن بدأ المقاولون البناء، وإن المقاولين لاحظوا غياب متطلبات العمل كمشكلة من البداية، وإن تغيير متطلبات العمل والمواصفات استمر حتى عام 2013 فلم يعد ممكناً إكمال الموقع واختباره كما خطط له. ويذكر التقرير أن لجنة ضبط التغيير Change Control Board والمستودع المركزي للمتطلبات لم يداروا بشكل فعال. وتقرير مكتب المحاسبة الحكومي GAO-14-694 في يوليو 2014 يذكر أن عقود بناء المنصة صدرت بينما المتطلبات التقنية الأساسية غير معروفة، وأن المبالغ الملتزم بها لعقد المنصة الفيدرالية ارتفعت من 56 مليون دولار في سبتمبر 2011 إلى أكثر من 209 ملايين في فبراير 2014، ثم يذكر تقرير GAO-15-238 في مارس 2015 أن المتطلبات لم تدر بشكل فعال، فلم يتأكد الفريق دائماً أن المتطلبات معتمدة ومرتبطة بمصدرها وبالمتطلبات الأدنى منها، وأن وثائق الاختبار كانت تنقصها عناصر أساسية مثل معايير نجاح الاختبار. والدرس هنا مباشر: تأخر قرارات المتطلبات، وضعف ضبط التغيير، وغياب التتبع ومعايير القبول، أربع مشكلات من قائمتنا في مشروع واحد.

نظام Virtual Case File في مكتب التحقيقات الفيدرالي FBI

كان نظام Virtual Case File جزءاً من مشروع Trilogy لتحديث أنظمة مكتب التحقيقات الفيدرالي، وهدفه نظام جديد لإدارة القضايا. وتقرير المفتش العام في وزارة العدل الأمريكية رقم 05-07 الصادر في فبراير 2005 يذكر أن المكتب أنفق على هذا النظام أكثر من ثلاث سنوات و170 مليون دولار، وأنه يتجه إلى ترك النظام والبدء بحل آخر، ويضع في أول أسباب التأخير وزيادة الكلفة «متطلبات تصميم سيئة التعريف وتتطور ببطء» Poorly Defined and Slowly Evolving Design Requirements. ويقول التقرير إن الفريق والمقاولين لم يكن لديهم فهم ثابت لمتطلبات التصميم، وإن المشروع لم يكن له خط أساس Baseline ثابت في سنواته الأولى، وينقل عن مدير في المشروع أن نطاقه زاد بنحو 80% منذ بدايته، وأن المكتب أراد ترسية العقود بسرعة دون متطلبات واضحة فاختار نوع عقد بالكلفة مع مكافأة، وأن غياب المتطلبات الواضحة أثر بشدة على الوقت والكلفة. ولاحظ أن جزءاً من التغيير كان مبرراً، فقد تغيرت أولويات المكتب بعد أحداث سبتمبر 2001، لكن التغيير المبرر نفسه يحتاج خطاً أساسياً وإدارة، وإلا تحول إلى زحف نطاق لا يعرف أحد حدوده.

البرنامج الوطني لتقنية المعلومات NPfIT في هيئة الصحة البريطانية NHS

بدأت بريطانيا البرنامج الوطني لتقنية المعلومات في NHS لتوفير سجلات صحية إلكترونية لكل مريض عبر عقود مركزية كبيرة. وتقرير مكتب التدقيق الوطني NAO الصادر في مايو 2011 يقول إن 2.7 مليار جنيه أنفقت على أنظمة السجلات الصحية لا تمثل قيمة مقابل المال، وإن المواعيد انزلقت من 2010 إلى 2015-2016. وفي جانب المتطلبات ينقل التقرير عن الوزارة أن المواعيد الأصلية لم تتحقق لأن الموردين اضطروا إلى تخصيص أكثر بكثير مما كان متوقعاً لتلبية احتياجات كل مؤسسة صحية، وأن الطريقة الأصلية لم تنجح فدفعت الوزارة أكثر لتكييف الأنظمة مع الاحتياجات المحلية، وأن الوزارة لم تتفق مع الأطباء على «الحد الأدنى من المواصفات» التي تجعل النظام مقبولاً لهم إلا في عام 2008، بعد سنوات من بدء البرنامج. ويذكر التقرير أيضاً خلافاً مع أحد الموردين حول ما سماه «متطلبات جديدة»، فالمورد يراها إضافات تستحق تمويلاً، والوزارة تراها تصحيحات لازمة ليصبح النظام صالحاً للاستخدام، وانتهى الأمر بإنهاء عقده. والدرس هنا أن المتطلبات التي تكتب مركزياً دون المستخدمين الحقيقيين لا تصمد أمام الواقع، وأن غياب معيار قبول متفق عليه يحول كل تعديل إلى نزاع على من يدفع.

وماذا عن أرقام تقرير CHAOS؟

سوف تقرأ في عروض كثيرة أن «أغلب مشاريع البرمجيات تفشل» مع أرقام من تقارير CHAOS التي تنشرها مجموعة Standish منذ 1994، وأشهرها أن 16% فقط من المشاريع نجحت في تقرير 1994، و53% تعثرت، و31% ألغيت، كما ينقلها باحثان من جامعة VU Amsterdam في مقالهما The Rise and Fall of the Chaos Report Figures المنشور في مجلة IEEE Software عام 2010. لكن المقال نفسه يطبق تعريفات Standish على بيانات 1211 مشروعاً حقيقياً، ويخلص إلى أن هذه التعريفات مضللة لأنها تقيس فقط الانحراف عن التقدير الأول للكلفة والوقت والميزات، ومن جانب واحد لأنها تتجاهل المشاريع التي انتهت بأقل من التقدير، وأن الأرقام الناتجة بلا معنى لأنها تتأثر بانحياز التقديرات في كل مؤسسة، وقد سبقه Robert Glass بنقد مشابه في مجلة Communications of the ACM. لذلك لا تقم ببناء حجتك على هذه النسب، وإذا احتجت أن تقنع إدارتك بأهمية المتطلبات فالتقارير الرقابية أعلاه أقوى، لأنها تسمي المشروع والسبب والكلفة.

ماذا تقرأ بعد هذا المقال؟

المقال التالي يطبق كل ما سبق على طلب العيادة نفسه: خطة المقابلة وأسئلتها، وبيان المشكلة، وخريطة أصحاب المصلحة، والقصص ومعايير القبول بصيغة Gherkin مع اختبار يعمل فعلاً، والمتطلبات غير الوظيفية بالأرقام، ووثيقة SRS من صفحة، وقائمة المراجعة، وطلب تغيير بعد التوقيع:

دليلمن فكرة غامضة إلى متطلبات Requirements واضحة: مثال عملي مع القوالبكيف تحول جملة «نبغى نظام حجز مواعيد لعيادة» إلى متطلبات Requirements واضحة يمكن بناؤها واختبارها، مع قوالب جاهزة للنسخ.

وبعد المتطلبات تأتي المعمارية التي تبنى عليها، والتصميم الموجه بالمجال الذي يحول لغة المتطلبات إلى كود، وتوثيق القرارات المعمارية، ونمذجة التهديدات التي تكشف المتطلبات الأمنية من التصميم:

دليلالتصميم والمعمارية: أربعة مستويات لنشاط واحدما الفرق بين تصميم البرمجيات ومعماريتها وتصميم الأنظمة ومعمارية المؤسسة، ومن يقرر في كل مستوى وكم يعيش قراره.دليلالتصميم الموجه بالمجال Domain-Driven Design ببساطةلماذا تعني كلمة «الطلب» ثلاثة أشياء في نفس الشركة، وكيف يقسم DDD النظام إلى سياقات لكل منها لغته ونموذجه.دليلتوثيق المعمارية: مخططات C4 وسجلات القرارات المعمارية ADRكيف ترسم نظامك بمخططات C4 يفهمها المطور الجديد، وتحفظ سبب كل قرار مهم في سجل ADR داخل المستودع.دليلنمذجة التهديدات Threat Modeling للمبتدئينكيف تسأل ما الذي قد يسوء في تصميم تطبيقك قبل أن تكتب الكود، وتقرر لكل تهديد هل تصلحه أو تقبله، مع قالب جاهز للنسخ.

تدريب عملي

1. خذ آخر ثلاث تذاكر عملت عليها، واسأل عن كل واحدة: هل فيها «حتى» أو So that تشرح الحاجة؟ هل لها معايير قبول بمثال محدد؟ هل يمكنك أن تجد من طلبها ولماذا؟
2. اكتب قائمة بكل الافتراضات في مشروعك الحالي التي لم يتأكد منها أحد، وبجانب كل افتراض اسم من يستطيع تأكيده، ثم أرسل له السؤال اليوم.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• ما يقوله العميل في الاجتماع الأول جزء صغير مما يحتاجه، وهندسة المتطلبات هي العمل المنظم لكشف الباقي قبل أن يتحول إلى كود.
• العميل يتكلم غالباً بلغة الحل، فاسأل «لماذا؟» حتى تصل إلى الحاجة، ثم اختر الحل عن وعي.
• فرق بين المتطلبات الوظيفية وغير الوظيفية وقواعد العمل والقيود والافتراضات، لأن كل نوع يعامل ويختبر بطريقة مختلفة.
• الأنشطة كما يصفها ISO/IEC/IEEE 29148 وSWEBOK v4 هي الجمع والتحليل والتوثيق والتحقق، والإدارة تحفظ الاتفاق مع الوقت، وكلها تتكرر مع كل دورة.
• لا توجد طريقة جمع واحدة تكفي: الوثائق ثم المقابلات ثم الملاحظة ثم النموذج الأولي.
• كل متطلب يحتاج رقماً ومعيار قبول بمثال محدد، وأفضل صيغة لقواعد العمل هي Given/When/Then لأنها تتحول إلى اختبار.
• رتب الأولويات بطريقة MoSCoW واترك هامشاً، واجعل رقم المتطلب يظهر في التذكرة والكود والاختبار، وامنع زحف النطاق بقرار مكتوب لكل تغيير.
• تقارير الرقابة عن HealthCare.gov ونظام FBI ومشروع NHS تذكر نفس المشكلات: متطلبات متأخرة أو غير واضحة، ونطاق يتغير دون ضبط، ومستخدمون حقيقيون غائبون.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، مع مراجعة التعريفات والأنشطة من صفحة المعيار ISO/IEC/IEEE 29148:2018 والفصل الأول من SWEBOK v4، والقصص الموثقة من تقارير HHS OIG وGAO ووزارة العدل الأمريكية ومكتب التدقيق الوطني البريطاني.