كيفية كتابة وثيقة متطلبات تطوير البرمجيات [قالب + دليل]

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

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

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

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

---

لماذا تُهم وثيقة المتطلبات الجيدة

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

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

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

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

---

ما ليست عليه وثيقة متطلبات البرمجيات

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

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

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

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

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

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

---

الأقسام الثمانية التي يجب أن تتضمنها كل وثيقة متطلبات برمجية

1. نظرة عامة على المشروع

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

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

يجب أن تتناول نظرتك العامة على المشروع:

• المشكلة أو الفرصة الجوهرية التي تعالجها
• من يعاني من هذه المشكلة حالياً وكيف يتعامل معها اليوم
• لماذا الآن — ما الذي تغيّر، أو ما الذي يدفع هذه المبادرة في هذه المرحلة بالذات
• وصف موجز للحل الذي تفكر فيه (مع مراعاة أن هذا نقطة انطلاق، لا متطلب ثابت)
• نوع المنتج الذي تبنيه — تطبيق ويب، أو تطبيق جوال، أو أداة داخلية، أو منصة API، أو نظام تجارة إلكترونية، أو مزيج من ذلك

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

2. السياق التجاري والأهداف

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

يجب أن يتناول هذا القسم:

• نموذج عملك — هل تبني لعملاء، أم لمستخدمين داخليين، أم لكليهما؟ هل هذا منتج يُدرّ إيرادات أم مبادرة لخفض التكاليف؟
• الأهداف التجارية — ما الذي يبدو عليه النجاح من منظور الأعمال؟ زيادة المعاملات، أو خفض التكاليف التشغيلية، أو تسريع وقت المعالجة، أو دخول سوق جديد؟
• مقاييس نجاح قابلة للقياس — كيف ستعرف بعد 12 شهراً أن المشروع نجح؟ كن محدداً. "تحسّن الكفاءة" ليس مقياساً. "تقليل وقت إدخال البيانات يدوياً بنسبة 60%" هو مقياس.
• الأهمية الاستراتيجية — هل هذا منتج أساسي أم أداة داعمة؟ هل هو نموذج أولي لاختبار الطلب، أم نظام إنتاجي يحل محل شيء قائم؟
• مشهد أصحاب المصلحة — من يهتم بهذا المشروع داخلياً وكيف؟ الوثيقة التي تذكر "الرئيس التنفيذي يرعى هذه المبادرة شخصياً" أو "المدير المالي أقر الميزانية بشرط الإطلاق في ديسمبر" تُخبر الشركة الكثير عن الديناميكيات التي ستعمل ضمنها.

3. المستخدمون

أفضل البرمجيات تُبنى على فهم دقيق لمن سيستخدمها وما يحتاج إلى إنجازه. الأوصاف العامة للمستخدمين ("أصحاب الأعمال الصغيرة"، "عملاء المؤسسات الكبرى") لا تكاد تفيد بشيء. أما الأوصاف الدقيقة فقيّمة للغاية.

لكل نوع مستخدم، صف:

• هويتهم — دورهم، وسياقهم، والبيئة التي سيستخدمون فيها المنتج (مكتب، أجهزة جوالة، ميدان، بيئة عمليات عالية الضغط)
• مستواهم التقني — هل هم مرتاحون مع واجهات برمجية معقدة، أم يحتاجون إلى تجربة مبسّطة للغاية؟ هل يستخدمون أدوات مماثلة بالفعل؟
• ما يحتاجون إلى إنجازه — المهمتان أو الثلاث اللتان يحتاجون إلى تنفيذهما بكفاءة باستخدام هذا المنتج
• الحجم — لكم مستخدم من هذا النوع تصمم؟ عشرة مستخدمين داخليين لهم متطلبات مختلفة تماماً عن عشرة آلاف مستهلك
• متطلبات إمكانية الوصول — الالتزامات القانونية أو الاعتبارات المتعلقة بذوي الإعاقة

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

4. الميزات والوظائف الأساسية

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

هيكل هذا القسم حول فئتين:

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

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

لكل ميزة جوهرية، اكتب قصة مستخدم موجزة بالصيغة: "بوصفي [نوع المستخدم]، أريد أن [أفعل شيئاً]، حتى أتمكن من [تحقيق نتيجة]." قصص المستخدمين تُبقي الأوصاف مركّزة على احتياج المستخدم لا على افتراضات الواجهة.

