كيف تكتب SRS لمشروع التخرج خطوة بخطوة، دليل عملي مع قالب جاهز

المشرف طلب منك وثيقة SRS لمشروع تخرجك وانت ما تعرف من وين تبدأ. تفتح قوقل وتلاقي مصادر بالانجليزي تشرح معايير IEEE بشكل نظري بحت، أو قوالب طويلة تخوف أكثر ما تساعد. لو هذا وضعك الحين، خلنا نختصر عليك الطريق.

الموضوع أبسط مما تتخيل. افهم الهيكل الصحيح، امشي خطوة خطوة، وخلاص. هنا نشرح كل قسم من أقسام وثيقة متطلبات البرمجيات (Software Requirements Specification) بأمثلة من مشاريع تخرج فعلية، مع قالب جاهز تنسخه وتعبيه مباشرة.

ايش هي وثيقة SRS ولماذا المشرف يطلبها

وثيقة SRS هي اختصار لـ Software Requirements Specification، أو بالعربي: وثيقة مواصفات متطلبات البرمجيات. ببساطة، الوثيقة اللي تصف بالضبط ايش المفروض النظام يسويه وايش الشروط اللي لازم يحققها. فكر فيها كعقد بينك وبين المشرف. انت تقول “هذا اللي بسويه”، وهو يقول “تمام، هذا اللي بقيمك عليه”.

لماذا المشرف يصر عليها

المشرف ما يطلب SRS عشان يعذبك. هو يعرف (من تجربته مع دفعات قبلك) ان بدونها المشاريع تنهار. السبب الحقيقي ان SRS تحميك من ثلاث مشاكل:

• تغيير النطاق المفاجئ: بدون وثيقة واضحة، كل مرة يشوف المشرف المشروع يطلب اضافات جديدة. لما يكون عندك SRS موقعة ومعتمدة، تقدر تقول “هذا ما كان ضمن النطاق المتفق عليه”
• سوء الفهم: انت فاهم شيء والمشرف فاهم شيء ثاني تماما. وما تكتشف هذا الا في الاسبوع 10 من الفصل. الوثيقة تضمن ان الكل على نفس الصفحة من البداية
• التقييم العادل: لجنة المناقشة تقيم مشروعك بناء على ايش وعدت تسويه مقابل ايش فعلا سويته. بدون SRS، ما فيه معيار واضح

معيار IEEE 830 ببساطة

لما تسمع “معيار IEEE 830 لكتابة SRS”، لا تخاف. هذا المعيار ببساطة هو دليل ارشادي يحدد ايش المفروض وثيقة SRS تحتوي عليه وكيف تنظمها. ما تحتاج تحفظه أو تقرأ الوثيقة الأصلية كلها. الهيكل اللي بنشرحه في هذا الدليل مبني على هذا المعيار بشكل مبسط يناسب مشاريع التخرج.

هيكل وثيقة SRS لمشروع التخرج

وثيقة SRS مشروع تخرج تتكون من أربعة أقسام رئيسية. أربعة بس. خلنا نمشي عليها واحد واحد.

---

القسم الأول: المقدمة (Introduction)

المقدمة أسهل جزء في الوثيقة. هدفها بسيط: أي شخص يقرأ الوثيقة يفهم السياق بسرعة بدون ما يحتاج يسألك.

1.1 الغرض (Purpose)

اشرح في فقرة أو فقرتين ليش هذي الوثيقة موجودة ومن الجمهور المستهدف فيها. مثال:

الغرض من هذه الوثيقة هو تحديد المتطلبات الوظيفية وغير الوظيفية لنظام تسجيل الطلاب الالكتروني. الوثيقة موجهة لفريق التطوير، المشرف الأكاديمي، ولجنة تقييم مشروع التخرج.

1.2 النطاق (Scope)

حدد حدود مشروعك بوضوح: ايش النظام يسويه وايش ما يسويه. هذا القسم يحميك لما المشرف يجيك في الاسبوع 8 ويقول “ليش ما اضفتم خاصية الدفع؟” مثال:

النظام يتيح للطلاب تسجيل المقررات، عرض الجداول، وسحب المواد الكترونيا. النظام لا يشمل نظام الدفع المالي أو نظام إدارة المحتوى التعليمي.

