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

الفئة	نوع المستند	وظيفته الأساسية
قانونية	العقد	إنشاء وحكم العلاقة القانونية
تنفيذية	SOW	تحديد ما سيتم تنفيذه
تقنية	SRS	تحديد كيف يعمل النظام
تصميمية	UI Spec	تحديد كيف يبدو التطبيق

الحالة	هل التوثيق ضروري؟	السبب
مشروع مدفوع	نعم	لحماية الحقوق
فريق متعدد	نعم	لتوحيد الفهم
تطبيق تجاري	نعم	لتقليل المخاطر
مشروع طويل	نعم	لإدارة التغيير
مشروع صغير جدًا	أحيانًا	حسب التعقيد

العنصر	العقد (Contract)	نطاق العمل (SOW)
الوظيفة	إنشاء العلاقة القانونية	تحديد ما سيتم تنفيذه
الطابع	قانوني بحت	تنفيذي تعاقدي
قابلية التعديل	صعبة (ملحق عقد)	أسهل (SOW جديدة)
التفاصيل التقنية	❌ لا	⚠️ عامة فقط
المدة	إطار عام	مدة تنفيذ محددة
يُستخدم عند النزاع	دائمًا	عند الخلاف حول النطاق
القوة القانونية	أصلية	مستمدة من العقد

الخطأ	النتيجة
عدم كتابة SOW	خلاف دائم حول “ما المتفق عليه”
إدخال تفاصيل تقنية في العقد	صعوبة التعديل ونزاع قانوني
عدم تحديد Out of Scope	توسّع مجاني في العمل
عدم توقيع SOW	ضعف القوة القانونية
استخدام وصف عام	سوء تفسير التنفيذ

مستند مواصفات المتطلبات (SRS): العقل التقني الذي يوجّه التنفيذ

هذا المستند هو المرجع الذي يعمل عليه المبرمج، ويعتمد عليه المصمم، ويختبر بناءً عليه فريق ضمان الجودة (QA). وأي مشروع تطبيق يُنفَّذ دون SRS واضح هو مشروع محكوم بالاجتهاد والتأويل لا بالاتفاق.

---

أولاً: ما هو مستند SRS؟

مستند SRS هو وثيقة تقنية تحليلية تُحدّد كيف يجب أن يعمل النظام من حيث الوظائف والسلوك والقيود، دون الدخول في تفاصيل التنفيذ البرمجي الداخلي.

بعبارة دقيقة:

SOW تقول: ماذا سنبني
SRS تقول: كيف يجب أن يعمل ما سنبنيه

ولهذا يُعد SRS الجسر الحقيقي بين:

• الفكرة التجارية

• والتنفيذ البرمجي

---

ثانياً: لماذا يُعد SRS مستنداً لا غنى عنه؟

غياب SRS يؤدي عمليًا إلى المشكلات التالية:

• اختلاف فهم المبرمجين لنفس الميزة

• تغيّر التنفيذ من إصدار لآخر دون مرجع

• صعوبة اختبار التطبيق بموضوعية

• تضخم التكاليف بسبب إعادة العمل (Rework)

بينما وجود SRS يوفّر:

• وضوحًا تنفيذيًا

• مرجعية ثابتة

• قابلية للاختبار

• سهولة إدارة التغيير

---

ثالثاً: ماذا يحتوي مستند SRS بالتفصيل؟

1. المقدمة (Introduction)

تشمل:

• هدف المستند

• نطاق النظام

• الجمهور المستهدف

• تعريفات واختصارات

2. الوصف العام للنظام (Overall Description)

يتضمن:

• منظور النظام (System Perspective)

• فئات المستخدمين

• القيود العامة

• الافتراضات

3. المستخدمون والأدوار (User Roles)

مثل:

• مستخدم عادي

• مزوّد خدمة

• مشرف النظام

4. المتطلبات الوظيفية (Functional Requirements – FR)

