1. مقدمه اي بر مهندسي نيازمنديها
فصل پنجم: مدلسازي و تحليل نيازمنديها
توسط: رضا گرگان محمدي
استاد راهنما: آقاي دکتر احمد عبدا.. زاده

2. فهرست مطالب دلایل تحلیل نیازمندیها وظایف تحلیلگر سیستم مدل سازی
روشهای مدل سازی
جمع بندی

3. مقدمه تعريف زير براي مدلسازي قابل ارائه است:
مدل سازی فعاليتی است که در آن تحليلگر سيستم نيازمنديهاي استخراج شده را استفاده کرده و پالايش ميکند و مدلهايي از داده ها، و دامنه هاي رفتاري و عملکردي سيستم نرم افزاري را ايجاد مي کند.

4. دلايل تحليل نيازمنديها
دستاوردهاي لازم براي مرور مشتري و درک سيستم را فراهم ميکند.
وروديهاي مناسب براي فازهاي طراحي و تست را فراهم ميکند.
ابزاري براي ارزيابي کيفيت محصول توليد شده را براي توسعه دهنده و مشتري فراهم مي کند.
امکان چک کردن کامل بودن، سازگاري، و صحت نيازمنديها را فراهم ميکند.

5. مدلسازي و تحليل نيازمنديها
مدلسازي: ايجاد توصيفي انتزاعي که قابل تفسير باشد.
دسته هاي مدل سازي مهندسي نيازمنديها
مدل سازي بنگاه (Enterprise Modeling)
مدل سازي داده اي (Data Modeling)
مدل سازي رفتاري (Behavioral Modeling)
مدل سازي دامنه (Domain Modeling)
مدل سازي نيازمنديهاي غيرکارکردي (Modeling Nonfunctional Requirement)
تحليل مدلهاي نيازمنديها (Analyzing Requirements Models)

6. وظايف تحليلگر سيستم مطالعه مشكلات و نيازمندي­هاي سازمان تجاري
تعيين بهترين راهكار براي بهبود سازمان تجاري از طريق بكارگيري
افراد
روشها
فناوري اطلاعات
كمك به كاربران و مديران سيستم مبتني بر فناوري اطلاعات جهت تعريف نيازمنديهاي سيستم جديد يا ارتقاي سيستم فعلي

7. نقش تحليلگر سيستم ارزيابي گزينه ها براي پياده سازي سيستم
توسعه در داخل سازمان (in-house)
توسعه برون سپاري شده(Outsourced)
براي پروژه هاي توسعه در داخل سازمان با تيمي از تحليلگران و توسعه دهندگان کار کنيد.

8. مشخصات يک تحليلگر موفق از بُعد تحليل درك سازمان مهارتهاي حل مشكلات
داشتن تفكر سيستمي
از بُعد فني
درك تواناييها و محدوديتهاي فني
از بُعد مديريتي
داراي توانايي مديريت پروژه ها، منابع، ريسكها و تغييرات
از بُعد روابط اجتماعي
داراي مهارتهاي ارتباطي كلامي و نوشتاري مؤثر
از بُعد كار گروهي
توانايي كار در يك تيم كاري مبتني بر پروژه شامل
مدير
تحليلگران سيستم
برنامه نويسان
كاربران
ساير متخصصين

9. سایر نقشها در سیستم
مسئول بازبینی: مسئول فراهم کردن بازخوردهای دوره ای به اعضای تیم پروژه در مورد دستاوردهای ایجاد شده است.
هماهنگ کننده بازبینی ( Review Coordinator)
مسئول تسهیل بازبینی رسمی و نظارت و تضمین اینکه این بازبینی ها در هنگام نیاز انجام میگیرد و اینکه بر اساس یک استاندارد مطلوب انجام میگیرد.

