# كراسة الشروط لتطبيق جوال: نموذج من صفحة واحدة

> كراسة شروط من صفحة واحدة تحدد بها نطاق تطبيق iOS الخاص بك وتوجّه الذكاء الاصطناعي: 10 أسئلة، ونموذج تنسخه، وما يجب ألا تضعه فيها.

الصفحة الأصلية: [كراسة الشروط لتطبيق جوال: نموذج من صفحة واحدة](https://devoria.fr/ar/blog/mobile-app-requirements-document-one-page-template)
الكاتب: [Mehdi Azizi](https://devoria.fr/ar/mehdi-azizi)
النشر: 2026-08-31
آخر مراجعة للمحتوى: 2026-10-09


## كراسة الشروط لتطبيق جوال: الإجابة المختصرة

كراسة الشروط الجيدة لتطبيق جوال، عندما تبني تطبيقك الخاص، تكفيها صفحة واحدة. تجيب فيها عن عشرة أسئلة: لمن التطبيق، وما المشكلة التي يحلها، وما وظيفته الرئيسية، وكيف يربح المال، وماذا يحدث بدون حساب، وما البيانات التي يجب أن تبقى محفوظة، وعلى أي منصة، وما الذي يبقى خارج النسخة الأولى، وكيف ستعرف أنه ينجح، وما قيودك. النموذج الذي تنسخه موجود في الأسفل. ويمكنك أيضًا [تحميل القالب مع جدول التحقق الخاص به (.md)](https://devoria.fr/ressources/cahier-des-charges-app-ios.md)، بدون تسجيل.

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

أنا أنشر تطبيقات iOS الخاصة بي. Solys، منبّه بألعاب صغيرة، وTradaZen، محاكي تداول، متاحان على App Store. أما Nolera وClic فقد رفضتهما Apple، ثم صحّحتهما. هذه هي الطريقة التي أطبقها على كل واحد منها، وهي التي أقترحها عليك هنا.

## لماذا تكفي صفحة واحدة لتحديد نطاق تطبيقك

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

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

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

## ماذا يجب أن تحتوي كراسة الشروط لتطبيق جوال؟

أجب عن كل سؤال من هذه الأسئلة بجملة أو جملتين.

1. **من يستخدم التطبيق، وفي أي موقف؟** ليس «الفئة من 18 إلى 35 عامًا». بل شخص محدد، في لحظة محددة من يومه.
2. **ما المشكلة التي يحلها التطبيق، في جملة واحدة؟** إذا احتجت إلى «وأيضًا»، فأنت تصف تطبيقين.
3. **ما هي الوظيفة الرئيسية الوحيدة في النسخة الأولى؟** وظيفة واحدة فقط. الباقي ينتظر الأرقام. صفحة [MVP لتطبيق iOS](https://devoria.fr/ar/expertise/ios-app-mvp) تشرح كيف تختار.
4. **كيف يربح التطبيق المال؟** اشتراك، أو شراء لمرة واحدة، أو مجاني. هذه الإجابة تغيّر التطبيق منذ الشاشة الأولى. إذا كنت مترددًا، اقرأ [اشتراك أم شراء لمرة واحدة لتطبيق iOS](https://devoria.fr/ar/blog/ios-app-subscription-vs-one-time-purchase).
5. **ماذا يمكن فعله بدون إنشاء حساب؟** حسم ما هو متاح بدون تسجيل مبكرًا يجنبك إعادة بناء مسار الاستقبال كاملًا.
6. **ما البيانات التي يجب أن تبقى عند تغيير الهاتف؟** هذا هو السؤال الذي يحدد هل تحتاج إلى خادم خلفي مثل Supabase، أم يمكن أن يبقى كل شيء على الجهاز.
7. **iOS فقط، أم iOS وAndroid؟** نصيحتي عندما تبدأ: iOS أولًا. أشرح السبب بالتفصيل في [تطبيق iOS وAndroid في الوقت نفسه](https://devoria.fr/ar/blog/ios-or-android-app-which-first).
8. **ما الذي يبقى صراحةً خارج النسخة الأولى؟** القسم الأكثر فائدة في الوثيقة. يقطع النقاشات قبل أن تبدأ، مع نفسك ومع الذكاء الاصطناعي.
9. **كيف ستعرف أنه ينجح؟** إشارة واحدة، قابلة للقياس في الأسابيع التي تلي الإطلاق: تجارب مجانية بدأت، مشتركون، مستخدمون يعودون.
10. **ما قيودك الحقيقية؟** الوقت الذي تستطيع تخصيصه كل أسبوع، وأجهزتك، و[حساب Apple Developer](https://devoria.fr/ar/blog/apple-developer-account-price-free-or-99) الذي يكلّف [99 دولارًا في السنة](https://developer.apple.com/programs/enroll/). ليس لديك Mac؟ هذا ليس عائقًا، كما أشرح في [نشر تطبيق iOS بدون Mac](https://devoria.fr/ar/blog/publish-ios-app-without-mac-expo-eas).

## نموذج كراسة الشروط لتنسخه

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

- **الاسم المؤقت للتطبيق:** …
- **لمن:** شخص … في اللحظة التي …
- **المشكلة المحلولة، في جملة واحدة:** …
- **الوظيفة الرئيسية في النسخة 1:** …
- **ما يراه المستخدم عند فتح التطبيق لأول مرة:** …
- **نموذج الربح:** اشتراك / شراء لمرة واحدة / مجاني، وما هو مدفوع: …
- **بدون حساب، يمكن:** …
- **البيانات التي تُحفظ بين هاتفين:** لا شيء / …
- **المنصة:** iOS أولًا (Android لاحقًا إذا جاءت الأرقام جيدة)
- **خارج النسخة 1:** …، …، …
- **إشارة النجاح:** …
- **التقنيات:** React Native، Expo، وSupabase إذا احتجت إلى حسابات، وRevenueCat للاشتراكات
- **القيود:** … ساعات في الأسبوع، حساب Apple Developer مفتوح أم لا، Mac أم لا
- **تطبيقات تعجبني تجربتها، ولماذا:** …

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

> كراسة الشروط ليست قائمة أمنيات. إنها قائمة قرارات اتُّخذت.

## مثال: الصفحة مكتملة لتطبيق خيالي

لترى مستوى التفصيل المطلوب، هذا هو النموذج مكتملًا لتطبيق مخترع للمثال: مؤقّت للمذاكرة.

- **لمن:** طالب يذاكر وحده في المساء ويفقد تركيزه بعد عشر دقائق.
- **المشكلة:** لا يستطيع إكمال جلسة عمل دون أن يلمس هاتفه.
- **الوظيفة الرئيسية:** بدء جلسة موقوتة ورؤية سلسلة الأيام التي التزم فيها.
- **الشاشة الأولى:** زر واحد فقط لبدء جلسة.
- **نموذج الربح:** اشتراك للإحصائيات المفصلة، والجلسة الأساسية مجانية.
- **بدون حساب:** كل شيء، ما عدا النسخ الاحتياطي بين هاتفين.
- **خارج النسخة 1:** وضع المجموعات، الترتيب بين الأصدقاء، الويدجت، نسخة Android.
- **إشارة النجاح:** مستخدمون يعودون عدة أيام متتالية.

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

## كيف تستخدم كراسة الشروط لتوجيه الذكاء الاصطناعي

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

**ضع الصفحة في السياق الدائم للمشروع.** Claude Code يقرأ ملف `CLAUDE.md` في الجذر، وCursor له ملفات القواعد الخاصة به. الصق فيه كراسة الشروط، مع التقنيات التي تستخدمها. هكذا ينطلق كل طلب من الأساس نفسه.

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

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

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

للتعمق في هذا الموضوع، فصّلت الفخاخ وعمليات التحقق في [إنشاء تطبيق iOS بالذكاء الاصطناعي](https://devoria.fr/ar/blog/build-ios-app-with-ai-pitfalls-checks).

## تحويل القرارات إلى معايير تحقق

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

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

هذا جدول مكتمل لمؤقّتنا الخيالي. إنها معايير للتحقق منها، وليست اختبارات نجحت بالفعل:

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

المواضيع التي ما زالت غامضة تتحول إلى قرارات يجب اتخاذها. مثلًا: ماذا يحدث إذا أقفل المستخدم الشاشة أو غيّر ساعة الهاتف أثناء جلسة؟ لا تترك الوكيل يختار بصمت. اكتب السلوك المطلوب، ثم أضف الحالة إلى الجدول. لتنظيم هذا الاختبار على تثبيت حقيقي، استخدم دليل [اختبار تطبيق iPhone باستخدام TestFlight](https://devoria.fr/ar/blog/testflight-test-iphone-app-before-submission).

### تحديد ما تحذفه عندما تتضخم النسخة الأولى

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

سجّل القرار وسببه في [سجل النموذج القابل للتحميل](https://devoria.fr/ressources/cahier-des-charges-app-ios.md). ستتمكن من التراجع عن هذا الخيار بعد الاختبارات، دون أن تفقد سبب النطاق الأولي. ثم يوضح الدرس [إنشاء تطبيق باستخدام Claude Code](https://devoria.fr/ar/blog/create-iphone-app-with-claude-code-tutorial) كيف تحوّل هذا التحديد إلى طلبات محدودة وقابلة للتحقق.

لتجربة من الواقع، [غيّر TradaZen نطاقه بعد نشره](https://devoria.fr/ar/blog/tradazen-case-study-launch-iphone-app). التحديد يساعدك على إطلاق نسخة أولى قابلة للقياس، ثم تقرر النسخة التالية بناءً على ملاحظات حقيقية.

## فخ قائمة الوظائف الطويلة

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

النسخة الأولى الجيدة تفعل شيئًا واحدًا، وتفعله جيدًا. لكن احذر من المبالغة في الاتجاه المعاكس: تطلب Apple أن يتجاوز التطبيق مجرد موقع ويب مغلّف، وفق [القاعدة 4.2 من App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/). وظيفة رئيسية واحدة، نعم؛ قشرة فارغة، لا: هذا هو سبب الرفض بموجب [guideline 4.2](https://devoria.fr/ar/blog/guideline-4-2-minimum-functionality-app-rejected).

## ما يجب ألا تحتويه كراسة الشروط لتطبيق جوال

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

## متى تحدّث كراسة الشروط؟

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

بعد نشر النسخة الأولى، تصبح الصفحة أساس النسخة التالية: ما كان خارج النسخة 1 يصعد، مرتبًا حسب ما تقوله لك الأرقام. النظرة الشاملة على المسار، من الفكرة إلى النشر، موجودة في صفحة [إنشاء تطبيق iPhone](https://devoria.fr/ar/expertise/create-an-iphone-app).

## من الصفحة إلى التطبيق المنشور

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

هذا المسار هو مسار [iOS Kit](https://devoria.fr/ar/kits/ios)، في أربع مراحل تتبعها بالسرعة التي تناسبك: الأولى تساعدك على اختيار التطبيق الذي يمكن أن يربح، وجمهوره وسعره، وكراسة الشروط هي نقطة انطلاقها.

لا تعرف هل فكرتك جاهزة لتكفيها صفحة واحدة؟ [التشخيص المجاني](https://devoria.fr/ar/diagnostic) يخبرك بما يعيق مشروعك اليوم وبأي مرحلة تبدأ. ثم تعرض الصفحة الرئيسية كيف [تنشئ تطبيق جوال](https://devoria.fr/ar) انطلاقًا من هذا التحديد، باستخدام Claude Code.

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

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

### كيف تكتب كراسة الشروط لتطبيق جوال؟

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

### ما البرنامج الذي تستخدمه لكتابة كراسة الشروط لتطبيق؟

ملاحظة بسيطة أو ملف نصي في جذر مشروعك: تنسخ فيه النموذج، ثم تستبدل كل سطر. ويمكنك أيضًا [تحميل القالب مع جدول التحقق الخاص به (.md)](https://devoria.fr/ressources/cahier-des-charges-app-ios.md)، بدون تسجيل. ولتوجيه الذكاء الاصطناعي، ضعه بعد ذلك في ملف السياق الخاص بمشروعك.

### هل تحتاج إلى كراسة شروط من 40 صفحة لتطبيق؟

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

### كيف تعطي كراسة الشروط لذكاء اصطناعي يكتب الكود؟

ضع الصفحة في السياق الدائم للمشروع: Claude Code يقرأ ملف `CLAUDE.md` في الجذر، وCursor له ملفات القواعد الخاصة به. استشهد بقسم «خارج النسخة 1» عندما يبالغ الذكاء الاصطناعي. وقبل أي عمل كبير، اطلب خطة تحترم الصفحة، دون كتابة الكود فورًا.

### كيف تتحقق من أن وظيفة ما تحترم كراسة الشروط؟

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

### ما الذي يجب ألا تضعه في كراسة الشروط لتطبيق؟

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


## مشروعك

[iOS Kit](https://devoria.fr/ar/kits/ios): أنشئ تطبيق iPhone مع Claude Code: الكود الأساسي لتطبيقاتي، والمهارات التي تتحقق من عمله، وحزم Apple Review Kit وApp Store Screenshots Kit وASO Kit. 129,99 €.