معظم تجاوزات الميزانية والخلافات التي نراها في مشاريع التطبيقات تبدأ من نقطة واحدة: متطلبات غير موثقة. عبارة «تطبيق مثل تطبيق فلان» تعني شيئا مختلفا عند العميل وعند كل شركة تقدم عرضا، والنتيجة عروض أسعار لا يمكن مقارنتها، ثم مفاجآت أثناء التنفيذ: «هذه الميزة لم تكن ضمن الاتفاق».
منذ 2014 ونحن نسلم تطبيقات لعملاء في مصر والخليج، والفارق بين مشروع يمضي بسلاسة ومشروع يتعثر يظهر مبكرا جدا: المشاريع التي بدأت بمستند متطلبات مكتوب، حتى لو صفحتين، توفر على أصحابها جزءا كبيرا من إعادة العمل والنقاشات المتأخرة، لأن الجميع يوقع على نطاق واضح منذ اليوم الأول. لذلك أعددنا هذا القالب المجاني: نفس الهيكل الذي نستخدمه داخليا عند تحليل متطلبات عملائنا، مبسطا ليعبئه صاحب فكرة أو مدير مشروع دون خلفية تقنية.
كيف تستخدم هذا القالب؟
- انسخ أو حمل: اقرأ القالب كاملا في الصفحة، أو حمله كملف Word جاهز للتعبئة.
- عبئ ما تعرفه: لا تتوقف عند الأقسام التقنية، املأ الأقسام التجارية أولا، فهي الأهم.
- ضع «TBD» عند المجهول: كتابة «لم يحدد بعد» أفضل بكثير من تخمين إجابة أو حذف السؤال.
- أرسله للشركات المرشحة: نفس المستند لكل الشركات = عروض أسعار قابلة للمقارنة فعلا. ويمكنك إرساله لنا لمراجعة مجانية وعرض سعر مكتوب خلال يوم عمل واحد.
القالب الكامل: 15 قسما
ضبط المستند
صفحة الغلاف الإدارية: تحدد من يملك المستند وأي نسخة هي المعتمدة، فلا يعمل أحد على نسخة قديمة.
| الإصدار | التاريخ | الكاتب / المالك | الحالة |
|---|---|---|---|
| 0.1 | مثال: 2026-07-01 | اسم مدير المشروع | مسودة |
الملخص التنفيذي
أول ما يقرؤه أي فريق تطوير. إن لم تستطع تلخيص الفكرة في فقرة، فالمتطلبات نفسها ما زالت غير ناضجة.
الأهداف ومؤشرات النجاح
التطبيق وسيلة لا غاية. الأهداف المكتوبة بأرقام قابلة للقياس هي ما يسمح لك لاحقا بالحكم: هل نجح المشروع؟
| المؤشر (KPI) | المستهدف | متى يقاس |
|---|---|---|
| مثال: عدد التسجيلات النشطة | 5,000 مستخدم | بعد 6 أشهر من الإطلاق |
| مثال: نسبة إتمام الطلب/الحجز | 60% من من بدأوا العملية | شهريا |
الفئات المستهدفة والشخصيات (Personas)
تصميم «لكل الناس» يعني تصميما لا يناسب أحدا. شخصيتان أو ثلاث تكفي لتوجيه قرارات الواجهة والميزات.
قصص المستخدم والميزات: بأولوية MoSCoW
أهم قسم في المستند. تصنيف Must/Should/Could/Won't يمنع تضخم النطاق ويجعل نسخة الإطلاق الأولى قابلة للتنفيذ بميزانية معقولة.
| # | الميزة / قصة المستخدم | الأولوية | ملاحظات |
|---|---|---|---|
| 1 | التسجيل بالبريد أو برقم الجوال مع رمز تحقق OTP | Must | مثال |
| 2 | تصفح الخدمات/المنتجات مع بحث وتصفية | Must | مثال |
| 3 | الدفع الإلكتروني داخل التطبيق | Must | البوابات في قسم التكاملات |
| 4 | الإشعارات الفورية (Push) | Should | مثال |
| 5 | تسجيل الدخول عبر Google / Apple | Should | مثال |
| 6 | تقييم الخدمة بعد كل عملية | Should | مثال |
| 7 | نقاط ولاء ومكافآت | Could | مرحلة لاحقة إن سمحت الميزانية |
| 8 | دعم عملات ودول متعددة | Won't | خارج نطاق النسخة الأولى |
Must = بدونها لا يطلق التطبيق · Should = مهمة لكن يمكن تأجيلها أسابيع · Could = تحسين جميل · Won't = خارج نطاق هذه المرحلة صراحة.
رحلات المستخدم الأساسية
صف بالخطوات كيف يمر المستخدم في أهم 3–4 رحلات. عبارات بسيطة تكفي: «يفتح التطبيق ← يختار ← يدفع ← يتلقى تأكيدا».
المنصات والأجهزة
تحديد المنصات وأقل إصدار مدعوم يؤثر مباشرة على السعر والجدول. القاعدة العملية: ادعم الإصدارات التي تغطي الغالبية العظمى من أجهزة جمهورك ولا تدفع ثمن دعم أجهزة شبه منقرضة.
| المنصة | مطلوبة؟ (نعم/لا/لاحقا) | أقل إصدار مدعوم |
|---|---|---|
| Android (هواتف) | شائع: Android 8.0+ | |
| iOS (آيفون) | شائع: iOS 14+ | |
| أجهزة لوحية (Tablet) | ||
| لوحة تحكم ويب (Admin) | أحدث المتصفحات |
المتطلبات غير الوظيفية
ما لا يظهر في الشاشات لكنه يحدد جودة التطبيق: السرعة، الأمان، والسلوك عند انقطاع الإنترنت. أغلب العقود تنسى هذا القسم ثم تختلف الأطراف عليه.
التكاملات مع خدمات خارجية
كل تكامل خارجي بند تكلفة ووقت مستقل. اذكرها كلها الآن، اكتشاف «نحتاج ربطا مع نظام المحاسبة» في منتصف التنفيذ يعني تعديل عقد.
| التكامل | المزود (إن حدد) | الغرض |
|---|---|---|
| بوابة دفع | مثال: Paymob / فوري / MyFatoorah / Stripe | الدفع بالبطاقات والمحافظ |
| خرائط وتحديد موقع | مثال: Google Maps | العناوين والتتبع |
| رسائل SMS / OTP | التحقق من رقم الجوال | |
| تحليلات | مثال: Firebase / GA4 | قياس الاستخدام |
| تسجيل اجتماعي | Google / Apple / فيسبوك | دخول أسرع |
متطلبات لوحة التحكم (Admin)
التطبيق الذي يراه المستخدم نصف المشروع فقط؛ النصف الآخر لوحة تديرها أنت. حدد الأدوار وصلاحية كل دور.
| الصلاحية \ الدور | مدير عام | مشرف محتوى | موظف دعم |
|---|---|---|---|
| إدارة المستخدمين والحسابات | ✓ | عرض فقط | |
| إدارة المحتوى/المنتجات | ✓ | ✓ | |
| الطلبات والمبالغ المستردة | ✓ | ✓ | |
| التقارير المالية | ✓ | ||
الجدول أعلاه مثال، عدل الأدوار والصلاحيات حسب فريقك.
التحليلات والتتبع
ما لا يقاس لا يتحسن. حدد الأحداث التي تريد تتبعها من اليوم الأول، إضافتها لاحقا تعني فقدان بيانات الشهور الأولى.
- فتح التطبيق لأول مرة، وإتمام التسجيل.
- تنفيذ الحدث الأساسي (طلب / حجز / شراء) ومراحله.
- بدء الدفع، نجاحه، أو فشله (مع سبب الفشل).
- فتح الإشعارات ونسبة التفاعل معها.
- الأعطال (Crash reporting) وشاشات الأخطاء.
- أحداث إضافية خاصة بنشاطك:
مراحل التسليم ومعايير القبول
لكل مرحلة تسليم ملموس واختبار قبول واضح. «اختبار القبول» هو الجملة التي تحسم لاحقا: هل هذه المرحلة مكتملة أم لا؟
| المرحلة | التسليم | اختبار القبول |
|---|---|---|
| 1, تحليل وتصميم UX/UI | نماذج شاشات تفاعلية | اعتماد كتابي للتصميم قبل البرمجة |
| 2, نسخة تجريبية (MVP) | تطبيق يعمل بميزات Must | تنفيذ الرحلة الأساسية كاملة دون أخطاء حرجة |
| 3, الإطلاق | النشر على المتجرين + لوحة التحكم | قبول التطبيق في Google Play و App Store |
| 4, الدعم بعد الإطلاق | فترة ضمان وإصلاح أخطاء | مدة الضمان ونطاقه في العقد |
الميزانية والجوانب التجارية
ذكر نطاق ميزانيتك لا يضعفك تفاوضيا، بل يجعل العروض واقعية ومصممة على مقاسك بدل عروض عشوائية. وتذكر: ملكية الكود يجب أن تكون لك، بالعقد.
| الدفعة | النسبة | مرتبطة بـ |
|---|---|---|
| مثال: دفعة أولى | % | توقيع العقد وبدء التحليل |
| مثال: دفعة ثانية | % | اعتماد التصميم / تسليم MVP |
| مثال: دفعة أخيرة | % | الإطلاق على المتجرين |
- الملكية الفكرية: الكود المصدري والتصميمات والدومين وحسابات المتاجر ملك للعميل، ينص على ذلك في العقد صراحة.
- عقد مكتوب: النطاق، الجدول، الدفعات، والضمان، كلها مكتوبة وموقعة.
الافتراضات والمخاطر وخارج النطاق
القسم الذي يمنع معظم الخلافات: ما تفترضه، وما قد يعطل المشروع، وما هو خارج الاتفاق صراحة.
مسرد المصطلحات
حتى يقرأ الجميع، التقني وغير التقني، نفس الكلمات بنفس المعنى.
| المصطلح | المعنى |
|---|---|
| MVP | النسخة الأولى القابلة للإطلاق بالميزات الأساسية فقط |
| API | واجهة ربط برمجية بين التطبيق والأنظمة الأخرى |
| MoSCoW | منهجية ترتيب الأولويات: Must / Should / Could / Won't |
| UAT | اختبار القبول من العميل قبل الإطلاق |
ما الذي يجعل مستند المتطلبات جيدا؟
رأينا مئات المستندات من العملاء عبر السنين، والجيد منها يشترك في أربع صفات:
- محدد: «إشعار للعميل عند تغير حالة الطلب» أفضل من «نظام إشعارات متكامل». الجملة الأولى يمكن تسعيرها وبرمجتها واختبارها؛ الثانية باب مفتوح للتأويل.
- قابل للاختبار: كل متطلب يجب أن تستطيع أن تسأل عنه لاحقا: «كيف نتأكد أنه تحقق؟». إن لم يوجد جواب، أعد صياغته.
- مرتب الأولويات: قائمة من 40 ميزة كلها «ضرورية» تعني عمليا أن لا شيء ضروري. تصنيف MoSCoW في القسم 5 يحسم ذلك.
- صادق مع المجهول: «TBD، سنحدد بوابة الدفع بعد مقارنة العمولات» أفضل ألف مرة من اختيار عشوائي يتغير لاحقا. الشركات المحترمة تقدر الوضوح وتساعدك في حسم المفتوح.
ولا تنشغل بالكمال: مستند معبأ بنسبة 70% ومرسل اليوم أنفع من مستند مثالي لا يكتمل أبدا. الأقسام 2 و3 و5 هي الحد الأدنى الذي يسمح لأي شركة جادة بتقدير مشروعك.
مستند المتطلبات مقابل الـBrief مقابل العرض الفني
تختلط هذه المستندات الثلاثة على كثيرين، والفرق بسيط:
- الـBrief (الموجز): صفحة واحدة تعرف بالفكرة والجمهور والميزانية، مناسب للتواصل الأول وجس النبض. يمكنك توليده في دقائق بـمولد الـBrief المجاني لدينا.
- مستند المتطلبات (هذه الصفحة): 5–15 صفحة تفصل الميزات والأولويات والتكاملات ومعايير القبول، هو الأساس الذي تبنى عليه عروض أسعار دقيقة وقابلة للمقارنة، ثم يرفق بالعقد.
- العرض الفني (Proposal): تكتبه الشركة ردا على مستندك: فهمها للنطاق، والمنهجية، والجدول، والسعر. جودة العرض الذي تستلمه تعكس مباشرة جودة المتطلبات التي أرسلتها.
الترتيب الطبيعي إذن: Brief للتواصل الأول ← مستند متطلبات للشركات المرشحة ← عروض فنية تقارن بينها بعدل. وإذا أردت تقدير ميزانية قبل ذلك كله، جرب حاسبة تكلفة التطبيقات.
الترخيص وطريقة الاقتباس
هذا القالب مجاني للاستخدام والتعديل في مشاريعك الخاصة، التجارية وغير التجارية، ولا تحتاج إلى ذكرنا داخل مستندك. أما إعادة نشره أو توزيع الملف أو بيعه بأي صورة فيشترط رابطا ظاهرا إلى هذه الصفحة.
طريقة الاقتباس: ويب بايونير (2026). قالب مستند متطلبات تطبيق الجوال. web-pioneer.com. https://web-pioneer.com/templates/mobile-app-requirements-document
أسئلة شائعة
هل أحتاج هذا المستند فعلا قبل طلب عروض الأسعار؟
نعم، وهذا أهم استخدام له. بدون متطلبات موحدة ستستلم عروضا مبنية على افتراضات مختلفة يستحيل مقارنتها، وغالبا ما يفوز العرض الأرخص لأنه افترض الأقل. مستند واحد يرسل لكل الشركات يجعل المقارنة عادلة ويحميك من «هذا لم يكن ضمن الاتفاق» لاحقا.
ما الطول المناسب لمستند المتطلبات؟
لتطبيق متوسط: 5 إلى 15 صفحة كافية تماما. الأهم من الطول أن تكون الميزات مرتبة الأولويات ومعايير القبول واضحة. المستندات الأطول من ذلك عادة تخلط المتطلبات بالتصميم التفصيلي، وهذا دور الشركة المنفذة في مرحلة التحليل.
هل تساعدني ويب بايونير في تعبئة القالب؟
نعم، مجانا. أرسل لنا المستند بأي درجة اكتمال عبر النموذج أدناه أو واتساب، ونراجعه معك في جلسة قصيرة: نسد الفجوات ونشير إلى المخاطر، ثم نقدم عرض سعر مكتوبا خلال يوم عمل واحد، دون أي التزام عليك بالتعاقد معنا.
لدي فكرة حساسة، هل توقعون اتفاقية عدم إفصاح (NDA)؟
نعم. نوقع اتفاقية عدم إفصاح قبل استلام أي تفاصيل إذا طلبت ذلك، ونتعامل مع كل المستندات الواردة بسرية كاملة. نعمل بعقود مكتوبة منذ 2014 وسجلنا التجاري 206687 معلن.
بأي صيغة تسلم المواصفات في مشاريعكم الفعلية؟
في المشاريع الحقيقية نحول مستند المتطلبات بعد التعاقد إلى: نطاق تفصيلي يوقعه الطرفان ويلحق بالعقد، نماذج شاشات تفاعلية (Figma) تعتمد قبل البرمجة، وتوثيق فني للـAPI ولوحة التحكم عند التسليم، مع ملكية كاملة لكل ذلك للعميل.
جاهز لتحويل المتطلبات إلى تطبيق حقيقي؟
أرسل لنا مستندك، نراجعه مجانا ونرد بعرض سعر مكتوب خلال يوم عمل واحد، بعقد واضح وملكية كاملة للكود.
حمل القالب واحصل على مراجعة مجانية
أدخل بياناتك وسيبدأ تحميل ملف Word فورا، وفريقنا جاهز لمراجعة مستندك مجانا وإرسال عرض سعر مكتوب خلال يوم عمل واحد.
