مهندسی نیازها فصل 7 درس مهندسي نرم‌افزار 2

Slides:



Advertisements
Similar presentations
Understanding Requirements Unit II
Advertisements

7.1 A Bridge to Design & Construction
Chapter 7 Requirements Engineering
1 R&D SDM 1 Software Project Management Requirements Analysis 2010 Theo Schouten.
OO Development Process. UML and Process UML standardizes notation, not process –Increase likelihood of widespread acceptance There is significant variability.
1 R&D SDM 1 Software Project Management Requirements Analysis 2009 Theo Schouten.
Lifecycle Phases time InceptionElaborationConstruction Transition  Define the scope of the project and develop business case  Inception Define the scope.
1 SWE Introduction to Software Engineering Lecture 5.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
03/12/2001 © Bennett, McRobb and Farmer Development Process Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Requirement engineering for an online bookstore system
Slide 1 Requirements Workflow. Slide 2 The Phases/Workflows of the Unified Process Figure 3.1 l Phase is Business context of a step Workflow is Technical.
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 7 Requirements Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Chapter 4 Requirements Engineering
Online Music Store MSE Project Presentation I Presented by: Reshma Sawant Major Professor: Dr. Daniel Andresen.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
Requirements Engineering How do we keep straight what we are supposed to be building?
SWE311_Ch07 (071) Software & Software Engineering Slide 1 Chapter 7 Requirements Engineering.
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
IS 466 ADVANCED TOPICS IN INFORMATION SYSTEMS LECTURER : NOUF ALMUJALLY 22 – 10 – 2011 College Of Computer Science and Information, Information Systems.
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 7 Requirements Engineering Elements of software requirement gathering.
Chapter 7 Requirements Engineering
Software Engineering Saeed Akhtar The University of Lahore Lecture 7 Originally shared for: mashhoood.webs.com.
Requirements Gathering How do we find out what we are supposed to be building?
For accurate communication, since a project can have several participants, each from different background. Represent a given aspect of the system We will.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Chapter 5 Understanding Requirements
© Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 1 what are use cases? “A specification of sequences of actions, including variant.
© 2010 Bennett, McRobb and Farmer1 Development Process Based on Chapter 5 Bennett, McRobb and Farmer Object Oriented Systems Analysis and Design Using.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
By Germaine Cheung Hong Kong Computer Institute
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Requirements Engineering Requirements Elicitation Overview of Requirements Analysis.
© Bennett, McRobb and Farmer 2005
Essentials of Modeling with IBM Rational Software Architect V7.5
Requirement Engineering
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
Requirements Gathering
ITEC 370 Lecture 6 Requirements. Review Requirements –What are some of the stages of the requirements gathering process? –What is the end result of this.
Requirements Engineering Determining and Defining the Requirements for the Project.
CS 8532: Adv. Software Eng. – Spring 2009 Dr. Hisham Haddad Chapter 7 CS 8532: Advanced Software Engineering Dr. Hisham Haddad Class will start momentarily.
® IBM Software Group © 2009 IBM Corporation Essentials of Modeling with IBM Rational Software Architect V7.5 Module 0: About This Course.
ITEC 370 Lecture 4 Requirements. Review Teams –What did you learn? –What roles are there? –What are the biggest challenges right now for your team?
IF2036 Software Engineering TIM RPL Requirement Engineering.
Development Process Based on Chapter 5 Bennett, McRobb and Farmer
Requirements Engineering
DT249/4 Information Systems Engineering Lecture 0
UML - Unified Modeling Language
UML: Unified modeling language
مهندسي نيازمندي هاي سيستم اعلام كننده خودكار قرار ملاقاتها تحت وب
Artificial Intelligence استوارت راسل، پیتر نورویگ
Rational Worldwide Software Symposium
For all your restaurant searching needs
مدل‌هاي فرايند پيشنهادي
Rational Worldwide Software Symposium
The Unified/Rational Unified Process (UP/RUP) Defined
Director of Industry Relations
واسط كاربري هوشمند Intelligent User Interface
Chapter 7 Requirements Engineering
The Ethics of Autonomous Weapons
Chapter 7 Requirements Engineering
Requirements Engineering Tasks
Chapter 5 Understanding Requirements.
Rational Worldwide Software Symposium
Requirements Engineering
Presentation transcript:

مهندسی نیازها فصل 7 درس مهندسي نرم‌افزار 2 دكتر احمد عبداله زاده بارفروش تهيه كننده : پويا جافريان Artificial Intelligent Systems Laboratory

مهندسی نیازها (دوره حیات) آغاز(Inception) : مطرح نمودن تعداد سوال برای به دست آوردن : درک اولیه از مسئله افرادی که به راه حل نیاز دارند. ماهیت راه حل مورد نیاز کارایی ارتباط و همکاری اولیه بین مشتری و توسعه دهنده آشکارسازی(Elicitation) : به دست آوردن همه نیازها از همه ذینفعان جزئیات(Elaboration) : تهیه یک مدل تحلیل که نیازهای داده ای، کارکردی و رفتاری را مشخص نماید. مذاکره (Negotiation): توافق بر روی سیستمی که باید تحویل داده شود. Artificial Intelligent Systems Laboratory

مهندسی نیازها (دوره حیات) توصیف (Specification): می توان یک یا چند مورد زیر باشد: یک مستند مجموعه ای از مدل ها توصیف رسمی و ریاضی مجموعه ای از سناریوهای کاربر (مورد کاربرد) یک نمونه (Prototype) اعتبارسنجی (Validation) : یک مکانیزم بازبینی برای یافتن : خطاها در متن یا در برداشت از مفهوم نیازها محل هایی که نیاز به وضوح بیشتر دارند. اطلاعاتی که حذف شده یا موجود نیستند. ناهمگونی بین نیازها (یک مشکل اساسی در مهندسی سیستمهای بزرگ) نیازهای متضاد یا غیر واقعی مدیریت نیازها (Requirement Management) Artificial Intelligent Systems Laboratory

مرحله آغاز (Inception) تعیین ذینفعان تشخیص وجود دیدگاه های مختلف بین ذینفعان حرکت در جهت ایجاد همکاری بین ذینفعان سوالات کلی زیر بر روی مشتری، ذینفعان، اهداف کلی و سودی که از سیستم حاصل می شود تاکید دارد: چه کسی درخواست کار را داده است؟ چه کسی از محصول استفاده خواهد نمود؟ سود مالی یک محصول یا راه حل موفق چیست ؟ Artificial Intelligent Systems Laboratory

مرحله آغاز (Inception) مجموعه سوالات زیر به توسعه دهندگان کمک می کنند تا مسئله و دیدگاه مشتری نسبت به محصول را بهتر بشناسد: شما چگونه یک خروجی خوب از یک محصول موفق را تشخیص می دهید؟ محصول باید به حل چه مسائلی بپردازد؟ آیا می تواند محیط کسب و کاری را که راه حل باید در آن مورد استفاده قرار گیرد شرح دهید؟ آیا محدودیت کارایی خاصی بر روی رویکرد ما به محصول تاثیر گذار است؟ مجموعه سوالات زیر بر روی میزان موثر بودن ارتباطات تاکید دارد : آیا شما بهترین فرد رسمی برای پاسخ گویی به سوالات هستید؟ آیا سوالات من به مسئله شما مرتبط است ؟ آیا من بیش از حد سوال مطرح می کنم ؟ آیا شخص دیگری وجود دارد که اطلاعات تکمیلی را فراهم نماید؟ آیا سوال دیگری وجود دارد که از شما بپرسم؟ Artificial Intelligent Systems Laboratory