وهي قلب SRS، وتُكتب بصيغة:

• مرقّمة (FR-01, FR-02…)

• واضحة

• قابلة للاختبار

مثال:

FR-01: يجب أن يسمح النظام للمستخدم بإنشاء حساب باستخدام رقم الجوال مع رمز تحقق.

5. المتطلبات غير الوظيفية (Non-Functional Requirements – NFR)

تشمل:

• الأداء

• الأمان

• القابلية للتوسع

• الاعتمادية

• التوافق

مثال:

NFR-03: يجب ألا يتجاوز زمن استجابة واجهة إنشاء الطلب 2 ثانية عند 1000 مستخدم متزامن.

6. القيود والافتراضات

• قيود تقنية

• قيود زمنية

• قيود تشريعية

7. معايير القبول (Acceptance Criteria)

متى يُعتبر النظام “مقبولًا”؟

---

رابعاً: الفرق بين SOW وSRS (مقارنة حاسمة)

جدول (1): مقارنة SOW وSRS

---

خامساً: من يكتب مستند SRS؟

هل يجب أن يكون مبرمجًا؟

لا يُشترط أن يكون كاتب SRS مبرمجًا، لكن يُشترط أن يكون:

• ملمًّا بالبرمجة

• فاهمًا لهندسة الأنظمة

• قادرًا على صياغة متطلبات واقعية قابلة للتنفيذ

الدور المهني الصحيح هو:

• محلل نظم (System Analyst)

• أو محلل أعمال تقني (Technical Business Analyst)

النموذج الأمثل:

الذكاء الاصطناعي يكتب المسودة → مبرمج خبير يراجع → صاحب المشروع يعتمد

---

سادساً: هل يمكن للذكاء الاصطناعي كتابة SRS؟

نعم، وبكفاءة عالية، إذا توفّر وصف واضح للمشروع.
لكن الاعتماد النهائي يجب أن يكون بعد مراجعة بشرية تقنية لضمان:

• الواقعية

• التكلفة

• الأداء

• القيود الفعلية

وهذا الأسلوب أصبح معتمدًا في كثير من الفرق التقنية الحديثة.

---

سابعاً: هل يحتوي SRS على وصف شاشات التطبيق؟

الجواب الدقيق:

نعم، ولكن بوصف وظيفي لا تصميمي.

أي:

• ما الذي تتيحه الشاشة

• ما المدخلات

• ما المخرجات

• ما حالات الخطأ

ولا يُذكر:

• الألوان

• أماكن الأزرار

• نوع الخط

لأن ذلك من اختصاص UI Spec.

---

ثامناً: مثال مختصر لوصف شاشة داخل SRS

Screen: Login
يجب أن تتيح شاشة تسجيل الدخول للمستخدم إدخال رقم الجوال وكلمة المرور، والتحقق من صحة البيانات، وعرض رسالة خطأ عند الفشل، أو الانتقال إلى الشاشة الرئيسية عند النجاح.

هذا وصف:

• وظيفي

• قابل للاختبار

• غير مقيِّد للتصميم

---

تاسعاً: أخطاء شائعة في كتابة SRS

جدول (2): أخطاء شائعة وتأثيرها

---

وثيقة مواصفات واجهة المستخدم (UI Spec): ضبط الشكل والتنفيذ البصري، ثم الخلاصة الشاملة

بعد أن اكتمل لدينا الإطار القانوني (العقد)، وحدود التنفيذ (SOW)، والعقل التقني الذي يوجّه السلوك (SRS)، نصل إلى المستند الذي يضبط كيف سيظهر التطبيق وكيف تتصرف واجهته أمام المستخدم النهائي، وهو:

UI Specification Document (UI Spec)
وثيقة مواصفات واجهة المستخدم

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

---

أولاً: ما هو UI Spec وما الذي يميّزه؟