1.3 التعريفات والاختصارات (Definitions & Acronyms)

اعمل جدول بسيط فيه كل المصطلحات التقنية والاختصارات اللي تستخدمها في الوثيقة. هذا يساعد المشرف واللجنة يفهمون وثيقتك بدون ما يحتاجون يبحثون عن تعريفات. مثال:

المصطلح	التعريف
SRS	Software Requirements Specification - وثيقة مواصفات المتطلبات
API	Application Programming Interface - واجهة برمجة التطبيقات
CRUD	Create, Read, Update, Delete - العمليات الأساسية على البيانات
Admin	مدير النظام اللي يملك صلاحيات كاملة

1.4 المراجع (References)

اذكر أي مراجع أو معايير بنيت عليها وثيقتك. مثلا: معيار IEEE 830، وثائق الجامعة، أو متطلبات المشرف.

---

القسم الثاني: الوصف العام (Overall Description)

هنا تعطي الصورة الكبيرة عن نظامك قبل ما تدخل في التفاصيل. فكر فيه كمقدمة تقنية للي يقرأ الوثيقة لأول مرة.

2.1 منظور المنتج (Product Perspective)

وضح هل النظام مستقل بالكامل أو جزء من نظام أكبر. اذا كان يتكامل مع أنظمة ثانية، وضح ذلك هنا.

نظام تسجيل الطلاب هو تطبيق ويب مستقل يتكامل مع قاعدة بيانات الجامعة الحالية عبر REST API. النظام يعمل على المتصفح ولا يحتاج تثبيت برامج اضافية.

2.2 خصائص المستخدمين (User Characteristics)

حدد من هم المستخدمين المتوقعين ومستوى خبرتهم التقنية. هذا يساعدك لاحقا في تصميم الواجهات. مثال:

نوع المستخدم	الوصف	المستوى التقني
الطالب	طلاب جامعيون يحتاجون تسجيل مقررات	متوسط - يستخدمون تطبيقات يوميا
المرشد الاكاديمي	أعضاء هيئة تدريس يراجعون طلبات الطلاب	متوسط إلى منخفض
مدير النظام	موظف تقني يدير النظام والصلاحيات	عالي

2.3 القيود (Constraints)

اذكر القيود التقنية أو الادارية اللي تؤثر على مشروعك. كن صريح. المشرف يحترم الطالب الواقعي أكثر من اللي يوعد بالمستحيل. أمثلة:

• النظام لازم يعمل على آخر اصدارين من Chrome و Firefox
• قاعدة البيانات لازم تكون MySQL حسب متطلبات القسم
• المشروع لازم يكتمل خلال فصل دراسي واحد (14 اسبوع)
• فريق التطوير شخصين فقط

2.4 الافتراضات والتبعيات (Assumptions & Dependencies)

ايش الأشياء اللي تفترض انها موجودة أو صحيحة عشان مشروعك ينجح؟ مثلا:

• نفترض ان قاعدة بيانات الطلاب الحالية فيها API جاهز للتكامل
• نفترض ان المستخدمين عندهم اتصال انترنت مستقر
• نفترض ان الجامعة توفر سيرفر للاستضافة

---

القسم الثالث: المتطلبات الوظيفية (Functional Requirements)

هنا القلب الحقيقي للوثيقة. المتطلبات الوظيفية تصف بالضبط ايش النظام يقدر يسويه. كل وظيفة لازم تكون مرقمة، واضحة، ومحددة. هذا القسم اللي المشرف يقضي أكثر وقته يقرأه.

القاعدة الذهبية: كل متطلب لازم يكون قابل للاختبار

لو كتبت متطلب وما تقدر تصمم اختبار (Test Case) يثبت انه تحقق أو ما تحقق، فهذا متطلب ضعيف. لازم تسأل نفسك: كيف اثبت ان هذا المتطلب اتنفذ؟

مثال عملي: نظام تسجيل طلاب

هذي أمثلة على متطلبات وظيفية مكتوبة بشكل صحيح:

FR-001: يجب أن يتمكن الطالب من تسجيل الدخول باستخدام
        الرقم الجامعي وكلمة المرور.

FR-002: يجب أن يعرض النظام قائمة المقررات المتاحة
        للتسجيل بناء على خطة الطالب الدراسية.

