وثيقة متطلبات البرمجيات (SRS) تصف كل ما يجب أن يفعله النظام بتفصيل يكفي من يبنيه. اكتبها في تسعة أقسام: نظرة عامة، المستخدمون والأدوار، نطاق الإصدار الأول، المتطلبات الوظيفية مرقّمة، قصص المستخدم ومعايير القبول، البيانات، المتطلبات غير الوظيفية، ما هو خارج النطاق، والأسئلة المفتوحة. اجعل كل متطلب جملة واحدة قابلة للاختبار. وفي فنّان تسألك مديرة المنتج نورة الأسئلة التي تحسم النطاق، ثم تكتب الوثيقة وقائمة المهام وتسلّمها للبنّاء.
- كيف اكتب وثيقة متطلبات
- نموذج وثيقة SRS بالعربي
- وثيقة متطلبات البرمجيات
- كيف اكتب متطلبات تطبيق للمبرمج
- الفرق بين SRS و PRD
- امثلة user stories ومعايير القبول
ما هي وثيقة المتطلبات، وهل أحتاجها فعلاً؟
وثيقة متطلبات البرمجيات (Software Requirements Specification، وتُختصر SRS) نص يصف ما يجب أن يفعله النظام: من يستخدمه، ماذا يستطيع كل مستخدم، ما البيانات، وما القواعد. ليست وثيقة تقنية، ولا تذكر لغات برمجة. هي اتفاق مكتوب بين من يريد النظام ومن يبنيه.
تحتاجها كلما كان هناك طرف ثانٍ: مبرمج مستقل يسعّر العمل، شركة ستوقّع معها عقداً، شريك يجب أن يوافق، أو ذكاء اصطناعي سيبني من وصفك. بلا وثيقة، كل طرف يبني النظام الذي في رأسه هو. ولمشروع صغير تكفي صفحتان إلى أربع.
- تجيب عن
- ماذا يفعل النظام بالضبط؟
- قارئها
- من يبني، ومن يختبر، ومن يوافق
- طولها لتطبيق صغير
- صفحتان إلى أربع صفحات
- لا تحتوي
- لغات برمجة أو قرارات تقنية
SRS أم PRD أم ملخص من صفحة: أيها أكتب؟
الأسماء تربك المبتدئين. الفرق ببساطة في السؤال الذي تجيب عنه كل وثيقة:
اختر ما يشبه حالتك لترى النصيحة.
ملخص المشروع: صفحة واحدة فيها المشكلة، الجمهور، الحل، وما يميّزه. اكتبه أولاً، فإن لم تستطع اختصار الفكرة في صفحة فهي لم تنضج بعد.
وثيقة المنتج PRD: المشكلة، الجمهور، الأهداف، ومؤشرات النجاح. مناسبة لفرق المنتجات والمستثمرين. دليلها: كتابة PRD بالذكاء الاصطناعي.
وثيقة المتطلبات SRS: كل ما يفعله النظام بالتفصيل الذي يحتاجه البنّاء. هي موضوع هذا المقال، وهي ما يطلبه المبرمج قبل أن يعطيك سعراً.
خطة الإصدارات: ما الذي يدخل الإصدار الأول وما الذي يؤجَّل. تُكتب بعد SRS أو معها.
ما أقسام وثيقة SRS؟ قالب جاهز
هذا قالب من تسعة أقسام يناسب أغلب التطبيقات الصغيرة والمتوسطة. المثال في العمود الثالث لنظام مواعيد عيادة أسنان.
| القسم | ما يُكتب فيه | مثال |
|---|---|---|
| 1. نظرة عامة | ما النظام ولمن، في فقرة | نظام يحجز منه مرضى العيادة مواعيدهم ويدير منه الاستقبال جدول الأطباء |
| 2. المستخدمون والأدوار | جدول: الدور وما يستطيع فعله | مريض، موظف استقبال، طبيب، مدير |
| 3. نطاق الإصدار الأول | قائمة بما يدخل الإصدار الأول | الحجز، الإلغاء، جدول اليوم، التذكير |
| 4. المتطلبات الوظيفية | جمل مرقّمة لما يفعله النظام | م-12: يمنع النظام حجز موعدين في الوقت نفسه للطبيب نفسه |
| 5. قصص المستخدم ومعايير القبول | قصة لكل ميزة مع شروط اكتمالها | انظر القسم التالي |
| 6. البيانات | الأشياء التي تُحفظ وحقولها وعلاقاتها | موعد: مريض، طبيب، تاريخ، وقت، حالة |
| 7. المتطلبات غير الوظيفية | اللغة، الأجهزة، الأمان، الخصوصية | عربي من اليمين لليسار، يعمل على الجوال |
| 8. خارج النطاق | ما لن يُبنى الآن صراحةً | الدفع الإلكتروني، الملف الطبي |
| 9. أسئلة مفتوحة | ما لم يُحسم بعد ومن يحسمه | هل يحجز المريض دون حساب؟ |
كيف أكتب متطلباً وظيفياً واضحاً؟
المتطلب الجيد يمكن أن تضع بجانبه علامة صح أو خطأ بعد البناء. إن احتجت نقاشاً لتعرف هل تحقق، فهو أمنية لا متطلب.
- النظام سهل الاستخدام
- يستطيع المريض إدارة مواعيده
- إشعارات للمرضى
- تقارير شاملة للمدير
- النظام آمن
- يُتم المريض الحجز في ثلاث خطوات على الأكثر
- يلغي المريض موعده حتى 6 ساعات قبله، وبعدها يظهر رقم العيادة
- تصل المريض رسالة تذكير قبل الموعد بيوم
- يعرض التقرير عدد المواعيد والغياب لكل طبيب شهرياً
- لا يرى الطبيب إلا مواعيد مرضاه
خمس قواعد للصياغة
- متطلب واحد في كل جملة. إن وجدت «و» فغالباً هما متطلبان.
- رقّم كل متطلب (م-1، م-2) لتشير إليه في النقاش والاختبار.
- ابدأ بالفاعل: «يستطيع موظف الاستقبال…» أو «يمنع النظام…».
- اكتب الأرقام: كم ساعة، كم محاولة، كم حرفاً.
- اكتب ما يحدث عند الفشل، لا عند النجاح فقط.
كيف أكتب قصص المستخدم ومعايير القبول؟ أمثلة جاهزة
قصة المستخدم جملة تربط الميزة بصاحبها وهدفه: بصفتي [دور]، أريد [فعلاً]، لكي [فائدة]. ومعايير القبول شروط محددة تقول متى تُعدّ القصة منجزة، وتُكتب بصيغة: بافتراض حالة، عندما يحدث فعل، إذن تظهر نتيجة.
| قصة المستخدم | معايير القبول |
|---|---|
| بصفتي مريضاً، أريد حجز موعد من جوالي، لكي لا أتصل بالعيادة | بافتراض أني سجّلت الدخول، عندما أختار طبيباً ويوماً، إذن تظهر الأوقات المتاحة فقط. عندما أؤكد، إذن يظهر الموعد في «مواعيدي» وتصلني رسالة تأكيد |
| بصفتي موظف استقبال، أريد رؤية جدول اليوم، لكي أجهّز الملفات | بافتراض وجود مواعيد اليوم، عندما أفتح الجدول، إذن تظهر مرتبة بالوقت مع اسم المريض والطبيب والحالة. عندما لا توجد مواعيد، إذن تظهر رسالة «لا مواعيد اليوم» |
| بصفتي مريضاً، أريد إلغاء موعدي، لكي يستفيد منه غيري | بافتراض أن الموعد بعد أكثر من 6 ساعات، عندما أضغط إلغاء وأؤكد، إذن تصير حالته «ملغى» ويعود الوقت متاحاً. وإن بقي أقل من 6 ساعات، إذن يختفي زر الإلغاء ويظهر رقم العيادة |
ما المتطلبات غير الوظيفية، وما الذي أضعه خارج النطاق؟
المتطلبات الوظيفية تقول ماذا يفعل النظام. غير الوظيفية تقول كيف يكون وهو يفعله. تُنسى غالباً، ثم تظهر شكوى بعد الإطلاق.
عن الخصوصية: إن كان نظامك يجمع بيانات شخصية في السعودية أو الإمارات فهناك أنظمة لحماية البيانات يجب الرجوع إلى مصادرها الرسمية. نقطة بداية عامة في قائمة نظام حماية البيانات للتطبيقات.
أما «خارج النطاق» فاكتب فيه كل ما سيسأل عنه أحدهم ولن تبنيه الآن، مع كلمة «لاحقاً» أو «أبداً». مثال: الدفع الإلكتروني لاحقاً، الملف الطبي أبداً لأنه خارج غرض النظام، تطبيق الجوال في الإصدار الثاني.
كيف أكتب وثيقة يبني منها الذكاء الاصطناعي جيداً؟
الوثيقة التي يفهمها مبرمج جديد دون أن يتصل بك تصلح للذكاء الاصطناعي أيضاً. مع أربع عادات إضافية تصنع فرقاً واضحاً:
- اكتب البيانات صراحةً. الإنسان يستنتج أن للموعد حالة، والأداة قد تستنتج أو لا. اكتب: حالة الموعد: مؤكد، حضر، لم يحضر، ملغى.
- ضع الأدوار في جدول. صف لكل دور، وعمود لكل ما يستطيعه: يرى، يضيف، يعدّل، يحذف.
- افصل الإصدار الأول عن الباقي. وثيقة فيها أربعون ميزة بلا ترتيب تُبنى كلها نصف بناء. قل: هذه الثماني أولاً.
- استخدم المسميات نفسها دائماً. إن كتبت «موعد» فلا تكتب بعدها «حجز» و«زيارة» للشيء نفسه.
ولا تسلّم الوثيقة كلها دفعة واحدة إن كانت طويلة. سلّم الإصدار الأول، راجعه، ثم أضف، على طريقة ابنِ ميزة واحدة في كل مرة. وإن كنت تكتب بمساعدة مساعد محادثة عام فاقرأ خطّط تطبيقك مع ChatGPT أو Claude.
كيف تكتب نورة الوثيقة عني في فنّان؟
الصفحة البيضاء أصعب ما في الوثيقة. مديرة المنتج نورة في فنّان تبدأ من الجهة الأخرى: تخبرها بفكرتك كما تشرحها لصديق ولو بجملة واحدة، فتسألك السؤال الذي يحسم القرار، ثم تكتب الوثيقة.
- 1اشرح الفكرة
في المحادثة، أو ابدأ من اقتراح جاهز مثل «اكتبي وثيقة متطلبات (SRS) لتطبيق…».
- 2أجب عن أسئلتها
أسئلة تحسم النطاق: من المستخدمون؟ ما الذي يدخل الإصدار الأول؟ وتقول لك بصراحة ما تبدأ به وما تحذفه.
- 3استلم الوثيقة والمهام
تظهر الوثيقة في تبويب المستندات بنوعها (SRS أو PRD أو ملخص أو خطة إصدارات)، وقائمة مهام مرتّبة بالأولوية في تبويب المهام.
- 4عدّل جزءاً بعينه
حدّد فقرة واختر «عدّل هذا الجزء»، واطلب: فصّل أكثر، اختصر، أضف أمثلة. تعدّل نورة المقطع المحدد فقط ويبقى الباقي كما هو. وتستطيع التحرير بنفسك أيضاً.
- 5اعتمد وسلّم
اعتمد الوثيقة نسخة نهائية، ثم «أرسلي إلى البنّاء»: ويب أو جوال، تطبيق جديد أو تعديل على تطبيق قائم، وبخطة أولاً أو بناء مباشر.
اكتبي وثيقة متطلبات (SRS) لنظام مواعيد لعيادة أسنان فيها ثلاثة أطباء وموظفة استقبال. المرضى يحجزون من الجوال برقم الجوال، ويلغون حتى 6 ساعات قبل الموعد. الاستقبال يرى جدول اليوم لكل طبيب ويضيف مواعيد للمتصلين هاتفياً. الطبيب يرى مواعيده فقط ويسجّل حضر أو لم يحضر. المدير يرى تقريراً شهرياً بعدد المواعيد والغياب. خارج النطاق الآن: الدفع الإلكتروني والملف الطبي. اسأليني عما ينقص قبل الكتابة، ثم اكتبي الوثيقة بأقسام مرقّمة تشمل جدول الأدوار، المتطلبات الوظيفية، قصص المستخدم مع معايير قبول بصيغة بافتراض وعندما وإذن، البيانات، والمتطلبات غير الوظيفية. واقترحي ما يؤجَّل للإصدار الثاني.
جرّبه في فنّانما الأخطاء الشائعة، وكيف أراجع الوثيقة قبل تسليمها؟
رسم توضيحي- وصف الحل بدل الحاجة: «زر أزرق في الأعلى» بدل «يصل المستخدم للحجز من أي شاشة».
- كل شيء أولوية عالية: إن كان كل شيء مهماً فلا شيء مهم.
- وثيقة لا تُحدَّث: بعد أول تعديل شفهي تصير الوثيقة تاريخاً لا مرجعاً. عدّلها أولاً ثم اطلب التغيير.
- نسيان لوحة الإدارة: من يضيف الأطباء؟ من يغيّر ساعات العمل؟
- متطلبات قانونية بالتخمين: الفواتير والضريبة والخصوصية تُراجع من مصادرها الرسمية أو مع مختص.
والوثيقة ليست نهاية الطريق. بعدها يأتي البناء ثم الاختبار، ومعايير القبول التي كتبتها هي ما يُختبر به. الصورة الكاملة في فريق منتج بالذكاء الاصطناعي: خطّط وابنِ واختبر.
الخلاصة
- SRS تجيب عن «ماذا يفعل النظام بالضبط»، و PRD تجيب عن «لماذا نبنيه ولمن».
- كل متطلب جملة واحدة مرقّمة يمكن اختبارها بنعم أو لا.
- معايير القبول هي تعريف «انتهى»: الحالة، الفعل، النتيجة المتوقعة.
- قسم «خارج النطاق» يحميك من الخلاف أكثر من أي قسم آخر.
- الوثيقة التي يفهمها مبرمج جديد دون أن يسألك تصلح أيضاً للبناء بالذكاء الاصطناعي.
أسئلة شائعة
ما الفرق بين SRS و PRD؟
كم صفحة يجب أن تكون وثيقة المتطلبات؟
هل أحتاج وثيقة متطلبات إذا كنت أبني بالذكاء الاصطناعي؟
من يكتب وثيقة المتطلبات؟
هل تُكتب الوثيقة بالعربية أم بالإنجليزية؟
ماذا أفعل حين تتغير المتطلبات بعد البدء؟
اسأل مساعدك الذكي عن هذا الموضوع
انسخ هذا الطلب والصقه في مساعد الذكاء الاصطناعي الذي تستخدمه، ثم أضف تفاصيل حالتك.
أقرأ هذا الدليل: «كيف تكتب وثيقة متطلبات (SRS) يبني منها الناس والذكاء الاصطناعي؟» https://fanann.com/ar/blog/write-a-requirements-document/ سؤالي: كيف اكتب وثيقة متطلبات اعتمد على هذه الصفحة كمصدر واشرح لي الإجابة خطوة بخطوة بما يناسب حالتي، واذكر ما يجب أن أتحقق منه قبل أن أبدأ، واذكر رابط الصفحة كمرجع.