على سبيل المثال:

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

لا تحتاج إلى قصة مستخدم لكل تفاعل صغير. ركّز على التدفقات التي تُعرّف المنتج.

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

5. المتطلبات والقيود التقنية

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

تناول ما يلي بحسب ما ينطبق:

• الأنظمة الحالية والتكاملات — هل يحتاج هذا المنتج إلى الاتصال ببرامج أخرى؟ أدرج كل نظام باسمه. إدارة علاقات العملاء (Salesforce، HubSpot)، أنظمة تخطيط موارد المؤسسات (SAP، NetSuite)، بوابات الدفع (Stripe، PayPal)، منصات التواصل (Twilio)، برامج المحاسبة (Xero، QuickBooks)، واجهات برمجية للخدمات اللوجستية. عمل التكامل هو في الغالب المصدر الأهم للتعقيد والتكاليف غير المتوقعة، لذا كلما كنت أكثر تحديداً هنا كان أفضل.
• نقل البيانات — هل تنقل بيانات من نظام قائم؟ كم حجمها، وبأي صيغة، وما مدى تعقيدها؟
• تفضيلات الاستضافة والبنية التحتية — هل لديك تفضيل لمنصة سحابية (AWS، Azure، Google Cloud)؟ بنية تحتية قائمة تحتاج إلى النشر ضمنها؟ متطلبات محددة لإقامة البيانات جغرافياً؟
• القيود التقنية — هل لدى فريقك الداخلي تفضيل أو متطلب تقني؟ هل لديك مطورون سيصونون المنتج بعد الإطلاق، وإن كان الأمر كذلك، ما هي حزمة التقنيات لديهم؟
• متطلبات الامتثال والتنظيم — GDPR، وPCI-DSS للمعاملات المالية، وHIPAA لبيانات الرعاية الصحية، وISO 27001، ولوائح هيئة الرقابة المالية، ومعايير إمكانية الوصول (WCAG). أدرج كل التزام امتثال تعلم به.
• متطلبات الأداء — هل يحتاج النظام إلى استيعاب أعداد كبيرة من المستخدمين المتزامنين؟ معالجة البيانات في الوقت الفعلي؟ أوقات استجابة دون ثانية تحت الأحمال؟
• متطلبات المتصفحات والأجهزة — ما المتصفحات والأجهزة التي يجب أن يدعمها المنتج؟ هل يحتاج إلى العمل دون اتصال؟

6. التصميم والهوية التجارية

أوضح نقطة انطلاقك حتى تتمكن الشركة من تحديد نطاق العمل التصميمي بدقة.

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

7. الميزانية والجدول الزمني

هذا هو القسم الذي يتركه العملاء فارغاً في أغلب الأحيان، وهو أغلى الإغفالات. سنتناول مسألة الميزانية مباشرة: الامتناع عن الإفصاح عن ميزانيتك لا يحميك. بل يفعل العكس.

حين لا تعرف الشركة ميزانيتك، لا تستطيع تحديد النطاق وفقاً لها. إما ستبالغ في الهندسة (مقدمةً عرضاً لا تستطيع تحمله)، أو ستُضيّق النطاق (مقدمةً عرضاً يفتقد ما تحتاجه فعلاً). في كلتا الحالتين، تضيع وقتك ووقتهم، وتنتهي بعروض لا يمكن مقارنتها بشكل مفيد.

لا تحتاج إلى الالتزام برقم دقيق. النطاق ("لدينا ميزانية في حدود 60,000–80,000 جنيه إسترليني للمرحلة الأولى") كافٍ تماماً ويمنح الشركة كل ما تحتاجه لتحديد النطاق بشكل مناسب.

بالنسبة للجدول الزمني:

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

8. معايير الاختيار

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

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

---

قالب وثيقة المتطلبات

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

---

TradeHub — منصة السوق بين الشركات — وثيقة متطلبات تطوير البرمجيات

مقدمة من: Acme Distribution Ltd — سارة تشن، رئيسة قسم المنتجات التاريخ: 15 يناير 2025 الموعد النهائي للرد: 31 يناير 2025

---

