فرآیند مهندسی نیازها

صفحه 1:
فر آیند مهندسی نیازها ۱ 0 0 com ‎Come CT tod‏ ل ‎Se‏ تع سسه5 مولع ‎ 

صفحه 2:
اهداف ا ال ل معرفى تكنيك هايى براى استخراج و تحليل نيازها درک معتبرسازی نیازها و نقش بازبینی نیازها 0 RCS ane aCe eae ‏نيازهاى ديكر‎ Se ‏ل‎ Come CT tod ©lan Sommervil 

صفحه 3:
فر آیند مهندسی نبازها ‎cele‏ 00 لبازها تغيييات كسترده اى.بو.دامنه ى سیستم. افراد درگیر و نيازهاى سازمان ايجاد خواهد كرد. در هر صورت. فعالیت های مشترکی وجود دارد ‎٠‏ استخراج نيازها؛ * تحليل نيازها؛ ات ل ‏*؟ مديريت نيازها. ‎000 ‏علازسم‌هصمی‎ 4 Se ‏ل‎ Come CT tod 

صفحه 4:
elicitation and rr 8 anaysis \ ۷ Requiements ), \_ specification J = /Requiements \_ validation J م Requiements SSS document requirements User and system Requiements \ اده Se ‏ل‎ Come CT tod r <4 (Feasibility) \ study >! Feasibility repot 00 

صفحه 5:
Se nee Cent me come CT tod 000 

صفحه 6:
مطالعات امکان سنجی ل مطالعه ی امکان سنجی مشخص خواهد کرد که آیا سیستم ارزشمند است يا خير. ‎a Peeper eee 2) 5‏ Eee SPs ene ‏ل‎ آيا سيستم مى تواند با استفاده از تكنولوزى و بودجه ى ا ۳ استفاده يكيارجه شو create Ces Se ‏ل‎ Come CT tod 

صفحه 7:
۳ ICO US) EL) ‎Cee ee eerie rents ney ee ea‏ مجموعه ى ‏اطلاعات و كزارش نوشته شده. *؟ سولاتى از ‎ ‎[ele ara)‏ 52 شود جه سيستمى بياده سازى نشده است؟ ‏ا ان ‏*؟ سيستم جكونه كمك خواهد كرد؟ ‏مشكلات يكيارجه سازى جه خواهد شد؟ ‎ON aeRO REACT ST rene‏ ‎i eee eed ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 8:
استخراج و تحلیل گاهی اوقات استخراج یا کشف نیازها نامیده شده اند. ‎ect) <8)‏ ۹ ‎eee oor‏ ا ا اك سيستم را فمشخصن جواهند كرد: ‏ل ا ا ل ا ۱ ‏ع ا ا 50 ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 9:
3200000 ‎CRO ELSES CS‏ 6 0 ‎rep aa pas eau EEDI CS‏ 0 * ممكن است كارفرمايان مختلفء نيازهاى متضادى داشته باشند. * ممكن است فاكتورهاى سازمانى و سياسى بر نيازهاى سيستمى تاثير بكذارند. ‎٠‏ نیازها در طی فرآیند تحلیل تغییر می یابند. ممکن است ا ا ا ‎ee‏ ‎Come CT tod‏ ل ‎Se‏ 4 مللننصه‌هههک صعاق 

صفحه 10:
Se ‏ل‎ Come CT tod 

صفحه 11:
فعالیت های ف رآیند *؟ كشف نيازها ا ل ل 1 | ۱ زر 0 *؟ اولويت و رفع نيازها متضاد. مستندسازی نیازها نيازها مستندسازى شده و در جرخه ى مارييجى وارد مى كند. ile 2004 Se ‏ل‎ Come CT tod ©lan Sommervil 

صفحه 12:
نيازهاى سيستمى و كاربران از فرآيند كردآورى اطلاعات ييشنهادى و سيستم هاى موجود, اخذ مى كردد. ‎bs‏ منابع اطلاعاتی شامل مستندات. كارفيمايان سيستم و تعیین مشخصات سيستم ‎Bs torr Cele EE‏ ‎Come CT tod‏ ل ‎Se‏ 4 مللننصه‌هههک صعاق 

صفحه 13:
OPO glo lS مشتریان پانک ۱ مدیران بانک 0 مديران بانى اطلاعاتى مديران امنيت بازاريابى مهندسین نگهدار سخت افزار و نرم افزار ناظران بانک Se ‏ل‎ Come CT tod للتجههههک حقاه 

صفحه 14:
دیدگاه ها ديدكاه. ساختار نيازها از نقطه نظيهاى مختلف كارفرمايان مى باشد. ممكن است كارفرمايان ديدكاه هاى متفاوت را ‎aD coca) <‏ ا ل ‎Se ‏ل‎ Come CT tod ‎ ‎©lan Sommervil ‎ 