مرحله آشکارسازی نیازها (Elicitation) جمع آوری نیازها با همکاری تشکیل جلسه با حضور توسعه دهندگان و مشتریان یک برنامه زمانی منعطف در نظر گرفته می شود. قوانینی برای آماده سازی و حضور در جلسه تهیه می شود. یک فرد وظیفه کنترل جلسه را بر عهده می گیرد. از یک مکانیزم برای اندازه گیری حساسیت و میزان توافق گروه استفاده می شود. هدف از جلسه شناخت مسئله، ارائه عناصر راه حل، مذاکره در مورد رویکردها و توصیف مجموعه اولیه ای از نیازها است. Artificial Intelligent Systems Laboratory

مرحله آشکارسازی نیازها (Elicitation) Quality Function Deployment(QFD) سه نوع از نیازها تعیین می شود (معمولی، مورد انتظار، جالب) در جلسه با مشتری، ابزار function deployment برای تعیین ارزش هریک از کارکردهای مورد نیاز سیستم استفاده می شود. ابزار Information deployment برای تعیین اشیاء داده ای و وقایعی که سیستم باید آنها را مصرف یا تولید کند؛ مورد استفاده قرار میگیرد. ابزار Task deployment رفتار سیستم را در محیط آن مورد بررسی قرار می دهد. با انجام تحلیل ارزش (Value Analysis) اولویت هریک از نیازمندی ها تعیین می شود. سناریوهای کاربر نام دیگر آن مورد کاربرد (Use-case) می باشد و نشان می دهد سیستم در آینده چگونه مورد استفاده قرار خواهد گرفت. توسعه دهندگان و کاربران سیستم هریک مجموعه ای از سناریو های احتمالی استفاده از سیستم را تهیه می کنند. Artificial Intelligent Systems Laboratory

محصولات کاری مرحله آشکارسازی (Elicitation) بیانیه نیازها و امکان سنجی بیانیه حوزه سیستم یا محصول فهرستی از مشتریان، کاربران، و دیگر ذینفعان سیستم که در فرایند آشکار سازی نیازها شرکت کرده اند. توصیف محیط فنی سیستم فهرستی از نیازها و محدودیت های مرتبط با هر نیاز مجموعه ای از سناریوهای استفاده از سیستم (موارد کاربرد) که دید عمیق تری نسبت به استفاده از سیستم در شرایط مختلف اجرا ایجاد می کند. نمونه برای تعریف بهتر مسئله Artificial Intelligent Systems Laboratory

موارد کاربرد (Use Cases) تعریف : مجموعه ای از سناریوهای کاربر که چگونگی استفاده کاربر از سیستم را نشان می دهد. هر سناریو از دیدگاه یک ”بازیگر“ ( یک فرد یا ابزار که از طریقی با سیستم ارتباط برقرار می کند) شرح داده می شود. هر سناریو به سوالات زیر پاسخ می دهد ک چه کسی بازیگر اولیه و چه کسی بازیگر ثانویه است؟ اهداف بازیگر چیست ؟ چه پیش شرط هایی قبل از آغاز سناریو باید وجود داشته باشد؟ چه فعالیت های اصلی یا کارکردهایی باید توسط بازیگر انجام شود؟ چه گسترش هایی در هنگام شرح سناریو باید انجام شود؟ سناریو به چه حالت های متفاوتی می تواند انجام پذیرد؟ چه اطلاعاتی از سیستم توسط بازیگر اخذ، تولید یا تغییر داده می شود؟ آیا بازیگر سیستم را از تغییرات رخ داده در محیط بیرون آگاه می کند؟ بازیگر تمایل دارد چه اطلاعاتی از سوی سیستم برای وی تهیه شود؟ آیا بازیگر تمایل دارد در مورد تغییرات ناخواسته مطلع شود؟ Artificial Intelligent Systems Laboratory

نمودار مورد کاربرد (Use Case Diagram) Artificial Intelligent Systems Laboratory