القسم الأول: نظرة عامة على المشروع

ما هي المشكلة الجوهرية التي ستحلها هذه البرمجية؟ من يعاني منها؟ لماذا يُعالَج هذا الأمر الآن؟ ما نوع المنتج الذي تبنيه؟

• بيان المشكلة: تدير شبكتنا المكونة من أكثر من 400 مورد تجاري علاقاتها مع المشترين حالياً عبر مزيج من الطلبات الهاتفية ومرفقات PDF بالبريد الإلكتروني ونظام إدارة طلبات قديم يعود إلى عام 2011. لا يستطيع المشترون — وهم في الغالب مديرو المشتريات في شركات البناء وإدارة المرافق — تصفح المخزون الحالي أو التحقق من الأسعار الفورية أو تقديم الطلبات خارج ساعات العمل. لا يملك الموردون أي رؤية على نشاط المشترين أو حالة الطلبات دون متابعة يدوية.
• لماذا الآن: أطلق منافسان رئيسيان بوابات مشتريات رقمية في الأشهر الثمانية عشر الماضية. نخسر حسابات السوق المتوسطة تحديداً لأننا لا نستطيع تقديم تجربة طلب ذاتية الخدمة. وافق مجلس الإدارة على الميزانية للربع الأول من عام 2025.
• الحل المقترح (على مستوى عالٍ): سوق متعدد الموردين بين الشركات حيث يُدرج الموردون التجاريون المعتمدون منتجاتهم ويديرون مخزونهم، ويتصفح المشترون التجاريون المتحقق منهم المنتجات ويطلبون عروض أسعار ويُقدمون طلباتهم بشروط دفع مؤجلة. تتولى جهة تشغيل المنصة (نحن) تأهيل الموردين وتجني عمولات على المعاملات.
• نوع المنتج: تطبيق ويب (يُعطى الأولوية للحاسوب المكتبي مع استجابة للجوال)

---

القسم الثاني: السياق التجاري والأهداف

ما هي النتائج التجارية أو المؤسسية التي صُمِّم هذا المشروع لتحقيقها؟

• سياق نموذج العمل: عمولة منصة بنسبة 4–8% على كل معاملة، تتدرج بحسب حجم الموردين. لا رسوم إدراج على الموردين. يدفع المشترون بشروط صافي 30 أو صافي 60 يوماً بحسب حالة الحساب.
• الهدف التجاري الأساسي: الحفاظ على شبكة الموردين الحالية واسترداد 20% من حسابات المشترين في السوق المتوسطة المفقودة في غضون 12 شهراً من الإطلاق.
• مقاييس النجاح: إجمالي قيمة بضاعة 2 مليون جنيه إسترليني عبر المنصة في غضون 6 أشهر من الإطلاق؛ أكثر من 80 مورداً نشطاً مدرجاً خلال 90 يوماً؛ متوسط معدل تحويل جلسة المشتري إلى طلب فوق 18%.
• الأهمية الاستراتيجية: هذه هي مبادرة النمو الرقمي الأساسية للشركة لعامي 2025–2026. إنها ليست مشروعاً ثانوياً.
• أصحاب المصلحة الداخليون الرئيسيون: الرئيس التنفيذي (الموافقة النهائية)، رئيس قسم المنتجات (جهة الاتصال اليومية)، رئيس قسم التجارة (علاقات الموردين)، مدير تقنية المعلومات (قرارات البنية التحتية).

---

القسم الثالث: المستخدمون

من سيستخدم هذا المنتج؟ كرر لكل نوع مستخدم مميز.

نوع المستخدم 1 — المشتري التجاري (مدير المشتريات)

• الدور / الوصف: مديرو المشتريات وضباط التوريد في شركات البناء وإدارة المرافق والصيانة. يُقدمون طلبات متكررة للمواد الاستهلاكية والأدوات والمعدات نيابةً عن مؤسساتهم.
• المستوى التقني: متوسط — مرتاحون مع الأدوات القائمة على الويب، يستخدمون البريد الإلكتروني وجداول البيانات يومياً، لكنهم غير تقنيين
• المهام الرئيسية: تصفح المنتجات والبحث عنها عبر الموردين، والتحقق من الأسعار والتوافر، وتقديم الطلبات مقابل الحسابات القائمة، وتتبع حالة الطلبات، وإنشاء تقارير الشراء
• الحجم التقريبي: 2,000–3,000 مشترٍ مسجل عند الطرح الكامل
• متطلبات إمكانية الوصول: يُشترط الامتثال لمعيار WCAG 2.1 AA (بعض المستخدمين من المحترفين التجاريين الأكبر سناً)

