‫رنا حسين الشهراني‬

‫‪Ch3‬‬
‫صفحة ‪18‬‬

‫‪ .3‬هندسة المتطلبات عملية تحديد وتوثيق المتطلبات التي تعني ما يتطلبه العميل من النظام والقيود التي يجب أن يعمل‬

‫النظام بموجبها‪.‬‬

‫‪ 3.1‬أنواع المتطلبات‬

‫‪ ‬متطلبات األعمال‬

‫‪ ‬متطلبات المستخدم‬

‫‪   ‬متطلبات البرامج‬

‫‪ o‬المتطلبات الوظيفية‬

‫‪ o‬المتطلبات غير الوظيفية‬

‫‪ 3.1.1‬متطلبات األعمال‬

‫بيان مستوى أعلى من أهداف وأهداف واحتياجات المنظمة‪.‬‬

‫‪ 3.1.2  ‬متطلبات المستخدم‪3‬‬

‫‪  ‬بيانات بلغة طبيعية باإلضافة إلى بعض الرسوم البيانية التي توضح الحاجة لمستخدم معين‬

‫‪ 3.1.3‬متطلبات البرامج‬

‫‪  ‬متطلبات البرامج هي وصف تفصيلي لنظام برمجيات يتم تطويره‪ .‬وهو يغطي المتطلبات الوظيفية وغير الوظيفية‪ .‬يتم‬
‫صياغة هذه المتطلبات بشكل صحيح في شكل وثيقة تعرف باسم وثيقة مواصفات متطلبات البرامج (‪ .)SRS‬يستخدم ‪SRS‬‬
‫كإتفاق بين العمالء والمقاولين‪ .‬يساعد ‪ SRS‬في التقييم الحقيقي للمتطلبات قبل بدء التصميم‪ .‬كما يوفر أسا ًسا واقعيًا لتقدير‬
‫تكاليف المنتج ‪ ،‬والمخاطر ‪ ،‬والجداول الزمنية‪ .‬يمكن أن يساعد االستخدام الصحيح لـ ‪ SRS‬في تجنب فشل مشروع‬
‫البرنامج‬

‫صفحة ‪19‬و‪20‬‬

‫‪ 3.2‬المتطلبات الوظيفية‬

‫هذه هي بيانات الخدمات‪ 3‬التي يجب أن يوفرها النظام ‪ ،‬وكيف يجب أن يتفاعل النظام مع مدخالت‪ 3‬معينة ‪ ،‬وكيف يجب أن‬
‫يتصرف النظام في مواقف معينة‪ .‬في بعض الحاالت ‪ ،‬قد تحدد المتطلبات الوظيفية بوضوح ما يجب أال يفعله النظام‪.‬‬
‫تعتمد هذه المتطلبات على نوع البرامج التي يتم تطويرها ‪ ،‬والمستخدمين المتوقعين للبرنامج ‪ ،‬والنهج العام الذي تتبعه‬
‫المنظمة عند كتابة المتطلبات‪.‬‬

‫‪ 3.3‬متطلبات غير وظيفية‬

‫هذه قيود على الخدمات أو الوظائف التي يقدمها النظام‪ .‬غالبًا ما تنطبق هذه المتطلبات على النظام ككل ‪ ،‬بدالً من ميزات‬
‫أو خدمات النظام الفردية‪ .‬ال تتعلق المتطلبات غير الوظيفية بشكل مباشر بالخدمات المحددة التي يقدمها النظام لمستخدميها‪3‬‬
‫بدالً من ارتباطها بخصائص النظام مثل الموثوقية ووقت االستجابة واحتياجات‪ 3‬التخزين‪ .‬بدال من ذلك ‪ ،‬قد تحدد القيود‬
‫على تنفيذ النظام مثل قدرات أجهزة اإلدخال ‪ /‬اإلخراج أو تمثيالت البيانات المستخدمة في واجهات مع أنظمة أخرى‬

