وثيقة متطلبات منصة تعليمية مخصصة (BRD/SRS): نموذج وأمثلة

لماذا يسعّر المطورون الوثيقة نفسها بأرقام متباعدة؟

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

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

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

BRD أم SRS: من يكتب ماذا ومتى؟

المصطلحان يُستخدمان بالتبادل كثيرًا، لكن الفرق بينهما عملي. وثيقة متطلبات العمل (BRD) تكتبها الجهة: لماذا المنصة، ولمن، وما النتائج المطلوبة، وما الحدود. وثيقة مواصفات متطلبات البرمجيات (SRS) تفصّل السلوك المطلوب بدقة يبني عليها المطور ويختبر عليها المختبر، وتُكتب غالبًا بالتعاون بين الجهة وفريق التطوير في مرحلة الاكتشاف.

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

هيكل وثيقة متطلبات المنصة التعليمية في عشرة أقسام

الأقسام 2 و4 و5 و8 هي التي تحدد الجهد أكثر من غيرها، ولهذا نفصّلها أدناه.

الأدوار والصلاحيات: مصفوفة لا قائمة أسماء

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

وأضف تحت المصفوفة ثلاثة أسئلة يغفلها كثيرون: هل يحمل المستخدم أكثر من دور (متعلم في برنامج ومدرب في آخر)؟ وهل تُربط الأدوار بمجموعات نظام الهوية؟ ومن ينشئ الأدوار المخصصة لاحقًا: مسؤول النظام من الواجهة، أم المطور بتعديل برمجي؟ الإجابة الأخيرة وحدها تغيّر التقدير.

قصص المستخدم ومعايير القبول: أمثلة جيدة وسيئة

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

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

القواعد التشغيلية: ما يجعل منصة التعلم مختلفة

منصات التعلم مليئة بقواعد تبدو بديهية حتى يُسأل عنها. اجمعها في قسم مستقل بصيغة جداول قرار أو جمل شرطية، لأن المطور يحتاجها مجتمعة لا مبعثرة في القصص:

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

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

المتطلبات غير الوظيفية: الأداء والأمن والعربية والاستضافة

هذا القسم يُكتب عادة بعبارات لا تُقاس: «سريعة»، «آمنة»، «تتحمل عددًا كبيرًا». المطور يسعّر حينها على افتراضه، والمختبر لا يجد ما يختبر عليه. اكتب كل بند بقيمة تحددها جهتك وطريقة قياس:

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

التكاملات وواجهات API: صِف البيانات لا اسم النظام

«تكامل مع نظام الموارد البشرية» قد يعني ملفًا يُرفع يدويًا كل شهر، أو مزامنة لحظية في الاتجاهين. اكتب لكل تكامل خمسة أشياء:

1. النظام الآخر: اسمه وإصداره ومن يملكه في جهتك.
2. البيانات: ما الذي ينتقل تحديدًا (موظف جديد، تغيير وظيفة، إيقاف، نتيجة، شهادة).
3. الاتجاه: من المنصة، أو إليها، أو في الاتجاهين.
4. التوقيت: لحظي عند الحدث، أم مجدول، أم يدوي عند الطلب.
5. المتاح لدى الطرف الآخر: واجهة برمجية موثقة، أم قاعدة بيانات، أم ملفات فقط. هذا يحدده نظامك لا المطور، ويجب أن يُعرف قبل التسعير.

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

خارج النطاق والافتراضات: القسمان اللذان يمنعان الخلاف

أكثر الخلافات بعد التعاقد ليست على ما كُتب، بل على ما لم يُكتب. قسم «خارج النطاق» يغلق باب الافتراض بأن كل ما لم يُستثن مشمول، وقسم «الافتراضات» يكشف ما تعتمد عليه الجهة دون أن تقوله. أمثلة لما يُكتب فيهما:

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

وأضف بندين لا يخصان السلوك لكنهما يحددان مستقبل المنصة: ملكية الكود والتراخيص (هل تملك الجهة الكود المطوّر لها، وما وضع النواة؟)، وتسليم البيانات والتوثيق عند انتهاء العلاقة. أنماط الملكية وما يترتب عليها في دليل ملكية كود المنصة التعليمية.

سيناريو: جهة تأهيل مهني بتقييم ميداني لدى شركاء

مثال افتراضي للتوضيح جهة تأهيل مهني تدرّب نحو 1,200 فني صيانة صناعية سنويًا بالشراكة مع 40 منشأة صناعية. البرنامج ثلاث مراحل: وحدات نظرية على المنصة، ثم تدريب على رأس العمل في المنشأة يقيّمه مشرفها بقائمة مهارات، ثم اختبار نهائي وشهادة يُتحقق منها. بدأت الجهة وهي مقتنعة بأنها تحتاج منصة تُبنى من الصفر، لأن «لا منصة تفعل ما نفعله».

كتبت الجهة وثيقتها على الأقسام العشرة، فخرجت منها نتيجتان غيرتا شكل المشروع:

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

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

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

الخلاصة: وثيقة تُختبر، لا وثيقة تُقرأ فقط

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

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