نوع المستخدم 2 — المورد التجاري (البائع)

• الدور / الوصف: موظفو المبيعات والعمليات في شبكة الموردين لدينا. يديرون قوائم منتجاتهم، ويستجيبون لطلبات عروض الأسعار، وينفذون الطلبات المقدمة عبر المنصة.
• المستوى التقني: منخفض إلى متوسط — كثيرون منهم ليسوا متطورين رقمياً؛ يجب أن تكون الواجهة بسيطة
• المهام الرئيسية: رفع وإدارة قوائم المنتجات والأسعار، والرد على استفسارات المشترين، وإدارة مسار الطلبات، وعرض تحليلات المبيعات، واستلام المدفوعات
• الحجم التقريبي: 400–600 مورد مسجل

نوع المستخدم 3 — مسؤول المنصة (داخلي)

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

---

القسم الرابع: الميزات والوظائف الأساسية

الميزات الأساسية (بدونها لا يمكن إطلاق المنتج):

الميزة	قصة المستخدم	ملاحظات
كتالوج المنتجات والبحث	بوصفي مشترياً، أريد البحث في المنتجات وتصفيتها عبر جميع الموردين حتى أجد ما أحتاجه بسرعة	بحث نصي شامل، تصفية حسب الفئة والمورد والسعر والتوافر
طلب عرض السعر (RFQ)	بوصفي مشترياً، أريد طلب عرض سعر مخصص من مورد حتى أتمكن من التفاوض على السعر في الطلبات الكبيرة	يتلقى المورد إشعاراً ويرد ضمن المنصة
الدفع بشروط مؤجلة	بوصفي مشترياً، أريد تقديم طلب مقابل حساب الائتمان الخاص بي حتى أدفع بشروط صافي 30 دون بطاقة	حدود حساب الائتمان يضبطها مسؤول المنصة لكل مشترٍ
إدارة منتجات البائع	بوصفي مورداً، أريد إضافة قوائم منتجاتي وأسعاري وتحديثها حتى يبقى كتالوجي محدثاً	يُشترط رفع CSV بكميات كبيرة للموردين أصحاب الكتالوجات الضخمة
إدارة الطلبات (للطرفين)	بوصفي مورداً، أريد رؤية الطلبات الواردة وتحديد حالتها كمُرسَلة حتى يتلقى المشترون تحديثات الحالة	إشعارات بريد إلكتروني عند كل تغيير في الحالة
محرك العمولات والمدفوعات	بوصفي مشغل منصة، أريد احتساب العمولة تلقائياً على كل معاملة وجدولة المدفوعات للموردين	Stripe Connect لتقسيم المدفوعات والعائدات

الميزات المرغوبة (ذات قيمة لكن غير مطلوبة للإطلاق):

الميزة	قصة المستخدم	ملاحظات
قوائم الطلبات المحفوظة / المفضلات	بوصفي مشترياً، أريد حفظ المنتجات التي أطلبها بانتظام حتى أتمكن من إعادة طلبها بسرعة	أولوية للإصدار 1.1
تقييمات أداء الموردين	بوصفي مشترياً، أريد رؤية تقييمات الوفاء بالطلبات للموردين حتى أتخذ قرارات مستنيرة	يستلزم سياسة إشراف قبل الإطلاق
تكامل ERP (Sage/Xero)	بوصفي مشترياً، أريد مزامنة الطلبات تلقائياً مع نظام المحاسبة الخاص بنا	يعتمد على أنظمة ERP التي يستخدمها المشترون فعلاً — يحتاج مزيداً من البحث

خارج النطاق صراحةً لهذا التعاون:

• تطبيقات iOS أو Android الأصلية (الويب المتجاوب كافٍ للإطلاق)
• متعدد العملات أو الشحن الدولي (السوق البريطانية فقط عند الإطلاق)
• صفحات منتجات عامة لتحسين محركات البحث (المنصة مغلقة على الحسابات المسجلة فقط)