مرحله جزئی سازی (Elaboration) هدف از این مرحله فراهم آوردن شرحی از اطلاعات مورد نیاز در حوزه کارکردی و رفتاری برای سیستم کامپیوتری است. اجزاء مدل آنالیز : اجزاء مبتنی بر سناریو (شرح سیستم از دیدگاه کاربر) کارکردی : پردازش های انجام شده توسط کارکردهای سیستم موارد کاربرد : شرح تعاملات بازیگر و سیستم اجزاء مبتنی بر کلاس (ارتباط بین اشیائی که توسط بازیگر تغییر داده می شوند و ویژگی های این اشیاء) با توجه به سناریوها به دست می آید. اجزاء رفتاری ( رفتار سیستم و کلاس ها را به صورت مجموعه ای از حالات و انتقال بین حالت های مختلف مشخص می کند.) نمودار حالت اجزاء مبتنی بر جریان ( نحوه جریان اطلاعات را درون سیستم و نحوه تغییر آن توسط کارکردهای سیستم را مشخص می کند) نمودار جریان داده Artificial Intelligent Systems Laboratory

مرحله جزئی سازی (Elaboration) هدف از این مرحله فراهم آوردن شرحی از اطلاعات مورد نیاز در حوزه کارکردی و رفتاری برای سیستم کامپیوتری است. اجزاء مدل آنالیز : اجزاء مبتنی بر سناریو (شرح سیستم از دیدگاه کاربر) کارکردی : پردازش های انجام شده توسط کارکردهای سیستم موارد کاربرد : شرح تعاملات بازیگر و سیستم اجزاء مبتنی بر کلاس (ارتباط بین اشیائی که توسط بازیگر تغییر داده می شوند و ویژگی های این اشیاء) با توجه به سناریوها به دست می آید. اجزاء رفتاری ( رفتار سیستم و کلاس ها را به صورت مجموعه ای از حالات و انتقال بین حالت های مختلف مشخص می کند.) نمودار حالت اجزاء مبتنی بر جریان ( نحوه جریان اطلاعات را درون سیستم و نحوه تغییر آن توسط کارکردهای سیستم را مشخص می کند) نمودار جریان داده Artificial Intelligent Systems Laboratory

Artificial Intelligent Systems Laboratory نمونه ای از یک کلاس UML Artificial Intelligent Systems Laboratory

نمودار حالت UML برای مدل سازی رفتاری Artificial Intelligent Systems Laboratory

Artificial Intelligent Systems Laboratory الگوهای آنالیز نام الگو: نام الگو که بیانگر ماهیت آن می باشد. هدف: شرح موردی که توسط الگ بازنمایی یا انجام می شود. کاربرد: سناریوای که مشخص می کند الگو چگونه می تواند پاسخگوی مسئله مورد نظر باشد. نیروها و حوزه : شرح موارد خارجی که می تواند بر نحوه استفاده از الگو اثرگذار باشد و موارد خارجی که در صورت استفاده از الگو حل خواهند شد. راه حل: شرحی از نحوه اعمال الگو برای حل مسئله با تاکید بر مسائل ساختاری و رفتاری Artificial Intelligent Systems Laboratory

Artificial Intelligent Systems Laboratory الگوهای تحلیل نتایج : مشخص می کند که وقتی الگو اعمال شود چه اتفاقی رخ خواهد داد و چه Trade-off هایی در هنگام استفاده از الگو وجود دارد. طراحی : نحوه طراحی الگوی آنالیز با استفاده از الگوهای طراحی موجود. استفاده های معمول: نمونه هایی از استفاده از الگو در سیستم های واقعی الگوهای مرتبط : الگوهایی که از جنبه های زیر با الگوی مورد نظر در ارتباط هستند: معمولاً همراه این الگو استفاده می شود. از لحاظ ساختاری شبیه الگوی مورد نظر است. نوع دیگری از الگوی مورد نظر است. Artificial Intelligent Systems Laboratory