FR-003: يجب أن يتمكن الطالب من اضافة مقرر إلى جدوله
        بشرط عدم وجود تعارض في الوقت.

FR-004: يجب أن يرسل النظام اشعار بريد الكتروني للطالب
        عند تأكيد التسجيل أو رفضه.

FR-005: يجب أن يتمكن المرشد الاكاديمي من الموافقة على
        طلبات التسجيل أو رفضها مع ذكر السبب.

FR-006: يجب أن يتمكن مدير النظام من اضافة مقررات جديدة
        وتحديد الحد الأقصى لعدد الطلاب في كل شعبة.

مثال عملي: تطبيق متجر الكتروني

FR-001: يجب أن يتمكن الزائر من تصفح المنتجات
        بدون تسجيل حساب.

FR-002: يجب أن يتمكن المستخدم من البحث عن منتجات
        بالاسم أو الفئة أو نطاق السعر.

FR-003: يجب أن يتمكن المستخدم المسجل من اضافة
        منتجات إلى سلة التسوق.

FR-004: يجب أن يحسب النظام اجمالي الطلب شامل ضريبة
        القيمة المضافة (15%) ورسوم الشحن.

FR-005: يجب أن يتمكن البائع من اضافة منتجات جديدة
        مع الصور والوصف والسعر والكمية المتاحة.

FR-006: يجب أن يتمكن مدير النظام من مراجعة المنتجات
        المضافة والموافقة عليها قبل نشرها.

كيف تكتب متطلب وظيفي صحيح

لاحظ في الأمثلة فوق ان كل متطلب:

• يبدأ بـ “يجب أن” وهذا يجعله الزامي وواضح
• يحدد الفاعل (الطالب، المرشد، مدير النظام، الزائر)
• يحدد الاجراء بشكل دقيق (تسجيل دخول، اضافة مقرر، البحث)
• يذكر الشروط ان وجدت (بشرط عدم وجود تعارض)
• مرقم برقم فريد يسهل الاشارة اليه لاحقا

---

القسم الرابع: المتطلبات غير الوظيفية (Non-Functional Requirements)

المتطلبات غير الوظيفية تصف كيف النظام يشتغل، مو ايش يسوي. يعني: السرعة، الأمان، سهولة الاستخدام. هي اللي تفرق بين نظام “يشتغل” ونظام يشتغل بشكل يحترم المستخدم.

الأداء (Performance)

NFR-001: يجب أن يستجيب النظام لطلبات البحث
         خلال 3 ثواني كحد أقصى.

NFR-002: يجب أن يتحمل النظام 100 مستخدم متصل
         في نفس الوقت بدون تأثر ملحوظ في الأداء.

NFR-003: يجب أن لا يتجاوز وقت تحميل أي صفحة
         5 ثواني على اتصال انترنت بسرعة 5 Mbps.

الأمان (Security)

NFR-004: يجب تشفير كلمات المرور باستخدام خوارزمية
         bcrypt قبل تخزينها في قاعدة البيانات.

NFR-005: يجب أن تنتهي جلسة المستخدم (Session) تلقائيا
         بعد 30 دقيقة من عدم النشاط.

NFR-006: يجب أن يمنع النظام محاولات تسجيل الدخول
         بعد 5 محاولات فاشلة متتالية لمدة 15 دقيقة.

سهولة الاستخدام (Usability)

NFR-007: يجب أن يتمكن مستخدم جديد من اتمام عملية
         التسجيل بدون مساعدة خارجية خلال 5 دقائق.

NFR-008: يجب أن يدعم النظام اللغة العربية والانجليزية
         مع امكانية التبديل بينهما من أي صفحة.

NFR-009: يجب أن يكون تصميم الواجهات متوافقا مع
         الشاشات بأحجام 320px إلى 1920px (متجاوب).

التوفر والموثوقية (Availability & Reliability)

NFR-010: يجب أن يكون النظام متاحا بنسبة 99%
         خلال ساعات العمل الرسمية (8 صباحا - 10 مساء).

NFR-011: يجب عمل نسخة احتياطية من قاعدة البيانات
         مرة واحدة يوميا على الأقل.

---

متطلبات الواجهات الخارجية (External Interface Requirements)

هذا القسم يصف كيف نظامك يتواصل مع العالم الخارجي. ينقسم إلى أربعة أنواع.