‫‪ 3.3.1‬التصنيفات غير الوظيفية‬

 ‫رنا حسين الشهراني‬

‫متطلبات المنتج‪ :‬تحدد هذه المتطلبات خصائص سلوك البرامج مثل األداء (مدى سرعة تنفيذ النظام ومقدار الذاكرة‬
‫المطلوبة) والموثوقية (ما هو معدل الفشل المقبول) واألمان وسهولة االستخدام‪( .‬شرح في القسم‬

‫‪ )3-3-2‬المتطلبات التنظيمية ‪ :‬تمثل هذه المتطلبات متطلبات واسعة للنظام مستمدة من السياسات‪ 3‬واإلجراءات في منظمة‬
‫العميل ومن جانب المطورين‪.‬‬

‫وتشمل هذه المتطلبات المتطلبات التشغيلية التي تعني كيفية استخدام النظام وتطويره‬

‫تحدد المتطلبات لغة البرمجة ‪ ،‬بينما تحدد المتطلبات البيئية بيئة التشغيل الخاصة بالنظام‪.‬‬

‫‪ ‬المتطلبات الخارجية‪ :‬تستمد هذه المتطلبات من عوامل خارجية إلى النظام وعملية تطويره‪.‬‬

‫وهي تشمل المتطلبات التنظيمية التي تعني الميزات التي تساعد في اعتماد النظام من قبل جهة تنظيمية ‪ ،‬وتضمن‬
‫المتطلبات التشريعية أن النظام يعمل ضمن القانون ‪ ،‬وتضمن المتطلبات األخالقية أن يكون النظام مقبواًل لمستخدميه‬
‫وعامة الجمهور‪.‬‬

‫‪ 3.3.2‬المقاييس لتحديد المتطلبات غير الوظيفية‬

‫خاصية‬ ‫قياس‬
‫سرعة‬ ‫المعامالت‪ 3‬التي تمت معالجتها ‪ /‬توقيت تحديث الشاشة‪3‬‬
‫الثاني‬
‫حجم‬ ‫بايت ‪ M‬عدد رقائق ‪ROM‬‬

‫سهولة االستعمال‬ ‫وقت التدريب عدد إطارات المساعدة‬

‫الموثوقية‬ ‫متوسط الوقت للفشل‬

‫احتمال عدم التوافر‬
‫معدل حدوث الفشل‬
‫قابلية التنقل‬ ‫لنسبة المئوية للبيانات المستقلة المستهدفة‪3‬‬
‫عدد األنظمة المستهدفة‬
‫الوقت إلعادة تشغيل بعد الفشل‬
‫النسبة المئوية لألحداث التي تسبب الفشل‬
‫احتمال تلف البيانات عند الفشل‬
‫‪ 3.4‬المتطلبات اكتمالها واتساقها‬

‫من حيث المبدأ ‪ ،‬ينبغي أن تكون المتطلبات كاملة ومتسقة‪.‬‬

‫‪  ‬مكتمل‪ :‬يجب أن تتضمن أوصا ًفا لجميع التسهيالت المطلوبة‪.‬‬

‫متسقة‪ :‬يجب أال يكون هناك أي تعارض في أوصاف مرافق النظام‪ .‬من الناحية العملية ‪ ،‬من المستحيل إنتاج وثيقة‬
‫متطلبات كاملة ومتسقة‪.‬‬

‫صفحة ‪12‬‬

‫‪ SRS 3.5‬الوثيقة‬

‫‪ SRS‬هي وثيقة مرحلة تحليل وليست وثيقة تصميم ‪ ،‬لذا فهي تنص على ما يجب أن يفعله نظام وظائف ‪ WHAT‬بدالً من‬
‫كيفية القيام به‪.‬‬