10. سایر نقشها در سیستم (ادامه)
مسئول بازبینی فنی
مسئول ارائه بازخورد برای فرآیند بازبینی است. این نقش به بحث بازبینی فنی دستاوردهای پروژه میپردازد.
ذینفع
نماینده گروهی از افراد است که نیازهای آنها باید توسط پروژه ارضا شود.

11. تضاد بین نیازمندیها
تضاد بین نیازمندیها اغلب بدلیل دیدگاههای مختلف ذینفعان اتفاق می افتد.
برای اینکه استخراج نیازمندیها کافی و کامل باشد باید دیدگاه های همه گروه های درگیر دریافت شده و در نهایت در یک مسیر سازگار تجمیع شود.

12. مدلسازي
تعريف
به دليل پيچيدگي واقعيت و نامرتبط بودن بسياري از جنبه هاي پيچيدگي به مشكلي كه قرار است حل شود از يک بازنمايي ساده­سازي شده از واقعيت استفاده مي­شود.
يک مدل انتزاعي از يک مسئله جهان واقعي است که مي­تواند توسط يک سيستم محاسباتي نمايش داده شده و دستکاري شود.
مدل­سازي يک روش و تکنيک ثابت­شده در مهندسي است.
مدلسازي يكي از فعاليتهاي اصلي در ساخت سيستمهاي مبتني بر فناوري اطلاعات با كيفيت است.
مدل­سازي فيزيکي در برابر مدل­سازي منطقي
توصيف منطقي سيستم: هدف و عملکرد سيستم را ترسيم مي­کند و توصيفات را به يک پياده­سازي فيزيکي خاص پيوند نمي­دهد.
توصيف فيزيکي سيستم: به چگونگي ساخت سيستم تمرکز دارد.

13. انواع مدلها Iconic (نمايي) مدلي شبيه سيستم در مقياس كوچكتر
Analog (رقمي)
مدلي كه از نظر رفتاري شبيه سيستم باشد مانند: چارت سازماني، نمودارها، نقشه و ...
رياضي (كمّي)
ايجاد رابطه محاسباتي بين پارامترهاي تعريف شده نيازمندي

14. مزاياي مدلسازي در مهندسي نرم افزار
درك بهتر سيستمهاي مبتني بر فناوري اطلاعات
توصيف نيازمنديهاي سيستم جهت كنترلِ
كامل بودن
صحت
سازگاري آنها
ايجاد و مقايسه راه حلهاي مختلف طراحي سيستم با هزينه كم بدون نياز به پياده سازي سيستم
ابزاري براي برقراري ارتباط و تعامل با ساير ذينفعان سيستم

15. روشهاي تحليل نيازمنديها
به طور کلي سه روش براي تحليل نيازمندي­ها وجود دارد:
ساخت يافته (Structured): ساخت سيستم براساس دو مفهوم مستقل ساختار (Data) و رفتار (Procedure)
شي گرا (Object Oriented)
معرفي يك مفهوم جديد تحت عنوان شيء و تعبيه دو مفهوم ساختار و رفتار در آن به منظور نزديكتر شدن به مفاهيم موجود در دنياي واقعي
ساخت سيستم تجاري بر اساس مفاهيمي از قبيل: كلاسها، اشياء و تعاملات بين آنها، صفات و متدهاي اشياء و ...
رسمي- بصری (Formal): روشهاي غيررسمي و نيمه رسمي از زبان طبيعي، دياگرامها، جدولها، و علامتگذاريهاي ساده استفاده ميکنند. شامل تحليل ساختيافته و شي­گرا است. روش­هاي رسمي بر مبناي syntax و semantic رسمي است. نظير Z، VDM، LOTOS.

16. روشهاي رسمي
روشهاي رسمي به طور گسترده در بين توسعه دهندگان نرم افزار استفاده نميشود.
عوامل موثر در پذيرش کند روشهاي رسمي:
دشواري درک علايم
دشواري فرموله کردن جنبه هاي معيني از نيازمنديها
نتيجه و بازدهي کار چندان مشخص نيست.

