جهّز وصف المشكلة، وأدوار المستخدمين، ورحلة أساسية كاملة، وقواعد العمل، والتكاملات، ومعايير الاستلام، وما تؤجله من الإصدار الأول. لا تحتاج أن تختار لغة البرمجة بنفسك، ولا أن ترسم كل شاشة. تحتاج معلومات تجعل الشركات تفهم حدود العمل نفسها، وتكشف ما لا يزال يحتاج قرارًا قبل اعتماد سعر تفصيلي.
إذا كانت فكرتك «تطبيقًا للحجوزات»، فهذه بداية الحديث. أما النطاق فيشرح: من يحجز ماذا، ومتى يصبح الحجز مؤكدًا، ومن يحق له إلغاؤه، وماذا يحدث عند التعارض. هنا تبدأ المقارنة المفيدة بين عروض التطوير.
هل تحتاج وثيقة طويلة قبل التواصل مع شركة تطوير؟
يمكنك بدء النقاش بموجز مختصر. لكن لا تتعامل مع تقدير أولي على أنه التزام بنطاق لم يُحسم بعد. طول الملف ليس معيارًا لجاهزيته؛ المهم أن يستطيع القارئ ربط كل وظيفة بمستخدم ونتيجة وشروط واضحة.
يعرض دليل الخدمات في GOV.UK قصص المستخدم باعتبارها وصفًا للشخص واحتياجه والهدف منه، ومعايير القبول باعتبارها نتائج تساعد على التحقق من تلبية ذلك الاحتياج. هذا أسلوب مفيد للتوثيق، وليس اشتراطًا تنظيميًا سعوديًا. دليل كتابة قصص المستخدم.
إذا كان الفريق مختلفًا أصلًا على طريقة التشغيل، فابدأ بـاكتشاف المنتج وتوثيق المتطلبات. المطلوب حسم القرارات التي تغيّر النطاق، لا تجميل وصف الفكرة.
سبعة قرارات يجب أن تظهر في ملفك
| القرار | ماذا تكتب؟ | ماذا يحدث إذا تركته مفتوحًا؟ |
|---|---|---|
| المشكلة | أين يتعطل العمل الحالي، ومن يتأثر؟ | قد تحصل على وظائف لا تعالج السبب |
| المستخدمون | العميل، الموظف، المشرف، وصلاحية كل دور | قد يغيب عمل لوحة الإدارة عن العرض |
| الرحلة الأساسية | البداية والخطوات ونتيجة الإتمام | تُسعّر شاشات منفصلة دون عملية مكتملة |
| قواعد العمل | شروط التأكيد والإلغاء والتعديل والتعارض | يبني كل مورد تفسيرًا مختلفًا |
| البيانات والربط | الأنظمة والحقول والجهة المالكة والصلاحيات المتاحة | يبقى جزء مؤثر من التنفيذ غير مقدّر |
| حدود الإصدار | ما يدخل الآن وما يؤجل وما يستبعد | تتوسع النسخة الأولى دون قرار واضح |
| القبول والتسليم | حالات الاختبار والملفات والحسابات والمسؤول عن الاعتماد | يصبح معنى «انتهينا» محل خلاف |
أضف القيود ذات الأثر: العربية والإنجليزية، أنواع الأجهزة، اتصال ضعيف، موعد مرتبط بتشغيل فعلي، وميزانية تخطيطية إذا رغبت في مشاركتها. لا تكتب «يدعم العربية» فقط؛ حدّد الشاشات والمحتوى والتواريخ والأرقام ورسائل الأخطاء التي تحتاج مراجعة بالعربية.
مثال افتراضي: تطبيق حجز معدات للفعاليات في الرياض
هذا مثال تعليمي، وليس مشروعًا نفّذته LAB أو نتيجة عميل.
لنفترض أن منشأة تؤجر معدات للفعاليات وتدير الطلبات حاليًا باتصالات وجدول مشترك. طلبها الأول: «تطبيق يعرض المعدات ويستقبل الحجوزات». بعد تفصيل العملية، تظهر قرارات تغيّر التنفيذ:
- العميل يرسل طلبًا، لكنه لا يحصل على حجز مؤكد فورًا.
- الموظف يراجع توافر المعدات وتاريخ الإرجاع قبل التأكيد.
- بعض المعدات تُؤجر بوحدات متعددة؛ وبعضها قطعة واحدة.
- المشرف يستطيع تعديل الحجز، مع توثيق التعديل وصاحبه.
- التوصيل خارج نطاق الإصدار الأول، وكذلك الدفع داخل التطبيق.
رحلة الإصدار الأول: اختيار معدات وفترة استخدام، إرسال الطلب، مراجعة الموظف، تأكيد التوافر، ثم إظهار الحالة للعميل. بهذا نعرف أن المطلوب ليس صفحة عرض فقط، وأن لوحة الموظف جزء أساسي من المنتج.
كيف تتحول الرحلة إلى معيار قبول؟
بدل «يمنع النظام الأخطاء في الحجز»، اكتب:
- عندما يكون مورد غير متاح في الفترة المطلوبة، لا يستطيع الموظف تأكيد طلب متعارض عليه.
- إذا حاول موظفان تأكيد آخر وحدة متاحة في الوقت نفسه، ينجح تأكيد واحد فقط، ويظهر للآخر أن التوافر تغيّر.
- الطلب غير المؤكد يظهر للعميل بوصفه طلبًا قيد المراجعة، لا حجزًا مضمونًا.
- عند إلغاء حجز مؤكد، تتحدث إتاحة المعدات بحسب القاعدة المعتمدة، ويُسجّل من نفّذ الإلغاء.
- إذا تعذر إرسال إشعار، تبقى حالة الحجز الصحيحة ظاهرة داخل النظام، ولا يتكرر الحجز بسبب إعادة المحاولة.
هذه الحالات تكشف التصميم والبرمجة والاختبار المطلوبين. ويمكن لـتصميم تجربة المستخدم تحويلها إلى تدفقات ونموذج قابل للتجربة قبل الالتزام بتفاصيل الواجهات.
افصل «قرارًا ناقصًا» عن «ميزة مؤجلة»
المؤجل قرار واعٍ: الدفع داخل التطبيق ليس ضمن الإصدار الأول. أما الناقص فهو سؤال يؤثر على تقدير العمل: هل يتوفر نظام مخزون حالي يمكن الربط معه؟
أنشئ سجلًا صغيرًا: السؤال، المسؤول عن حسمه، الدليل المطلوب، وأثره على العرض. مثلًا: «تأكيد وجود واجهة لقراءة الكميات لدى مزود المخزون». لا تكتب «ربط مع النظام الحالي» كأنه تفصيل محسوم إذا لم تُراجع وثائقه وصلاحياته.
عندما يكون الربط مؤثرًا، يصبح تطوير وربط واجهات برمجة التطبيقات نطاقًا واضحًا: ماذا نقرأ، وماذا نكتب، ومن يصرّح بذلك، وكيف تُعالج الأخطاء والتكرارات. اسم النظام وحده لا يجيب عن هذه الأسئلة.
كيف تقارن عروض التطوير بعد إرسال المتطلبات؟
أرسل الإصدار نفسه من الملف لكل جهة. اجمع أسئلتها، ثم وزّع التوضيحات المؤثرة حتى لا يقارن فريقك أرقامًا مبنية على افتراضات مختلفة.
اطلب أن يوضح كل عرض:
- ما الذي يغطيه من المتطلبات، وما الذي لم يدخل في السعر.
- الافتراضات التي يعتمد عليها، وما الذي يتغير إذا لم تتحقق.
- المخرجات في كل مرحلة، ومن يعتمدها، وما المطلوب من فريقك.
- الخدمات الخارجية والتكاليف المتكررة التي لا تشملها أتعاب التنفيذ.
- معالجة طلبات التغيير، والدعم بعد التسليم، ومسؤولية تشغيل النظام.
- طريقة تسليم الكود والتصاميم والتوثيق والحسابات وفق الاتفاق.
لا تحكم على العرض بعدد الشاشات فقط. شاشة واحدة قد تحمل قواعد وصلاحيات معقدة، بينما عدة صفحات معلومات قد تتطلب عملًا أبسط. ولا تفترض أن العرض الأغلى أشمل؛ ابحث عن تغطية مكتوبة يمكن مراجعتها.
قائمة مراجعة قبل اعتماد بدء التطوير
- [ ] اتفق صاحب القرار وممثل التشغيل على الرحلة الأساسية.
- [ ] جرى فصل صلاحيات العميل والموظف والمشرف.
- [ ] وُثّقت حالات الفشل والتعارض، وليس المسار المثالي فقط.
- [ ] المتطلبات المفتوحة لها مالك، ولم تُخفَ داخل عبارات عامة.
- [ ] معايير القبول تشرح ما سيُختبر وبأي بيانات تجريبية.
- [ ] شُرح ما يشمله التسليم وما يحتاج تشغيلًا أو اشتراكًا مستقلًا.
- [ ] توجد طريقة واضحة لاعتماد التغييرات بعد بدء العمل.
من المفيد إشراك اختبار وضمان جودة البرمجيات في مراجعة حالات القبول مبكرًا؛ فالمعيار الذي لا تستطيع اختباره يحتاج توضيحًا قبل أن يصبح بند استلام.
أخطاء شائعة تزيد الغموض
نسخ تطبيق مشهور كاملًا: المرجع يساعد على شرح تفاعل، لكنه لا يحدد ما تحتاجه أنت ولا قواعد تشغيلك.
اعتبار كل فكرة ضرورة للإطلاق: اسأل ما الذي يمنع إكمال الرحلة إذا حُذف. إذا لم يمنعها، ناقش تأجيله بدل إدخاله تلقائيًا.
تسليم بيانات عملاء حقيقية ضمن طلب العرض: استخدم عينات منزوعة البيانات الشخصية أو بيانات مصطنعة، وشارك أقل قدر يكفي لشرح المشكلة.
ترك الاستلام إلى نهاية المشروع: اتفق مبكرًا على الدليل المطلوب لكل متطلب، وعلى من يراجع ويعتمد النتيجة.
أسئلة شائعة
هل أحتاج تصميمًا كاملًا للحصول على عرض سعر؟
لا. يمكن بدء التقدير برحلات ومتطلبات واضحة. لكن إذا كانت تفاعلات المنتج غير محسومة، فقد تحتاج نموذجًا أوليًا أو مرحلة اكتشاف قبل عرض تفصيلي.
هل أكتب وثيقة SRS بنفسي؟
يمكنك كتابة قواعد نشاطك وأمثلة التشغيل والنتائج المطلوبة. أما تحويلها إلى مواصفات مترابطة فيستفيد من مشاركة التحليل والتصميم والتطوير والاختبار. اسم الوثيقة أقل أهمية من وضوحها.
هل أختار تطبيق جوال أم ويب قبل توثيق المتطلبات؟
دوّن احتياج الاستخدام أولًا: هل يحتاج المستخدم خصائص الجهاز؟ هل يدخل يوميًا أم نادرًا؟ هل يعمل الموظف من مكتب؟ هذه الإجابات تساعد الفريق على اقتراح القناة المناسبة بدل اختيارها بسبب شيوعها.
هل توثيق المتطلبات يمنع تغير السعر؟
لا يضمن ذلك. لكنه يجعل أسباب التغيير قابلة للنقاش: تعديل نطاق، أو اعتماد خارجي لم يتحقق، أو قرار جديد. وثّق أثر التغيير قبل الموافقة عليه.
الخطوة التالية
جهّز رحلة واحدة، وأمثلة تشغيل آمنة، وقائمة بالقرارات غير المحسومة. استخدمها لمناقشة نطاق تطوير التطبيقات مع LAB، وتحديد هل أصبحت جاهزًا للتنفيذ أم تحتاج أولًا إلى اكتشاف وتوثيق. بهذه البداية، يدور النقاش حول منتج يمكن تسليمه ومراجعته، لا رقم منفصل عن معناه.
المصادر
- GOV.UK: كتابة قصص المستخدم ومعايير القبول. استُخدم لشرح أسلوب ربط المتطلبات بالاحتياج والنتيجة، وليس مرجعًا قانونيًا محليًا.
- تاريخ مراجعة المصدر: 26 أكتوبر 2026. الجداول والمثال وقائمة المقارنة أدوات تحريرية مقترحة، وليست معايير إلزامية أو نتائج مشاريع.