واجهة المستخدم (User Interface)

صف شكل التفاعل بين المستخدم والنظام بشكل عام. ما تحتاج تحط تصاميم كاملة هنا، بس اذكر المبادئ العامة:

• النظام يستخدم واجهة ويب تعمل على المتصفح
• التصميم يتبع مبادئ Material Design
• الألوان الرئيسية: أزرق داكن للعناصر الأساسية، أبيض للخلفية
• القوائم تكون على الجانب الأيمن (لدعم العربية)

واجهة الأجهزة (Hardware Interface)

اذا نظامك يتعامل مع أجهزة معينة، وضحها هنا. مثلا:

• قارئ البطاقة الذكية لتوثيق هوية الطالب
• طابعة لطباعة الجدول الدراسي

اذا مشروعك تطبيق ويب بحت وما يتعامل مع أجهزة خاصة، تقدر تكتب “لا توجد واجهات أجهزة خاصة” وهذا مقبول تماما.

واجهة البرمجيات (Software Interface)

وضح الأنظمة والخدمات الخارجية اللي نظامك يتكامل معها:

• Firebase Authentication لتسجيل الدخول
• Stripe API لمعالجة المدفوعات
• خدمة SendGrid لارسال البريد الالكتروني
• قاعدة البيانات: MySQL 8.0 على سيرفر AWS RDS

واجهة الاتصالات (Communication Interface)

صف بروتوكولات الاتصال المستخدمة:

• الاتصال بين الواجهة الأمامية والخادم عبر HTTPS (REST API)
• تنسيق البيانات المتبادلة: JSON
• اذا فيه اتصال فوري: WebSocket لخاصية الاشعارات المباشرة

---

كيف تكتب SRS مشروع تخرج خطوة بخطوة

فهمت الأقسام؟ طيب. هذي الخطوات العملية اللي تبدأ فيها اليوم (حرفيا اليوم، مو بكرة).

---

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

شفنا عشرات وثائق SRS من طلاب في جامعات سعودية مختلفة (جامعة الملك عبدالعزيز، جامعة الملك سعود، جامعة أم القرى). نفس الأخطاء تتكرر كل فصل دراسي.

1. نسخ وثيقة مشروع ثاني وتغيير الاسم

هذا أكثر خطأ نشوفه. الطالب يلاقي وثيقة SRS على الانترنت لمشروع مشابه، ينسخها ويغير اسم المشروع والمتطلبات السطحية. النتيجة؟ المشرف يكتشف هذا في ثانيتين لأن القيود والافتراضات ما تنطبق على مشروعك. وفي لجنة المناقشة، أول سؤال يكشفك. واحد من الطلاب نسخ وثيقة فيها “النظام يدعم الدفع بالدولار” وهو مشروعه محلي بالكامل. المشرف ما احتاج يسأل كثير.

2. كتابة متطلبات عامة وغامضة

“النظام يكون سريع” و”النظام يكون آمن” و”الواجهة تكون جميلة” ليست متطلبات. كل متطلب لازم يكون محدد بمعيار قابل للقياس. بدل “سريع”، اكتب “وقت الاستجابة أقل من 3 ثواني”. بدل “آمن”، اكتب “تشفير البيانات باستخدام AES-256”.

3. خلط المتطلبات الوظيفية بغير الوظيفية

المتطلب الوظيفي يصف ايش النظام يسوي (اجراء محدد). المتطلب غير الوظيفي يصف كيف يسويه (معيار جودة). لا تخلطهم في نفس القائمة. رقم كل نوع بشكل منفصل: FR للوظيفية و NFR لغير الوظيفية.

4. نسيان أصحاب المصلحة الثانويين

الطلاب يكتبون متطلبات المستخدم الأساسي وينسون باقي الأدوار. نظام تسجيل طلاب ما يخدم الطلاب بس، فيه مرشد أكاديمي ومدير نظام وموظف قبول. كل دور يحتاج متطلبات خاصة فيه.

5. عدم ربط المتطلبات ببعضها

بعض المتطلبات تعتمد على بعض. مثلا، ما يقدر الطالب يسجل مقرر (FR-003) اذا ما سجل دخول أولا (FR-001). وضح هذي التبعيات في الوثيقة.