17. روشهاي رسمي (ادامه)
با توجه به اینکه نرم افزار یک توصیف فرمال است تحلیل رفتار آن نیز قابل بیان به صورت فرمال است.
منطبق یک محمل مناسب برای انجام چنین تحلیلی است
مهندسی نیازمندیها باید فاصله یین دنیای غیررسمی نیازهای ذینفعان و دنیای رسمی رفتار نرم افزار را پوشش دهد.
پرسش کلیدی در خصوص استفاده از روشهای فرمال استفاده یا عدم استفاده از آن نیست بلکه تعیین زمان استفاده از فرمال سازی است.

18. مزايا و معايب روشهاي رسمي
مزاياي استفاده از روشهاي رسمي:
تضمين ميكند كه سيستم تجاري موردنظر تا حد زيادي با توصيفاتش مطابقت كند
همه چيز بصورت صريح و عاري از ابهام بيان مي شود
معايب استفاده از روشهاي رسمي:
صحت سيستم (Correctness) را بطور كامل تضمين نمي­كند
درك آن براي همه ذينفعان سيستم دشوار است.
كاربرد گسترده اي ندارد

19. مزاياي تحليل شي­گرا افزايش بهره­وري كاهش حجم فعاليت­هاي تحليل
كاهش پيچيدگي در طراحي
تسهيل فرآيند بازنگري و تأييد نيازمندي­ها توسط كاربران
وجود يك زبان مشترك و واحد بين كاربران، تحليلگران، طراحان و پياده سازان
قابليت استفاده مجدد از كد و طراحي
ساخت مدلهايي كه
به واقعيت نزديكترند
دقيقترند
درك و نگهداريشان آسانتر است
استحكام (Stability)
ايجاد يك تغيير كوچك در نيازمنديها منجر به تغييرات گسترده در سيستم در حال توسعه نمي شود

20. زبان مدل­سازي يکپارچه (UML)
يك زبان گرافيكي يكپارچه و استاندارد براي مدلسازي شي گرا است. استفاده از اين زبان مزاياي زير را دارد:
تعريف يك نگاشت يكپارچه از تحليل به طراحي و از طراحي به پياده­سازي
تعريف مجموعه اي از علائم و نمادهاي يكپارچه و استاندارد و نامتناقض
آسان­تر كردن برقراري ارتباط و تعامل با ديگران
كمك به شناسايي موارد از قلم افتاده و ناسازگار
پشتيباني از فازهاي تحليل و طراحي توسعه سيستم­هاي تجاري مبتني بر فناوري اطلاعات در هر دو مقياس كوچك و بزرگ
Unified Modeling Language

21. ديدگاه­هاي چندگانه UML از يک سيستم
Use case View : جهت نمايش كاركردهاي سيستم
Logical View : عبارت است از يک تصوير Static از Class هاي اصلي و ارتباطات آنها
Development View : نشان مي­دهد که چگونه کد برنامه­ها داخل Packageها و Libraryها سازماندهي مي­شوند و چگونه از نرم­افزارهاي استاندارد تجاري استفاده مي­کنند.
Process View : جهت نمايش پردازشها و Task ها استفاده مي­شوند.
Physical View: نشان دهنده پروسسورها، Device ها و ارتباط با محيط­هاي عملياتي مي­باشند.

22. دیدگاه های مختلف در UML

23. تحليل و مذاکره نيازمنديها

24. تحليل و مذاکره نيازمنديها (ادامه)
استخراج، تحلیل، و مذاکره در مورد نیازمندیها در قالب یک فرآیند حلزونی به صورت شکل قابل تصور است.

25. دلايل اهميت تحليل مسائل
به منظور اجتناب از توليد محصولي که نيازمنديها را پوشش ميدهد اما مسائل را حل نميکند.

26. چارچوب PIECES براي حل مسائل

