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