صفحه 15:
انواع ديدكاه ها © ديدكاه هاى تعاملى ا سیستم های دیگر بصورت مستقیم با سیستم تعامل دارند. در Pate RP Ces me ‏ل ا ل ا‎ 8 OD) ديدكاه هاى غير مستقيم ا سیستم استفاده نمی کند ام,بر ازهااتثیر می گذارند: در ‎NO‏ مديران و كارمند امنيت ديدكاه هاى غيرمستقيم دارند. ديدكاه هاى دامنه ویژگی های و محدودیت های دامنه. نیازها را تحت تأثیر قرار می دهند ‎ine Carine‏ ۱ ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 16:
Sea شناسایی انواع دید گاه ها Se ‏ل‎ Come CT tod تامين كنندكان و دريافت كنندكان ‎fp GE Ge‏ سیستم هایی که بطور غیرمستقیم با سیستم رابطه دارند؛ قوانین و استانداردها؛ متابع تجاری و نیازهای کیفی؛ مهندسینی که سیستم را توسعه داده و نگهداری می کنند؛ بازاريابى و ديدكاه هاى تجارى ديكر. Gloria 

صفحه 17:
1 ۹ Fee mt MI CRT Domain users | | 7 [| ‏تحت‎ ‎|| stat standards} system Por] عمسی]| یی اسس] managers Se nee Cent me come CT tod L ide [aes Finance | | Arce Students| an Sommervill 

صفحه 18:
020-65 eee ee eS ae eee TC ok cele) ‏سوالاتی وا برای کارفرمایان سيسقم که امتفاده کشگان با‎ ‏توسعه دهندگان سیستم هستند. مطرح می کند.‎ دو شيوه براى مصاحبه وجود دارد مصاحبه هاى بسته - به سوالاتى ازييش تعريف شده ياسخ داده می شود. و 0 Se ‏ل‎ Come CT tod للتجههههک حقاه 

صفحه 19:
مصاحبه ها در عمل . بطور طبيعى مخلوطى از مصاحبه هاى بسته و باز هستند. مصاحبه ها براى درك بيشتر مفيد هستندء اينكه كارفرمايان ‎ae ec eg‏ سح ال 5000 و برخى با دانش دامنه به حدى آشنا هستند كه بسختى در مورد آن مساله حرف زده يا فكر مى كنند كه نياز به حرف زدن 00 Se ‏ل‎ Come CT tod للتجههههک حقاه 

صفحه 20:
مصاحبه گرهای موثر [9 ele CE SRC teal ‏كنند و نبايد در مورد نيازها بيش داورى كرد.‎ 2 كند و نبايد بسادكى با سوال ”مى خواهيد جه كار كنيد“ پاسخ را بپذیرد. ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 21:
سناریوها ‎ST eos Cer ene yes on)‏ استفاده ی سیستم در جهان واقع مى باشد. 00 ‎Se ‏ل‎ Come CT tod ‎tone Je ely 5l cine gi ‎reeks)‏ طبيعى؛ ‎SP eee nel ‏ا‎ ‎CEI SCT ROM ICT ESE ISM BES ene eel cen ‏ا‎ ‎ ‏للتجههههک حقاه ‎ 

صفحه 22:
۱۳۹۹ ١ ‏ريو‎ Initial assmption: Theuser has logged on to the LIBSYS sysan and has located thejoumd containing the copy of the aticle Nornal: The user seleds the article to be copied. He or slp is then prompted by the sytem to etha providestisaiber informaton for thejoumd or to indicate how thay will pay for the article Alteratve payment mdinds aw by credit cad ory quoting anorganisational aocamt nuntber. The usar is than asked to fill in a copyright fomn that mantains detals of the trasadion and they then subnit this the LIBSYS sy$an. ‘The copyright fom is checked and, if OK, the PDF version of the artide is downbaded to the LIBSYS ‘working areaon the usez cosmputer and the user is informed thatit is avaialie. Theuser is asked to 4 printer and a copy of theattide is printad. If the artide has beenflaqyed as yrint only ‏عاط عل كذ عش‎ fron theusxgsystem acetheuser has confirmed thatprinting is complete 000 Se ‏ل‎ Come CT tod 

صفحه 23:
۱9۹۹ eee ae ‘What cangp wrong Theuser ney fai to fill in thecqpyright formoomedily. In tlis case the farm stould be re-prserted to theuser for conection. If theresibmitted fom is sill incaed then the use erecpes! fortheatide &rjeded The pymentmay berepctal ly the gst Theusero aquatt frtheatide Brgeded The aticledownloadmayfail. Rey until successfil orthe user ternimates he «esson. It may not bepossble to print theattide. If the attide is not flagged as yaiint-only, shan itis eld in the LIBSYS workspae. Otherwise, the artide is deled ami the user, acount credited with the cost of the attic] Other activities Similtaeais éwnloals d other aticles. Systemstateon completion: User is logged on. The downloaied article has bem delded fram LIBSYS ‘workspncef ithasbeen flaggedas printonly. ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 24:
موار داستفاده ۱ ۱ ns بیان می دارد. لل ات ا كه تمكن زا با سيستم تووضيف نمايد. ° ممکن است دیاگرام توالی برای افزودن جزییات به ‎cle DS eer CSP‏ | نشان داده می شود. ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 25:
مورداستناده ی جاپ مقاله Article printing 004 Se ‏ل‎ Come CT tod ©lan Sommervill 

