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