27. بيان اجمالي مشکل، فرصت، يا رهنمود
چارچوب PIECES (ادامه)
پروژه
مدير پروژه
تهيه کننده
نام آخرين تغييردهنده
تاريخ تهيه
تاريخ آخرين تغيير
بيان اجمالي مشکل، فرصت، يا رهنمود
فوريت
قابليت رويت
منافع سالانه
اولويت يا رتبه
راهکار پيشنهادي
ASAP
High-med-low
توسعه سيستم جديد
6 ماه
اصلاح نرم افزار فعلي

28. نمودار Ishikawa
اين نمودار يک ابزار گرافيکي است که براي تعيين، کاوش، و به تصوير کشيدن مسائل و علت و معلول آن مسائل استفاده ميشود.
همچنين اغلب تحت عنوان ”نمودار علت و معلول“ يا نمودار Fishbone شناخته ميشود.

29. تحليل Cause & effect
تحليل علت و معلول (cause & effect) تکنيکي است که از طريق آن مسائل جهت تعيين ريشه و تاثير آنها مورد مطالعه قرار ميگيرند. در عمل، تاثيرات ميتوانند علائمي از مشکلات عميقتر و پايه اي تر باشند که در عوض بايد براي دلايل و تاثيرات مورد تحليل قرار گيرند تا زمانيکه علتها و تاثيرات منجر به ايجاد علائم يا مشکلات ديگر نشود.
ليستي از عواملي که در يک مشکل مشخص تاثير دارند تهيه شود.
به طور پيوسته سوال "چرا" پرسيده شود.

30. تحليل Root- Cause
دياگرام fishbone يک روش براي تعيين علل ريشه اي براي مسائل است. در بين مواردي که در اين نمودار نشان داده ميشود ممکن است برخي نقش مهمتري در پيدايش مسئله داشته باشند.

31. دياگرام Pareto اين نمودار بر اساس قانون 80-20 است.
يک روش براي تمرکز بر مهمترين دلايل ريشه اي يک مسئله استفاده از اصل پارتو ”قانون 80-20“ است.
اين نمودار عوامل موثر در پيدايش يک مسئله را رتبه بندي ميکند تا بر مهمترين عواملي تاکيد کند که بيشترين تاثير را در مسئله دارند.
قانون پارتو: 20 درصد عوامل باعث بروز 80 درصد مشکلات ميشوند.

32. اهداف بهبود سيستم
يک هدف واحدي براي سنجش موفقيت است. در واقع چيزي است که ما انتظار داريم به آن دست پيدا کنيم در صورتي که منابع کافي اختصاص يابد.
مثال: کاهش زمان توليد محصول تا 50 درصد

33. بيان قيود مشتري (Constraints)
يک قيد عبارت است از چيزي که انعطافپذيري شما در تعريف يک راهکار براي اهداف را محدود ميکند. به طور اصولي، قيود قابل تغيير نيستند. قيود سيستم به دسته هاي زير قابل تفکيک است:
سياسي
محيطي
اقتصادي
امکانسنجي
سيستم
فني

34. ماتريس مشکلات، فرصتها، اهداف، و قيود
پروژه
مدير پروژه
تهيه کننده:
نام آخرين تغييردهنده:
تاريخ تهيه:
تاريخ آخرين تغيير
تحليل علت و معلول
اهداف بهبود سيستم
مشکل يا فرصت
علل يا تاثيرات
اهدف سيستم
قيود سيستم

35. انجام بررسي هاي لازم بررسي هاي ضروري
ضرورت نيازمندي بررسي ميشود. در برخي موارد، ممکن است نيازمنديهايي پيشنهاد شوند که در اهداف کسب و کار يا مسئله خاصي که بايد توسط سيستم پاسخ داده شود مشارکت ندارند.
بررسي هاي سازگاري و کامل بودن
نيازمنديها به طور متقابل از نظر سازگاري و کامل بودن مورد بررسي قرار ميگيرند.
سازگاري به اين معنا است که هيچ نيازمندي اي نبايد متناقض باشد.
کامل بودن به اين معنا است که همه سرويسها يا قيدهاي مورد نياز بايد در نظر گرفته شوند.
بررسي هاي امکانپذيري
نيازمنديها از نظر امکانپذيري مورد بررسي قرار ميگيرند. اين امکانپذيري درچارچوب بودجه و زمان فراهم شده براي توسعه سيستم است.