صفحه 26:
و۹ User administration supplier Catalogue services ‎Come CT od‏ ل ‎See‏ 4 مللنصع‌هههک صعاق ‎ 

صفحه 27:
jan Sommerv Se nee Cent me come CT tod 

صفحه 28:
مسرم التي لم ‎form Workspace Peter‏ request complete copyright OK deliver aide OF confirm Se ‏ل‎ Come CT tod 

صفحه 29:
eS a Taek Che S) oa سيستم هاى نرم افزارى در محتواى اجتماعى و سازمانى بكار مى روند. مى تواند نيازهاى سيستم را تحت تاثير قرار دهد. 00 ‏ا ا‎ ote SIO ‏ا ا‎ CE et * تحلیل های خوب باید به این فاکتورها حساس باشد اما مععول روش اصولی برای تحلیل لیست. Se ‏ل‎ Come CT tod ©lan Sommervil 

صفحه 30:
200 | 0 ae pore ee LCL CET eg Cy ۱ | 0 ee cee ۳ 1 SIP Ces pen ‏باشكوه تر و ييجيده تر نشان مى دهد.‎ ‎Come CT tod‏ ل ‎Se‏ لأكتعسسه5 مولع ‎ 

صفحه 31:
eC eee) Pee eae pene Sc eO pCO el DMCS PaT ese 0353-2 تركيب مطالعه ى علمى با نمونه سازى اوليه. توسعه ى نمونه سازى اوليه به سوالات بدون ياسخ تحليل مطالعه ی علمی پاسخ می دهد. مشكل مطالعه ى علمى اين است كه ممكن است بر يايه ى ع لل ‎Bey‏ Se ‏ل‎ Come CT tod ©lan Sommervil 

صفحه 32:
مطالعه ی علمی و نمونه سازی اولیه Ethngraphic Debriefing Focused nays ‏ی‎ meetings ۰۱00000 Ky Gen development ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 33:
eT TCLS yee eer be cays ea ‏تعريف شده كار مى كنند.‎ eee el es eer es LOPES Se ‏ل‎ Come CT tod 0 

صفحه 34:
معتبرسازى نيازها * دغدغه این است که نیاز های سیستم با آنچه مشتری می خواهد 5 هزينه هاى خطاى نيازها بيشتر است بنابراين معتبرسازى بسيار *؟ تثبيت خطاى يك نياز بعد از تحويل ممكن است هزينه اى ‎٠٠١‏ ‏مرتبه بيشتر از خطاى بياده سازى دارد. ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 35:
بررسی نیازها اعتیار ‎ee eee‏ اك يشتيبان نيازهاى مشترى باشد؟ سازكارى: آيا ذر نيازها تضاذ وجوذ ذارة؟ ال. آيا ‎Lid‏ توابع توسط مشترى درخواست شده است؟ واقع بينى. آيا مى توان نيازها را با بودجه و تكنولوزى موجود يياده سازى نمود؟ ا 6 ۱ create! Ces Se ‏ل‎ Come CT tod 

صفحه 36:
مرور نيازها ۳ نمونه سازی اولیه ل ا ل ا ل © توليد خالت ست توسعه ى تست نيازها براى بررسى قابليت تست. Se ‏ل‎ Come CT tod 

صفحه 37:
مرور نیازها ee er ees ae ese ‏باقاعده باید صورت پذیرد.‎ *؟ متقاضى و بيمانكار بايد در مرورها همكارى داشته باشند. * ممكن است مرورها رسمى (با مستندات كامل) يا ‎toe) eee‏ ا ات 0 ا 1 مشتريان و كاربيان مى تواند حل مشكلات را تسريع 505 00 tra Se ‏ل‎ Come CT tod 

صفحه 38:
بررسی های مرور ‎a) or 3‏ قابليت دزك. آيا نيازها به ديستى درك شده اند؟ قابليت رديابى: آيا نيازهاى مبدا به درستى كفته شده است؟ ‎0 tabs eats Fae ep Cs eee ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 39:
مدیریت نیازها مدیریت نیازها فرآیند مدیریت تغییر نیازها در طی فرآیند 6 Soe Ree eee eS) pete e) نيازها بناجار ناقص و متناقص هستند Se ene ‏م لل ا‎ Ai ‏نيازهاى تجارى تغيير كرده و درك بهترى از سيستم حاصل‎ ‏فى گردد:‎ ل ا ا ل ا ‎tary tor‏ Se ‏ل‎ Come CT tod 

