كتابة متطلبات مشروع برمجي: قالب جاهز قبل طلب عرض السعر

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

لماذا تختلف العروض على المشروع نفسه#

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

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

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

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

ما الفرق بين المتطلب والرغبة#

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

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

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

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

قالب كتابة متطلبات مشروع برمجي#

القالب ليس ملفاً تنزّله، بل تسعة عناوين تكتب تحت كل واحد منها فقرة قصيرة أو قائمة. اكتبه في مستند نصي عادي بالعربية، ولا تشغل نفسك بالتنسيق:

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

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

كيف تصف المستخدمين والصلاحيات#

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

في شركة موارد بشرية صغيرة، الفرق بين «الموظف يرى مسيّر رواتبه» و«الموظف يرى مسيّرات قسمه» أسبوع عمل كامل في قاعدة البيانات وفي كل شاشة. اكتب الجملة الصحيحة مرة واحدة الآن بدل أن تدفع ثمنها مرتين لاحقاً.

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

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

المتطلبات غير الوظيفية التي ينساها أصحاب المشاريع#

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

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

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

كيف تحوّل المستند إلى عرض سعر قابل للمقارنة#

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

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

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

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

أسئلة شائعة#

هل أحتاج خبرة تقنية لكتابة المتطلبات؟#

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

هل أذكر التقنيات التي أريدها في المستند؟#

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

ماذا لو تغيّرت المتطلبات بعد توقيع العقد؟#

هذا متوقع، ولهذا يُقسَّم التنفيذ على دفعات. عند كل دفعة تراجع ما سُلّم وتضيف طلباتك الجديدة إلى قائمة تُسعَّر مستقلة. البنود التي تحتمل التأجيل تنتقل إلى الدفعة التالية بدل أن تعطّل التسليم الحالي.

كم صفحة يكفي مستند المتطلبات؟#

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

هل أرسل المستند نفسه إلى كل الشركات؟#

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

ما تكتبه هذا الأسبوع#

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