6. المبالغة في التفصيل أو التبسيط

بعض الطلاب يكتبون وثيقة من صفحتين فقط وبعضهم يكتبون 80 صفحة. الحد المعقول لمشروع تخرج عادي هو 15 إلى 30 صفحة. تكفي تغطي كل شيء بوضوح بدون تكرار أو حشو.

---

كم التفصيل المطلوب في SRS مشروع التخرج

كل طالب يسأل نفس السؤال: كم المفروض أكتب؟ الجواب: اكتب بالقدر الكافي عشان مبرمج ثاني (ما يعرف مشروعك) يقدر يبني النظام من وثيقتك بدون ما يرسلك واتساب كل ساعة يسأل.

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

لو اديت وثيقتك لزميل في القسم ما يعرف مشروعك، وقدر يفهم بالضبط ايش النظام يسوي وايش ما يسويه من الوثيقة فقط، فأنت في المسار الصحيح. لو سألك أسئلة كثيرة، الوثيقة ناقصة.

أرقام تقريبية لمشروع تخرج

• المقدمة: 2-3 صفحات
• الوصف العام: 3-5 صفحات
• المتطلبات الوظيفية: 5-10 صفحات (حسب حجم النظام)
• المتطلبات غير الوظيفية: 2-3 صفحات
• واجهات النظام: 2-4 صفحات
• الاجمالي: 15-25 صفحة (بدون الملاحق)

هذي أرقام تقريبية. تطبيق مهام بسيط (To-Do)؟ ممكن 12 صفحة تكفي. نظام ادارة مستشفى فيه 8 أنواع مستخدمين؟ توقع 35+ صفحة.

---

قالب SRS جاهز لمشروع التخرج

هذا هيكل كامل تقدر تنسخه وتبدأ تعبيه مباشرة. عدل الأقسام حسب مشروعك:

# وثيقة مواصفات متطلبات البرمجيات (SRS)
# [اسم المشروع]

## سجل التعديلات
| الاصدار | التاريخ | الوصف | المعدل |
|---------|---------|-------|--------|
| 1.0     | --/--/---- | الاصدار الأولي | [الاسم] |

---

## 1. المقدمة

### 1.1 الغرض
[اشرح الغرض من هذه الوثيقة ومن الجمهور المستهدف]

### 1.2 النطاق
[صف حدود النظام: ايش يشمل وايش لا يشمل]

### 1.3 التعريفات والاختصارات
| المصطلح | التعريف |
|---------|---------|
| ...     | ...     |

### 1.4 المراجع
[اذكر المعايير والمصادر المستخدمة]

---

## 2. الوصف العام

### 2.1 منظور المنتج
[هل النظام مستقل أو جزء من نظام أكبر؟]

### 2.2 وظائف النظام الرئيسية
[قائمة مختصرة بأهم وظائف النظام]

### 2.3 خصائص المستخدمين
| نوع المستخدم | الوصف | المستوى التقني |
|-------------|-------|---------------|
| ...         | ...   | ...           |

### 2.4 القيود
[القيود التقنية والادارية]

### 2.5 الافتراضات والتبعيات
[ايش تفترض انه صحيح أو موجود]

---

## 3. المتطلبات التفصيلية

### 3.1 المتطلبات الوظيفية

#### 3.1.1 ادارة المستخدمين
| الرقم  | المتطلب | الأولوية |
|--------|---------|---------|
| FR-001 | ...     | عالية   |
| FR-002 | ...     | عالية   |

#### 3.1.2 [الوظيفة الثانية]
| الرقم  | المتطلب | الأولوية |
|--------|---------|---------|
| FR-003 | ...     | متوسطة |

### 3.2 المتطلبات غير الوظيفية

#### 3.2.1 الأداء
| الرقم   | المتطلب | المعيار |
|---------|---------|--------|
| NFR-001 | ...     | ...    |

#### 3.2.2 الأمان
| الرقم   | المتطلب | المعيار |
|---------|---------|--------|
| NFR-002 | ...     | ...    |

#### 3.2.3 سهولة الاستخدام
| الرقم   | المتطلب | المعيار |
|---------|---------|--------|
| NFR-003 | ...     | ...    |

---

## 4. متطلبات الواجهات الخارجية