صفحه 40:
Urls pets Peseyran el pep penance ‏ا‎ COUPE nS) ‏اولويت نيا‎ * ea *؟ مشتريان سيستم ممكن است نيازهاى تجارى اى را تعيين كد كه يا نبا رقاى كاربر زهابى ‎les‏ اسك * محيط هاى تكنيكى و تجارى در طى توسعه. تغيير مى ‎meee)‏ ‎Come CT tod‏ ل ‎Se‏ 4 علازسم‌ههمی حعاق 

صفحه 41:
1 ‏َع‎ ‎Initial Changed understanding} understanding of problem of problem ۱ Changed requirements requiements Time ‎Come CT tod‏ ل ‎Se‏ 4 عللزنههه5 صهاق 

صفحه 42:
mmr re Te Sh) ‎e‏ ا ل ل لت ا ل نشات می گيرد. برای نمونه در یک بیمارستان هميشه دكترهاء يرستاران و غيره وجود دارند بطوريكه ممكن است از مدل هاى دامنه ناشى شوند. ‎ ‏نيازهاى سست. نيازهايى كه در طى توسعه يا حين استفاده ی سیستم تغییر می یابند. در بیمارستان. نيازهايى كه از ‎Se ‏ل‎ Come CT tod ‎ ‎000 ant eee 

صفحه 43:
Description Roquireamerts that change becais of chages to the environment in which the orarisaton is openting. For example, in hogpial systems the funding of paient caema chageam hus require diff aent trea ment information to be colle¢ed Recuiremerts that emarye as the custoner’s understanding of the sytan derebps during the system devdopment. The design proces my reved nav emeryert reqirements. Requiremerts that reaik from the introduction of the computer system. Inkroducing the computer system may changethe oryarisatons pracesses and openup new was of warking which generate new system raquirenerts Recuiremerts thatdqend on tle patticular sy¢amsorbusness processes within an orgarisaton. As these change, the comjathility requiranents on the commissioned ordelveral sytem may dso have b evolve. 00 ۸ SiR ete me ee ee CT tg 

صفحه 44:
برنامه ی مدیریت نیازها ا 0 نيازهاء برنامه ريزى زير خواهيد داشت: ؟ شناسایی ننازها ل فرآيند مديريت ل ل 0 *_ سیاست های قابلیت ردیابی * اطلاعاتی د رمورد ارتباط ابزار پشتیبانی 62690808 * ابزار پشتیبان برای مدیریت تغییر نیازها درخواست می شود؛ 3 اصلاح شده است؛ 000 ees Se ‏ل‎ Come CT tod 

صفحه 45:
قابليت رديابى اا ل ‎eV ors‏ سيستم را دارد قابلیت ردیابی منبع ‎ss) Aas Reece eS ae‏ * قابلیت ردیابی نیازها *؟ برقرارى ارتباط بين نيازهاى وابسته؛ ؟ قابلیت ردیابی طراحی ا ‎Sey Slo a SRC‏ ‎Come CT tod‏ ل ‎Se‏ 4 مللنصه‌هههک صعاق 

صفحه 46:
Se ‏ل‎ Come CT tod 

صفحه 47:
ابزار يشتيبان 0000507 * ذخيرهى نيازها *_نیازها باید در یک منبع ذخیره و مدیریت شوند. ات 0 ‎SUPP Ronse le ee nore Ul‏ جريان اطلاعات را بين مراحى مختلف بصورت 9 ‎eS eae eee‏ ‎e‏ الت *_بازیابی ارتباط بین نیازها بطور خودکار انجام می پذیرد. Se ‏ل‎ Come CT tod 

صفحه 48:
00 * بايذ تمامى تغييرات نيازها ييشنهاد: شود: تب اك * تحلیل مشکل. مشکل نبازها و تغییر بیان می شود؟ ‎ee Ce Sa‏ 1 ‎eee Se)‏ يياده سازى تغيير. مستئد نيازها و مستندات ديكر وابسته به تغيير اصلاح مى شود. Se ‏ل‎ Come CT tod للتجههههک حقاه 

صفحه 49:
سا ی ۳ Identified Revised change specification) problem | problem analysis and Change analysis Change _ |] requirements = ‏تر ما‎ and costing implementatiog 00 4 Se ‏ل‎ Come CT tod 