مذاکره در نیازمندی ها (Negotiation) تعیین ذینفعان کلیدی افرادی که در مذاکره درگیر هستند. مشخص نمودن ”شرط برد“ هر ذینفع شرایط برد همواره بدیهی نیستند. مذاکره حرکت به سمت مجموعه ای از نیازها که به حالت “Win-Win” منجر می شود. Artificial Intelligent Systems Laboratory

مذاکره در نیازمندی ها (Negotiation) نکات کلیدی یک فرایند رقابت نیست. یک راهبرد مشخص داشته باشید. به صورت فعال گوش دهید. بر روی علایق طرفین دیگر تمرکز کنید. سعی کنید مسائل شخصی نشوند. خلاق باشید. برای تعهد آمادگی داشته باشید. Artificial Intelligent Systems Laboratory

اعتبار سنجی نیازمندی ها (Validation) آیا هریک از نیازمندی ها با اهداف کلی سیستم همخوانی دارند؟ آیا نیازمندی ها دارای درجه لازم از تجرد می باشند؟ (برخی نیازها دارای جزئیات فنی بوده که در این مرحله از توسعه سیستم مورد نیاز نمی باشد) آیا نیازمندی واقعاً ضروری بوده ، یا نیازمندی برخی ویژگی های اضافی سیستم را مشخص می کند؟ آیا هریک از نیازمندی ها محدود و نامبهم می باشند؟ آیا درخواست دهنده و منبع هریک از نیازمندی ها موجود است؟ آیا نیازمندی وجود دارد که با دیگر نیازمندی ها در تضاد باشد؟ Artificial Intelligent Systems Laboratory

اعتبارسنجی نیازمندی ها (Validation) آیا همه نیازمندی ها در محیط فنی که سیستم در آن توسعه داده خواهد شد؛ قابل دستیابی هستند؟ آیا همه نیازمندی ها، پس از پیاده سازی قابل تست می باشند؟ آیا مدل کلی نیازمندی ها بیانگر کارکردها، اطلاعات و رفتار سیستمی که قرار است تولید شود می باشند؟ آیا مدل نیازمندی ها به درستی تقسیم بندی شده است ؟ آیا از الگوهای نیازمندی در مدل نیازمندی ها استفاده شده است؟ آیا همه این الگو ها با نیازمندی های کاربر همخوانی دارند؟ Artificial Intelligent Systems Laboratory

مدیریت نیازمندی ها (Requirement Management) مجموعه ای از فعالیت ها که تیم پروژه را در زمینه تشخیص، کنترل، و ردگیری نیازمندی ها و انجام تغییر در حین پیشرفت پروژه، یاری می کند. تعداد زیادی از این فعالیت ها مشابه آن فعالیت هایی است که فرایند مدیریت پیکربندی نرم افزار (SCM) را تشکیل می دهند. نیازمندی ها در مرحله اول، تشخصی داده شده و با یک مشخصه یکتا علامت گذاری می شوند. سپس نیازمندی ها با توجه به نوع (کارکردی، داده ای، رفتاری، ارتباطی، یا خروجی) طبقه بندی می شوند. جداول ردگیری تهیه شده و در هنگام تغییر هریک از نیازمندی ها به روز می شوند. سیستم های مبتنی بر پایگاه داده اعضای تیم را بسیار یاری خواهند نمود. Artificial Intelligent Systems Laboratory

جداول ردگیری (Traceability) جدول ردگیری Feature ها ( مشخص کننده ارتباط نیازمندی ها با ویژگی های قابل رویت و مد نظر مشتری ) جدول ردگیری Source (مشخص کننده منبع هر نیازمندی ) جدول ردگیری Dependency (مشخص کننده ارتباط بین نیازمندی ها) جدول ردگیری Subsystem (مشخص کننده طبقه بندی نیازمندی ها با توجه به زیر سیستم) جدول ردگیری Interface ( مشخص کننده رابطه نیازمندی ها با واسط های داخلی و خارجی) Artificial Intelligent Systems Laboratory