الرد على طلبات العروض RFP وكتابة العرض الفني

يصلك ملف من ثمانين صفحة اسمه «كراسة الشروط والمواصفات»، والموعد النهائي بعد ثلاثة أسابيع، وفيه نطاق العمل ومعايير التقييم وشروط العقد والغرامات ونماذج يجب تعبئتها. والطريقة البسيطة أن يفتح أحد المهندسين ملف Word فارغاً ويبدأ بكتابة وصف المنتج، ثم يكتشف في اليوم الأخير أن الكراسة تطلب شهادة لم يجهزها أحد، وأن السعر يجب أن يكون في ملف منفصل، وأن متطلباً في الصفحة 54 يجعل المشروع خاسراً. وفي هذا المقال سوف نبني طريقة منظمة للرد على طلب العروض Request for Proposal، واختصاراً RFP: كيف تقرأه، وكيف تقرر هل تتقدم أصلاً، ثم مصفوفة الامتثال Compliance Matrix التي نولدها من الكراسة بسكربت، وهيكل العرض الفني، وجدول الأسعار، مع قوالب تنسخها كما هي.

المواضيع في السلسلة:

• المبيعات B2B للتقنيين: من العميل المحتمل إلى العقد
• الرد على طلبات العروض RFP وكتابة العرض الفني (الموضوع الحالي)
• البيع للجهات الحكومية في السعودية: المنافسات ومنصة اعتماد

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

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

• الفرق بين طلب المعلومات RFI وطلب الأسعار RFQ وطلب العروض RFP.
• ما تقرأه أولاً في الكراسة، وقرار التقدم من عدمه Go/No-Go ببطاقة تقييم.
• الاستفسارات: كيف تكتبها ومتى.
• مصفوفة الامتثال: ما هي، ونولدها من كراسة مثال بسكربت في Docker، ونرى ما الذي لا يلتقطه السكربت.
• هيكل العرض الفني قسماً قسماً.
• جدول الأسعار وجدول الدفعات بمثال محسوب.
• المراجعة قبل التقديم، وقائمة التقديم.

طلب المعلومات وطلب الأسعار وطلب العروض

ثلاثة أسماء تخلط بينها الفرق كثيراً، والفرق بينها في ما يريده العميل منك:

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

ماذا تقرأ أولاً؟

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

1. معايير التقييم وأوزانها Evaluation Criteria: كم وزن الفني وكم وزن المالي، وما الحد الأدنى للنجاح الفني. فإذا كان الفني 70% فالعرض المكتوب جيداً أهم من السعر، وإذا كان المالي 70% فالسعر يحسم.
2. المتطلبات الإلزامية وشروط التأهيل: الشهادات، والخبرات السابقة بعدد ومدة، والتصنيف، والمحتوى المحلي. ومتطلب إلزامي واحد لا تحققه يستبعد العرض كله مهما كان جيداً.
3. شروط العقد: المدة، والغرامات، وحدود المسؤولية، وملكية الكود، ومستوى الخدمة SLA. هنا تجد ما يحول المشروع إلى خسارة.
4. تعليمات التقديم: الموعد بالساعة، وعدد الملفات وصيغتها، والنماذج الإلزامية، والضمان الابتدائي.
5. نطاق العمل والمتطلبات الفنية: الآن فقط تقرأ التفاصيل بعين المهندس.

قرار التقدم Go/No-Go

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

والنتيجة في المثال: (4 × 25 + 4 × 20 + 2 × 15 + 3 × 15 + 3 × 15 + 4 × 10) ÷ 5 = 340 ÷ 5 = 68 من 100. والقاعدة التي نقترحها أن تتقدم فوق 65، وأن تناقش بين 50 و65، وأن تعتذر تحت 50، وأي معيار درجته صفر في المتطلبات الإلزامية يعني الاعتذار مهما كان المجموع. ولاحظ أن «العلاقة بالعميل» أضعف نقطة في المثال، فالكراسة التي تصلك دون أن تعرف الجهة قبلها تكون فرصتك فيها أقل في الغالب، وهذا ما يجعل متابعة خطط المشتريات المنشورة وطلبات المعلومات مهمة كما ذكرنا في مقال البيع للجهات الحكومية.