فرآیند مهندسی نیازها Omid.Mofidian@gmail. com ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter اهداف ‏ ‏ ‏ ‏ درک فعالیت های اصلی مهندسی نیازها و ارتباط های آنها معرفی تکنیک هایی برای استخراج و تحلیل نیازها درک معتبرسازی نیازها و نقش بازبینی نیازها درک نقش مدیریت نیازها در پشتیبانی فرآیند مهندسی نیازهای دیگر ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 فرآیند مهندسی نیازها ‏ ‏ فرآیندهای مهندسی نیازها تغییرات گسترده ای بر دامنه ی سیستم ،افراد درگیر و نیازهای سازمان ایجاد خواهد کرد. در هر صورت ،فعالیت های مشترکی وجود دارد • • • • استخراج نیازها؛ تحلیل نیازها؛ معتبرسازی نیازها؛ مدیریت نیازها. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 فرآیندمهندسی نیازها Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility report System models U ser and system requirements Requirements document ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter مهندسی نیازها Requirements specification System requirements specification and modeling U ser requirements specification Business requirements specification System requirements U ser elicitation requirements elicitation Feasibility study Prototyping Requirements elicitation Reviews Requirements validation System requirements document ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter مطالعات امکان سنجی ‏ ‏ مطالعه ی امکان سنجی مشخص خواهد کرد که آیا سیستم ارزشمند است یا خیر. مطالعه ای کوتاه برای بررسی های • آیا سیستم اهداف سازمانی را دربرمی گیرد؛ • آیا سیستم می تواند با استفاده از تکنولوژی و بودجه ی جاری مهندسی شود؛ • آیا سیستم می تواند با سیستم های دیگر مورد استفاده یکپارچه شود. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 پیاده سازی مطالعه ی امکان سنجی ‏ ‏ براساس ارزیابی اطالعات (چه درخواست شده) ،مجموعه ی اطالعات و گزارش نوشته شده. سواالتی از افراد در سازمان مطرح می شود • • • • • • چه سیستمی پیاده سازی نشده است؟ چه مشکالتی وجود دارد؟ سیستم چگونه کمک خواهد کرد؟ مشکالت یکپارچه سازی چه خواهد شد؟ آیا تکنولوژی جدیدی نیاز است؟ چه مهارت هایی؟ چه امکاناتی باید برای پشتیبانی سیستم وجود داشته باشد؟ ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 استخراج و تحلیل ‏ ‏ ‏ گاهی اوقات استخراج یا کشف نیازها نامیده شده اند. کارکنان تکنیکی همراه با مشتریان دامنه ی برنامه ی کاربردی، سرویس هایی که سیستم باید فراهم نماید و محدودیت های سیستم را مشخص خواهند کرد. می توان کاربران نهایی ،مدیران ،مهندسان نگهدار ،کارشناسان حوزه ،اتحادیه ی صنفی را کارفرما نامید. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مشکالت تحلیل نیازها ‏ ‏ ‏ ‏ ‏ کارفرمایان نمی دانند واقعًا چه می خواهند. کارفرمایان نیازها را با عبارات خود بیان می دارند. ممکن است کارفرمایان مختلف ،نیازهای متضادی داشته باشند. ممکن است فاکتورهای سازمانی و سیاسی بر نیازهای سیستمی تاثیر بگذارند. نیازها در طی فرآیند تحلیل تغییر می یابند .ممکن است کارفرمایان جدید بوجودآیند و محیط تجاری تغییر می یابد. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 نیازهای مارپیچی ©Ian Sommerville 2004 Requirements classification and organisation Requirements prioritization and negotiation Requirements discovery Requirements documentation Software Engineering, 7th edition. Chapter فعالیت های فرآیند ‏ ‏ ‏ ‏ کشف نیازها • برای کشف نیازها با کارفرمایان در رابطه هستند .نیازهای دامنه در این مرحله کشف می شوند. • نیازها گروهی و سازمانی را در دسته های منسجم بیان می دارد. • اولویت و رفع نیازها متضاد. • نیازها مستندسازی شده و در چرخه ی مارپیچی وارد می کند. طبقه بندی و سازماندهی نیازها اولویت بندی و مذاکره مستندسازی نیازها ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 کشف نیازها ‏ ‏ نیازهای سیستمی و کاربران از فرآیند گردآوری اطالعات پیشنهادی و سیستم های موجود ،اخذ می گردد. منابع اطالعاتی شامل مستندات ،کارفرمایان سیستم و تعیین مشخصات سیستم های مشابه می باشند. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 کارفرمایان ATM ‏ ‏ ‏ ‏ ‏ ‏ ‏ ‏ ‏ مشتریان بانک نماینده های بانک های دیگر مدیران بانک کارمندان باجه ها مدیران بانک اطالعاتی مدیران امنیت بازاریابی مهندسین نگهدار سخت افزار و نرم افزار ناظران بانک ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 دیدگاه ها ‏ ‏ دیدگاه ،ساختار نیازها از نقطه نظرهای مختلف کارفرمایان می باشد .ممکن است کارفرمایان دیدگاه های متفاوت را طبقه بندی کنند. تحلیل از چند نظر مهم است. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 انواع دیدگاه ها ‏ دیدگاه های تعاملی • ‏ دیدگاه های غیرمستقیم • ‏ افراد یا سیستم های دیگر بصورت مستقیم با سیستم تعامل دارند .در ،ATMمشتری و بانک اطالعاتی دیدگاه های تعاملی دارند. کارفرمایانی از سیستم استفاده نمی کنند اما بر نیازها تاثیر می گذارند .در ،ATMمدیران و کارمند امنیت دیدگاه های غیرمستقیم دارند. دیدگاه های دامنه • ویژگی های و محدودیت های دامنه ،نیازها را تحت تاثیر قرار می دهند. در ،ATMارتباطات درونی بانک استاندارد خواهد شد. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 تعریف دیدگاه ‏ شناسایی انواع دیدگاه ها • • • • • • تامین کنندگان و دریافت کنندگان سرویس های سیستم؛ سیستم هایی که بطور غیرمستقیم با سیستم رابطه دارند؛ قوانین و استانداردها؛ منابع تجاری و نیازهای کیفی؛ مهندسینی که سیستم را توسعه داده و نگهداری می کنند؛ بازاریابی و دیدگاه های تجاری دیگر. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 LIBSYS دیدگاه سلسله مراتبی All VPs I ndirect L ibrary manager F inance Students ©Ian Sommerville 2004 I nteractor Article providers Staff U sers External L ibrary staff System managers Domain UI standards Classification system Cataloguers Software Engineering, 7th edition. Chapter مصاحبه ‏ ‏ در مصاحبه های رسمی و غیررسمی ،تیم مهندسی نیازها سواالتی را برای کارفرمایان سیستم که استفاده کنندگان یا توسعه دهندگان سیستم هستند ،مطرح می کند. دو شیوه برای مصاحبه وجود دارد • • مصاحبه های بسته – به سواالتی ازپیش تعریف شده پاسخ داده می شود. مصاحبه های باز – موارد بحث ،ازپیش تعریف شده نبوده و با کارفرمایان به نتایجی می رسند. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مصاحبه ها در عمل ‏ ‏ ‏ بطور طبیعی مخلوطی از مصاحبه های بسته و باز هستند. مصاحبه ها برای درک بیشتر مفید هستند ،اینکه کارفرمایان چه می کنند و چطور با سیستم تعامل دارند. مصاحبه ها برای درک نیازهای دامنه مناسب نمی باشد • • مهندسین نیازها نمی توانند واژگان دامنه ی خاص را درک کنند. برخی با دانش دامنه به حدی آشنا هستند که بسختی در مورد آن مساله حرف زده یا فکر می کنند که نیاز به حرف زدن ندارد. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مصاحبه گرهای موثر ‏ ‏ مصاحبه ها باید روشنفکرانه بوده ،به کارفرمایان گوش کنند و نباید در مورد نیازها پیش داوری کرد. مصاحبه گر باید با یک سوال یا گزارش بحث را شروع کند و نباید بسادگی با سوال ”می خواهید چه کار کنید“ پاسخ را بپذیرد. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 سناریوها ‏ ‏ سناریوها نمونه هایی از چگونگی استفاده ی سیستم در جهان واقع می باشد. باید شامل • • • • • توصیفی از راه حل آغازین؛ توصیفی از رویدادهای طبیعی؛ توصیفی از اشتباهات احتمالی؛ اطالعاتی در مورد فعالیت های همزمان دیگر؛ توصیفی از حالت خاتمه ی سناریوها. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 LIBSYS 1 سناریو Initial assu mption: The user has logged on to the LIBSYS system and has located the journal containing the copy of the article. Normal: The user selects the article to be copied. He or she is then prompted by the system to either provide subscriber information for the journal or to indicate how they will pay for the article. Alternative payment methods are by credit card or by quoting anorganisational account number. The user is then asked to fill in a copyright form that maintains details of the transaction and they then submit this to the LIBSYS system. The copyright form is checked and, if OK, the PDF version of the article is downloaded to the LIBSYS working areaon the userصcom s puter and the user is informed thatit is available. Theuser is asked to select a printer and a copy of thearticle is printed. If the article has beenflagged as ش print-onlyصit is deleted from the userص s system oncetheuser has confirmed thatprinting is complete. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter LIBSYS 2 سناریو What cango wrong: Theuser may fail to fill in the copyright formcorrectly. In this case, the form should be re-presented to the user for correction. If the resubmitted form is still incorrect then the userصreq s uest for the article is rejected. The payment may be rejected by the system. The user صeque s st r for the article is rejected. The articledownloadmayfail. Retry until successful or the user terminates the session. It may not be possible to print the article. If the article is not flagged as ش print-onlyصthen it is held in the LIBSYS workspace. Otherwise, the article is deleted and the userص s account credited with the cost of the article. Other activities: Simultaneous downloads of other articles. Systemstate on completion: User is logged on. The downloaded article has been deleted from LIBSYS workspaceif it hasbeen flaggedas print-only. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter موارداستفاده ‏ ‏ ‏ مورداستفاده سناریویی مبتنی بر تکنیکی در UMLاست که اکتورها را در یک محاوره شناسایی کرده و محاوره را بیان می دارد. مجموعه ای از موارداستفاده باید تمامی محاوره های ممکن را با سیستم توصیف نماید. ممکن است دیاگرام توالی برای افزودن جزییات به موارداستفاده بکار رود .فرآیند توالی رویداد در سیستم نشان داده می شود. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مورداستفاده ی چاپ مقاله Article printing ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter LIBSYS موارداستفاده ی Article search L ibrary U ser Article printing U ser administration Supplier ©Ian Sommerville 2004 L ibrary Staff Catalogue services Software Engineering, 7th edition. Chapter چاپ مقاله item: Article copyrightF orm: Form myWorkspace: Workspace myPrinter: Printer U ser request request complete return copyright OK deliver article OK print send inform confirm delete ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter توالی چاپ مقاله item: Article copyrightF orm: Form myWorkspace: Workspace myPrinter: Printer U ser request request complete return copyright OK deliver article OK print inform send confirm delete ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter فاکتورهای اجتماعی و سازمانی ‏ ‏ ‏ سیستم های نرم افزاری در محتوای اجتماعی و سازمانی بکار می روند .می تواند نیازهای سیستم را تحت تاثیر قرار دهد. فاکتورهای اجتماعی و سازمانی دیدگاه منفردی نبوده اما تمامی دیدگاه ها را تحت تاثیر قرار می دهند. تحلیل های خوب باید به این فاکتورها حساس باشد اما معموًال روش اصولی برای تحلیل نیست. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مطالعه ی علمی ‏ ‏ ‏ ‏ دانشمندان اجتماعی زمان قابل توجهی برای مشاهده و تحلیل افرادی که واقعًا کار می کنند صرف می نمایند. افراد کار را توصیف نمی کنند. ممکن است اهمیت فاکتورهای اجتماعی و سازمانی مشاهده گردد. معموًال مطالعه ی علمی ،کار مدل های ساده ی سیستم را باشکوه تر و پیچیده تر نشان می دهد. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 تمرکز مطالعه ی علمی ‏ ‏ ‏ ‏ در مطالعه ی پروژه ی فرآیند کنترل ترافیک توسعه داده شده. ترکیب مطالعه ی علمی با نمونه سازی اولیه. توسعه ی نمونه سازی اولیه به سواالت بدون پاسخ تحلیل مطالعه ی علمی پاسخ می دهد. مشکل مطالعه ی علمی این است که ممکن است بر پایه ی سلسله مراتبی باشد اما نباید طوالنی باشد. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مطالعه ی علمی و نمونه سازی اولیه Ethno graphic analysis Debriefing meetings Focused ethnography Prototype evaluation Generic system development ©Ian Sommerville 2004 System protoyping Software Engineering, 7th edition. Chapter حوزه ی مطالعه ی علمی ‏ ‏ نیازهایی که از افراد درگیر ناشی می شود به شیوه ایی که تعریف شده کار می کنند. نیازهایی که از مساعی و همکاری افراد دیگر ناشی می شود. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 معتبرسازی نیازها ‏ ‏ دغدغه این است که نیاز های سیستم با آنچه مشتری می خواهد مطابقت داشته باشد. هزینه های خطای نیازها بیشتر است بنابراین معتبرسازی بسیار مهم می باشد • تثبیت خطای یک نیاز بعد از تحویل ممکن است هزینه ای 100 مرتبه بیشتر از خطای پیاده سازی دارد. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 بررسی نیازها ‏ ‏ ‏ ‏ ‏ اعتبار .آیا سیستم توابعی را فراهم می نماید که بهترین پشتیبان نیازهای مشتری باشد؟ سازگاری .آیا در نیازها تضاد وجود دارد؟ کمال .آیا تمامی توابع توسط مشتری درخواست شده است؟ واقع بینی .آیا می توان نیازها را با بودجه و تکنولوژی موجود پیاده سازی نمود؟ اثبات پذیری .آیا می توان نیازها را بررسی کرد؟ ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 تکنیک های معتبرسازی نیازها ‏ ‏ ‏ مرور نیازها • تحلیل اصولی (سیستماتیک) نیازها • بکارگیری مدل قابل اجرای سیستم برای بررسی نیازها. • توسعه ی تست نیازها برای بررسی قابلیت تست. نمونه سازی اولیه تولید حالت تست ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مرور نیازها ‏ ‏ ‏ تا زمانیکه تعریف نیازها تنظیم شده باشد بازبینی های باقاعده باید صورت پذیرد. متقاضی و پیمانکار باید در مرورها همکاری داشته باشند. ممکن است مرورها رسمی (با مستندات کامل) یا غیررسمی باشند .ارتباط های مناسب بین توسعه دهنده ها، مشتریان و کاربران می تواند حل مشکالت را تسریع نماید. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 بررسی های مرور ‏ ‏ ‏ ‏ قابلیت اثبات .آیا نیازهای قابلیت تست واقعی را دارد؟ قابلیت درک .آیا نیازها به درستی درک شده اند؟ قابلیت ردیابی .آیا نیازهای مبدا به درستی گفته شده است؟ قابلیت سازگاری .آیا می توان نیاز را بدون تاثیر بر نیازهای دیگر تغییر داد؟ ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مدیریت نیازها ‏ ‏ مدیریت نیازها فرآیند مدیریت تغییر نیازها در طی فرآیند مهندسی نیازها و توسعه ی سیستم می باشد. نیازها بناچار ناقص و متناقص هستند • • نیازهای جدید در طی یک فرآیند ناشی می شود بنابراین نیازهای تجاری تغییر کرده و درک بهتری از سیستم حاصل می گردد. دیدگاه های متفاوت نیازهای مختلفی داشته و غالبًا متناقضند. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 تغییر نیازها ‏ ‏ ‏ اولویت نیازها از دیدگاه های مختلف در طی فرآیند توسعه تغییر می یابد. مشتریان سیستم ممکن است نیازهای تجاری ای را تعیین کنند که با نیازهای کاربر نهایی متضاد است. محیط های تکنیکی و تجاری در طی توسعه ،تغییر می یابد. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 ارزیابی نیازها I nitial understanding of problem I nitial requirements Changed understanding of problem Changed requirements Time ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter نیازهای پایدار و سست ‏ ‏ نیازهای پایدار .نیازهای ثابت از فعالیت سازمانی مشتری نشات می گیرد .برای نمونه در یک بیمارستان همیشه دکترها ،پرستاران و غیره وجود دارند بطوریکه ممکن است از مدل های دامنه ناشی شوند. نیازهای سست .نیازهایی که در طی توسعه یا حین استفاده ی سیستم تغییر می یابند .در بیمارستان ،نیازهایی که از سیاست بهداشتی ناشی می شود. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 طبقه بندی نیازها Requirem ent Type Description Mutable requirements Requirements that change because of changes to the environment in which the organisation is operating. For example, in hospital systems, the funding of patient care may changeand thus require different treatment information to be collected. Emergent requirements Requirements that emerge as the customer's understanding of the system develops during the system development. The design process may reveal new emergent requirements. Consequential requirements Requirements that result from the introduction of the computer system. Introducing the computer system may change the organisations processes and open up new ways of working which generate new system requirements Compatibility requirements Requirements that depend on the particular systems or business processes within an organisation. As these change, the compatibility requirements on the commissioned or delivered sys tem may also have to evolve. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter برنامه ی مدیریت نیازها ‏ در طی فرآیند مهندسی نیازها ،برنامه ریزی زیر خواهید داشت: • شناسایی نیازها • فرآیند مدیریت تغییر • سیاست های قابلیت ردیابی • ابزار پشتیبانی CASE • چه نیازهایی منحصرًا شناسایی شده است؛ • زمانیکه نیازها تغییر یابد فرآیند دنبال می شود؛ • اطالعاتی د رمورد ارتباط نیازها یی که اصالح شده است؛ • ابزار پشتیبان برای مدیریت تغییر نیازها درخواست می شود؛ ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 قابلیت ردیابی ‏ ‏ ‏ ‏ قابلیت ردیابی دغدغه ی ارتباط بین نیازها ،منابع و طراحی سیستم را دارد قابلیت ردیابی منبع • برقرار ارتباط بین نیازها با کارفرمایان؛ • برقراری ارتباط بین نیازهای وابسته؛ • برقراری ارتباط از نیازها به طراحی؛ قابلیت ردیابی نیازها قابلیت ردیابی طراحی ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 ماتریس قابلیت ردیابی ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter ابزار پشتیبان CASE ‏ ‏ ‏ ذخیره ی نیازها • نیازها باید در یک منبع ذخیره و مدیریت شوند. • فرآیند مدیریت تغییر فرآیند جریان کاری است که می تواند جریان اطالعات را بین مراحی مختلف بصورت خودکار تعریف و ذخیره نماید. • بازیابی ارتباط بین نیازها بطور خودکار انجام می پذیرد. مدیریت تغییر مدیریت ردیابی ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مدیریت تغییر نیازها ‏ ‏ باید تمامی تغییرات نیازها پیشنهاد شود. مراحل اصلی • تحلیل مشکل .مشکل نیازها و تغییر بیان می شود؛ • تحلیل و هزینه ی تغییر .تاثیر تغییر روی نیازهای دیگر ارزیابی می شود؛ • پیاده سازی تغییر .مستند نیازها و مستندات دیگر وابسته به تغییر اصالح می شود. ‏Software Engineering, 7th edition. Chapter ©Ian Sommerville 2004 مدیریت تغییر I dentified problem Problem analysis and change specification ©Ian Sommerville 2004 Change analysis and costing Change implementation Revised requirements Software Engineering, 7th edition. Chapter