---

القسم الخامس: المتطلبات والقيود التقنية

• التكاملات المطلوبة: Stripe Connect (تقسيم المدفوعات وعائدات الموردين)، SendGrid (البريد الإلكتروني التعاملي)، HubSpot CRM (مزامنة سجلات المشترين والموردين)، Companies House API (التحقق من هوية الشركات KYB أثناء تأهيل الموردين)
• نقل البيانات: نعم — ما يقارب 12,000 سجل منتج من النظام القديم (قاعدة بيانات SQL Server، متاحة للتصدير بصيغة CSV). بيانات حسابات الموردين والمشترين تحتاج أيضاً إلى نقل (~400 مورد، ~1,800 حساب مشترٍ). جودة البيانات معروف بعدم اتساقها وستحتاج إلى تنظيف.
• تفضيلات الاستضافة / البنية التحتية: AWS مفضل (حساب AWS قائم). يُشترط اختيار المنطقة البريطانية لإقامة البيانات.
• القيود التقنية: لا قيود على اختيار الحزمة التقنية — نُفوّض الأمر لتوصية الشركة. النظام القديم مبني بـ .NET لكننا لسنا مقيدين بتقنيات Microsoft.
• متطلبات الامتثال: GDPR (المملكة المتحدة) — نعالج البيانات الشخصية للمشترين والموردين. لا نطاق PCI-DSS مطلوب إذا استخدمنا Stripe لمعالجة الدفع.
• متطلبات الأداء: يجب أن يُعيد البحث في المنتجات نتائجه في أقل من ثانية واحدة. يجب أن تدعم المنصة 500 مستخدم متزامن عند الإطلاق دون تدهور في الأداء.
• دعم المتصفحات / الأجهزة: Chrome، Firefox، Safari، Edge (آخر إصدارين). متجاوب مع الجوال لكن الحاسوب المكتبي هو حالة الاستخدام الأساسية.
• المجاهيل التقنية المعروفة: لسنا متأكدين مما إذا كانت مزامنة المخزون الفوري من أنظمة الموردين ممكنة عند الإطلاق — يعتمد ذلك على توافق أنظمة الموردين. نودّ الاطلاع على رأي الشركة في هذا الشأن خلال مرحلة الاستكشاف.

---

القسم السادس: التصميم والهوية التجارية

• أصول الهوية التجارية الحالية: لدينا دليل أسلوب أساسي (شعار، لوحة ألوان، خطوط) لكن لا توجد مكتبة مكونات أو نظام تصميم للواجهة
• العمل التصميمي الحالي: لا شيء — نبدأ من الصفر في تصميم المنتج
• نهج التصميم: تقوم الشركة بالتصميم من الصفر ضمن إرشادات هويتنا التجارية
• مرجع المظهر والإحساس: نُعجب بوضوح Faire.com (سوق الجملة) وكفاءة واجهة إدارة مشاريع Procore. أسلوب نظيف ومهني ووظيفي على حساب الزخرفة.
• المخرجات التصميمية المتوقعة: نماذج أولية لتجربة المستخدم للتدفقات الرئيسية، وتصاميم واجهة عالية الدقة لجميع الشاشات، ومكتبة مكونات تُسلَّم مع قاعدة الكود

---

القسم السابع: الميزانية والجدول الزمني

• نطاق الميزانية: 120,000–180,000 جنيه إسترليني للنموذج الأولي (الأقسام 1 و4 المتطلبات الأساسية أعلاه). ندرك أن هذا قد يحتاج إلى تدقيق بعد مرحلة الاستكشاف.
• تاريخ الإطلاق المستهدف: نسخة بيتا خاصة مع 20 مورداً تجريبياً و50 مشترياً بحلول أكتوبر 2025. إطلاق عام في يناير 2026.
• الموعد النهائي الصارم: تاريخ النسخة البيتا الخاصة (أكتوبر 2025) مهم لكن غير محدد تعاقدياً. إطلاق يناير 2026 العام مرتبط بحضور معرض تجاري وهو موعد ثابت.
• الانفتاح على التدرج: نعم — نحن منفتحون على تقسيم البناء على مراحل إذا كان يُقلل المخاطر. تفضيلنا الحصول على شيء قابل للاستخدام من قِبل المشترين والموردين في أقرب وقت ممكن حتى لو كانت مجموعة الميزات محدودة.
• توافر الموارد من جانب العميل: سارة تشن (رئيسة قسم المنتجات) متاحة 2–3 أيام في الأسبوع كجهة اتصال أساسية. يمكن لمدير تقنية المعلومات دعم قرارات البنية التحتية. لا موارد تطوير داخلية.

