---
title: "كيف تكتب متطلبات مشروع برمجي يمكن تسعيره بدقة؟"
description: "قالب من صفحة واحدة لمتطلبات مشروع برمجي: المستخدمون وسير العمل والأولويات والتكاملات والبيانات ومعايير النجاح، وما تتركه جانبًا، وكيف يُبنى عرض السعر."
url: https://kftechsolutions.dev/ar/blog/software-project-brief
language: ar
published: 2026-11-06
modified: 2026-11-06
author: Kirollos Fayez
site: "KF Tech Solutions — https://kftechsolutions.dev"
---

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

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

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

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

## ما الغرض من وثيقة المتطلبات؟

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

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

## قالب الصفحة الواحدة

انقل هذا الهيكل إلى مستند واملأ كل صف بلغة بسيطة.

| القسم | ماذا تكتب | مثال |
|---|---|---|
| الخلفية | المنشأة والمشكلة في جملتين أو ثلاث | موزّع لديه ثلاثة مستودعات يتابع الطلبات في جداول بيانات، وأرقام المخزون لا تتطابق أبدًا |
| المستخدمون | كل فئة من المستخدمين وعددها التقريبي | 12 مندوب مبيعات و4 موظفين في المستودع ومديران ونحو 300 عميل |
| سير العمل | المهام الرئيسية في صورة خطوات قصيرة | المندوب يسجّل الطلب، والمستودع يجهّزه، والسائق يسلّمه، ثم تصدر الفاتورة |
| الأولويات | ضروري ومهم وممكن ومؤجل | ضروري: الطلبات والمخزون. ممكن: تطبيق جوال للعملاء |
| التكاملات | الأنظمة التي يجب أن يتصل بها | برنامج المحاسبة، وواتساب، وبوابة دفع |
| البيانات | ما يحفظه النظام وما يُنقل إليه من الوضع الحالي | 2,000 منتج وسجلات العملاء لخمس سنوات في ملفات Excel |
| النجاح | كيف ستعرف أنه يعمل | تطابق جرد المخزون مع الرفوف خلال أسبوع من الإطلاق |
| القيود | الموعد النهائي ونطاق الميزانية واللغات والأجهزة | التشغيل خلال أربعة أشهر، بالعربية والإنجليزية، والموظفون يستخدمون هواتف أندرويد |

## المستخدمون وسير العمل

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

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

## ضروري ومهم وممكن ومؤجل

قسّم الخصائص إلى أربع مجموعات. هذه هي طريقة MoSCoW المستخدمة على نطاق واسع في المشروعات الرشيقة (Agile):

- **ضروري (Must have):** لا فائدة من النظام عند إطلاقه بدونها.
- **مهم (Should have):** مهمة، لكن يوجد بديل مؤقت في الأسابيع الأولى.
- **ممكن (Could have):** مفيدة إذا سمح الوقت والميزانية.
- **مؤجل هذه المرة (Won't have this time):** متفق على أنها خارج النطاق حاليًا.

كن صارمًا مع قائمة الضروري. فاتحاد الأعمال الرشيقة (Agile Business Consortium)، الذي يتولى إطار DSDM الذي نشأت منه هذه الطريقة، يوصي بألا يتجاوز جهد المتطلبات الضرورية في العادة 60% من إجمالي الجهد، حتى تعمل البنود المهمة والممكنة كهامش أمان عندما يتبيّن أن التقديرات غير دقيقة. ولقائمة المؤجل أهميتها أيضًا: فهي تمنع عودة البنود إلى النطاق خلسة فيما بعد.

## التكاملات والبيانات ومعايير النجاح

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

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

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

## ما الذي تتركه خارج الوثيقة؟

الوثيقة الجيدة تصف المشكلة لا الحل. اترك خارجها:

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

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

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

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

إذا كانت الوثيقة واضحة ونطاق العمل مستقرًا، تكون النتيجة سعرًا ثابتًا مرفقًا به نطاق عمل مكتوب. أما إذا كانت أجزاء كبيرة غير معروفة، فالمطوّر الأمين إما يقترح مرحلة استكشاف مدفوعة أولًا، وإما يقترح التعاقد بالوقت والمواد. ويشرح دليلنا عن [السعر الثابت مقابل الوقت والمواد](https://kftechsolutions.dev/blog/fixed-price-vs-time-and-materials) متى يناسب كل نموذج، ويوضح مقال [التكلفة الفعلية لبناء تطبيق ويب](https://kftechsolutions.dev/blog/what-does-a-web-app-actually-cost-to-build) أين تذهب الأموال.

قارن العروض على أساس الوثيقة نفسها، واسأل كل جهة عمّا هو مستبعد من عرضها. وإذا لم تكن لديك خلفية تقنية، فمقال [كيف تختار شركة برمجيات](https://kftechsolutions.dev/blog/how-to-choose-a-software-company) يزوّدك بالأسئلة المناسبة، ويتناول مقال [لماذا تفشل المشروعات البرمجية](https://kftechsolutions.dev/blog/why-software-projects-fail) الأخطاء التي تمنعها الوثيقة الواضحة.

في KF Tech Solutions نبني [البرمجيات المخصصة](https://kftechsolutions.dev/services/custom-software)، ونعمل مع المنشآت في مصر والخليج. نراجع وثيقتك معك في مكالمة، ونسأل عن كل ما تركته مفتوحًا. تبدأ المشروعات من 200 دولار (نحو 750 ريالًا سعوديًا / 735 درهمًا إماراتيًا)، ويتحدد السعر النهائي حسب نطاق العمل، مع عرض سعر ثابت مكتوب بعد مكالمة مجانية.

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

### ما الطول المناسب لوثيقة متطلبات المشروع البرمجي؟

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

### هل أُفصح عن ميزانيتي؟

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

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

هذا ما يحدث عادةً. اتفقوا في العقد على كيفية طلب التغييرات وتسعيرها واعتمادها قبل بدء أي عمل عليها. ووجود قائمة واضحة للبنود المؤجلة يجعل هذه النقاشات أسهل كثيرًا.

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

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

هل لديك مسودة وثيقة، أو مشكلة تريد وصفها فقط؟ [أرسلها إلينا](https://kftechsolutions.dev/contact) أو [احجز مكالمة مجانية](https://kftechsolutions.dev/book)، وسنراجعها معك.

## المصادر

- [ترتيب الأولويات بطريقة MoSCoW، إطار DSDM، اتحاد الأعمال الرشيقة (Agile Business Consortium)](https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html)

---

KF Tech Solutions is a software studio in Cairo, Egypt, founded by Kirollos Fayez in 2020; its only website is kftechsolutions.dev. It is not affiliated with KFTECH Software Solutions (kftechsols.com).