Use Cases | موارد استفاده
مورد استفاده یا use case سناریوی مستندی است که نشان می‌دهد یک نقش کاربری چگونه با سیستم تعامل می‌کند تا به هدف مشخصی برسد: پیش‌شرط‌ها، گام‌ها، پاسخ سیستم، مسیرهای جایگزین و نتیجهٔ مورد انتظار. پل بین نیاز واقعی و طراحی و توسعه است؛ به‌جای فهرست ویژگی‌های جدا، داستانی ساختاریافته از «چه کسی چه کاری را تمام می‌کند» می‌سازد. ورود به حساب ساده است؛ رزرو پرواز با انتخاب صندلی و پرداخت پیچیده‌تر. این مدخل روی use case به‌عنوان روایت گام‌به‌گام تعامل سیستم تمرکز دارد—نه داستان کاربری یک‌خطی، نه صرفاً user flow بصری، و نه مورد آزمون خام بدون زمینهٔ هدف.
پل نیاز کاربر و رفتار سیستم
تیم‌ها وقتی ویژگی را جداگانه طراحی می‌کنند، سفر ناقص می‌سازند: جستجو هست اما جزئیات محصول با سبد هماهنگ نیست، یا سبد بدون مسیر پرداخت شفاف می‌ماند. use case این قطعه‌ها را در یک سناریوی کامل می‌چیند. برای خرید آنلاین، جستجو، صفحهٔ کالا، سبد و تسویه یک مورد استفادهٔ به‌هم‌پیوسته‌اند نه چهار پروژهٔ موازی بدون قرارداد مشترک.
در مدیریت محصول، use case به اولویت‌بندی کمک می‌کند: اگر سناریوی اصلی «تمدید اشتراک قبل از انقضا» است، هر ویژگی حاشیه که این مسیر را شلوغ کند زیر ذره‌بین می‌رود. در طراحی، زمینه برای وایرفریم و پروتوتایپ می‌سازد تا صفحه در انزوا قضاوت نشود.
تفاوت بنیادین با داستان کاربری
داستان کاربری کوتاه و هدف‌محور است: «به‌عنوان کاربر می‌خواهم رمز را بازنشانی کنم تا دوباره وارد شوم.» نیاز و انگیزه را فشرده می‌گوید، جزئیات سیستم را باز نمی‌کند. use case همان هدف را باز می‌کند: کاربر لینک فراموشی را می‌زند، سیستم ایمیل می‌فرستد، توکن منقضی می‌شود یا نمی‌شود، رمز جدید اعتبارسنجی می‌شود، جلسه ایجاد می‌شود یا خطا برمی‌گردد. ساختار، شرط و نتیجهٔ سیستم اینجا پررنگ است.
تیم چابک گاهی فقط با داستان جلو می‌رود و بعد در توسعه ابهام ظاهر می‌شود. افزودن use case برای جریان‌های پیچیده—پرداخت، مجوز، چندنقشه—ابهام را کم می‌کند بدون اینکه همه چیز را به سند سنگین آبشاری تبدیل کند. داستان برای برش ارزش و گفت‌وگوی بک‌لاگ است؛ use case برای وضوح تعامل و پوشش مسیرها.
اجزای قابل‌اتکای یک سند
نام و شناسه، بازیگر اصلی، هدف، پیش‌شرط، محرک شروع، جریان اصلی موفق، جریان‌های جایگزین و استثنا، پس‌شرط موفقیت، و گاهی قواعد کسب‌وکار. سطح جزئیات باید با مخاطب سند جور باشد: برای هم‌راستایی محصول و طراحی، گام‌های مفهومی کافی است؛ برای مهندسی و QA، شاخه‌های خطا و وضعیت داده مهم می‌شوند.
زیاده‌نویسی دشمن استفاده است. سندی که هیچ‌کس بازخوانی نمی‌کند ارزش ندارد. بهتر است چند use case حیاتی به‌روز بمانند تا ده‌ها صفحهٔ کهنه. مالک مشخص—معمولاً محصول‌منجر با مشارکت طراحی و فنی—از پوسیدگی سند جلوگیری می‌کند.
خوراک طراحی تجربه و جریان کاربر
use case زمینه می‌دهد؛ user flow ترتیب صفحه‌ها و تصمیم‌ها را تصویر می‌کند. اول سناریو را می‌نویسید تا بفهمید سیستم باید چه پاسخ‌هایی بدهد، بعد جریان را می‌کشید تا ببینید کاربر از کجا به کجا می‌رود. بدون سناریو، جریان ممکن است زیبا باشد اما هدف کسب‌وکار را گم کند. بدون جریان، سناریو روی کاغذ می‌ماند و اصطکاک رابط دیده نمی‌شود.
در نقد طراحی بپرسید: آیا این صفحه بخشی از کدام use case است؟ اگر جواب مبهم است، احتمال تزئین یا ویژگی یتیم بالاست. برای نمونه‌سازی، مسیر اصلی use case را کامل پوشش دهید؛ شاخه‌های نادر را در دور بعد.
توسعه، آزمون و ردیابی نیاز
توسعه‌دهنده از use case می‌فهمد رفتار مورد انتظار سیستم در هر گام چیست، نه فقط اینکه «باید دکمه داشته باشد». تیم کیفیت مستقیماً مورد آزمون می‌سازد: جستجوی پرواز، انتخاب صندلی، پرداخت ناموفق، انقضای نشست. ردیابی از سناریو تا تست ابهام را کم می‌کند و اختلاف «ما این را نمی‌دانستیم» را کاهش می‌دهد.
در یکپارچگی سیستم‌های چندخدمتی—مثلاً درگاه پرداخت و موجودی انبار—use case مرز مسئولیت را روشن می‌کند: اگر پرداخت موفق و رزرو موجودی ناموفق باشد، سیستم چه می‌کند؟ این شاخه‌ها اگر فقط در ذهن یک مهندس باشند، در تولید غافلگیر می‌کنند.
دسترس‌پذیری و تنوع شرایط کاربر
سناریوهایی بنویسید که فقط کاربر ایده‌آل موس‌به‌دست نباشند: ورودی صوتی، صفحه‌خوان، کنتراست بالا، قطعی شبکه میانهٔ پرداخت، یا کاربر با مجوز محدود. اگر use case فقط مسیر شاد کاربر حرفه‌ای را بگوید، شمول دیر و گران به پروژه اضافه می‌شود. گنجاندن این شاخه‌ها در همان سند اولیه، طراحی و پذیرش را از روز اول متعهد می‌کند.
همین منطق برای نقش‌های مختلف است: مدیر، عضو مهمان، نمایندهٔ پشتیبانی. یک هدف واحد ممکن است چند use case با بازیگر متفاوت بخواهد، چون مجوز و داده فرق می‌کند.
هم‌زبانی ذی‌نفعان بدون نمایش اسلاید اضافه
وقتی محصول، طراحی، مهندسی و کسب‌وکار روی یک سناریوی گام‌به‌گام توافق می‌کنند، جدل بعدی کمتر دربارهٔ سلیقه و بیشتر دربارهٔ اولویت شاخه است. use case قرارداد مشترک است: «این را پشتیبانی می‌کنیم؛ آن استثنا را عمداً بیرون گذاشتیم.» برای ذی‌نفع غیر فنی، خواندن جریان اصلی معمولاً فهمیدنی‌تر از دیاگرام کلاس یا بک‌لاگ خام است.
بازبینی کوتاه فصلی use caseهای حیاتی—همراه با دادهٔ واقعی استفاده—نشانی می‌دهد کدام سناریو هنوز مهم است و کدام باید بازنشسته شود. سند مرده خطرناک‌تر از نبود سند است چون اعتماد کاذب می‌سازد.
نمونهٔ فشرده: تمدید اشتراک
بازیگر: مدیر حساب. هدف: تمدید سالانه قبل از قطع سرویس. پیش‌شرط: اشتراک فعال با تاریخ انقضا. جریان اصلی: اعلان درون‌محصول، مشاهدهٔ طرح، تأیید پرداخت، رسید، تمدید تاریخ. جایگزین: کارت منقضی، تغییر طرح، لغو در میانه. پس‌شرط موفقیت: دسترسی بدون وقفه و ثبت رویداد مالی. از همین اسکلت، صفحهٔ اعلان، فرم پرداخت و ایمیل تأیید طراحی می‌شوند و آزمون‌ها شاخه‌ها را پوشش می‌دهند.
اگر کارت ذخیره‌شده منقضی باشد، سیستم نباید فقط پیام خطای مبهم نشان دهد؛ use case باید بگوید آیا کاربر به فرم به‌روزرسانی کارت هدایت می‌شود، آیا مهلت اضافی داده می‌شود، و آیا دسترسی تا حل مشکل در حالت محدود می‌ماند. همین جزئیات است که داستان کاربری یک‌خطی معمولاً جا می‌گذارد و در تولید به اختلاف تیم تبدیل می‌شود.
سبک نگارش سبک در برابر قالب سنگین
مکتب کلاسیک نرم‌افزار گاهی قالب‌های بسیار رسمی با ده‌ها فیلد اجباری داشت که تیم‌های چابک را فراری می‌داد. نسخهٔ کاربردی امروز کوتاه‌تر است: هدف، بازیگر، جریان اصلی در چند پاراگراف شماره‌دار، و دو یا سه شاخهٔ حیاتی. اگر شاخه‌ای در شش ماه اخیر رخ نداده و ریسک پایینی دارد، لازم نیست صفحه را پر کند. کیفیت use case به خوانده‌شدن و به‌روز ماندن است، نه به ضخامت فایل.
ابزار می‌تواند ویکی، تیکت لینک‌شده، یا بخش پذیرش در داستان باشد. مهم این است که نسخهٔ واحد حقیقت برای سناریوی پیچیده وجود داشته باشد و با تغییر محصول هم‌گام شود. وقتی طراحی اسپرینت بعد مسیر پرداخت را عوض می‌کند، use case همان روز باید علامت بازبینی بخورد وگرنه QA روی قرارداد کهنه تست می‌نویسد.
جمع‌بندی: مورد استفاده روایت ساختاریافتهٔ تعامل کاربر با سیستم برای رسیدن به هدف است، با گام، شرط و نتیجه. آن را از داستان کاربری کوتاه جدا کنید، برای جریان‌های پیچیده نگه دارید، به طراحی و QA وصل کنید، دسترس‌پذیری و نقش‌ها را در سناریو بیاورید، و سند را زنده نگه دارید. وقتی ویژگی‌ها داخل use case معنا پیدا کنند، محصول کمتر شبیه مجمع‌الجزایر دکمه و بیشتر شبیه مسیر تمام‌شدنی کار به نظر می‌رسد.
سوالات متداول
سناریوی مستندی که نشان می‌دهد کاربر چگونه با سیستم تعامل می‌کند تا به هدف برسد، شامل گام‌ها، شرایط، مسیرهای جایگزین و نتیجهٔ مورد انتظار.
داستان کاربری بیانیهٔ کوتاه نیاز و هدف است؛ use case تعامل را با جزئیات گام‌ها، پاسخ سیستم و شاخه‌ها شرح می‌دهد و برای طراحی و آزمون ساختاریافته‌تر است.
زمینهٔ سفر کامل را می‌دهد تا ویژگی‌ها به‌صورت جزیره‌ای طراحی نشوند و وایرفریم و جریان کاربر به هدف واقعی گره بخورند.
توسعه رفتار مورد انتظار سیستم را از روی سناریو می‌خواند و QA مستقیماً مورد آزمون و پوشش شاخه‌های خطا را از همان سند می‌سازد.
بله؛ سناریوهایی با صفحه‌خوان، ورودی صوتی یا محدودیت شبکه را زود بنویسید تا شمول بخشی از قرارداد محصول باشد نه وصلهٔ آخر.