‫‪Software Engineering I‬‬

‫هندسة برمجيات ‪1‬‬

‫محاضرة ‪ :6‬هندسة ا‪1‬تطلبات‪:‬‬

‫الجزء ا‪8‬ول‬
‫‪requirement‬‬
‫‪engineering:‬علي معيوف‬
‫‪ part‬اعداد‪ :‬د‪ .‬مبروكه‬
‫ربيع ‪one‬‬
‫‪2020/07/20-2020‬‬
 ‫هندسة ا‪/‬تطلبات‪ :‬الجزء ا‪#‬ول‬
‫‪software engineering: part one‬‬
‫ا‪/‬واضيع التي تمت تغطيتها‬
‫ا‪1‬تطلبات الوظيفية وغير الوظيفية •‬
‫وثيقة متطلبات البرمجية •‬
‫مواصفات ا‪1‬تطلبات •‬
‫عمليات هندسة ا‪1‬تطلبات •‬
‫استنباط و تحليل ا‪1‬تطلبات •‬
‫التحقق من صحة ا‪1‬تطلبات •‬
‫إدارة ا‪1‬تطلبات •‬
 ‫هندسة ا'تطلبات‬

‫عملية إنشاء الخدمات التي يحتاجها العميل من النظام •‬

‫‪.‬والقيود التي يعمل بموجبها وتطويرها‬

‫ا‪M‬تطلبات نفسها هي أوصاف خدمات النظام والقيود التي •‬

‫‪.‬يتم إنشاؤها أثناء عملية هندسة ا‪M‬تطلبات‬
 ‫ما هي ا(تطلبات؟‬
‫قد يتراوح ذلك من بيان تجريدي رفيع ا‪,‬ستوى لخدمة أو •‬
‫‪.‬قيود نظام إلى مواصفات وظيفية رياضية مفصلة‬
‫هذا أمر ‪ S‬مفر منه ‪P‬ن ا‪,‬تطلبات قد تخدم وظيفة مزدوجة •‬
‫قد تكون ا‪P‬ساس للعقد ب‪ W‬الزبون و ا‪,‬طور ‪ -‬لذلك يجب أن –‬
‫مفتوحا للتفسير ؛‬
‫ً‬ ‫يكون‬
‫قد يكون أساس العقد نفسه ‪ -‬لذلك يجب تحديده بالتفصيل ؛ –‬
‫‪.‬كل هذه العبارات قد تسمى ا‪,‬تطلبات •‬
 ‫)تجريد ا‪,‬تطلبات )ديفيس‬
‫)‪requirements abstraction (Davis‬‬
‫إذا كانت الشركة ترغب في السماح بعقد مشروع كبير" •‬
‫لتطوير البرمجيات ‪ ،‬فيجب عليها تحديد احتياجاتها‬
‫بطريقة مجردة بما فيه الكفاية بحيث ‪ N‬يتم تحديد أي حل‬
‫مسب ًقا‪ .‬يجب كتابة ا‪V‬تطلبات بحيث يمكن للعديد من‬
‫ا‪V‬قاول] تقديم عطاءات للعقد ‪ ،‬وتقديم طرق مختلفة ربما‬
‫لتلبية احتياجات ا‪V‬ؤسسة العميلة‪ .‬بمجرد منح العقد ‪،‬‬
‫يجب على ا‪V‬قاول كتابة تعريف للنظام للعميل بمزيد من‬
‫التفاصيل حتى يفهم العميل ما يمكن أن يفعله‬
‫البرنامج‪ .‬يمكن تسمية كلتا الوثيقت] بوثيقة ا‪V‬تطلبات‬
‫" ‪.‬للنظام‬
 ‫أنواع ا'تطلبات‬
‫متطلبات ا&ستخدم •‬
‫بيانات باللغة الطبيعية با‪9‬ضافة إلى الرسوم البيانية للخدمات –‬
‫‪.‬التي يوفرها النظام والقيود التشغيلية‪ .‬مكتوبة للعم>ء‬
‫متطلبات النظام •‬
‫وثيقة منظمة تحدد ا‪Q‬وصاف التفصيلية لوظائف النظام –‬
‫والخدمات والقيود التشغيلية‪ .‬يحدد ما يجب تنفيذه بحيث يكون‬
‫‪.‬جز ًءا من عقد ب] العميل وا&طور‬
 ‫متطلبات ا&ستخدم‬