‫وثيقة ‪ SRS‬هي الوثيقة األولى واألكثر أهمية في ‪ SDLC‬مما يعني أنه إذا كان هناك أي خطأ في هذا المستند ‪ ،‬فقد يستمر‬
‫حتى المرحلة األخيرة وقد تضيع جميع الجهود‪ .‬فهو يساعد مختلف الناس في نطاق عملهم‪ .‬في جانب العمالء الذي يتراوح‬
 ‫رنا حسين الشهراني‬

‫من اإلدارة العليا إلى مستخدمي إدخال البيانات بشكل مشابه في جانب التطوير ‪ ،‬يتم استخدامه من قبل مدير المشروع‬
‫والمهندسين المسؤولين عن تطوير البرنامج‪.‬‬

‫صفحة ‪22‬‬

‫الرموز‬ ‫وصف‬
‫جمل لغة طبيعية‬ ‫يتم كتابة المتطلبات باستخدام جمل مرقمة باللغة الطبيعية‪.‬‬
‫يجب أن تعبر كل جملة عن متطلب واحد‪.‬‬
‫لغة طبيعية منظمة‬ ‫تتم كتابة المتطلبات بلغة طبيعية على نموذج أو قالب‬
‫قياسي‪ .‬يقدم كل حقل معلومات حول جانب من المتطلبات‬
‫لغات وصف التصميم‬ ‫يستخدم هذا األسلوب لغة مثل لغة البرمجة ‪ ،‬ولكن مع‬
‫ميزات أكثر تجريدية لتحديد المتطلبات من خالل تحديد‬
‫العمليات‬
‫نموذج من النظام‪ .‬نادرً ا ما يتم استخدام هذا األسلوب على‬
‫الرغم من أنه يمكن أن يكون مفي ًدا لمواصفات الواجهة‬
‫تدوينات رسومية‬
‫تستعمل النماذج الرسومية ‪ ،‬المكملة بالتعليقات التوضيحية‬
‫النصية ‪ ،‬لتحديد المتطلبات الوظيفية للنظام ؛ تستخدم‬
‫‪ UML‬استخدام الرسوم البيانية وتسلسل الحالة بشكل شائع‬
‫المواصفات الرياضية‬ ‫ترتكز هذه الرموز على مفاهيم رياضية مثل أجهزة أو‬
‫مجموعات الحالة المحدودة‪ .‬على الرغم من أن هذه‬
‫المواصفات غير الواضحة يمكن أن تقلل من الغموض في‬
‫مستند المتطلبات ‪ ،‬فإن معظم العمالء ال يفهمون مواصفات‬
‫رسمية‪ .‬ال يمكنهم التحقق من أنها تمثل ما يريدون‬
‫ويترددون في قبوله كنظام عقد‬
‫‪ 3.6‬متطلبات هندسة العمليات (‪)RE‬‬

‫تختلف العمليات المستخدمة‪ 3‬لتكنولوجيا ‪ RE‬بشكل كبير حسب مجال التطبيق واألشخاص المعنيين والمنظمة التي تطور‬
‫المتطلبات‪.‬‬

‫ومع ذلك ‪ ،‬هناك عدد من األنشطة العامة المشتركة لجميع العمليات‬

‫‪ ‬استنباط متطلبات‬

‫‪ ‬تحليل المتطلبات‬

‫‪ ‬متطلبات التحقق من الصحة‬

‫ً‬
‫نشاطا تكراريًا يتم فيه تشذير هذه العمليات‪.‬‬ ‫‪ ‬إدارة المتطلبات من الناحية العملية ‪ ،‬يعد ‪RE‬‬

‫صفحة ‪23‬‬

‫‪ 3.6.1‬متطلبات عملية االنتقاء والتحليل‬

‫يعمل مهندسو البرامج مع مجموعة من أصحاب المصلحة في النظام لمعرفة تطبيق البرنامج‪ .‬بشكل عام ‪ُ ،‬تعرف هذه‬
‫العملية باسم تجميع المتطلبات وتحويلها إلى‬