خطة الأسابيع الثلاثة

بعد قرار التقدم وزع الوقت قبل أن تبدأ الكتابة، والصورة التالية تبين خطة لمنافسة مدتها ثلاثة أسابيع:

وفي أول يوم عين مالكاً واحداً للعرض Bid Manager، فهو المسؤول عن الموعد والتجميع، ومالكاً لكل قسم: المهندس للحل والمعمارية، ومدير المشروع للخطة والفريق، والمالية للسعر. والعرض الذي يملكه الجميع يجمع في الليلة الأخيرة.

الاستفسارات Clarifications

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

• «ورد في البند 4.2 التكامل مع نظام السجل الطبي عبر HL7 FHIR، فما اسم النظام وإصداره، وهل يدعم واجهة FHIR اليوم أم أن تطويرها ضمن نطاقنا؟»
• «ورد في البند 6.3 التراخيص لعدد غير محدود من المستخدمين، فهل المقصود موظفو الجهة فقط أم يشمل المرضى في تطبيق الجوال؟»
• «هل يقبل أن تكون الاستضافة على مزود سحابي مرخص داخل المملكة، أم المطلوب الاستضافة في مركز بيانات الجهة؟»

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

مصفوفة الامتثال Compliance Matrix

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

جهزنا كراسة قصيرة للتدريب باسم rfp-sample.txt، وهي مثال كتبناه وليست كراسة جهة حقيقية:

# كراسة شروط ومواصفات (مثال للتدريب): منصة حجز المواعيد للعيادات
## 3. نطاق العمل
3.1 يجب أن يدعم النظام حجز المواعيد عبر الويب وتطبيق الجوال.
3.2 يجب أن تكون الواجهة باللغتين العربية والإنجليزية مع دعم الكتابة من اليمين إلى اليسار.
3.3 يفضل أن يدعم النظام التذكير بالمواعيد عبر الرسائل النصية.
3.4 يلتزم المتعاقد بتدريب 20 موظفاً من موظفي الجهة.
## 4. المتطلبات التقنية
4.1 يجب أن تستضاف البيانات داخل المملكة العربية السعودية.
4.2 يجب أن يتكامل النظام مع نظام السجل الطبي الحالي عبر واجهة HL7 FHIR.
4.3 يجب ألا يقل توافر الخدمة عن 99.5% شهرياً.
4.4 يجب دعم الدخول الموحد SSO عبر SAML 2.0.
4.5 يفضل توفير لوحة تقارير للإدارة.
## 5. الأمن السيبراني
5.1 يلتزم المتعاقد بالضوابط الأساسية للأمن السيبراني الصادرة عن الهيئة الوطنية للأمن السيبراني.
5.2 يجب إجراء اختبار اختراق قبل التشغيل وتسليم تقريره.
## 6. التسليم والدعم
6.1 يجب تسليم النظام خلال 120 يوماً من توقيع العقد.
6.2 يلتزم المتعاقد بالدعم والصيانة لمدة 24 شهراً.
6.3 التراخيص لعدد غير محدود من المستخدمين طوال مدة العقد ودون تكلفة إضافية.

والسكربت matrix.py يقرأ كل سطر يبدأ برقم بند، ويصنفه بحسب الكلمات: «يجب» و«يلتزم» إلزامي، و«يفضل» مفضل، وغير ذلك «للعلم»، ثم يكتب ملف CSV يفتح في Excel:

# Builds a compliance matrix (CSV) from the numbered requirements of an RFP text file.
import csv, re, sys

MUST = ("يجب", "يلتزم", "shall", "must")
SHOULD = ("يفضل", "should")
src, out = sys.argv[1], sys.argv[2]
section, rows = "", []
for line in open(src, encoding="utf-8"):
    line = line.strip()
    if line.startswith("## "):
        section = line[3:]
        continue
    m = re.match(r"^(\d+\.\d+)\s+(.*)$", line)
    if not m:
        continue
    rid, text = m.groups()
    kind = "إلزامي" if any(w in text for w in MUST) else "مفضل" if any(w in text for w in SHOULD) else "للعلم"
    rows.append({"id": rid, "section": section, "requirement": text, "type": kind,
                 "compliance": "", "response_ref": "", "owner": "", "notes": ""})
