Transcript نیازمندیهای عملیاتی

‫نیازمندیها‬
‫نیازمندیها چه هستند؟‬
‫• نیازمندیها عبارتند از توانمندیها و قابلیتهایی که نرم افزار‬
‫باید مطابق آنها عمل نماید‪ .‬این نیازمندیها به طور کلی به دو‬
‫دسته ”نیازمندیهای عملیاتی“ و ”نیازمندیهای غیرعملیاتی“‬
‫تقسیم بندی می شوند‪.‬‬
‫• نیاز مندیهای عملیاتی یک نرم افزار توسط موردهای‬
‫کاربرد و سناریوی آنها توصیف می شود‬
‫• نیازمندیهای غیرعملیاتی نرم افزار در مستندی بنام‬
‫”مشخصات متمم“ ارایه می گردد‬
‫نیازمندیهای غیرعملیاتی‬
‫•‬
‫•‬
‫•‬
‫•‬
‫قابلیت استفاده (‪ :)Usability‬فاکتورهای انسانی‪ ،‬وجود مستندات‪،‬‬
‫رابط کاربری مناسب‬
‫قابلیت اتکا)‪ :(Reliability‬فرکانس خرابی‪ ،‬قابلیت بهبود از خرابی‬
‫کارایي (‪ :)Performance‬زمان پاسخ‪ ،‬توان عملیاتی‬
‫قابلیت پشتیبانی)‪ :(Supportability‬قابلیت تطبیق‪ ،‬قابلیت‬
‫پیکربندی‪.‬‬
‫سازماندهی نیازمندیها در ‪Agile UP‬‬
‫•‬
‫•‬
‫•‬
‫•‬
‫مدل موردهای کاربرد (‪)Use Case Model‬‬
‫مستند مشخصات متمم (‪)Supplementary Specification‬‬
‫مستند چشم انداز)‪(Vision‬‬
‫قوانین تجاری)‪(Business Rules‬‬
‫موردهای کاربرد)‪(Use Cases‬‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫اکتور‪ :‬شخص‪ ،‬سیستم و یا سازمانی که خارج از محدوده نرم افزار‬
‫مورد بحث قرار گرفته و با آن به نحوی تعامل دارند‪ :‬صندوقدار در‬
‫سیستم فروش یک فروشگاه‬
‫سناریو‪ :‬متنی است که توصیف کننده دنباله ای از تعامالت بین اکتور‬
‫و نرم افزار برای دریافت یک خدمت مشخص از نرم افزار می باشد‪:‬‬
‫به عنوان مثال سناریو یک خرید موفق و ثبت آن در سیستم فروش‬
‫مورد کاربرد‪ :‬مجموعه ای از سناریوهای موفق و یا ناموفق است که‬
‫توصیف کننده استفاده یک اکتور از نرم افزار برای رسیدن به یک‬
‫هدف مشخص می باشد‪.‬‬
‫نکته‪ :‬موردهای کاربرد دیاگرام نیستند بلکه مستندات متنی می باشند ‪.‬‬
‫در سناریوی یک مورد کاربرد دقیقا باید مشخص شود کاربر سیستم‬
‫چه عملی انجام می دهد و در مقابل سیستم چگونه عمل می کند‬
‫انواع اکتورها‬
‫• اکتور اولیه (‪ :)Primary‬کاربرانی که مستقیما با سیستم در تعامل‬
‫هستند‪ :‬صندوقدار‬
‫• اکتور پشتیبان (‪ :)Supporting‬سیستمهای خارجی که سرویسهای‬
‫به نرم افزار ما ارایه می دهند‪ :‬مانند سیستم احراز هویت پرداخت‬
‫اعتباری در سیستم فروش‬
‫• اکتور خارجی (‪ :)Offstage‬مستقیما با سیستم ما در تعامل نیستند‬
‫اما ممکن است به صورت غیر مستقیم استفاده کننده باشد‪ :‬اداره‬
‫مالیات در سیستم فروش‬
‫دو فرمت برای نوشتن سناریو‬
‫ بدون پرداختن به جزییات فقط سناریوی موفق را‬:‫• فرمت خالصه‬
:‫بیان می کند‬
Process Sale:
A customer arrives at a checkout with items to purchase. The cashier uses the
POS system to record each purchased item. The system presents a running
total and line-item details. The customer enters payment information, which
the system validates and records. The system updates inventory. The customer
receives a receipt from the system and then leaves with the items.
‫دو فرمت برای نوشتن سناریو‬
.‫ عالوه بر سناریوی موفق کلیه حاالت استثنا را نیز شامل می شود‬:‫• فرمت کامل‬
Main Success Scenario (or Basic Flow):
1.Customer arrives at POS checkout with goods and/or services to purchase.
2.Cashier starts a new sale.
3.Cashier enters item identifier.
4.System records sale line item and presents item description, price, and running total. Price
calculated from a set of price rules.
5.Cashier repeats steps 3-4 until indicates done.
5.System presents total with taxes calculated.
6.Cashier tells Customer the total, and asks for payment.
7.Customer pays and System handles payment.
8.System logs completed sale and sends sale and payment information to the external
Accounting system (for accounting and commissions) and Inventory system (to update
inventory).
9.System presents receipt.
10.Customer leaves with receipt and goods (if any).
‫حاالت استثناء در فرمت کامل‬
Extensions (or Alternative Flows):
*a. At any time, Manager requests an override operation:
1.System enters Manager-authorized mode.
2.Manager or Cashier performs one Manager-mode operation. e.g., cash
balance change, resume a suspended sale on another register, void a
sale
3.System reverts to Cashier-authorized mode.
*b. At any time, System fails:
1.Cashier restarts System, logs in, and requests recovery of prior state.
2.System reconstructs prior state.
2a. System detects anomalies preventing recovery:
1.System signals error to the Cashier, records the error, and enters
a clean state.
2.Cashier starts a new sale.
‫نکات مهم در نوشتن موردهای کاربرد‬
‫• موردهای کاربرد را مستقل از تکنولوژی بنویسید‬
‫• موردهای کاربرد را با تاکید بر هدف و قصد اکتور بنویسید و نه نحوه رسیدن‬
‫به هدف‬
…
1.Administrator identifies self.
2.System authenticates identity.
3.…
…
1.Adminstrator enters ID and password in dialog box (see Picture 3).
2.System authenticates Administrator.
3.System displays the "edit users" window (see Picture 4).
4.…
‫نکات مهم در نوشتن موردهای کاربرد‬
‫• موردهای کاربرد را به صورت خالصه و بدون کلمات اضافی‬
‫بنویسید‬
‫• موردهای کاربرد را به صورت جعبه سیاه بنویسید‬
Black-box style
The system records the sale.
Not
The system writes the sale to a
database. …or (even worse):
The system generates a SQL INSERT
statement for the sale
‫سواالتی که به یافتن اکتورها کمک می کند‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫چه کسی مدیریت امنیت و کاربران سیستم را به عهده دارد؟‬
‫آیا ”زمان“ اکتور سیستم است؟‬
‫آیا یک پردازه مانیتورینگ وجود دارد که در صورت بروز‬
‫خرابی سیستم را راه اندازی مجدد کند؟‬
‫آیا نرم افزار بروزرسانی می شود؟‬
‫آیا عالوه بر کاربران انسانی سیستمهای خارجی از سرویسهای‬
‫سیستم مورد نظر استفاده می کنند؟‬
‫در زمان بروز خرابی چه کسی باید مطلع شود؟‬
‫چه کسی الگهای سیستم را بررسی می کند؟‬
‫یافتن موردهای کاربرد‬
)external events( ‫• تعیین وقایع خارجی سیستم‬
‫• تعیین اکتور صادر کننده واقعه‬
‫• تعیین هدف اکتور به عنوان مورد کاربرد‬
External Event
From Actor
Goal/Use Case
enter sale line item
Cashier
enter payment
Cashier or Customer process a sale
…
process a sale
‫موردهای کاربرد سودمند در تکرارهای اولیه تشریح چگونه‬
‫تعیین می شوند؟‬
‫• آزمایش های زیر در این رابطه مورد استفاده قرار می گیرند‪:‬‬
‫– تست رئیس‪ :‬موردکاربرد از دید رئیس ارزشمند باشد‬
‫– تست ‪ :EBP‬مورد کاربرد بیانگر عملی باشد که توسط یک شخص در یک زمان و در‬
‫پاسخ به واقعه ای تجاری انجام شده و منجر به ارزش افزوده تجاری می گردد‪.‬‬
‫– تست اندازه‪ :‬مورد کاربرد دارای سناریویی با تعداد قابل توجهی گام باشد‪.‬‬
‫• مثال‪:‬‬
‫‪Log in‬‬
‫‪Process sale‬‬
‫‪Handle Returns‬‬
‫‪Enter Sale Item‬‬
‫•‬
‫•‬
‫•‬
‫•‬
‫تحلیل نیازمندیها در فرایند توسعه تکراری‬
‫• در فاز آغاز‪:‬‬
‫– نام اکثر موردهای کاربرد مشخص میشوند‬
‫– حداکثر ‪ 10‬درصد از موردهای کاربرد با فرمت کامل توصیف می شوند‬
‫– باقی مورد های کاربرد تنها با فرمت خالصه بیان می شوند‪.‬‬
‫• در فاز تشریح‪ :‬به تدریج در تکرارهای متوالی در این فاز درصد بیشتری از‬
‫موردهای کاربرد به فرمت کامل (در جلسات ابتدای هر تکرار) توصیف می‬
‫شوند‪ .‬بطوریکه پس از اتمام این فاز ‪ 90‬درصد موردهای کاربرد با فرمت‬
‫کامل توصیف شده اند‪.‬‬
‫• در فاز ساخت‪ :‬با خاتمه فاز تشریح تقریبا ‪ 90‬درصد از موردهای کاربرد‬
‫کامال تشریح شده اند‪.‬در فاز ساخت به ‪ 10‬درصد باقیمانده که عمدتا موردهای‬
‫کاربرد مهمی از لحاظ معماری یا تجارت نیستند پرداخته می شود‪.‬‬
‫• نکته‪ :‬به تفاوت تحلیل نیازمندیها در این روش و مدل آبشاری دقت نمایید‪.‬‬
‫ تحلیل نیازمندیهای سیستم فروش در فاز آغاز‬:‫مثال‬
‫موردهای کاربردی که با فرمت‬
‫کامل توصیف می شوند‬
Process Sale
Handle Returns
‫موردهای کاربردی که با فرمت خالصه توصیف می شوند‬
Process Rental
Analyze Sales Activity
Manage Security
…
Cash In
Cash Out
Manage Users
Start Up
Shut Down
Manage System Tables
…
‫مستند چشم انداز(‪)Vision‬‬
‫• مستند چشم انداز پروژه که در فاز آغاز تهیه می شود شامل‬
‫بخشهای زیر می باشد‪:‬‬
‫– بیان مساله (‪)Problem Statement‬‬
‫– ذینفعان و صاحبان پروژه (‪)Stakeholder Description‬‬
‫– اهداف کلیدی و سطح باالی ذینفعان پروژه)‪(Key High-Level Goals‬‬
‫– دیاگرام متن سیستم (‪)System Context Diagram‬‬
‫– خالصه قابلیت های عملیاتی سیستم (‪)Functional Features‬‬
‫– خالصه قابلیتهای غیرعملیاتی سیستم (‪)non-functional Features‬‬
‫مثال‪ :‬مستند چشم انداز برای سیستم فروش ‪POS‬‬