‫حالة دراسية‪ :‬نظام ا&علومات للصحة العقلية‪MHC-PMS‬‬
‫نظام ا‪6‬علومات للصحة العقلية يهدف الى توفير معلومات •‬
‫عن الصحة العقلية لكل زبون )مستخدم( سواء مريض ام‬
‫‪G.‬‬
‫اذا كان الزبون مريض يتم فتح ملف له و تسجيل بياناته و •‬
‫‪.‬الطبيب ا‪6‬عالج له و بيانات زياراته و الع‪S‬ج ا‪6‬عطى له‬
‫يصدر النظام شهريا ً تقارير ادارية تب‪ Y‬تكلفة الدواء بكل •‬
‫)عيادة تتبع هذا النظام )متطلبات مستخدم‬
 ‫متطلبات النظام‬
‫حالة دراسية‪ :‬نظام ا‪2‬علومات للصحة‪MHC-PMS‬‬
‫العقلية تقرير مختصرعن •‬
‫في نهاية كل شهر‪ ،‬يصدر النظام‬
‫ا‪D‬دوية و تكلفتها بكل عيادة‬
‫يجب ان يكون النظام قادرا على اصدار التقرير تلقائيا ً •‬
‫بعد الساعة ‪ 17:30‬في اخر يوم من الشهر‬
‫يجب اصدار تقرير با‪D‬دوية خاص لكل عيادة يشمل اسم •‬
‫الدواء و كمية الجرعة و الكمية ا‪V‬توفرة و التكلفة‬
‫اذا كان الدواء يتوفر بجرعات مختلفة‪ ،‬يجب ان يكون هناك •‬
‫تقرير منفصل لكل دواء حسب الجرعة‬
‫‪ D‬يسمح للوصول لتقاربر التكلفة ا‪ D‬للمخول^ فقط •‬
‫قارئوا أنواع مختلفة من مواصفات‬
‫ا‪5‬تطلبات‬
 ‫ا‪.‬تطلبات الوظيفية‬
‫‪ functional requirements‬ا‪.‬تطلبات الوظيفية •‬
‫بيانات الخدمات التي يجب أن يقدمها النظام ‪ ،‬وكيف يجب أن –‬
‫يتفاعل النظام مع مدخ‪G‬ت معينة وكيف يجب أن يتصرف‬
‫‪.‬النظام في مواقف معينة‬
‫‪.‬قد يذكر ما ‪ P‬ينبغي للنظام القيام به –‬
 ‫ا‪0‬تطلبات غير الوظيفية‬
‫‪non functional requirements‬‬
‫القيود ا‪0‬فروضة على الخدمات أو الوظائف التي يقدمها النظام –‬
‫‪.‬مثل قيود التوقيت ‪ ،‬والقيود على عملية التطوير ‪ ،‬وا‪0‬عايير ‪ ،‬إلخ‬
‫غالبًا ما تنطبق على النظام ككل بد‪ ًO‬من ا‪0‬يزات أو الخدمات –‬
‫‪.‬الفردية‬
 ‫متطلبات ا‪$‬جال‬
‫‪Domain requirements‬‬

‫القيود ا‪$‬فروضة على النظام من مجال التشغيل •‬

 ‫ا‪.‬تطلبات الوظيفية‬