‫التفاصيل التقنية حتى يمكن تحويلها بسهولة إلى وثيقة التصميم‪.‬‬

‫اكتشاف المتطلبات‪ :‬التفاعل مع أصحاب المصلحة الكتشاف متطلباتهم‪ .‬يتم اكتشاف متطلبات المجال أيضا في هذه‬
‫المرحلة‪.‬‬
 ‫رنا حسين الشهراني‬

‫تصنيف المتطلبات وتنظيمها‪ :‬المتطلبات ذات الصلة بالمجموعات وتنظمها في مجموعات متماسكة‪.‬‬

‫تحديد األولويات والتفاوض‪ :‬تحديد أولويات المتطلبات وحل النزاعات‪.‬‬

‫مواصفات المتطلبات‪ :‬يتم توثيق المتطلبات والمدخالت‪ 3‬في الجولة التالية من الحلزونية‬

‫صفحة ‪24‬‬

‫‪ 3.6.2‬متطلبات تقنيات االنتصاف‬

‫يقوم مهندسو المتطلبات بتجميع المتطلبات من العمالء‪ 3‬في حالة المنتجات التي يتم التحدث بها من خالل العديد من التقنيات‬
‫‪ ،‬يتم إعطاء أدناه األساليب األكثر استخدامًا‪:‬‬

‫تحليل الوثيقة‪ :‬هو أسلوب لمراجعة الوثائق الحالية لألنظمة المقارنة لجمع المعلومات األقرب إلى النظام قيد التطوير‪.‬‬
‫مقابلة‪ :‬هي أسهل وأقوى تقنية لجمع المتطلبات‪ .‬مهندس المتطلبات إجراء مقابالت مع العمالء في شكل حوار منظم‪.‬‬

‫المالحظة‪ :‬هي تقنية فعالة لتحديد كيفية أداء المستخدمين لوظائفهم من خالل مشاهدتها في بيئة عملهم‪ .‬إنه يزيد من معرفة‬
‫مهندس المتطلبات بأسلوب العمل لمجموعة من األشخاص‪ .‬يتم اتباع هذه التقنية حيث ال يمكن للعمالء شرح متطلباتهم‬
‫شفهيا في المقابالت‪ .‬النمذجة‪ :‬هي عملية تكرارية تشمل المستخدمين إلكمال المتطلبات‪ .‬يقدم المستخدمون المتطلبات‬
‫وفريق المطور إلنشاء نظام تقريبي وعرض النتائج مرة أخرى للمستخدم‪ .‬وهو فعال للغاية حيث يشارك المستخدمون‬
‫بشكل كامل لتصحيح معلوماتهم وتعديلها‪ .‬يساعد المستخدم على استدعاء جميع الوظائف التي قد ال يدركونها حتى يروا‬
‫العمل‬

‫صفحة ‪25‬‬

‫نسخة من النظام‪ .‬سيستمر المستخدم‪ 3‬والمحلل في تنفيذ التكرارات المختلفة ‪ ،‬إلى أن تكتمل جميع المواصفات‪ .‬سيتم‬
‫استخدام النموذج األولي كنموذج لبناء النظام الفعلي‪.‬‬

‫‪ 3.6.3‬مشاكل خالل متطلبات االستنتاج‬

‫‪ -‬ال يعرف أصحاب المصلحة ما يريدون فعالً‪.‬‬

‫‪ -‬يعبّر أصحاب المصلحة عن متطلباتهم وفق شروطهم الخاصة‪.‬‬

‫‪ -‬قد يكون لدى أصحاب المصلحة المختلفين متطلبات متضاربة‪.‬‬

‫‪ -‬قد تؤثر العوامل التنظيمية والسياسية على متطلبات النظام‪.‬‬

‫‪ -‬تتغير المتطلبات خالل عملية التحليل‪ .‬قد يظهر أصحاب المصلحة الجدد وقد تتغير بيئة األعمال‪.‬‬