قرار هست چی رو بررسی کنیم؟
چطور نیازمندی‌ها را به زبانی بنویسیم که طراح، برنامه‌نویس، مدیر پروژه و ذی‌نفع همه بفهمند؟
تحلیل نیازمندی وقتی ارزش پیدا می‌کند که بشود آن را به زبانی قابل فهم برای طراح، توسعه‌دهنده، مدیر پروژه و ذی‌نفع درآورد. یکی از روش‌های ساده ولی مؤثر برای این کار مدل‌سازی Use Case است.
Use Case چیست؟
Use Case سناریویی است که در آن یک «کاربر» (یا یک سیستم دیگر) با سیستم ما تعامل می‌کند تا به هدفی مشخص برسد. ساده‌تر: توصیف می‌کند چه کسی، چه کاری را، چطور با سیستم انجام می‌دهد.
پنج عنصر اصلی دارد:
- کنش‌گر (Actor): کسی که با سیستم تعامل می‌کند، مثل کاربر، مدیر یا سیستم دیگر
- سیستم (System): چیزی که باید تحلیل و طراحی کنیم
- کاربرد (Use Case): کاری که کنش‌گر از سیستم می‌خواهد، مثل ثبت‌نام، گزارش‌گیری یا ارسال پیام
- سناریو (Scenario): دنباله‌ی گام‌ها برای رسیدن به هدف
- سناریوهای جایگزین (Alternative Flows): حالت‌های خاص یا خطاهایی که ممکن است پیش بیایند
یک مثال: ثبت‌نام آنلاین
کنش‌گر دانشجو است، سیستم سامانه‌ی آموزش دانشگاه، و کاربرد «ثبت‌نام دروس ترم جدید.» سناریوی اصلی این‌طور پیش می‌رود:
- دانشجو وارد سامانه می‌شود
- فهرست دروس نمایش داده می‌شود
- دانشجو درس‌ها را انتخاب می‌کند
- سیستم ظرفیت را بررسی می‌کند
- انتخاب‌ها ثبت می‌شوند
- پیام تأیید نمایش داده می‌شود
و سناریوی جایگزین: اگر ظرفیت درس پر باشد، پیام خطا داده می‌شود و دانشجو باید درس دیگری بردارد.
دیاگرام Use Case
برای مدل‌سازی بصری از دیاگرام استفاده می‌کنیم، معمولاً با Draw.io یا نرم‌افزارهای UML. بیضی برای کاربردها، آدمک برای کنش‌گرها، و خط برای ارتباط بین کنش‌گر و کاربرد. ساده‌ترین شکلش این است:
[دانشجو] ———> (ثبت‌نام دروس)
چرا مفید است؟
ساده است و برای همه‌ی ذی‌نفع‌ها قابل فهم، به کشف سناریوها و حالت‌های خاص کمک می‌کند، ارتباط تحلیل‌گر و طراح را راحت‌تر می‌کند، پایه‌ی طراحی تست (Test Case) می‌شود و برای سیستم‌های پیچیده‌تر هم قابل توسعه است. به نظرم قشنگی Use Case این است که به جای توصیف فنی، روی رفتار واقعی کاربر با سیستم تمرکز می‌کند و نیازمندی‌های عملکردی را شفاف و قابل سنجش نشان می‌دهد.
مرتبط: 15 آشنایی با ساختار سند نیازمندی‌ها (SRS) (بعد از مدل‌سازی، نیازها را در یک سند رسمی ثبت می‌کنیم).