with open(out, "w", newline="", encoding="utf-8-sig") as f:
    w = csv.DictWriter(f, fieldnames=list(rows[0].keys()))
    w.writeheader(); w.writerows(rows)
print(f"{len(rows)} requirements: " + ", ".join(f"{k} {sum(r['type'] == k for r in rows)}" for k in ["إلزامي", "مفضل", "للعلم"]))
for r in rows:
    print(f"{r['id']:<5} {r['type']:<7} {r['requirement'][:60]}")

نشغله في Container دون تثبيت Python على الجهاز:

docker run --rm -v "$PWD:/lab" -w /lab python:3.13.17-slim \
  python matrix.py rfp-sample.txt compliance-matrix.csv

والمخرج سوف يكون كما يلي:

14 requirements: إلزامي 11, مفضل 2, للعلم 1
3.1   إلزامي  يجب أن يدعم النظام حجز المواعيد عبر الويب وتطبيق الجوال.
3.2   إلزامي  يجب أن تكون الواجهة باللغتين العربية والإنجليزية مع دعم الكت
3.3   مفضل    يفضل أن يدعم النظام التذكير بالمواعيد عبر الرسائل النصية.
3.4   إلزامي  يلتزم المتعاقد بتدريب 20 موظفاً من موظفي الجهة.
4.1   إلزامي  يجب أن تستضاف البيانات داخل المملكة العربية السعودية.
4.2   إلزامي  يجب أن يتكامل النظام مع نظام السجل الطبي الحالي عبر واجهة HL
4.3   إلزامي  يجب ألا يقل توافر الخدمة عن 99.5% شهرياً.
4.4   إلزامي  يجب دعم الدخول الموحد SSO عبر SAML 2.0.
4.5   مفضل    يفضل توفير لوحة تقارير للإدارة.
5.1   إلزامي  يلتزم المتعاقد بالضوابط الأساسية للأمن السيبراني الصادرة عن
5.2   إلزامي  يجب إجراء اختبار اختراق قبل التشغيل وتسليم تقريره.
6.1   إلزامي  يجب تسليم النظام خلال 120 يوماً من توقيع العقد.
6.2   إلزامي  يلتزم المتعاقد بالدعم والصيانة لمدة 24 شهراً.
6.3   للعلم   التراخيص لعدد غير محدود من المستخدمين طوال مدة العقد ودون تك

في المخرج أعلاه لاحظ التالي:

• البند 6.3 صنفه السكربت «للعلم» لأنه لا يحتوي «يجب» ولا «يلتزم»، وهو في الحقيقة أخطر متطلب في الكراسة كلها، فتراخيص لعدد غير محدود من المستخدمين قد تعني كل المرضى في تطبيق الجوال، وهذا يغير السعر كله. وهذا سبب أن السكربت يكتب المسودة فقط، وأن كل سطر «للعلم» يقرؤه إنسان ويقرر، وأن هذا البند تحديداً يتحول إلى سؤال في فترة الاستفسارات.
• الكراسات الحقيقية لا تأتي بهذا الترتيب النظيف، فبعضها PDF بجداول، وبعض المتطلبات في الملاحق أو في شروط العقد، لذلك عدل التعبير المنتظم Regular Expression بحسب شكل الكراسة، وابحث يدوياً في الملاحق عن كلمات مثل «غرامة» و«ضمان» و«على المتعاقد».
• الملف يكتب بترميز utf-8-sig، والسبب أن Excel لا يتعرف على UTF-8 في ملفات CSV دون علامة BOM فيعرض العربية رموزاً غير مقروءة.

بعد ذلك يعبئ مالك كل قسم الأعمدة الفارغة، فتصبح المصفوفة هكذا:

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

هيكل العرض الفني

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

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