‫‪.‬وصف وظيفة أو خدمات النظام •‬
‫حسب نوع البرنامج وا‪:‬ستخدم‪ 6‬ا‪:‬توقع‪ 6‬ونوع النظام •‬
‫‪.‬الذي يستخدم فيه البرنامج‬
‫قد تكون متطلبات ا‪:‬ستخدم الوظيفية عبارة عن بيانات •‬
‫‪.‬عالية ا‪:‬ستوى عما يجب أن يقوم به النظام‬
‫يجب أن تصف متطلبات النظام الوظيفي خدمات النظام •‬
‫‪.‬بالتفصيل‬
‫مثال‪ :‬ا‪.‬تطلبات الوظيفية‪MHC-PMS‬‬
‫لل‬
‫قادرا على البحث في قوائم •‬
‫ً‬ ‫يجب أن يكون ا‪8‬ستخدم‬
‫‪.‬ا‪8‬واعيد لجميع العيادات‬
‫يُنشئ النظام يوميًا ‪ ،‬لكل عيادة ‪ ،‬قائمة با‪8‬رضى الذين •‬
‫‪.‬يتوقع منهم حضور ا‪8‬واعيد في ذلك اليوم‬
‫يتم تحديد هوية كل موظف يستخدم النظام بشكل فريد •‬
‫‪.‬من خ^ل رقم ا‪8‬وظف ا‪8‬كون من ‪ 8‬أرقام‬
 ‫عدم دقة ا'تطلبات‬
‫‪.‬تنشأ ا‪+‬شاكل عندما ‪ 2‬يتم ذكر ا‪+‬تطلبات بدقة •‬
‫يمكن تفسير ا‪+‬تطلبات الغامضة بطرق مختلفة بواسطة •‬
‫‪.‬ا‪+‬طورين وا‪+‬ستخدم‪G‬‬
‫بالنظر في مصطلح "البحث" في الشرط ‪• 1‬‬
‫تفسير ا‪+‬ستخدم ‪ -‬البحث عن اسم ا‪+‬ريض في جميع ا‪+‬واعيد –‬
‫في جميع العيادات ؛‬
‫تفسير ا‪+‬طور ‪ -‬ابحث عن اسم ا‪+‬ريض في عيادة فردية‪ .‬يختار –‬
‫ا‪+‬ستخدم عيادة ثم البحث‬
 ‫اكتمال و تناسق ا'تطلبات‬
‫‪.‬من حيث ا‪-‬بدأ ‪ ،‬يجب أن تكون ا‪-‬تطلبات كاملة ومتسقة •‬
‫تامة و مكتملة •‬
‫‪.‬ينبغي أن تشمل أوصاف جميع الخدمات و ا‪-‬رافق ا‪-‬طلوبة –‬
‫ثابتة •‬
‫يجب أ‪ V‬يكون هناك تعارض أو تناقضات في أوصاف منشآت –‬
‫‪.‬النظام‬
‫في التطبيق العملي ‪ ،‬من ا‪-‬ستحيل إنتاج وثيقة متطلبات •‬
‫‪.‬كاملة ومتسقة‬
 ‫ا‪0‬تطلبات غير الوظيفية‬