---

القسم الثامن: معايير الاختيار

سنقيّم الردود وفق المعايير التالية (بترتيب تقريبي للأولوية):

1. الخبرة الموثّقة في منصات السوق متعددة الموردين وتطبيقات تقسيم المدفوعات / Stripe Connect
2. أقدمية الفريق المقترح لمشروعنا — نريد مهندسين متمرسين، لا فريق تسليم من المبتدئين
3. مصداقية وتحديد النهج التقني المقترح (ستُنفّرنا العروض العامة)
4. نموذج الدعم بعد الإطلاق وخيارات استمرارية التطوير
5. التوافق التجاري ضمن نطاق ميزانيتنا المُعلنة

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

الموعد النهائي للرد: 31 يناير 2025

---

أكثر أخطاء وثيقة المتطلبات شيوعاً

التركيز المفرط على الحل

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

صف النتيجة. صف المستخدم. دع عملية التصميم تحدد الواجهة.

وثيقة "Airbnb لـ X"

"نريد بناء Airbnb لتربية الكلاب" أو "Spotify للكتب الصوتية" أو "Uber لصيانة الحدائق" ليست وثيقة متطلبات. إنها استعارة. وهي في الغالب علامة على أن كاتبها لم يُنجز بعد العمل الجاد المتمثل في فهم ما يحتاج المنتج فعلاً إلى فعله.

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

الامتناع عن الإفصاح عن ميزانيتك

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

إغفال الجدول الزمني

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

إغفال متطلبات التكامل

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

إرسال الوثيقة إلى شركات كثيرة جداً

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

---

ما الطول الأنسب للوثيقة؟

لا توجد إجابة شاملة، لكن ثمة إرشادات منطقية حسب نوع المشروع.

نوع المشروع	الطول المقترح للوثيقة
أداة داخلية بسيطة أو نموذج أولي	2–4 صفحات
تطبيق ويب متوسط التعقيد	4–8 صفحات
منتج استهلاكي أو منصة	6–10 صفحات
نظام مؤسسي بتكاملات متعددة	8–15 صفحة
قطاع خاضع للرقابة (تقنية مالية، صحة، قانون)	10–20 صفحة

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

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

---

ماذا يحدث بعد إرسال الوثيقة

كيف يبدو الرد الجيد من الشركة:

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

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

كيف يبدو الرد الضعيف:

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

إدارة العملية بعد وصول الردود:

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

---

كيف نستخدم وثيقتك في Cyberbeak

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

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

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

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

---

الأسئلة المتكررة

هل أحتاج إلى وثيقة متطلبات إذا كنت أتعاقد بنظام الوقت والمواد؟

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

هل يجب أن أُضمّن نماذج أولية أو تخطيطات واجهة في وثيقتي؟

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

ماذا لو لم أكن أعرف ميزانيتي فعلاً؟

ابدأ من المبادئ الأولى. ابحث عن تكلفة بناء منتجات برمجية مماثلة — دليل تكلفة تطوير البرمجيات المخصصة الخاص بنا نقطة انطلاق مفيدة. تحدث مع فريقك المالي أو مجلس الإدارة حول حجم الاستثمار المبرر نظراً للقيمة التجارية المتوقعة من المشروع. حتى نطاق واسع — "نفكر في حدود 40,000–100,000 جنيه إسترليني بحسب النطاق" — أكثر فائدة من الصمت. إذا كنت حقاً في غياب تام لأي وضوح بشأن الميزانية، فأكثر النهج صدقاً هو ذكر ذلك في وثيقتك وطلب من الشركات الرد بمجموعة من خيارات التحديد عند مستويات استثمار مختلفة.

كيف أقارن عروض الأسعار من شركات مختلفة حين قدّرت النطاق بشكل متفاوت؟

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

---

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

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