1. الملخص التنفيذي Executive Summary: صفحة واحدة لصاحب القرار الذي لن يقرأ غيرها: المشكلة بكلمات العميل، والحل في ثلاث جمل، ولماذا نحن، والنتيجة التي سوف يراها. واكتبه في الآخر لا في الأول.
2. فهمنا للمتطلبات: أعد صياغة المشكلة والأهداف بفهمك، لا بنسخ الكراسة، فهذا ما يقنع اللجنة أنك فهمت. وقد شرحنا تحويل الطلب إلى متطلبات في مقال هندسة المتطلبات.
3. الحل المقترح: ماذا سوف يرى كل مستخدم، مرتباً على المتطلبات، مع صور من المنتج الفعلي لا تصاميم مستعارة.
4. المعمارية والتكامل: مخطط السياق والمكونات، والاستضافة ومكان البيانات، والتكامل مع أنظمة العميل، والتوافرية. ومخططات C4 مناسبة جداً هنا كما في مقال توثيق المعمارية.
5. خطة التنفيذ والجدول الزمني: مراحل بمخرجات ومعايير قبول، ومسؤوليات العميل في كل مرحلة، مثل توفير بيئة الاختبار أو الوصول إلى النظام القديم، لأن تأخر العميل في مسؤولياته هو أكثر سبب لتأخر المشاريع.
6. الفريق: الأدوار ونسبة تفرغ كل دور والسير الذاتية المختصرة، ولا تضع سيرة شخص لن يعمل في المشروع.
7. الخبرات السابقة: مشاريع مشابهة بالجهة والمدة والنطاق، ومع وثيقة إنجاز أو خطاب من العميل إذا كانت مطلوبة.
8. الأمن والجودة والدعم: الالتزام بالضوابط المطلوبة مثل الضوابط الأساسية للأمن السيبراني، وطريقة الاختبار، ومستوى الخدمة وأوقات الاستجابة للأعطال.
9. مصفوفة الامتثال كما بنيناها أعلاه.

جدول الأسعار Pricing Sheet

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

في الجدول أعلاه لاحظ التالي:

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

ثم جدول الدفعات Payment Milestones، ويربط كل دفعة بمخرج يمكن التحقق منه، لأن المالية عند العميل لا تدفع إلا بمحضر استلام. ولنفرض أن بنود التنفيذ والاحتياطي واختبار الاختراق والتدريب مجموعها 882,600 ريال، فتوزع هكذا، والاستضافة والدعم تدفع ربع سنوياً:

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

المراجعة الناقدة Red Team Review

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

قائمة التقديم

انسخ هذه القائمة لكل منافسة وعلم عليها قبل الضغط على زر التقديم:

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

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

أخطاء شائعة

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

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

تدريب عملي

• عدل matrix.py لكي يصنف أي سطر فيه «غرامة» أو «ضمان» كبند مالي مستقل، وجربه على كراسة حقيقية منشورة.
• أضف إلى بطاقة Go/No-Go معياراً للمحتوى المحلي إذا كانت منافساتك حكومية.

وأقرب المقالات إلى هذا الموضوع على الموقع:

دليلالبيع للجهات الحكومية في السعودية: المنافسات ومنصة اعتمادكيف تبيع شركة تقنية لجهة حكومية من المصادر الرسمية: نظام المنافسات الجديد، ومنصة اعتماد، والضمانات، وآليات المحتوى المحلي.دليلالمبيعات B2B للتقنيين: من العميل المحتمل إلى العقدكيف تبيع شركة تقنية لشركات أخرى: من يقرر عند العميل، وكيف تؤهل الصفقة، وما الوثائق والتسعير من أول اجتماع إلى الفاتورة.دليلالعرض التوضيحي Demo وإثبات المفهوم PoC: كيف تديرهماكيف تبني عرضاً حول مشكلة العميل، وتدير إثبات مفهوم بمعايير نجاح مكتوبة ومدة محددة، مع قالب خطة جاهز للنسخ.دليلهندسة المتطلبات Requirements Engineering من الطلب إلى ما يبنىما هو المتطلب Requirement، وكيف تجمعه وتكتبه وتراجعه وتدير تغييره، ولماذا تفشل مشاريع كبيرة عندما تهمل هذه الخطوة.

سجل التحديثات

• أكتوبر 2026: كتابة المقال وتشغيل سكربت مصفوفة الامتثال على python:3.13.17-slim في Docker Engine 29.8.0.