‫وهي تحدد خصائص النظام وقيوده مثل ا(وثوقية ووقت •‬
‫ا‪O‬ستجابة ومتطلبات التخزين‪ .‬القيود هي قدرة جهاز‬
‫‪.‬ا‪V‬دخال ‪ /‬ا‪V‬خراج ‪ ،‬تمثيل النظام ‪ ،‬إلخ‬
‫أو ‪ IDE‬يمكن ً‬
‫أيضا تحديد عملية ا(تطلبات التي تتطلب •‬
‫‪.‬لغة برمجة أو طريقة تطوير معينة‬
‫قد تكون ا(تطلبات غير الوظيفية أكثر أهمية من ا(تطلبات •‬
‫الوظيفية‪ .‬إذا لم يتم ا‪O‬يفاء بها ‪ ،‬فقد يكون النظام عديم‬
‫‪.‬الفائدة‬
 ‫تنفيذ متطلبات غير وظيفية‬
‫قد تؤثر ا‪6‬تطلبات غير الوظيفية على البنية الكلية للنظام •‬
‫‪.‬بد‪ ًB‬من ا‪6‬كونات الفردية‬
‫على سبيل ا‪6‬ثال ‪ ،‬لضمان تلبية متطلبات ا‪G‬داء ‪ ،‬قد تضطر –‬
‫‪.‬إلى تنظيم النظام لتقليل ا‪B‬تصا‪B‬ت ب‪ N‬ا‪6‬كونات‬
‫قد يولد متطلب واحد غير وظيفي ‪ ،‬مثل متطلبات ا‪G‬مان ‪• ،‬‬
‫عد ًدا من ا‪6‬تطلبات الوظيفية ذات الصلة التي تحدد‬
‫‪.‬خدمات النظام ا‪6‬طلوبة‬
‫‪.‬قد يؤدي ً‬
‫أيضا إلى إنشاء متطلبات تقيد ا‪6‬تطلبات الحالية –‬
 ‫تصنيفات غير الوظيفية‬
‫متطلبات ا‪$‬نتج •‬
‫ا‪$‬تطلبات التي تحدد أن ا‪$‬نتج الذي تم تسليمه يجب أن –‬
‫يتصرف بطريقة معينة مثل سرعة التنفيذ وا‪$‬وثوقية وما إلى‬
‫‪.‬ذلك‬
‫ا‪$‬تطلبات التنظيمية •‬
‫ا‪$‬تطلبات التي هي نتيجة للسياسات وا‪U‬جراءات التنظيمية –‬
‫‪.‬مثل معايير العملية ا‪$‬ستخدمة ‪ ،‬ومتطلبات التنفيذ ‪ ،‬إلخ‬
‫ا‪$‬تطلبات الخارجية •‬
‫ا‪$‬تطلبات التي تنشأ عن عوامل خارجة عن النظام وعملية –‬
‫تطويره مثل متطلبات التشغيل البيني وا‪$‬تطلبات التشريعية ‪،‬‬
 ‫أمثلة *تطلبات غير‪MHC-PMS‬‬
‫وظيفية في‬
‫متطلبات ا*نتج •‬
‫متاحة لجميع العيادات خ*ل ‪ MHC-PMS‬يجب أن تكون •‬
‫ساعات العمل العادية )من ا@ثن= إلى الجمعة ‪ ،‬من‬
‫‪ 0830‬إلى ‪ .(17.30‬يجب أ‪ K‬تتجاوز فترة التوقف خ*ل‬
‫ٍ‬
‫ثوان في أي يوم واحد‬ ‫‪.‬ساعات العمل العادية خمس‬
‫ا*تطلبات التنظيمية يجب على مستخدمي نظام •‬
‫ا]صادقة على أنفسهم باستخدام بطاقة ‪MHC-PMS‬‬
‫‪.‬هوية ا]نطقة الصحية الخاصة بهم‬
‫ا*تطلبات الخارجية يجب على النظام تنفيذ أحكام •‬
 ‫ا‪-‬هداف وا'تطلبات‬
‫قد يكون من الصعب تحديد ا‪3‬تطلبات غير الوظيفية بدقة •‬
‫‪.‬وقد يكون من الصعب التحقق من ا‪3‬تطلبات غير الدقيقة‬
‫هدف •‬
‫‪.‬القصد العام للمستخدم مثل سهولة ا‪F‬ستخدام –‬
‫شرط غير وظيفي يمكن التحقق منه •‬
‫جمل باستخدام بعض التدابير التي يمكن اختبارها –‬
‫‪.‬بموضوعية‬
‫ا‪Y‬هداف مفيدة للمطورين ‪Y‬نها تب‪ X‬نوايا مستخدمي •‬
‫‪.‬النظام‬
 ‫متطلبات قابلية ا'ستخدام‬
‫يجب أن يكون النظام سهل ا‪0‬ستخدام من قبل الطاقم •‬
‫الطبي ويجب تنظيمه بطريقة تقلل من أخطاء‬
‫)ا‪K‬ستخدم‪) .‬هدف‬
‫يجب أن يكون ا‪K‬وظفون الطبيون قادرين على استخدام •‬
‫جميع وظائف النظام بعد أربع ساعات من التدريب‪ .‬بعد‬
‫هذا التدريب ‪ ،‬يجب أ‪ 0‬يتجاوز متوسط عدد ا‪X‬خطاء التي‬
‫يرتكبها ا‪K‬ستخدمون ا‪K‬تمرسون اثن^ في الساعة من‬
‫)استخدام النظام‪).‬متطلبات غير وظيفية قابلة ل`ختبار‬
‫مقاييس لتحديد ا*تطلبات غير‬
‫الوظيفية‬
‫خاصية‬ ‫قياس‬

‫‪ speed‬سرعة‬ ‫ا‪-‬عام‪/‬ت ا‪-‬عالجة ‪ /‬الثانية‬

‫وقت استجابة ا‪-‬ستخدم ‪ /‬الحدث‬
‫وقت تحديث الشاشة‬

‫‪size‬الحجم‬ ‫ميجابايت‬
‫‪ ROM‬عدد رقائق‬

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

‫‪Ease of use‬‬ ‫عدد إطارات ا‪-‬ساعدة‬

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

‫‪reliability‬‬ ‫)احتمال عدم توافرها )النظام‬
‫معدل حدوث الفشل‬
‫)التوفر )ا‪H‬تاحة‬

‫ا‪-‬تانة‬ ‫الوقت ‪Z‬عادة التشغيل بعد الفشل‬

‫‪robustness‬‬ ‫النسبة ا‪-‬ئوية ل]حداث التي تسبب الفشل‬
‫احتمال تلف البيانات بناء على الفشل‬

‫قابلية التنقل‬ ‫النسبة ا‪-‬ئوية للبيانات ا‪-‬عتمدة ا‪-‬ستهدفة‬

‫عدد ا‪c‬نظمة ا‪-‬ستهدفة‬
 ‫متطلبات ا‪$‬جال‬
‫‪.‬ا‪/‬تطلبات على النظام يفرضها ا‪/‬جال التشغيلي للنظام •‬
‫على سبيل ا‪/‬ثال ‪ ،‬يجب أن يأخذ نظام التحكم في القطار في –‬
‫‪.‬ا‪T‬عتبار خصائص الكبح في الظروف الجوية ا‪/‬ختلفة‬
‫تكون متطلبات ا‪/‬جال متطلبات وظيفية جديدة أو قيو ًدا •‬
‫‪.‬على ا‪/‬تطلبات الحالية أو تحديد حسابات محددة‬
‫في حالة عدم تلبية متطلبات ا‪/‬جال ‪ ،‬قد يكون النظام غير •‬
‫‪.‬قابل للتطبيق‬
 ‫متطلبات ا‪$‬جال‬
‫مثال‪ :‬نظام حماية القطار‬
‫لنظام حماية ‪ domain requirement‬هذا مجال متطلبات •‬
‫‪:‬القطار‬
‫‪:‬يحسب التباطؤ في القطار على النحو التالي •‬
‫‪– Dtrain = Dcontrol + Dgradient‬‬
‫التدرج ‪ /‬ألفا ا‪E‬عوض * ‪ms2‬هو ‪ Dgradient 9.81‬حيث –‬
‫‪T.‬نواع مختلفة من القطار ‪ms2 / alpha‬وتعرف قيم ‪9.81‬‬
‫من الصعب على غير ا‪E‬تخصص فهم تداعيات ذلك وكيفية •‬
‫‪.‬تفاعله مع ا‪E‬تطلبات ا‪T‬خرى‬
 ‫مشاكل متطلبات ا‪$‬جال‬
‫القابلية للفهم •‬
‫يتم التعبير عن ا‪6‬تطلبات بلغة مجال التطبيق ؛ –‬
‫غالبًا ما ‪ D‬يفهم ذلك مهندسو البرمجيات الذين يقومون بتطوير –‬
‫النظام‬
‫الضمنية •‬
‫يفهم اختصاصيو ا‪6‬جال ا‪6‬نطقة جي ًدا بحيث ‪ D‬يفكرون في –‬
‫‪.‬توضيح متطلبات ا‪6‬جال‬
 ‫ملخص ما سبق‬
‫تحدد متطلبات نظام البرنامج ما يجب على النظام فعله •‬
‫‪.‬وتحديد القيود على تشغيله وتنفيذه‬
‫ا‪L‬تطلبات الوظيفية هي بيانات عن الخدمات التي يجب •‬
‫على النظام توفيرها أو وصف لكيفية إجراء بعض‬
‫‪.‬العمليات الحسابية‬
‫غالبًا ما تقيد ا‪L‬تطلبات غير الوظيفية النظام الجاري •‬
‫‪.‬تطويره وعملية التطوير ا‪L‬ستخدمة‬
‫غالبًا ما تتعلق بالخصائص الناشئة للنظام وبالتالي •‬
‫‪.‬تنطبق على النظام ككل‬