### 4.1 واجهة المستخدم
[وصف عام للواجهات]

### 4.2 واجهة الأجهزة
[أي أجهزة خارجية يتعامل معها النظام]

### 4.3 واجهة البرمجيات
[الأنظمة والخدمات الخارجية]

### 4.4 واجهة الاتصالات
[بروتوكولات الاتصال المستخدمة]

---

## الملاحق
[أي مواد اضافية: مخططات أولية، نماذج شاشات، مسرد مصطلحات موسع]

---

أدوات مقترحة لكتابة SRS

ما تحتاج أداة خاصة. أي محرر نصوص يشتغل. بس بعض الأدوات تسهل حياتك أكثر من غيرها:

Google Docs (مجاني، الأفضل للعمل الجماعي)

لو فريقك يشتغل على الوثيقة مع بعض، هذا خيارك. كل شخص يعدل في نفس الوقت، فيه تاريخ التعديلات، وتقدر ترسل الرابط للمشرف يراجع ويعلق مباشرة. ابدأ بقالب فاضي وطبق الهيكل اللي شرحناه فوق.

Microsoft Word (الأكثر قبولا أكاديميا)

اذا جامعتك تطلب تسليم الوثائق بصيغة Word أو PDF، فـ Word هو الخيار المباشر. استخدم الأنماط (Styles) لتنسيق العناوين عشان تقدر تنتج جدول محتويات تلقائي. أغلب الجامعات السعودية تقبل Word بدون مشاكل.

Notion (مرن ومنظم)

Notion ممتاز لو تبي تنظم وثائقك كلها في مكان واحد: SRS، خطة المشروع، ملاحظات الاجتماعات. فيه قوالب جاهزة ويدعم الجداول والتنسيق بشكل ممتاز. لكن تأكد ان تصدر نسخة PDF أو Word للتسليم الرسمي.

LaTeX (للمتقدمين)

لو عندك خبرة في LaTeX، فيه قوالب SRS جاهزة على Overleaf تطلع بتنسيق احترافي. لكن بصراحة؟ لو ما استخدمت LaTeX قبل كذا، لا تتعلمه عشان وثيقة SRS. منحنى التعلم ما يستاهل لمهمة واحدة.

---

كيف تربط SRS بباقي وثائق مشروعك

وثيقة SRS ما تشتغل لوحدها. اذا كتبت خطة مشروع التخرج قبلها، تأكد ان النطاق والأهداف متطابقة بين الوثيقتين (المشرفين ينتبهون لهذا). والخبر الحلو: اذا كتبت SRS بشكل سليم، فصل المتطلبات في تقرير مشروع التخرج يصير جاهز عندك تقريبا.

ترتيب الوثائق المثالي في مشروع التخرج:

1. اختيار الفكرة: حدد مشكلة تستحق الحل (دليل اختيار فكرة المشروع)
2. خطة المشروع: حدد الأهداف والمنهجية والجدول الزمني
3. وثيقة SRS: فصل المتطلبات بشكل دقيق (هذا المقال)
4. التصميم (SDD): صمم بنية النظام وقاعدة البيانات والواجهات
5. التنفيذ والاختبار: ابرمج واختبر بناء على المتطلبات
6. التقرير النهائي: وثق كل شيء في التقرير الأكاديمي

---

الخطوة الجاية

الحين عندك كل اللي تحتاجه: الهيكل واضح، الأمثلة قدامك، والقالب جاهز تنسخه. ابدأ بالمتطلبات الوظيفية لأنها أصعب جزء وأهم جزء. اكتبها، رقمها، واسأل نفسك عن كل وحدة: “أقدر أصمم اختبار لها؟” لو الجواب لا، أعد صياغتها.

وقبل ما تسلم الوثيقة للمشرف، خل زميلك في الفريق يقرأها. لو سألك أسئلة كثيرة، الوثيقة ناقصة.

لو لسا ما بدأت في مشروعك أصلا، ارجع لدليل كيف تختار فكرة مشروع تخرج مميزة ثم كيف تكتب خطة مشروع تخرج. وبعدها ارجع هنا.

شيء أخير: الوقت اللي تصرفه على SRS صحيحة من البداية يوفر عليك أسابيع من التعديلات لاحقا. هذي مو مبالغة، هذا كلام ناس جربت.