كيف تُعدّ وثيقة متطلبات لتطوير البرمجيات: ماذا تكتب لفريق التطوير

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

ما وثيقة المتطلبات ولماذا يحتاجها العميل

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

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

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

الموجز والمواصفات الكاملة: ما الفرق

كثيرًا ما يُخلط بين «الموجز» و«وثيقة المتطلبات». والحقيقة أنهما وثيقتان مختلفتان لمرحلتين مختلفتين، والعميل يحتاج عادةً إلى الأولى فقط.

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

ماذا تفعل إذا لم تكن لديك وثيقة متطلبات

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

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

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

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

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

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

كيف تكتب موجز تطوير البرمجيات خطوة بخطوة

إن كنت تكتب الوثيقة بنفسك، فانتقل من المشكلة إلى التفاصيل لا العكس:

1. صُغ المشكلة في جملة أو جملتين دون مصطلحات تقنية.
2. صِف شكل النجاح: ما الذي سيتغير بشكل قابل للقياس بعد الإطلاق.
3. عدّد المستخدمين وما يفعله كل منهم في المنتج.
4. اكتب السيناريو الرئيسي خطوة بخطوة كأنه قصة: «يفتح العميل، ويختار، ويدفع، ويستلم».
5. قسّم الوظائف إلى ما يلزم في الإصدار الأول وما يمكن إضافته لاحقًا.
6. عدّد الأنظمة التي يجب الربط بها والبيانات التي تمر عبرها.
7. سمِّ القيود: الموعد المرغوب، ونطاق الميزانية، ومتطلبات تخزين البيانات.
8. اكتب معايير الاستلام بعبارات قابلة للتحقق، لا بكلمات مثل «مريح» و«جميل».
9. سلّم الموجز إلى فريق التطوير واسأل: ما غير الواضح، وما الزائد، وما الذي يمكن تبسيطه.

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

متطلبات التطبيق والبوت ووكيل الذكاء الاصطناعي: ماذا تضيف

الهيكل العام واحد، لكن لكل نوع من المنتجات أسئلته التي يحسن حسمها مسبقًا.

تطبيق للجوال أو لسطح المكتب

حدّد المنصات (iOS وAndroid وmacOS وWindows والويب)، وهل يلزم النشر في متاجر التطبيقات، والعمل دون إنترنت، والإشعارات، والتحديث التلقائي. وفي تطبيقات سطح المكتب: هل تحتاج إلى برنامج تثبيت وإلى التعامل مع الملفات على الحاسوب.

بوت تيليجرام أو تطبيق مصغّر

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

وكيل ذكاء اصطناعي

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

الأخطاء الشائعة في وثيقة المتطلبات

معظم مشكلات وثائق المتطلبات تتكرر من مشروع إلى آخر:

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

علاقة وثيقة المتطلبات بالمدة والنموذج الأولي والاستلام

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

وإن كانت الأفكار كثيرة واليقين قليلًا، فاكتب الوثيقة لا للمنتج كله، بل لإصدار أول يتضمن السيناريو الرئيسي. وكيف تحدد هذا الإصدار، تجده في نموذج أولي قابل للتطبيق MVP: من أين تبدأ.

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

كيف نعمل على المهمة في JEEKSSHIRE 24

نبدأ من المهمة لا من التقنية. وتسير العملية هكذا:

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

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

قصص المستخدم ومعايير القبول: كيف تصف الوظائف

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

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

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

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

حدود المشروع وآلية التغييرات

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

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

1. يُسجَّل التغيير: ما الذي يتغير ولماذا.
2. يقدّر المطوّر أثره في المدة وفي الأجزاء المنجزة.
3. يتفق الطرفان على ما يستبدله التغيير أو يؤجله.
4. بعد ذلك فقط يدخل حيز التنفيذ، وتُحدَّث المواصفات.

تُضبط الحدود بأشد صرامة في النسخة الأولى من المنتج. فإذا كنت تبدأ تطوير نموذج أولي قابل للتطبيق MVP، تساعدك قائمة «خارج النطاق» على إطلاق السيناريو الرئيسي أسرع وترك الباقي للإصدارات التالية.