UI Spec هو وثيقة تصميمية تنفيذية تشرح المكوّنات البصرية وسلوكها التفاعلي (Visual & Interaction Behavior)، بحيث يستطيع المبرمج تنفيذ الواجهة بدقة متّسقة، ويستطيع فريق الاختبار التحقق من المطابقة.

تميّزه الأساسي أنه:

• لا يشرح منطق الأعمال (Business Logic)

• ولا يكرر المتطلبات الوظيفية (FR)

• بل يضبط الشكل، الحالات، التفاعل، والتنقل

---

ثانياً: ماذا يحتوي UI Spec بالتفصيل؟

1) البيانات العامة

• اسم المشروع والمنصة (Mobile/Web)

• رقم الإصدار وتاريخ التحديث

• سجل التغييرات (Change Log)

2) نطاق الوثيقة

• ما يغطيه المستند (المكوّنات، الحالات، التنقل)

• ما لا يغطيه (منطق الأعمال، APIs)

3) الهوية البصرية (Visual Foundation)

• لوحة الألوان (Primary/Secondary/States)

• الخطوط وأحجام النصوص

• المسافات والشبكة (Grid/Spacing)

• الزوايا والظلال (Radius/Elevation)

• الأيقونات وأسلوبها

4) حالات الواجهة (UI States)

• التحميل (Loading/Skeleton)

• الخطأ (Error/Inline/Toast)

• النجاح (Success)

• الحالة الفارغة (Empty)

• عدم الاتصال (Offline)

5) التنقل (Navigation)

• Bottom Navigation / Top Bar / Drawer

• قواعد الرجوع

• انتقالات الشاشات ومددها

6) مواصفات المكوّنات (Components)

• الأزرار بأنواعها وحالاتها

• حقول الإدخال والتحقق

• القوائم والبطاقات

• النوافذ المنبثقة

• الإشعارات الصغيرة (Toast/Snackbar)

7) مواصفات الشاشات (اختياري)

• هدف الشاشة

• المكوّنات المستخدمة

• الحالات المختلفة

• نصوص الواجهة (Microcopy)

8) الوصولية والتوافق (Accessibility)

• تباين الألوان

• أحجام اللمس

• دعم RTL

• قابلية التكبير

9) التسليم والاختبار

• روابط ملفات التصميم

• الأصول (Assets)

• Checklist للمطابقة

---

ثالثاً: الفرق الحاسم بين UI Spec وSRS

كثيرًا ما يُخلط بينهما، لذا هذا الفصل ضروري.

جدول (1): مقارنة UI Spec وSRS

الخلاصة:

SRS يضبط السلوك، وUI Spec يضبط المظهر والتفاعل.

---

رابعاً: هل UI Spec مستند أساسي دائماً؟

ليس في كل مشروع، لكنه أساسي في الحالات التالية:

• مشاريع متوسطة وكبيرة

• فرق متعددة (مصممون + مبرمجون)

• منتجات طويلة العمر

• متطلبات تجربة مستخدم عالية

جدول (2): متى يكون UI Spec ضروريًا؟

---

خامساً: الخلاصة النهائية للمقال (المنظومة الكاملة)

الأعمدة الأربعة الأساسية

1. العقد (Contract): يحكم العلاقة القانونية

2. نطاق العمل (SOW): يحدّد ما سننفّذ وبأي حدود

3. مواصفات المتطلبات (SRS): تضبط سلوك النظام

4. مواصفات الواجهة (UI Spec): تضبط الشكل والتفاعل

جدول (3): المقارنة النهائية الشاملة

---

سادساً: هل يمكن الاختصار دون خسارة احترافية؟

نعم، بحدود:

• العقد مستقل دائماً

• يمكن دمج SOW + SRS في مستند واحد للمشاريع المتوسطة

• يبقى UI Spec مستقلًا إن كانت الواجهة مهمة

لكن أي اختصار غير مدروس = مخاطرة.

المصادر : 

Software Outsourcing Contracts Best Practices