فرض کنید قرار است برای یک فروشگاه اینترنتی، قابلیتی برای ثبت سفارش طراحی شود. اینکه بگوییم «کاربر باید بتواند سفارش ثبت کند» در نگاه اول کافی به نظر می‌رسد؛ اما برای طراحی و توسعه نرم‌افزار، هنوز سؤال‌های زیادی وجود دارد: کاربر از کجا شروع می‌کند؟ چه مراحلی را طی می‌کند؟ اگر محصول موجود نباشد چه اتفاقی می‌افتد؟ اگر پرداخت ناموفق باشد، سیستم چه رفتاری باید داشته باشد؟
اینجاست که یوزکیس (Use Case) اهمیت پیدا می‌کند.
یوزکیس روشی برای توصیف تعامل یک کاربر یا Actor با سیستم برای رسیدن به یک هدف مشخص است. در یک یوزکیس می‌توان مشخص کرد چه کسی با سیستم تعامل دارد، این تعامل چگونه آغاز می‌شود، جریان اصلی فعالیت‌ها چیست و در شرایط جایگزین یا خطا، سیستم چه رفتاری باید داشته باشد.
به همین دلیل، یوزکیس یکی از مفاهیم مهم در تحلیل و مستندسازی نرم‌افزار است و می‌تواند به اعضای مختلف تیم، از تحلیلگر و توسعه‌دهنده گرفته تا تستر نرم‌افزار، کمک کند رفتار مورد انتظار سیستم را بهتر درک کنند.
در این مقاله بررسی می‌کنیم یوزکیس چیست، چه اجزایی دارد، چگونه یک یوزکیس بنویسیم، Use Case Diagram چیست و یوزکیس چه تفاوتی با User Story و Test Case دارد. همچنین با یک مثال واقعی، نحوه استفاده از یوزکیس در یک پروژه نرم‌افزاری را بررسی خواهیم کرد.
یوزکیس (Use Case) چیست؟
یوزکیس (Use Case) روشی برای توصیف تعامل یک Actor با یک سیستم برای رسیدن به یک هدف مشخص است. در یک یوزکیس مشخص می‌شود کاربر یا یک سیستم دیگر چه کاری با نرم‌افزار انجام می‌دهد و نرم‌افزار در پاسخ به این تعامل چه رفتاری دارد.
برای مثال، در یک فروشگاه اینترنتی، «ثبت سفارش» می‌تواند یک یوزکیس باشد. مشتری به‌عنوان Actor وارد فرایند می‌شود، محصول موردنظر خود را انتخاب می‌کند، آن را به سبد خرید اضافه می‌کند، آدرس و روش پرداخت را مشخص می‌کند و در نهایت سفارش خود را ثبت می‌کند.
اما این فرایند همیشه به شکل ایده‌آل پیش نمی‌رود. ممکن است محصول موجود نباشد، پرداخت ناموفق باشد یا اطلاعات واردشده توسط کاربر معتبر نباشد. یک یوزکیس می‌تواند علاوه بر جریان اصلی (Main Flow)، این شرایط جایگزین و استثناها را نیز مشخص کند.
بنابراین، یوزکیس فقط فهرستی از قابلیت‌های نرم‌افزار نیست؛ بلکه تعامل بین Actor و سیستم و رفتار مورد انتظار سیستم در جریان این تعامل را توصیف می‌کند.
هدف از نوشتن یوزکیس چیست؟
هدف اصلی یوزکیس این است که تعاملات مهم بین کاربران یا سایر موجودیت‌های بیرونی و سیستم، به شکلی ساختاریافته و قابل فهم توصیف شود.
فرض کنید فقط در مستندات پروژه نوشته شده باشد:
«کاربر باید بتواند رمز عبور خود را بازیابی کند.»
این جمله هدف کلی را مشخص می‌کند، اما هنوز جزئیات زیادی روشن نیست. برای مثال:
- کاربر از کجا فرایند بازیابی را شروع می‌کند؟
- چه اطلاعاتی باید وارد کند؟
- سیستم چگونه هویت کاربر را بررسی می‌کند؟
- در صورت اشتباه بودن اطلاعات چه اتفاقی می‌افتد؟
- اگر کد بازیابی منقضی شده باشد چه می‌شود؟
- در پایان فرایند چه نتیجه‌ای باید حاصل شود؟
یوزکیس کمک می‌کند این تعامل و حالت‌های مختلف آن به شکل مشخص‌تری توصیف شوند.
به همین دلیل، یوزکیس می‌تواند در تحلیل نیازمندی‌ها، مستندسازی رفتار سیستم و درک سناریوهای قابل تست مورد استفاده قرار گیرد.
یوزکیس چه چیزی را توصیف می‌کند؟
هر یوزکیس معمولاً حول یک هدف مشخص شکل می‌گیرد و توضیح می‌دهد یک Actor چگونه با سیستم تعامل می‌کند تا به آن هدف برسد.
بسته به روش مستندسازی و نیاز پروژه، یک یوزکیس می‌تواند شامل مواردی مانند این‌ها باشد:
- Actor یا موجودیت تعامل‌کننده با سیستم
- هدف یوزکیس
- شرایط اولیه یا Preconditions
- رویداد آغازکننده یا Trigger
- جریان اصلی یا Main Flow
- جریان‌های جایگزین یا Alternative Flows
- شرایط استثنا یا Exception Flows
- نتیجه یا وضعیت نهایی
البته همه پروژه‌ها از یک قالب کاملاً یکسان برای نوشتن یوزکیس استفاده نمی‌کنند و میزان جزئیات آن می‌تواند بر اساس نوع پروژه، روش توسعه و نیاز تیم متفاوت باشد.
اجزای یوزکیس چیست؟
یک یوزکیس برای اینکه بتواند تعامل بین Actor و سیستم را به‌درستی توصیف کند، معمولاً از چند بخش تشکیل می‌شود. این بخش‌ها کمک می‌کنند مشخص شود چه کسی، با چه هدفی، تحت چه شرایطی و با طی کردن چه مراحلی با سیستم تعامل می‌کند.
البته قالب یوزکیس در همه پروژه‌ها یکسان نیست و ممکن است بسته به روش مستندسازی، نوع پروژه یا نیاز تیم، بعضی از این بخش‌ها حذف یا با جزئیات بیشتری نوشته شوند.
نام یوزکیس (Use Case Name)
نام یوزکیس باید کوتاه و مشخص باشد و معمولاً هدف یا فعالیت اصلی موردنظر را بیان کند.
برای مثال:
- ثبت سفارش
- ورود به حساب کاربری
- بازیابی رمز عبور
- لغو سفارش
- پرداخت قبض
بهتر است نام یوزکیس نشان‌دهنده یک هدف یا فعالیت مشخص باشد، نه صرفاً نام یک صفحه یا بخش از نرم‌افزار.
برای مثال، «صفحه پرداخت» نام مناسبی برای یوزکیس نیست، اما «پرداخت سفارش» هدف مشخصی را بیان می‌کند.
Actor
Actor فرد، سیستم یا موجودیت خارجی‌ای است که با سیستم موردنظر تعامل دارد تا یک هدف مشخص را دنبال کند.
برای مثال، در یوزکیس «ثبت سفارش»، مشتری می‌تواند Actor اصلی باشد. در یوزکیس «پرداخت سفارش» نیز ممکن است یک درگاه پرداخت خارجی با سیستم تعامل داشته باشد.
نکته مهم این است که Actor الزاماً یک انسان نیست؛ یک سیستم یا سرویس خارجی نیز می‌تواند Actor باشد.
Goal
Goal یا هدف مشخص می‌کند Actor از انجام این تعامل چه نتیجه‌ای می‌خواهد به دست آورد.
مثلاً در یوزکیس «بازیابی رمز عبور»، هدف Actor این است که بتواند دوباره به حساب کاربری خود دسترسی پیدا کند.
وجود یک هدف مشخص کمک می‌کند مرز یوزکیس را بهتر تعیین کنیم. اگر یک یوزکیس چند هدف کاملاً متفاوت را دنبال کند، ممکن است بهتر باشد آن را به چند یوزکیس مستقل تقسیم کنیم.
Preconditions
Precondition شرایطی است که قبل از شروع یوزکیس باید برقرار باشد.
برای مثال، برای یوزکیس «ثبت سفارش» ممکن است یکی از پیش‌شرط‌ها این باشد که کاربر وارد حساب خود شده باشد یا حداقل یک محصول در سبد خرید داشته باشد.
Precondition در واقع مشخص می‌کند یوزکیس از چه وضعیت اولیه‌ای آغاز می‌شود.
Trigger
Trigger رویداد یا اقدامی است که باعث شروع یوزکیس می‌شود.
برای مثال، در یوزکیس «بازیابی رمز عبور»، کاربر با انتخاب گزینه «رمز عبور را فراموش کرده‌ام» می‌تواند فرایند را آغاز کند.
Trigger ممکن است توسط Actor ایجاد شود یا در برخی سیستم‌ها یک رویداد خارجی یا حتی یک زمان مشخص باعث شروع فرایند شود.
Main Flow
Main Flow یا جریان اصلی، مسیر معمول و مورد انتظار تعامل بین Actor و سیستم است؛ یعنی حالتی که همه چیز طبق شرایط عادی پیش می‌رود.
برای مثال، در یوزکیس «ثبت سفارش» ممکن است جریان اصلی به این شکل باشد:
- کاربر محصولات موردنظر را انتخاب می‌کند.
- سیستم محصولات انتخاب‌شده را در سبد خرید نمایش می‌دهد.
- کاربر آدرس ارسال را انتخاب می‌کند.
- سیستم مبلغ نهایی سفارش را محاسبه می‌کند.
- کاربر روش پرداخت را انتخاب می‌کند.
- سیستم کاربر را به درگاه پرداخت هدایت می‌کند.
- پرداخت با موفقیت انجام می‌شود.
- سیستم سفارش را ثبت می‌کند.
- سیستم شماره سفارش را به کاربر نمایش می‌دهد.
Main Flow هسته اصلی یوزکیس است و باید مسیر رسیدن Actor به هدف را به شکلی روشن و قابل فهم نشان دهد.
Alternative Flow
همه کاربران الزاماً یک مسیر یکسان را طی نمی‌کنند. Alternative Flow مسیرهای دیگری است که در شرایط خاص می‌توانند جایگزین بخشی از جریان اصلی شوند، بدون اینکه لزوماً هدف اصلی یوزکیس از بین برود.
برای مثال، در فرایند ثبت سفارش، کاربر ممکن است به جای استفاده از یک آدرس قبلی، گزینه «افزودن آدرس جدید» را انتخاب کند.
در این حالت، فرایند ثبت سفارش همچنان ادامه پیدا می‌کند، اما مسیر رسیدن به هدف با Main Flow متفاوت است.
Exception Flow
Exception Flow به شرایط غیرعادی یا خطاهایی مربوط می‌شود که باعث می‌شوند جریان معمول یوزکیس تغییر کند یا متوقف شود.
برای مثال:
- پرداخت ناموفق باشد.
- محصول دیگر موجود نباشد.
- ارتباط با سرویس پرداخت قطع شود.
- کد تأیید منقضی شده باشد.
در چنین شرایطی باید مشخص شود سیستم چه رفتاری انجام می‌دهد و Actor چه نتیجه‌ای دریافت می‌کند.
تفاوت Alternative Flow و Exception Flow همیشه در همه متدولوژی‌ها با یک تعریف کاملاً یکسان بیان نمی‌شود، اما در بسیاری از مستندات، Alternative Flow برای مسیرهای معتبر و متفاوت و Exception Flow برای شرایط خطا یا استثنایی استفاده می‌شود.
Postconditions
Postcondition وضعیت مورد انتظار سیستم پس از پایان یوزکیس را مشخص می‌کند.
برای مثال، اگر یوزکیس «ثبت سفارش» با موفقیت انجام شود، می‌توان انتظار داشت:
- سفارش ایجاد شده باشد.
- وضعیت سفارش مشخص شده باشد.
- اطلاعات سفارش در سیستم ذخیره شده باشد.
- شماره سفارش به کاربر نمایش داده شده باشد.
Postcondition کمک می‌کند مشخص شود پس از پایان یوزکیس، سیستم باید در چه وضعیتی قرار داشته باشد.
در نتیجه، اگر بخواهیم ساختار یک یوزکیس را به‌صورت خلاصه ببینیم، می‌توانیم آن را این‌طور در نظر بگیریم:
Actor → Goal → Trigger → Main Flow → Alternative / Exception Flows → Postcondition
این اجزا باعث می‌شوند یوزکیس از یک توضیح کلی درباره قابلیت نرم‌افزار فراتر برود و به یک توصیف روشن از تعامل Actor با سیستم برای رسیدن به یک هدف مشخص تبدیل شود.
یک مثال کامل از یوزکیس
برای اینکه مفهوم یوزکیس بهتر روشن شود، بهتر است یک نمونه واقعی را از ابتدا تا انتها بررسی کنیم. فرض کنید در یک فروشگاه اینترنتی، کاربر می‌تواند محصولات موردنظر خود را انتخاب کرده و سفارش خود را ثبت کند.
در این مثال، یوزکیس با عنوان «ثبت سفارش» تعریف می‌شود.
مشخصات یوزکیس ثبت سفارش
نام یوزکیس: ثبت سفارش
Actor اصلی: مشتری
هدف: ثبت یک سفارش برای محصولات انتخاب‌شده
Trigger: انتخاب گزینه «ثبت سفارش»
Precondition: کاربر وارد حساب کاربری شده و حداقل یک محصول در سبد خرید دارد.
Main Flow؛ جریان اصلی
در حالت عادی، فرایند می‌تواند به شکل زیر پیش برود:
- مشتری سبد خرید خود را مشاهده می‌کند.
- سیستم محصولات و مبلغ سفارش را نمایش می‌دهد.
- مشتری آدرس ارسال را انتخاب می‌کند.
- سیستم هزینه ارسال و مبلغ نهایی را محاسبه می‌کند.
- مشتری روش پرداخت را انتخاب می‌کند.
- سیستم اطلاعات سفارش را نمایش می‌دهد.
- مشتری پرداخت را تأیید می‌کند.
- سیستم کاربر را به درگاه پرداخت هدایت می‌کند.
- پرداخت با موفقیت انجام می‌شود.
- سیستم سفارش را ثبت می‌کند.
- سیستم شماره سفارش را به مشتری نمایش می‌دهد.
در این جریان، هدف اصلی یعنی ثبت موفق سفارش محقق شده است.
Alternative Flow؛ جریان جایگزین
فرض کنید مشتری در مرحله انتخاب آدرس، تصمیم می‌گیرد آدرس جدیدی وارد کند.
در این حالت، می‌توان مسیر جایگزین را این‌گونه تعریف کرد:
- مشتری گزینه «افزودن آدرس جدید» را انتخاب می‌کند.
- سیستم فرم ثبت آدرس را نمایش می‌دهد.
- مشتری اطلاعات آدرس را وارد می‌کند.
- سیستم آدرس را ذخیره می‌کند.
- فرایند ثبت سفارش از مرحله انتخاب آدرس ادامه پیدا می‌کند.
در اینجا اتفاق غیرعادی یا خطایی رخ نداده است؛ فقط کاربر مسیر متفاوتی را برای رسیدن به همان هدف انتخاب کرده است.
Exception Flow؛ جریان استثنا
حالا فرض کنید پرداخت مشتری ناموفق باشد.
در این شرایط:
- درگاه پرداخت نتیجه ناموفق بودن تراکنش را به سیستم اعلام می‌کند.
- سیستم سفارش را در وضعیت مناسب قرار می‌دهد.
- پیام شکست پرداخت به مشتری نمایش داده می‌شود.
- مشتری می‌تواند دوباره برای پرداخت اقدام کند یا فرایند را ترک کند.
این نمونه نشان می‌دهد که یک یوزکیس فقط مسیر ایده‌آل را توصیف نمی‌کند؛ بلکه می‌تواند رفتار سیستم را در شرایط مختلف نیز مشخص کند.
Postcondition؛ وضعیت نهایی
اگر پرداخت با موفقیت انجام شده باشد، پس از پایان یوزکیس:
- سفارش در سیستم ثبت شده است.
- اطلاعات سفارش ذخیره شده است.
- یک شماره سفارش ایجاد شده است.
- وضعیت سفارش مشخص شده است.
- نتیجه ثبت سفارش به مشتری اعلام شده است.
بنابراین، وقتی یک یوزکیس به‌صورت کامل نوشته می‌شود، تیم پروژه فقط نمی‌داند «قابلیت ثبت سفارش وجود دارد»؛ بلکه می‌داند چه کسی، با چه هدفی، از چه مسیری و تحت چه شرایطی با سیستم تعامل می‌کند و سیستم در پایان چه وضعیتی باید داشته باشد.
چرا این مثال مهم است؟
همین یوزکیس می‌تواند مبنایی برای فعالیت‌های بعدی تیم باشد. تحلیلگر می‌تواند رفتار مورد انتظار سیستم را بررسی کند، توسعه‌دهنده می‌تواند منطق موردنیاز را بهتر درک کند و تستر نیز می‌تواند از جریان‌های مختلف یوزکیس برای شناسایی سناریوهای قابل تست استفاده کند.
به این ترتیب، یوزکیس می‌تواند مانند یک نقطه اتصال میان نیاز کسب‌وکار، رفتار سیستم و فعالیت‌های توسعه و تست عمل کند.
Use Case Diagram چیست؟
تا اینجا یوزکیس را به‌عنوان یک توصیف متنی از تعامل Actor با سیستم بررسی کردیم. اما گاهی لازم است همین تعاملات را به شکل تصویری نمایش دهیم تا ارتباط میان کاربران، سیستم و قابلیت‌های مختلف آن سریع‌تر قابل درک باشد. اینجاست که Use Case Diagram یا «نمودار یوزکیس» کاربرد پیدا می‌کند.
Use Case Diagram یکی از نمودارهای UML (Unified Modeling Language) است که برای نمایش Actorها، یوزکیس‌ها و ارتباط میان آن‌ها استفاده می‌شود.
برای مثال، در یک فروشگاه اینترنتی ممکن است مشتری بتواند:
- وارد حساب کاربری شود.
- محصولات را جست‌وجو کند.
- محصولی را به سبد خرید اضافه کند.
- سفارش ثبت کند.
- سفارش را پرداخت کند.
در Use Case Diagram می‌توان این تعاملات را در کنار Actor مربوط به آن‌ها نمایش داد تا محدوده سیستم و ارتباط کاربران با قابلیت‌های آن مشخص شود.
اجزای اصلی Use Case Diagram
یک Use Case Diagram معمولاً از چند عنصر اصلی تشکیل می‌شود.
Actor
Actor موجودیتی بیرونی است که با سیستم تعامل دارد. Actor می‌تواند یک کاربر، سازمان، سیستم دیگر یا یک سرویس خارجی باشد.
برای مثال در فروشگاه اینترنتی:
Customer می‌تواند یک Actor باشد و Payment Gateway نیز می‌تواند یک Actor خارجی باشد.
Use Case
Use Case معمولاً با یک بیضی نمایش داده می‌شود و یک هدف یا قابلیت مشخص سیستم را نشان می‌دهد.
برای مثال:
- Login
- Search Product
- Add to Cart
- Place Order
- Make Payment
هر یوزکیس باید یک تعامل یا هدف معنادار را نشان دهد، نه صرفاً یک صفحه یا جزء داخلی سیستم.
System Boundary
System Boundary محدوده سیستمی را که قرار است مدل شود مشخص می‌کند. معمولاً یوزکیس‌ها داخل این محدوده قرار می‌گیرند و Actorها بیرون آن نمایش داده می‌شوند.
این مرزبندی کمک می‌کند مشخص شود چه چیزی بخشی از سیستم موردنظر است و چه چیزی در خارج از آن قرار دارد.
Association
Association ارتباط میان Actor و یوزکیس را نشان می‌دهد.
برای مثال، اگر مشتری بتواند سفارش ثبت کند، ارتباط میان Actor «Customer» و یوزکیس «Place Order» نمایش داده می‌شود.
یک نمونه ساده
فرض کنید سیستم یک فروشگاه آنلاین را مدل می‌کنیم:
Customer می‌تواند با یوزکیس‌های زیر تعامل داشته باشد:
- Login
- Search Product
- Add to Cart
- Place Order
در هنگام پرداخت نیز سیستم می‌تواند با یک Payment Gateway خارجی تعامل داشته باشد.
در نتیجه، نمودار به ما کمک می‌کند بدون ورود به جزئیات جریان هر یوزکیس، یک تصویر کلی از Actorها، قابلیت‌های موردنظر و ارتباط میان آن‌ها داشته باشیم.
نکته مهم این است که Use Case Diagram جایگزین توضیحات متنی یوزکیس نیست. نمودار یک نمای کلی از تعاملات ارائه می‌دهد، در حالی که مشخصات متنی یوزکیس می‌تواند جزئیات جریان اصلی، مسیرهای جایگزین و شرایط استثنا را توضیح دهد.
در ادامه، برای کامل‌تر شدن این تصویر، باید با چهار رابطه مهم در Use Case Diagram یعنی Association، Include، Extend و Generalization آشنا شویم.
روابط در Use Case Diagram
در یک Use Case Diagram، فقط نمایش Actor و یوزکیس کافی نیست؛ گاهی لازم است رابطه میان یوزکیس‌ها یا میان Actorها نیز مشخص شود. در UML، چند نوع رابطه برای این منظور وجود دارد که مهم‌ترین آن‌ها Association، Include، Extend و Generalization هستند.
شناخت این روابط اهمیت زیادی دارد، چون استفاده نادرست از آن‌ها می‌تواند نمودار را پیچیده و حتی گمراه‌کننده کند.
Association چیست؟
Association ساده‌ترین رابطه در Use Case Diagram است و نشان می‌دهد یک Actor با یک یوزکیس تعامل دارد.
برای مثال، در یک فروشگاه اینترنتی:
Customer → Place Order
یعنی مشتری با یوزکیس «ثبت سفارش» تعامل دارد.
این رابطه معمولاً با یک خط ساده بین Actor و یوزکیس نمایش داده می‌شود و لزوماً به این معنی نیست که Actor تمام جزئیات اجرای یوزکیس را انجام می‌دهد؛ فقط نشان‌دهنده وجود تعامل است.
Include در یوزکیس چیست؟
رابطه Include زمانی استفاده می‌شود که یک یوزکیس برای انجام شدن، همیشه به اجرای یک رفتار یا یوزکیس دیگر نیاز داشته باشد.
فرض کنید یوزکیس اصلی ثبت سفارش باشد و سیستم برای ثبت سفارش، همیشه نیاز داشته باشد که احراز هویت کاربر را انجام دهد.
می‌توان این رابطه را به شکل زیر در نظر گرفت:
Place Order → Include → Authenticate User
در این حالت، رفتار مربوط به احراز هویت بخشی از فرایند ثبت سفارش است و هر بار که یوزکیس اصلی اجرا می‌شود، یوزکیس شامل‌شده نیز اجرا خواهد شد.
یکی از کاربردهای Include این است که یک رفتار مشترک را به جای تکرار در چند یوزکیس، در یک یوزکیس مستقل تعریف کنیم.
برای مثال:
- Place Order → Include → Authenticate User
- View Order → Include → Authenticate User
- Cancel Order → Include → Authenticate User
در اینجا رفتار مشترک Authenticate User می‌تواند یک بار تعریف شود و چند یوزکیس از آن استفاده کنند.
Extend در یوزکیس چیست؟
رابطه Extend زمانی کاربرد دارد که یک یوزکیس بتواند در شرایط مشخص، رفتار دیگری را به جریان خود اضافه کند؛ یعنی رفتار اضافه‌شده بخشی از مسیر اصلی و همیشگی نیست.
مثلاً فرض کنید یوزکیس اصلی ثبت سفارش باشد و در شرایط خاص، سیستم امکان استفاده از کد تخفیف را در اختیار کاربر قرار دهد.
می‌توان چنین رابطه‌ای را در نظر گرفت:
Apply Discount Code → Extend → Place Order
در این حالت، ثبت سفارش بدون استفاده از کد تخفیف نیز امکان‌پذیر است؛ اما اگر شرایط لازم برقرار باشد، رفتار مربوط به کد تخفیف می‌تواند به جریان اصلی اضافه شود.
بنابراین، یکی از راه‌های ساده برای درک تفاوت Include و Extend این است:
- Include: رفتار دیگری برای اجرای یوزکیس اصلی موردنیاز است.
- Extend: رفتار دیگری می‌تواند در شرایط مشخص به یوزکیس اصلی اضافه شود.
Generalization در یوزکیس چیست؟
Generalization برای نشان دادن رابطه تعمیم و تخصص بین Actorها یا یوزکیس‌ها استفاده می‌شود.
برای مثال، فرض کنید در یک سیستم دو نوع کاربر داشته باشیم:
- Customer
- Premium Customer
می‌توان Customer را Actor عمومی و Premium Customer را Actor تخصص‌یافته در نظر گرفت که ویژگی‌ها یا تعاملات بیشتری دارد.
Generalization فقط محدود به Actorها نیست و در شرایط مناسب می‌تواند میان یوزکیس‌ها نیز مورد استفاده قرار گیرد.
تفاوت Include و Extend در یک نگاه
| Include | Extend |
|---|---|
| برای رفتار موردنیاز و مشترک استفاده می‌شود. | برای رفتار اضافی و وابسته به شرایط استفاده می‌شود. |
| یوزکیس اصلی به رفتار شامل‌شده وابسته است. | یوزکیس اصلی می‌تواند بدون رفتار اضافه‌شده نیز اجرا شود. |
| برای جلوگیری از تکرار یک رفتار مشترک مناسب است. | برای مدل‌سازی رفتارهای اختیاری یا شرطی مناسب است. |
| اجرای یوزکیس شامل‌شده بخشی از جریان موردنظر است. | رفتار Extend فقط در شرایط مشخص وارد جریان می‌شود. |
البته نباید فقط بر اساس «اختیاری یا اجباری بودن» درباره این روابط تصمیم گرفت؛ مهم‌تر از آن، معنای رابطه و وابستگی رفتاری میان دو یوزکیس است.
در نتیجه، هنگام طراحی Use Case Diagram بهتر است فقط برای زیباتر شدن نمودار از Include یا Extend استفاده نکنیم. هر رابطه باید نشان‌دهنده یک ارتباط واقعی و معنادار میان رفتارهای سیستم باشد.
چگونه یک یوزکیس (Use Case) بنویسیم؟
نوشتن یوزکیس فقط پر کردن چند فیلد در یک قالب مشخص نیست. مهم‌تر از قالب، این است که هدف Actor، تعامل او با سیستم و رفتار مورد انتظار سیستم به‌درستی شناسایی و مستند شود.
برای نوشتن یک یوزکیس می‌توان از مراحل زیر استفاده کرد.
۱. هدف یوزکیس را مشخص کنید
ابتدا مشخص کنید Actor قرار است با استفاده از سیستم به چه هدفی برسد.
مثلاً:
- ثبت سفارش
- دریافت گزارش فروش
- بازیابی رمز عبور
- رزرو نوبت
- انتقال وجه
هدف باید مشخص و قابل تشخیص باشد. بهتر است یک یوزکیس چند هدف کاملاً متفاوت را با هم ترکیب نکند.
۲. Actor را مشخص کنید
مشخص کنید چه فرد، سیستم یا موجودیت خارجی‌ای برای رسیدن به این هدف با نرم‌افزار تعامل دارد.
برای مثال، در یوزکیس «رزرو نوبت پزشکی»:
Actor اصلی: بیمار
اما ممکن است یک سیستم پرداخت یا سامانه پیامک نیز به‌عنوان Actor خارجی در این فرایند حضور داشته باشد.
در این مرحله باید بین Actor اصلی و سایر موجودیت‌های درگیر تمایز قائل شد. Actor اصلی معمولاً همان موجودیتی است که هدف یوزکیس را دنبال می‌کند.
۳. Trigger را مشخص کنید
مشخص کنید چه رویدادی باعث شروع یوزکیس می‌شود.
برای مثال:
بیمار گزینه «رزرو نوبت» را انتخاب می‌کند.
یا:
سیستم در زمان مشخص، فرایند ارسال گزارش روزانه را آغاز می‌کند.
Trigger کمک می‌کند نقطه شروع تعامل مشخص باشد.
۴. Preconditions را تعیین کنید
در این مرحله مشخص می‌کنیم قبل از شروع یوزکیس چه شرایطی باید برقرار باشد.
مثلاً برای رزرو نوبت:
- کاربر وارد حساب خود شده است.
- پزشک موردنظر در سیستم وجود دارد.
- زمان‌های قابل رزرو در سیستم ثبت شده‌اند.
البته نباید هر پیش‌فرضی را به‌عنوان Precondition وارد کنیم. فقط شرایطی را مشخص کنید که واقعاً برای شروع یوزکیس ضروری هستند.
۵. Main Flow را بنویسید
حالا مسیر اصلی را مرحله‌به‌مرحله بنویسید.
برای مثال:
- بیمار پزشک موردنظر را انتخاب می‌کند.
- سیستم زمان‌های آزاد را نمایش می‌دهد.
- بیمار یک زمان را انتخاب می‌کند.
- سیستم اطلاعات نوبت را نمایش می‌دهد.
- بیمار رزرو را تأیید می‌کند.
- سیستم نوبت را ثبت می‌کند.
- سیستم نتیجه رزرو را به بیمار نمایش می‌دهد.
در این قسمت بهتر است هر مرحله یک تعامل مشخص بین Actor و سیستم را بیان کند و از وارد کردن جزئیات فنی غیرضروری خودداری شود.
۶. Alternative Flow و Exception Flow را بررسی کنید
بعد از نوشتن مسیر اصلی، بررسی کنید چه مسیرهای دیگری ممکن است رخ دهد.
Alternative Flow: بیمار به‌جای انتخاب زمان پیشنهادی، گزینه «مشاهده زمان‌های بیشتر» را انتخاب می‌کند.
Exception Flow: زمان انتخاب‌شده توسط بیمار در همان لحظه توسط فرد دیگری رزرو شده است.
این مرحله اهمیت زیادی دارد، چون بسیاری از رفتارهای مهم سیستم فقط در حالت ایده‌آل مشخص نمی‌شوند.
۷. Postconditions را مشخص کنید
در پایان مشخص کنید اگر یوزکیس با موفقیت اجرا شود، سیستم باید در چه وضعیتی قرار داشته باشد.
برای مثال:
یک نوبت برای بیمار ثبت شده و وضعیت آن در سیستم مشخص شده است.
اگر یوزکیس با خطا پایان پیدا کند، ممکن است وضعیت نهایی متفاوت باشد و این موضوع نیز در صورت نیاز مستند شود.
۸. یوزکیس را با ذی‌نفعان بررسی کنید
در نهایت یوزکیس باید با افرادی که در شناخت و تأیید نیازمندی نقش دارند بررسی شود.
هدف این بررسی این است که مشخص شود:
- آیا هدف یوزکیس درست تعریف شده است؟
- آیا Actorها درست شناسایی شده‌اند؟
- آیا Main Flow با رفتار مورد انتظار کسب‌وکار مطابقت دارد؟
- آیا شرایط جایگزین و استثناهای مهم پوشش داده شده‌اند؟
- آیا نتیجه نهایی یوزکیس مشخص است؟
این بررسی می‌تواند از سوءتفاهم‌هایی جلوگیری کند که اگر تا مرحله توسعه یا تست باقی بمانند، اصلاح آن‌ها دشوارتر خواهد بود.
یک نکته مهم در نوشتن یوزکیس
یوزکیس نباید به دستورالعمل فنی برای پیاده‌سازی نرم‌افزار تبدیل شود.
برای مثال، معمولاً نیازی نیست در Main Flow بنویسیم:
سیستم رکورد کاربر را در جدول
usersجست‌وجو می‌کند و سپس متدvalidateToken()را اجرا می‌کند.
این نوع جزئیات به نحوه پیاده‌سازی مربوط می‌شود. یوزکیس بهتر است روی هدف Actor و رفتار قابل مشاهده و مورد انتظار سیستم تمرکز کند.
به بیان ساده، یک یوزکیس خوب باید به این سؤال پاسخ دهد:
چه کسی می‌خواهد چه کاری انجام دهد و سیستم برای رسیدن به این هدف چگونه باید رفتار کند؟
تفاوت یوزکیس (Use Case) و User Story چیست؟
یوزکیس (Use Case) و داستان کاربر(User Story) هر دو برای توصیف نیازها و رفتار مورد انتظار نرم‌افزار استفاده می‌شوند، اما هدف و میزان جزئیات آن‌ها یکسان نیست.
User Story معمولاً نیاز را از دید کاربر و به شکل کوتاه بیان می‌کند. در مقابل، یوزکیس می‌تواند تعامل کاربر با سیستم را با جزئیات بیشتری، از شرایط اولیه تا جریان اصلی و مسیرهای جایگزین و استثنا، توصیف کند.
برای مثال، یک User Story می‌تواند این باشد:
«به‌عنوان یک مشتری، می‌خواهم بتوانم سفارش خود را به‌صورت آنلاین پرداخت کنم تا سفارش من ثبت شود.»
این جمله هدف و ارزش موردنظر کاربر را مشخص می‌کند، اما جزئیات تعامل را توضیح نمی‌دهد.
در یوزکیس مربوط به همین نیاز، می‌توان مشخص کرد:
- Actor چه کسی است؟
- چه چیزی فرایند را شروع می‌کند؟
- چه پیش‌شرط‌هایی وجود دارد؟
- جریان اصلی پرداخت چیست؟
- اگر پرداخت ناموفق باشد چه اتفاقی می‌افتد؟
- اگر تراکنش موفق باشد، سیستم چه وضعیتی پیدا می‌کند؟
مقایسه یوزکیس و User Story
| یوزکیس | User Story |
|---|---|
| تعامل Actor با سیستم را توصیف می‌کند. | یک نیاز یا قابلیت را از دید کاربر بیان می‌کند. |
| می‌تواند جزئیات زیادی داشته باشد. | معمولاً کوتاه و خلاصه است. |
| شامل Main Flow و در صورت نیاز Alternative و Exception Flow است. | معمولاً نیاز را در قالبی ساده و فشرده بیان می‌کند. |
| برای تحلیل و مستندسازی رفتار سیستم کاربرد دارد. | در روش‌های Agile برای بیان نیازهای کاربر بسیار رایج است. |
| می‌تواند برای سناریوهای پیچیده مناسب باشد. | برای بیان سریع و قابل فهم نیازهای محصول مناسب است. |
این دو مفهوم الزاماً رقیب یکدیگر نیستند و می‌توانند در یک پروژه در کنار هم استفاده شوند. برای مثال، یک User Story می‌تواند نیاز کاربر را در سطح کلی بیان کند و سپس در صورت نیاز، یک یوزکیس جزئیات تعامل مربوط به آن نیاز را مشخص کند.
بنابراین، انتخاب بین این دو به نوع پروژه، روش توسعه، پیچیدگی رفتار سیستم و میزان جزئیات موردنیاز تیم بستگی دارد.
اگر بخواهیم خیلی ساده تفاوت آن‌ها را بیان کنیم:
User Story بیشتر می‌گوید کاربر چه چیزی می‌خواهد و چرا؛ یوزکیس بیشتر توضیح می‌دهد کاربر و سیستم چگونه برای رسیدن به آن هدف با یکدیگر تعامل می‌کنند.
تفاوت یوزکیس (Use Case) و نیازمندی چیست؟
نیازمندی نرم‌افزار مشخص می‌کند نرم‌افزار چه نیاز، قابلیت یا محدودیتی را باید برآورده کند. یوزکیس یکی از روش‌هایی است که می‌توان با استفاده از آن، تعامل Actor با سیستم برای دستیابی به یک هدف را توصیف کرد.
به همین دلیل، یوزکیس و Requirement را نباید دو مفهوم کاملاً مشابه در نظر گرفت.
برای مثال، یک Requirement می‌تواند بیان کند:
«سیستم باید امکان ثبت سفارش آنلاین را برای مشتری فراهم کند.»
این نیازمندی مشخص می‌کند چه قابلیتی باید در سیستم وجود داشته باشد، اما جزئیات نحوه تعامل مشتری با سیستم را بیان نمی‌کند.
حالا می‌توان برای این نیازمندی یک یوزکیس با عنوان «ثبت سفارش» تعریف کرد و در آن مشخص کرد:
- Actor چه کسی است؟
- چه رویدادی فرایند را شروع می‌کند؟
- چه شرایطی قبل از شروع باید برقرار باشد؟
- جریان اصلی ثبت سفارش چگونه است؟
- در چه شرایطی مسیر فرایند تغییر می‌کند؟
- اگر پرداخت ناموفق باشد چه اتفاقی می‌افتد؟
- پس از پایان موفق فرایند، وضعیت سیستم چگونه خواهد بود؟
بنابراین، یوزکیس می‌تواند به جزئی‌تر کردن و قابل‌درک‌تر کردن یک بخش از نیازمندی‌ها کمک کند.
آیا هر Requirement یک یوزکیس دارد؟
خیر. همه Requirementها الزاماً به یک یوزکیس تبدیل نمی‌شوند.
برای مثال، این Requirement را در نظر بگیرید:
«سیستم باید اطلاعات کاربران را به‌صورت رمزنگاری‌شده ذخیره کند.»
این یک نیازمندی مهم است، اما الزاماً یک تعامل Actor با سیستم برای رسیدن به یک هدف مشخص را توصیف نمی‌کند؛ بنابراین ممکن است یوزکیس مستقیمی برای آن وجود نداشته باشد.
در مقابل، Requirementهایی که رفتار یا تعامل کاربر با سیستم را توصیف می‌کنند، معمولاً قابلیت مدل‌سازی با یوزکیس را دارند.
رابطه Requirement و یوزکیس چگونه است؟
می‌توان این رابطه را به‌صورت ساده این‌گونه در نظر گرفت:
Requirement → Use Case → جزئیات تعامل و رفتار سیستم
البته این رابطه همیشه یک‌به‌یک نیست. یک Requirement می‌تواند به چند یوزکیس مرتبط باشد و یک یوزکیس نیز ممکن است برای تحقق چند نیازمندی به کار رود.
به همین دلیل، در پروژه‌های واقعی بهتر است ارتباط میان نیازمندی‌ها و یوزکیس‌ها قابل ردیابی باشد؛ به‌خصوص در پروژه‌هایی که تعداد Requirementها و تعاملات سیستم زیاد است.
در نهایت، تفاوت اصلی این است که Requirement بیان‌کننده چیزی است که سیستم باید برآورده کند، در حالی که یوزکیس روشی برای توصیف یک تعامل مشخص با سیستم برای رسیدن به یک هدف است.
تفاوت یوزکیس (Use Case) و تست‌کیس (Test Case) چیست؟
با توجه به اینکه یوزکیس و تست‌کیس هر دو با رفتار سیستم سروکار دارند، گاهی این دو مفهوم با یکدیگر اشتباه گرفته می‌شوند. اما هدف و کاربرد آن‌ها متفاوت است.
یوزکیس برای توصیف تعامل یک Actor با سیستم و مشخص کردن رفتار مورد انتظار سیستم در مسیر رسیدن به یک هدف استفاده می‌شود؛ در حالی که Test Case برای بررسی و ارزیابی یک رفتار مشخص نرم‌افزار در شرایط معین طراحی می‌شود.
برای مثال، فرض کنید یک یوزکیس با عنوان «ورود کاربر» داریم.
در یوزکیس مشخص می‌کنیم که کاربر چگونه وارد سیستم می‌شود، سیستم اطلاعات ورود را بررسی می‌کند و در صورت معتبر بودن اطلاعات، کاربر وارد حساب خود می‌شود. همچنین می‌توان شرایطی مانند رمز عبور اشتباه یا حساب مسدودشده را نیز در نظر گرفت.
اما از همین رفتار می‌توان Test Caseهای مختلفی طراحی کرد.
یک یوزکیس می‌تواند به چند Test Case منجر شود
برای یوزکیس «ورود کاربر» می‌توان Test Caseهایی مانند این موارد داشت:
- ورود با نام کاربری و رمز عبور صحیح
- ورود با رمز عبور اشتباه
- ورود با نام کاربری نامعتبر
- ارسال فرم بدون وارد کردن اطلاعات
- تلاش برای ورود با حساب مسدودشده
در اینجا یوزکیس رفتار و تعامل مورد انتظار را توصیف می‌کند و Test Caseها بررسی می‌کنند که آیا نرم‌افزار در شرایط مشخص، همان رفتار مورد انتظار را دارد یا خیر.
مقایسه یوزکیس و Test Case
| یوزکیس | Test Case |
|---|---|
| تعامل Actor با سیستم را توصیف می‌کند. | نحوه بررسی یک رفتار مشخص سیستم را تعریف می‌کند. |
| بیشتر در تحلیل و مستندسازی رفتار سیستم کاربرد دارد. | در فعالیت‌های تست نرم‌افزار برای ارزیابی سیستم استفاده می‌شود. |
| می‌تواند Main Flow، Alternative Flow و Exception Flow داشته باشد. | معمولاً شامل شرایط اولیه، داده‌های تست، مراحل اجرا و نتیجه مورد انتظار است. |
| هدف آن توصیف رفتار مورد انتظار سیستم است. | هدف آن بررسی انطباق رفتار واقعی سیستم با نتیجه مورد انتظار است. |
| معمولاً از دید Actor و تعامل با سیستم نوشته می‌شود. | از دید فعالیت تست و شرایطی که باید بررسی شوند نوشته می‌شود. |
بنابراین، یوزکیس خودش Test Case نیست؛ اما می‌تواند یکی از منابع مهم برای شناسایی سناریوهای تست و طراحی Test Case باشد.
برای مثال:
یوزکیس: ورود کاربر
↓
سناریوهای مختلف تعامل
↓
Test Scenario
↓
Test Caseهای مشخص برای بررسی رفتار سیستم
البته طراحی Test Case فقط به یوزکیس محدود نمی‌شود و می‌تواند بر اساس Requirement، Acceptance Criteria، Test Scenario و سایر منابع نیز انجام شود.
به همین دلیل، اگر یک تیم تحلیل و تست به‌درستی با یکدیگر همکاری کنند، یوزکیس می‌تواند اطلاعات ارزشمندی برای شناسایی رفتارهایی که باید در تست بررسی شوند در اختیار تستر قرار دهد.
ارتباط یوزکیس (Use Case) با تست نرم‌افزار
یوزکیس مستقیماً یک سند تست نیست، اما می‌تواند اطلاعات ارزشمندی برای طراحی و پوشش سناریوهای تست در اختیار تستر قرار دهد. دلیل آن هم ساده است: یک یوزکیس رفتار سیستم را در شرایط مختلف توصیف می‌کند و هر یک از این مسیرها می‌تواند نقطه‌ای برای بررسی رفتار نرم‌افزار باشد.
برای مثال، فرض کنید یوزکیس مربوط به ثبت سفارش شامل این مسیرها باشد:
- جریان اصلی: سفارش با موفقیت ثبت می‌شود.
- جریان جایگزین: کاربر آدرس جدیدی اضافه می‌کند.
- جریان استثنا: پرداخت ناموفق است.
- جریان استثنا: محصول در زمان ثبت سفارش ناموجود می‌شود.
تستر می‌تواند این مسیرها را به‌عنوان ورودی برای شناسایی سناریوهای قابل تست در نظر بگیرد.
از یوزکیس چگونه سناریوی تست استخراج می‌شود؟
به‌صورت ساده می‌توان این ارتباط را چنین در نظر گرفت:
Use Case → Flowها و شرایط مختلف → Test Scenario → Test Case
برای مثال:
یوزکیس: ثبت سفارش
- سناریو ۱: ثبت موفق سفارش با پرداخت موفق
- سناریو ۲: ثبت سفارش با اضافه کردن آدرس جدید
- سناریو ۳: ثبت سفارش با پرداخت ناموفق
- سناریو ۴: تلاش برای ثبت سفارش با محصول ناموجود
هر کدام از این سناریوها می‌توانند به یک یا چند Test Case تبدیل شوند.
البته این به معنی آن نیست که تستر باید صرفاً یوزکیس‌ها را به Test Case تبدیل کند. Requirementها، Acceptance Criteria، Business Rules و سایر مستندات نیز می‌توانند منابع مهمی برای طراحی تست باشند.
یوزکیس چه کمکی به پوشش تست می‌کند؟
یکی از مزایای یوزکیس این است که تمرکز تستر فقط روی مسیر موفق باقی نمی‌ماند.
اگر در یوزکیس فقط Main Flow نوشته شده باشد، ممکن است توجه کمتری به شرایطی مانند خطا، ورودی نامعتبر یا مسیرهای جایگزین شود. اما وقتی Alternative Flow و Exception Flow نیز مستند شده باشند، تستر می‌تواند بررسی کند که آیا این شرایط نیز در تست‌ها پوشش داده شده‌اند یا خیر.
برای مثال، در یک یوزکیس پرداخت، فقط نباید بررسی شود که:
«کاربر با موفقیت پرداخت می‌کند.»
بلکه شرایطی مانند موارد زیر نیز ممکن است نیاز به بررسی داشته باشند:
- پرداخت ناموفق
- قطع ارتباط با درگاه
- منقضی شدن تراکنش
- بازگشت نتیجه نامعتبر از سرویس پرداخت
آیا یوزکیس برای تست End-to-End مناسب است؟
یوزکیس‌ها می‌توانند برای درک جریان‌های End-to-End نیز مفید باشند؛ به‌خصوص زمانی که یک هدف کاربر چند بخش مختلف سیستم را درگیر می‌کند.
برای مثال، یوزکیس «ثبت سفارش» ممکن است شامل تعامل با این بخش‌ها باشد:
رابط کاربری → سرویس سفارش → موجودی کالا → سرویس پرداخت → ثبت سفارش
این جریان می‌تواند به تست رفتار سیستم از دید کاربر کمک کند، اما انتخاب نوع و سطح تست باید بر اساس هدف تست و نیاز پروژه انجام شود.
در نتیجه، یوزکیس را می‌توان یکی از ورودی‌های مهم برای تحلیل تست‌پذیری و طراحی سناریوهای تست دانست، نه جایگزینی برای Test Case یا سایر مستندات تست.
یوزکیس (Use Case) در تحلیل نرم‌افزار چه نقشی دارد؟
یوزکیس یکی از ابزارهایی است که می‌تواند به تحلیلگر نرم‌افزار (Software Analyst) کمک کند تا رفتار مورد انتظار سیستم را از دید کاربران و سایر Actorها بهتر شناسایی و مستند کند.
در مرحله تحلیل، معمولاً فقط دانستن اینکه «سیستم چه قابلیتی باید داشته باشد» کافی نیست. باید مشخص شود کاربران چگونه از آن قابلیت استفاده می‌کنند، چه مسیرهایی ممکن است طی شود و سیستم در شرایط مختلف چه رفتاری باید داشته باشد.
برای مثال، فرض کنید نیازمندی یک سیستم فروشگاهی این باشد:
«مشتری باید بتواند سفارش خود را لغو کند.»
این جمله هدف کلی را مشخص می‌کند، اما هنوز پرسش‌های زیادی وجود دارد:
- چه کسی می‌تواند سفارش را لغو کند؟
- آیا همه سفارش‌ها قابل لغو هستند؟
- تا چه مرحله‌ای امکان لغو وجود دارد؟
- کاربر چگونه درخواست لغو را ثبت می‌کند؟
- اگر سفارش قبلاً ارسال شده باشد چه اتفاقی می‌افتد؟
- مبلغ پرداخت‌شده چگونه مدیریت می‌شود؟
- پس از لغو سفارش، وضعیت آن در سیستم چه خواهد بود؟
یوزکیس کمک می‌کند این پرسش‌ها به شکل ساختاریافته‌تری بررسی شوند.
یوزکیس برای Software Analyst
تحلیلگر نرم‌افزار می‌تواند از یوزکیس برای شناسایی و مستندسازی مواردی مانند این‌ها استفاده کند:
- Actorهای سیستم
- اهداف هر Actor
- تعاملات بین Actor و سیستم
- جریان‌های اصلی
- مسیرهای جایگزین
- شرایط استثنا
- پیش‌شرط‌ها و نتایج نهایی
- وابستگی میان برخی تعاملات
در نتیجه، یوزکیس می‌تواند بخشی از تصویر رفتاری سیستم را در اختیار تیم قرار دهد.
یوزکیس برای Business Analyst
یوزکیس فقط مخصوص تحلیلگر کسب‌وکار(Software Analyst) نیست. تحلیلگر کسب‌وکار نیز می‌تواند از آن برای تبدیل نیازهای کسب‌وکار به تعاملات قابل فهم‌تر با سیستم استفاده کند.
برای مثال، ممکن است یک نیاز کسب‌وکار این باشد:
«مشتری باید بتواند سفارش خود را قبل از ارسال لغو کند.»
Business Analyst می‌تواند با بررسی این نیاز و تعامل با Stakeholderها، شرایط و قوانین مربوط به لغو سفارش را شفاف‌تر کند.
سپس یوزکیس می‌تواند تعامل مشتری با سیستم و رفتار مورد انتظار نرم‌افزار را مستند کند.
البته مرز مسئولیت Business Analyst و Software Analyst در سازمان‌های مختلف یکسان نیست و ممکن است بسته به ساختار تیم، این فعالیت‌ها بین نقش‌های مختلف تقسیم شوند.
یوزکیس چگونه به Developer کمک می‌کند؟
یوزکیس می‌تواند دید روشن‌تری از رفتار مورد انتظار سیستم در اختیار توسعه‌دهنده قرار دهد.
برای مثال، وقتی جریان اصلی و شرایط استثنا مشخص شده باشند، توسعه‌دهنده فقط با یک جمله کلی مانند «امکان لغو سفارش وجود داشته باشد» مواجه نیست؛ بلکه می‌داند سیستم در شرایط مختلف چه رفتاری باید داشته باشد.
البته یوزکیس به‌تنهایی مشخصات فنی پیاده‌سازی را تعیین نمی‌کند و نباید با طراحی فنی سیستم اشتباه گرفته شود.
یوزکیس چگونه به Tester کمک می‌کند؟
تستر نیز می‌تواند از یوزکیس برای شناسایی رفتارهایی که باید بررسی شوند استفاده کند.
Main Flow می‌تواند مسیر موفق را مشخص کند و Alternative Flow و Exception Flow نیز شرایط دیگری را برای بررسی در اختیار تستر قرار دهند.
به این ترتیب، یوزکیس می‌تواند بین فعالیت‌های تحلیل، توسعه و تست یک نقطه اشتراک ایجاد کند.
یوزکیس در چرخه توسعه نرم‌افزار
اگر بخواهیم نقش آن را در یک جریان ساده نشان دهیم، می‌توانیم چنین مسیری را در نظر بگیریم:
Business Need → Requirement → Use Case → Development → Testing
این مسیر یک فرایند ثابت و اجباری برای همه پروژه‌ها نیست؛ اما نشان می‌دهد یوزکیس چگونه می‌تواند بین نیاز، رفتار مورد انتظار سیستم و فعالیت‌های توسعه و تست قرار بگیرد.
در نتیجه، ارزش اصلی یوزکیس در تحلیل نرم‌افزار این است که به تیم کمک می‌کند به جای تمرکز صرف بر فهرست قابلیت‌ها، رفتار سیستم را از منظر تعامل با Actorها بررسی و مستند کند.
چه زمانی از یوزکیس (Use Case) استفاده کنیم؟
یوزکیس زمانی مفید است که لازم باشد تعامل یک Actor با سیستم برای رسیدن به یک هدف مشخص به‌صورت دقیق‌تر بررسی و مستند شود. بنابراین، استفاده از آن بیشتر به پیچیدگی تعامل و نیاز پروژه به مستندسازی بستگی دارد، نه صرفاً به نوع نرم‌افزار.
وقتی یک فرایند چند مرحله دارد
اگر یک قابلیت با چند مرحله و تعامل مختلف انجام می‌شود، یوزکیس می‌تواند به شفاف شدن جریان کمک کند.
برای مثال، «ثبت سفارش» ممکن است شامل انتخاب محصول، بررسی موجودی، انتخاب آدرس، انتخاب روش پرداخت و دریافت نتیجه پرداخت باشد. در چنین شرایطی، توضیح این تعامل در قالب یوزکیس می‌تواند از یک توضیح کوتاه و کلی مفیدتر باشد.
وقتی مسیرهای جایگزین و خطا اهمیت دارند
اگر سیستم در شرایط مختلف رفتارهای متفاوتی دارد، یوزکیس می‌تواند این مسیرها را مستند کند.
برای مثال در فرایند ورود:
- ورود با اطلاعات صحیح
- وارد کردن رمز عبور اشتباه
- وارد کردن اطلاعات ناقص
- مسدود شدن حساب
- منقضی شدن کد تأیید
همگی می‌توانند بخشی از جریان‌های مختلف یک یوزکیس باشند.
وقتی چند Actor با یک سیستم تعامل دارند
در سیستم‌هایی که کاربران، سرویس‌های خارجی یا سیستم‌های دیگر با نرم‌افزار تعامل دارند، یوزکیس می‌تواند مشخص کند هر Actor چه هدفی دارد و چه تعاملی با سیستم انجام می‌دهد.
برای مثال در یک فروشگاه اینترنتی ممکن است Actorهای مختلفی مانند مشتری، مدیر فروشگاه و درگاه پرداخت وجود داشته باشند که هر کدام تعاملات متفاوتی با سیستم دارند.
وقتی تیم به مستندسازی رفتار سیستم نیاز دارد
یوزکیس می‌تواند برای مستندسازی رفتار سیستم در پروژه‌هایی که نیاز به تحلیل و مستندات دقیق‌تر دارند، مفید باشد.
این مستندات می‌توانند در طول پروژه برای تحلیلگران، توسعه‌دهندگان، تسترها و سایر اعضای تیم قابل استفاده باشند؛ به‌خصوص زمانی که لازم است درباره رفتار مورد انتظار سیستم در شرایط مختلف توافق مشترکی وجود داشته باشد.
آیا برای هر قابلیت باید یوزکیس نوشت؟
خیر. استفاده از یوزکیس برای هر قابلیت ساده‌ای لزوماً ضروری نیست.
اگر یک قابلیت بسیار ساده باشد و توضیح آن در قالب Requirement، User Story یا مستند دیگری کاملاً روشن باشد، ایجاد یک یوزکیس جداگانه ممکن است ارزش زیادی اضافه نکند.
برای مثال، اگر تنها نیاز سیستم این باشد که «کاربر بتواند زبان رابط کاربری را تغییر دهد»، ممکن است یک مستند کوتاه برای توضیح این نیاز کافی باشد.
در مقابل، برای فرایندهایی مانند ثبت سفارش، پرداخت، لغو سفارش، بازیابی حساب یا مدیریت درخواست‌های پیچیده که دارای چند مسیر و شرایط مختلف هستند، یوزکیس می‌تواند ارزش بیشتری داشته باشد.
بنابراین سؤال اصلی این نیست که:
«آیا این پروژه باید یوزکیس داشته باشد؟»
بلکه بهتر است پرسیده شود:
«آیا برای درک و مستندسازی این تعامل، یوزکیس ارزش ایجاد می‌کند؟»
این نگاه باعث می‌شود یوزکیس به یک مستند تشریفاتی تبدیل نشود و فقط در جایی استفاده شود که واقعاً به شفاف‌تر شدن رفتار سیستم کمک می‌کند.
آیا در Agile هم می‌توان از یوزکیس استفاده کرد؟
بله. استفاده از یوزکیس (Use Case) محدود به روش‌های سنتی توسعه نرم‌افزار نیست و می‌توان از آن در پروژه‌های Agile نیز استفاده کرد. تفاوت اصلی این است که در Agile معمولاً مستندات به اندازه‌ای تهیه می‌شوند که برای درک، توسعه و تست نیازمندی‌ها مفید باشند و از مستندسازی غیرضروری پرهیز شود.
در بسیاری از پروژه‌های Agile، User Story یکی از روش‌های رایج برای بیان نیازهای کاربر است. اما این موضوع به این معنا نیست که یوزکیس و User Story نمی‌توانند در یک پروژه در کنار یکدیگر استفاده شوند.
یوزکیس و User Story در Agile
برای مثال، یک User Story ممکن است چنین باشد:
به‌عنوان یک مشتری، می‌خواهم بتوانم سفارش خود را آنلاین لغو کنم تا در صورت تغییر تصمیم، سفارش برای من ارسال نشود.
این User Story نیاز و هدف کاربر را به‌صورت خلاصه بیان می‌کند.
اما اگر فرایند لغو سفارش پیچیده باشد، می‌توان از یوزکیس برای مشخص کردن جزئیات تعامل استفاده کرد؛ برای مثال:
- کاربر درخواست لغو را ثبت می‌کند.
- سیستم وضعیت سفارش را بررسی می‌کند.
- اگر سفارش هنوز ارسال نشده باشد، امکان لغو فراهم می‌شود.
- اگر سفارش ارسال شده باشد، سیستم درخواست لغو را نمی‌پذیرد.
- در صورت پرداخت قبلی، وضعیت بازگشت وجه مشخص می‌شود.
در این حالت، User Story می‌تواند نیاز را به شکل خلاصه بیان کند و یوزکیس جزئیات تعامل و مسیرهای مختلف را روشن‌تر کند.
آیا یوزکیس جایگزین User Story در Agile است؟
خیر. این دو ابزار الزاماً جایگزین یکدیگر نیستند.
User Story معمولاً برای بیان نیاز از دید کاربر و مدیریت آن در فرایند توسعه Agile استفاده می‌شود، در حالی که یوزکیس برای توصیف دقیق‌تر تعامل Actor و سیستم مناسب است.
در یک پروژه ممکن است فقط از User Story استفاده شود و در پروژه‌ای دیگر، برای برخی قابلیت‌های پیچیده‌تر از یوزکیس نیز استفاده شود.
چه زمانی یوزکیس در Agile مفیدتر است؟
یوزکیس می‌تواند در شرایطی ارزش بیشتری داشته باشد که:
- فرایند موردنظر چند مرحله داشته باشد.
- چند مسیر جایگزین یا استثنا وجود داشته باشد.
- چند Actor با سیستم تعامل داشته باشند.
- رفتار سیستم در شرایط مختلف نیاز به شفاف‌سازی داشته باشد.
- تیم برای تحلیل یا تست به جزئیات بیشتری از تعامل نیاز داشته باشد.
- لازم باشد رفتار یک قابلیت برای اعضای مختلف تیم مستند شود.
در مقابل، برای یک قابلیت ساده که با یک User Story و معیارهای پذیرش به‌خوبی قابل درک است، ایجاد یک یوزکیس کامل ممکن است ضرورتی نداشته باشد.
بنابراین، Agile بودن پروژه به معنی کنار گذاشتن یوزکیس نیست؛ بلکه مهم این است که مستندات متناسب با پیچیدگی و نیاز واقعی پروژه ایجاد شوند.
اشتباهات رایج در نوشتن یوزکیس
یوزکیس زمانی مفید است که بتواند رفتار مورد انتظار سیستم را به شکلی روشن و قابل استفاده برای تیم توصیف کند. با این حال، بعضی اشتباه‌ها باعث می‌شوند یوزکیس بیش از حد مبهم، طولانی یا فنی شود و کاربرد خود را از دست بدهد.
۱. نوشتن یوزکیس به شکل یک نیازمندی کلی
یکی از اشتباه‌های رایج این است که فقط یک قابلیت کلی نوشته شود و همان را یوزکیس در نظر بگیریم.
سیستم باید امکان ثبت سفارش را فراهم کند.
این جمله می‌تواند یک Requirement باشد، اما به‌تنهایی یک یوزکیس کامل نیست. در یوزکیس باید مشخص شود چه کسی، با چه هدفی و چگونه با سیستم تعامل می‌کند و در شرایط مختلف چه اتفاقی می‌افتد.
۲. تمرکز بیش از حد بر جزئیات فنی
یوزکیس باید رفتار قابل مشاهده و مورد انتظار سیستم را توضیح دهد، نه اینکه به دستورالعمل پیاده‌سازی تبدیل شود.
برای مثال، نوشتن عباراتی مانند:
سیستم متد
validateUser()را اجرا کرده و سپس جدولusersرا Query می‌کند.
جزئیات فنی پیاده‌سازی را وارد یوزکیس می‌کند.
بهتر است گفته شود:
سیستم اطلاعات کاربر را بررسی می‌کند و در صورت معتبر بودن اطلاعات، اجازه ورود را می‌دهد.
جزئیات فنی می‌تواند در مستندات طراحی یا فنی پروژه قرار گیرد.
۳. نادیده گرفتن Alternative Flow و Exception Flow
گاهی فقط مسیر موفق نوشته می‌شود:
کاربر وارد سیستم می‌شود → محصول را انتخاب می‌کند → پرداخت انجام می‌شود → سفارش ثبت می‌شود.
اما در دنیای واقعی، سیستم همیشه در شرایط ایده‌آل کار نمی‌کند.
مواردی مانند پرداخت ناموفق، اطلاعات نامعتبر، موجود نبودن محصول یا قطع ارتباط با یک سرویس خارجی می‌توانند بخش مهمی از رفتار سیستم باشند.
بنابراین، در یوزکیس‌های پیچیده باید مسیرهای جایگزین و استثناهای مهم نیز بررسی شوند.
۴. مشخص نکردن Actor
گاهی مشخص نیست چه کسی یا چه سیستمی تعامل را آغاز می‌کند.
برای مثال، عنوان «ثبت سفارش» به‌تنهایی مشخص نمی‌کند که این عملیات توسط مشتری، مدیر، یک سیستم خارجی یا Actor دیگری انجام می‌شود.
مشخص کردن Actor باعث می‌شود محدوده تعامل واضح‌تر باشد.
۵. ترکیب چند هدف متفاوت در یک یوزکیس
هر یوزکیس بهتر است یک هدف مشخص داشته باشد.
برای مثال، ساختن یک یوزکیس با عنوان:
مدیریت حساب کاربری
که هم شامل ثبت‌نام، ورود، تغییر رمز عبور، تغییر اطلاعات شخصی و حذف حساب باشد، می‌تواند بیش از حد گسترده شود.
در چنین شرایطی ممکن است بهتر باشد هر هدف مهم به‌عنوان یک یوزکیس جداگانه مستند شود.
۶. بیش از حد طولانی کردن یوزکیس
مستند کردن جزئیات به معنی اضافه کردن تمام اطلاعات ممکن نیست.
اگر یوزکیس آن‌قدر طولانی شود که پیدا کردن جریان اصلی یا شرایط استثنا دشوار باشد، احتمالاً باید ساختار آن بازبینی شود.
هدف این است که رفتار مهم و مورد نیاز برای درک تعامل مستند شود، نه اینکه هر جزئیات پروژه داخل یوزکیس قرار بگیرد.
۷. اشتباه گرفتن یوزکیس با User Story یا Test Case
یوزکیس، User Story و Test Case کاربردهای متفاوتی دارند.
User Story معمولاً نیاز کاربر را به شکل خلاصه بیان می‌کند، یوزکیس تعامل Actor و سیستم را توصیف می‌کند و Test Case برای بررسی یک رفتار مشخص طراحی می‌شود.
ممکن است این موارد به یکدیگر مرتبط باشند، اما یکی جایگزین دیگری نیست.
۸. استفاده از روابط Include و Extend بدون دلیل
در نمودار یوزکیس گاهی برای پیچیده‌تر یا حرفه‌ای‌تر نشان دادن نمودار، از روابط Include و Extend بیش از حد استفاده می‌شود.
این روابط باید زمانی استفاده شوند که واقعاً یک رابطه معنادار بین رفتارها وجود داشته باشد. اگر هر یوزکیس صرفاً برای ایجاد ساختار پیچیده‌تر به یوزکیس دیگری متصل شود، خوانایی نمودار کاهش پیدا می‌کند.
۹. نادیده گرفتن دیدگاه کاربر
یوزکیس باید حول هدف Actor و تعامل او با سیستم شکل بگیرد.
اگر متن بیشتر درباره ساختار دیتابیس، APIها، کلاس‌ها یا معماری نرم‌افزار باشد، احتمالاً از هدف اصلی یوزکیس فاصله گرفته‌ایم.
یک یوزکیس خوب باید به این سؤال پاسخ دهد:
Actor می‌خواهد به چه هدفی برسد و سیستم برای رسیدن به این هدف چگونه باید رفتار کند؟
در نتیجه، کیفیت یوزکیس بیشتر از اینکه به طول آن وابسته باشد، به شفافیت هدف، Actor، جریان تعامل و شرایط مختلف رفتار سیستم بستگی دارد.
Use Case Template چیست؟
Use Case Template یک قالب مشخص برای ثبت اطلاعات مربوط به یک یوزکیس است. استفاده از قالب باعث می‌شود یوزکیس‌های مختلف پروژه ساختار یکسانی داشته باشند و اعضای تیم بتوانند اطلاعات موردنیاز را راحت‌تر پیدا و بررسی کنند.
قالب یوزکیس می‌تواند بسته به پروژه، تیم یا متدولوژی متفاوت باشد و لازم نیست همه پروژه‌ها دقیقاً از یک Template استفاده کنند.
یک قالب استاندارد یوزکیس شامل چه بخش‌هایی است؟
یک Template رایج می‌تواند شامل بخش‌های زیر باشد:
| بخش | توضیح |
|---|---|
| Use Case Name | نام یوزکیس و هدف اصلی آن |
| Primary Actor | Actor اصلی که تعامل را برای رسیدن به هدف آغاز می‌کند |
| Goal | نتیجه‌ای که Actor می‌خواهد به آن برسد |
| Trigger | رویدادی که یوزکیس را آغاز می‌کند |
| Preconditions | شرایطی که قبل از شروع باید برقرار باشند |
| Main Flow | مسیر اصلی و معمول تعامل |
| Alternative Flow | مسیرهای جایگزین و معتبر |
| Exception Flow | شرایط خطا یا استثنا |
| Postconditions | وضعیت مورد انتظار سیستم پس از پایان یوزکیس |
| Business Rules | قوانین کسب‌وکار مرتبط، در صورت نیاز |
| Special Requirements | نیازمندی‌های خاص مرتبط با تعامل، در صورت نیاز |
همه این بخش‌ها برای تمام یوزکیس‌ها ضروری نیستند. بهتر است Template متناسب با نیاز واقعی پروژه طراحی شود.
نمونه Use Case Template
برای مثال، یک یوزکیس مربوط به ورود کاربر می‌تواند چنین ساختاری داشته باشد:
Use Case Name: ورود کاربر
Primary Actor: کاربر
Goal: ورود موفق کاربر به حساب کاربری
Trigger: کاربر فرم ورود را ارسال می‌کند.
Preconditions: کاربر قبلاً حساب کاربری ایجاد کرده باشد.
Main Flow:
- کاربر نام کاربری و رمز عبور را وارد می‌کند.
- سیستم اطلاعات واردشده را بررسی می‌کند.
- سیستم اعتبار اطلاعات را تأیید می‌کند.
- سیستم کاربر را وارد حساب کاربری می‌کند.
Alternative Flow: کاربر روش دیگری مانند ورود با کد یک‌بارمصرف را انتخاب می‌کند.
Exception Flow: اگر رمز عبور اشتباه باشد، سیستم پیام خطا نمایش می‌دهد و کاربر می‌تواند دوباره تلاش کند.
Postconditions: کاربر در صورت موفقیت وارد حساب خود شده است.
آیا همیشه باید از Template کامل استفاده کنیم؟
خیر. هدف Template این نیست که برای هر تعامل ساده، یک سند طولانی ایجاد شود.
برای یک قابلیت ساده ممکن است چند بخش اصلی مانند Actor، Goal، Trigger و Main Flow کافی باشد. اما برای فرایندهای پیچیده‌تر، اضافه کردن Alternative Flow، Exception Flow، Business Rules و سایر بخش‌ها می‌تواند به درک بهتر رفتار سیستم کمک کند.
بنابراین بهتر است Template به‌عنوان یک چارچوب قابل تنظیم در نظر گرفته شود، نه یک فرم اجباری که تمام بخش‌های آن باید در همه پروژه‌ها تکمیل شوند.
یوزکیس در SDLC چه نقشی دارد؟
یوزکیس می‌تواند در بخش‌های مختلف چرخه توسعه نرم‌افزار (SDLC) مورد استفاده قرار گیرد، اما نقش آن در همه پروژه‌ها و همه مراحل یکسان نیست. بیشترین کاربرد یوزکیس معمولاً در مرحله تحلیل و تعریف رفتار مورد انتظار سیستم است؛ با این حال، اطلاعات آن می‌تواند در مراحل بعدی نیز مورد استفاده قرار گیرد.
یوزکیس در مرحله تحلیل و تعریف نیازمندی‌ها
در این مرحله، تیم تلاش می‌کند مشخص کند سیستم چه نیازهایی را باید برآورده کند و کاربران چگونه با آن تعامل خواهند کرد.
یوزکیس می‌تواند به تحلیلگر کمک کند تا تعامل‌های مهم را شناسایی و برای هر تعامل، مواردی مانند Actor، هدف، جریان اصلی و شرایط جایگزین یا استثنا را مشخص کند.
برای مثال، در یک سیستم فروشگاهی ممکن است یوزکیس‌هایی مانند این موارد شناسایی شوند:
- ورود کاربر
- جستجوی محصول
- افزودن محصول به سبد خرید
- ثبت سفارش
- پرداخت سفارش
- لغو سفارش
در این مرحله، یوزکیس بیشتر به درک و مستندسازی رفتار مورد انتظار سیستم کمک می‌کند.
یوزکیس در مرحله طراحی و توسعه
یوزکیس مستقیماً طراحی فنی سیستم را تعیین نمی‌کند، اما می‌تواند اطلاعاتی درباره رفتار مورد انتظار در اختیار تیم توسعه قرار دهد.
برای مثال، اگر یوزکیس «ثبت سفارش» شامل بررسی موجودی، انتخاب روش پرداخت و ثبت نتیجه تراکنش باشد، توسعه‌دهنده می‌داند سیستم باید این تعامل‌ها و شرایط را پوشش دهد.
البته نحوه پیاده‌سازی این رفتار، مانند ساختار کلاس‌ها، APIها، دیتابیس یا معماری سیستم، موضوع طراحی فنی است و نباید با یوزکیس یکسان در نظر گرفته شود.
یوزکیس در مرحله تست
یوزکیس می‌تواند یکی از منابعی باشد که تستر برای شناسایی رفتارهای قابل بررسی از آن استفاده می‌کند.
Main Flow می‌تواند مسیر موفق را مشخص کند و Alternative Flow و Exception Flow نیز شرایط دیگری را برای طراحی سناریوهای تست نشان دهند.
برای مثال، از یوزکیس «پرداخت سفارش» می‌توان رفتارهایی مانند پرداخت موفق، پرداخت ناموفق و قطع ارتباط با درگاه را برای بررسی بیشتر شناسایی کرد.
البته یوزکیس تنها منبع طراحی تست نیست و تستر می‌تواند از Requirement، Acceptance Criteria، Test Scenario و سایر مستندات نیز استفاده کند.
یوزکیس در نگهداری و تغییرات نرم‌افزار
یوزکیس می‌تواند هنگام تغییر یک قابلیت موجود نیز مفید باشد.
فرض کنید در یک فروشگاه اینترنتی، امکان جدیدی اضافه شود که مشتری بتواند پس از ثبت سفارش، روش ارسال را تغییر دهد.
با بررسی یوزکیس‌های مرتبط می‌توان مشخص کرد این تغییر روی کدام جریان‌ها، شرایط جایگزین یا تعامل‌های موجود تأثیر می‌گذارد.
بنابراین، یوزکیس می‌تواند در درک تأثیر تغییرات روی رفتار سیستم نیز کاربرد داشته باشد.
یوزکیس در SDLC؛ از تحلیل تا تست
اگر بخواهیم نقش آن را به شکل ساده نمایش دهیم:
نیاز کسب‌وکار → تحلیل نیازمندی → یوزکیس → توسعه → طراحی و اجرای تست → بررسی رفتار سیستم
این زنجیره یک فرایند اجباری برای تمام پروژه‌ها نیست، اما نشان می‌دهد یوزکیس چگونه می‌تواند اطلاعاتی درباره رفتار سیستم را از مرحله تحلیل به فعالیت‌های بعدی منتقل کند.
در نتیجه، یوزکیس بیشتر از آنکه یک سند مخصوص یک مرحله خاص باشد، می‌تواند مرجع توصیف یک تعامل و هدف مشخص در سیستم باشد و در بخش‌های مختلف SDLC مورد استفاده قرار گیرد.
آیا یوزکیس هنوز در پروژه‌های نرم‌افزاری استفاده می‌شود؟
بله. یوزکیس همچنان یکی از روش‌های شناخته‌شده برای توصیف تعامل کاربران و سایر Actorها با سیستم است؛ اما نحوه استفاده از آن در پروژه‌های امروزی می‌تواند با توجه به نوع پروژه، متدولوژی توسعه و نیاز تیم متفاوت باشد.
در برخی پروژه‌ها، به‌ویژه پروژه‌هایی که فرایندهای پیچیده، تعاملات متعدد یا قوانین کسب‌وکار زیادی دارند، مستندسازی یوزکیس می‌تواند به ایجاد درک مشترک از رفتار سیستم کمک کند.
در مقابل، در بعضی تیم‌های Agile ممکن است به‌جای تهیه یوزکیس‌های مفصل، از ترکیبی از User Story، Acceptance Criteria و سایر مستندات سبک‌تر استفاده شود.
چرا هنوز از یوزکیس استفاده می‌شود؟
یکی از دلایل کاربرد یوزکیس این است که تمرکز آن بر هدف Actor و تعامل با سیستم است.
برای مثال، عبارت:
مشتری می‌تواند سفارش خود را لغو کند.
تنها قابلیت موردنظر را بیان می‌کند.
اما یوزکیس می‌تواند مشخص کند:
- چه کسی درخواست لغو را ایجاد می‌کند؟
- چه شرایطی قبل از لغو باید وجود داشته باشد؟
- اگر سفارش هنوز ارسال نشده باشد چه اتفاقی می‌افتد؟
- اگر سفارش قبلاً ارسال شده باشد چه می‌شود؟
- پس از لغو، وضعیت سفارش چگونه تغییر می‌کند؟
- در صورت پرداخت قبلی، چه رفتاری مورد انتظار است؟
این جزئیات در فرایندهای پیچیده می‌توانند برای تحلیل، توسعه و تست ارزشمند باشند.
آیا همه پروژه‌ها به یوزکیس نیاز دارند؟
خیر.
اگر یک سیستم یا قابلیت ساده باشد و نیازمندی‌ها با مستندات دیگری به‌خوبی قابل درک باشند، ممکن است ایجاد یوزکیس جداگانه ضروری نباشد.
همچنین در برخی تیم‌های Agile، ممکن است User Story و Acceptance Criteria برای توصیف نیاز و رفتار مورد انتظار کافی باشند.
بنابراین نمی‌توان گفت استفاده از یوزکیس همیشه بهتر است یا هر پروژه‌ای باید برای تمام قابلیت‌های خود یوزکیس داشته باشد.
یوزکیس در پروژه‌های مدرن چه جایگاهی دارد؟
امروزه بیشتر از اینکه سؤال این باشد که:
«آیا باید حتماً یوزکیس بنویسیم؟»
بهتر است پرسیده شود:
«برای این قابلیت، چه سطحی از مستندسازی برای درک درست رفتار سیستم لازم است؟»
اگر یک قابلیت ساده باشد، یک توضیح کوتاه یا User Story ممکن است کافی باشد. اگر تعامل پیچیده باشد، یوزکیس می‌تواند جزئیات بیشتری از جریان اصلی، مسیرهای جایگزین و شرایط استثنا ارائه کند.
بنابراین یوزکیس را می‌توان یک ابزار تحلیلی و مستندسازی قابل استفاده در کنار سایر روش‌ها دانست، نه روشی که متعلق به یک نسل خاص از فرایندهای توسعه نرم‌افزار باشد.
در عمل، انتخاب بین یوزکیس، User Story یا ترکیبی از آن‌ها باید بر اساس پیچیدگی سیستم، نیاز تیم به مستندسازی، نوع پروژه و شیوه کار سازمان انجام شود.
جمع‌بندی: یوزکیس چه کمکی به پروژه نرم‌افزاری می‌کند؟
یوزکیس روشی برای توصیف تعامل یک Actor با سیستم برای رسیدن به یک هدف مشخص است. برخلاف یک توضیح کلی درباره قابلیت‌های نرم‌افزار، یوزکیس تلاش می‌کند جریان تعامل، مسیرهای جایگزین و شرایط استثنا را نیز مشخص کند.
در این مقاله دیدیم که یک یوزکیس می‌تواند بخش‌هایی مانند Actor، Goal، Trigger، Preconditions، Main Flow، Alternative Flow، Exception Flow و Postconditions داشته باشد و در صورت نیاز، Business Rules یا سایر اطلاعات مرتبط نیز به آن اضافه شود.
همچنین نمودار یوزکیس (Use Case Diagram) امکان نمایش تصویری Actorها، یوزکیس‌ها و روابط میان آن‌ها را فراهم می‌کند و روابطی مانند Include، Extend و Generalization می‌توانند برای نمایش ارتباط‌های معنادار میان اجزای نمودار استفاده شوند.
یوزکیس در تحلیل نرم‌افزار می‌تواند به ایجاد درک مشترک میان Business Analyst، Software Analyst، Developer و Tester کمک کند. همچنین می‌تواند یکی از منابع شناسایی سناریوهای تست باشد؛ زیرا مسیر اصلی، مسیرهای جایگزین و شرایط استثنای یک تعامل را مشخص می‌کند.
از طرف دیگر، یوزکیس الزاماً جایگزین Requirement، User Story یا Test Case نیست. هرکدام هدف متفاوتی دارند و بسته به نیاز پروژه می‌توانند در کنار یکدیگر استفاده شوند.
در نهایت، مهم‌ترین نکته این است که یوزکیس را نباید صرفاً به‌عنوان یک فرم یا مستند اجباری در نظر گرفت. ارزش آن زمانی بیشتر می‌شود که بتواند به تیم کمک کند رفتار مورد انتظار سیستم و تعامل کاربران با آن را دقیق‌تر و قابل فهم‌تر مشخص کند.
منابع
- OMG – Unified Modeling Language Specification؛ مرجع استاندارد UML و مباحث مرتبط با Use Case و Use Case Diagram.
- OMG – Unified Modeling Language Specification, Version 1.5؛ مستندات ساختار و مفاهیم Use Case، Actor، Include و Extend.
- Microsoft Support – Create a UML Use Case Diagram؛ راهنمای عناصر و روابط اصلی در نمودار یوزکیس.