36. درک نيازها و قيود ذينفعان سيستم
نيازهاي افرادي که با سيستم کار ميکنند بايد به دقت و با جزئيات دريافت شود.
مسائل و چالشهاي پيش رو:
ذينفعان ميدانند چه ميخواهند اما قادر به بيان آن نيستند.
ذينفعان نميدانند چه ميخواهند.
ذينفعان تصور ميکنند که ميدانند دقيقاٌ چه ميخواهند در صورتي واقعاٌ اينطور نيست.
تحليلگران فکر ميکنند که مسائل کاربران را بهتر از خودشان درک ميکنند.

37. بررسیهای مرحله تحلیل بررسی لزوم: بررسی سازگاری و کامل بودن:
ضرورت نیازمندی تحلیل میشود. در برخی موارد ممکن است نیازمندیهایی پیشنهاد شوند که اصولاٌ کمی به اهداف تجاری سازمان و یا یک مسئله مشخص مورد توجه در سیستم مورد توسعه نمیکنند.
بررسی سازگاری و کامل بودن:
نیازمندیها برای سازگاری و کامل بودن به صورت متقابل بررسی میشوند.
سازگاری به این معنا است که هیچ نیازمندی ای نباید متناقض باشد
کامل بودن به این معنا است که هیچ سرویس یا قیدی که مورد نیاز است نادیده گرفته نشده است.
بررسی امکان پذیری:
نیازمندیها به منظور اطمینان از اینکه از نظر بودجه، زمان در نظر گرفته شده برای توسعه امکان پذیر باشند مورد بررسی قرار میگیرند.

38. مذاکره نیازمندیها بحث در مورد نیازمندیها اولویت بندی نیازمندیها
نیازمندیهایی که به عنوان ”مشکلدار“ مشخص شده اند مورد بحث قرار میگیرند و ذینفعان درگیر دیدگاههای خود در مورد این نیازمندیها را بیان میکنند.
اولویت بندی نیازمندیها
نیازمندیهای مورد اختلاف اولویت بندی شده تا اینکه نیازمندیهای مهم شناسایی گردند و به فرآیند تصمیم گیری کمک کنند.
توافق در مورد نیازمندیها
راهکارها برای مشکلات نیازمندیها شناسایی شده و یک مجموعه مورد توافق از نیازمندیها نهایی میشود. عموماٌ این امر شامل اعمال برخی تغییرات در برخی نیازمندیها است.

39. منابع نیازمندیها
درخواستهای همه ذینفعان باید دریافت شود و همچین باید نحوه رسیدگی به این درخواستها نیز مشخص باشد.
گرچه تحلیلگر سیستم مسئول جمع آوری این اطلاعات است، بسیاری از افراد در این زمینه همکاری دارند: افراد بازاریابی، کاربران نهایی، مشتریان و هر کس دیگری که به عنوان ذینفع پروژه در نظر گرفته میشود.

40. منابع نیازمندیها (ادامه)
مثالهایی از سایر منابع برای مطرح شدن نیازمندیها عبارتند از:
سند RFP
بیانه ماموریت سازمان (Mission Statement)
قواعد کسب و کار
قوانین و مقررات
سیستم های قدیمی(Legacy systems )
مدل های کسب و کار
نتایج جلسات و کارگاههای استخراج نیازمندیها

41. سایر منابع برای نیازمندیها
همکاران
مشتری
تحلیلگر
گزارش اشکلات
درخواستهای تغییر
کاربران
دامنه مسئله

42. جمع بندي

43. فهرست مراجع
Requirements Engineering: A RoadMap.