en_USes_ESfa_IRfr_FRhi_INid_ID

Use-Case 2.0: تکامل آگیل نیازهای مهندسی (راهنمای 2026)

Table of Contents hide

«آینده نیازها، بیشتر مستندات نیست — بلکه هوشمندانه‌تر، سبک‌تر و متناسب‌تر با ارائه است.»
— ایوار یاکوبسون، ایان اسپنس، کورت بیتنر

در محیط توسعه نرم‌افزار سریع‌السیر امروز، تیم‌ها به روشی نیاز دارند که تعادلی بینشفافیتانعطاف‌پذیریومقیاس‌پذیریرا بگذاریدUse-Case 2.0— تکامل مدرن و آگیل کاربردهای کلاسیک، طراحی شده برای موفقیت در محیط‌های Scrum، Kanban و لین، در حالی که قدرت نیازهای ساختاریافته را حفظ می‌کند.

توسعه‌یافته توسط پیشگامانایوار یاکوبسونایان اسپنسوکورت بیتنر (حدود 2011–2012)،Use-Case 2.0— کاربردها را به عنوان واحدهای سبک، قابل برش و مبتنی بر ارزش بازتعریف می‌کند که تمامی چرخه حیات تحویل نرم‌افزار را پشتیبانی می‌کنند — از کشف تا عملیات.

این مقاله به عمق در موردUse-Case 2.0,را ارائه می‌دهد، راهنمای جامع و عملی برای تیم‌هایی که می‌خواهند روش نیازهای خود را مدرن‌تر کنند بدون اینکه دقت یا ردیابی را از دست بدهند.


🔹 1. Use-Case 2.0 چیست؟

Use-Case 2.0رویکردی آگیل و مقیاس‌پذیر برای ثبت و ارائه عملکرد سیستم از طریقکاربردها— اما با یک تغییر. قوت‌های اصلی کاربردهای سنتی را حفظ می‌کند (شفافیت اهداف، طراحی مبتنی بر بازیگر، مدل‌سازی سناریوی تمام‌گیر) در حالی که سنگینی، بوروکراسی و مستندات اولیه که معمولاً تیم‌های آگیل را محدود می‌کنند، حذف می‌شود.

✅ اهداف اصلی:

  • سبک‌وزن: به حدی ساده که مانند یک داستان کاربری روی یک کارت شاخص باشد.

  • تدریجی: اهداف بزرگ را به بخش‌های کوچک و قابل ارسال تقسیم می‌کند.

  • مُحَدَّث بر اساس آزمون: آزمون‌ها از ابتدا تعریف می‌شوند — حتی قبل از کد نویسی.

  • تمرکز بر ارزش: هر بخش ارزش مشتری قابل اندازه‌گیری ارائه می‌دهد.

  • آماده چرخه عمر: پشتیبانی از نیازها، معماری، طراحی، اجرا، آزمون و عملیات را ارائه می‌دهد.

🔄 چگونگی متفاوت بودن از موارد استفاده سنتی:

ویژگی موارد استفاده سنتی مورد استفاده 2.0
اندازه پر حجم، مستندات کامل (10+ صفحه) سبک‌وزن، حداکثر 1 تا 2 صفحه
تحویل طراحی بزرگ از ابتدا تدریجی، مرحله به مرحله
تمرکز رفتار سیستم اهداف کاربر و ارزش
آزمون پس از توسعه انجام می‌شود از ابتدا تعریف می‌شود (سبک BDD)
مقیاس‌پذیری سخت در مقیاس‌گذاری مقیاس‌پذیری در «داخل»، «خارج» و «بالا»

✅ بهترین هر دو جهان: مورد استفاده 2.0 ترکیب می‌کند با ساختار موارد استفاده با انعطاف‌پذیری داستان‌های کاربر — ایده‌آل برای سیستم‌های پیچیده‌ای که در آن‌ها داستان‌های کاربری خالص می‌توانند مفهوم را از دست بدهند.


🔹 2. شش اصل اولیه مورد استفاده 2.0

این اصول بنیادی هر مرحله از فرآیند را هدایت می‌کنند. این‌ها اختیاری نیستند — این‌ها دی‌ان‌ای روش هستند.

  1. مورد استفاده را ساده و قابل درک نگه دارید
    از اصطلاحات فنی خودداری کنید. بر روی آنچه کاربر می‌خواهد به دست آورد تمرکز کنید، نه اینکه سیستم چگونه داخلی کار می‌کند.

  2. هدف خود را بدانید
    پرسش کنید: چرا من این مورد استفاده را نوشته‌ام؟آیا برای تمیز کردن لیست پیش‌نیازها است؟ طراحی معماری؟ طراحی آزمون؟ سطح جزئیات را متناسب با آن تنظیم کنید.

  3. بر روی بازیگران و اهداف آن‌ها تمرکز کنید
    هر مورد استفاده باید پاسخ دهد: چه کسی درگیر است؟ چه می‌خواهند به دست آورند؟ چرا این مهم است؟
    بازیگران می‌توانند انسان‌ها (مثلاً مشتری، مدیر) باشند، سیستم‌های خارجی (مثلاً درگاه پرداخت)، یا حتی فعال‌سازهای مبتنی بر زمان.

  4. سیستم را به برش‌هایی بسازید
    مورد استفاده را به برش‌های نازک و عمودی که تمام لایه‌ها را پوشش می‌دهد: رابط کاربری، منطق پشتیبان، داده‌ها و آزمون‌ها.

  5. برش‌های کامل تحویل دهید
    هر برش باید قابل تحویل (به صورت بالقوه) — به طور کامل آزمون شده، مستند شده و قابل نمایش. تحویل جزئی مجاز نیست.

  6. به موقعیت سازگار شوید
    Use-Case 2.0 یک اندازه برای همه نیست. جزئیات را برای سیستم‌های بزرگ افزایش دهید یا برای استارتاپ‌ها کاهش دهید. انعطاف‌پذیر است، نه سفت و سخت.


🔹 3. مفاهیم اصلی در Use-Case 2.0

🎯 عملگر

هر موجودیت (انسان یا سیستم) که با سیستم تعامل دارد.

  • عملگر اصلی: مبدأ استفاده از مورد (مثلاً مشتری که پول نقد برداشت می‌کند).

  • عملگر پشتیبان: به عملگر اصلی کمک می‌کند (مثلاً پایگاه داده بانک یا پردازشگر پرداخت).

📌 مورد استفاده

یک متمرکز بر هدفتوضیحی درباره اینکه یک عملگر چگونه به یک نتیجه ارزشمند دست می‌یابد.

  • با نام فعل + اسمبرداشت نقدپردازش درخواست بیمهایجاد حساب کاربری.

  • محدوده: معمولاً سطح سیستم، اما می‌تواند سطح کسب‌وکار یا سطح مؤلفه باشد.

📝 مثال:
مورد استفادهبرداشت نقد
هدف: اجازه دادن به مشتری برای دریافت نقدینگی از حساب خود از طریق ماشین خودپرداز

🧩 روایت مورد استفاده / داستان

توضیح مختصر و در قالب داستانی از مورد استفاده. شامل:

  • عنوان و هدف

  • افراد اصلی و حمایتی

  • محدوده

  • سناریوی موفق اصلی (مسیر شاد)

  • گسترش‌ها (گزینه‌ها، خطاها)

📌 نکته فرمت:از 1 تا 2 پاراگراف یا نکات فهرستی استفاده کنید. از رسم دیاگرام‌های کامل UML خودداری کنید مگر در صورت نیاز.

🔪 برش مورد استفاده (تغییردهنده بازی!)

توسعه‌ی قدرتمندترین در نسخه 2.0 مورد استفاده

یکبرش مورد استفادهاست:

  • یک بخش کوچک و خودکفا از یک مورد استفاده

  • تحویل دادنارزش شفاف و قابل اندازه‌گیری.

  • قابل آزمون، قابل تخمین و قابل اجرا در یک اسپرینت.

  • یکبرش عمودیکه در تمام لایه‌ها عبور می‌کند: نیازمندی‌ها → طراحی → کد → آزمون‌ها → رابط کاربری

💡 آن را به عنوان یکداستان کاربر خوب نوشته شده, اما بامتناز مورد استفاده بزرگتر.

✅ ویژگی‌های یک بخش خوب:

  • مستقل از بخش‌های دیگر (در صورت امکان)

  • ارزش خود را تأمین می‌کند

  • می‌تواند با آزمون‌ها تأیید شود

  • با هدف یک اسپرینت تطبیق دارد


🔹 4. فرآیند گام به گام: نحوه به کارگیری مورد استفاده 2.0

این فرآیند اثبات شده را دنبال کنید تا دیدگاه را به نرم‌افزار کاربردی تبدیل کنید — به صورت تدریجی و همکارانه.

✅ مرحله 1: شناسایی بازیگران و موارد استفاده (مرحله کشف)

با مغزفروشی شروع کنید:

  • کی از سیستم استفاده می‌کند؟

  • چه هدف‌هایی دارند؟اهداف کلیدی?

👉 هدف خود را بر روی5 تا 15 مورد استفاده سطح بالادر هر سیستم. از ایجاد بیش از 100 مورد کوچک خودداری کنید.

🛠️ مثال:سیستم ATM

  • بازیگران: مشتری، کارمند بانک، مدیر بانک

  • موارد استفاده: برداشت نقدی، واریز وجه، انتقال وجه، بررسی موجودی، تغییر کد عبور

✅ مرحله 2: طرح کلی موارد استفاده (روایت سبک)

برای هر مورد استفاده، یک روایت مختصر بنویسید:

  • عنوان: برداشت نقدی

  • هدف: امکان برداشت وجه از حساب مشتری از طریق ATM را فراهم کند.

  • افکار: مشتری (اصلی)، ماشین عامل خودپرداز (ATM)، سیستم بانکی (پشتیبان)

  • محدوده: فقط سیستم ATM

  • سناریوی موفق اصلی:

    1. مشتری کارت را وارد می‌کند.

    2. سیستم کارت را تأیید می‌کند.

    3. مشتری کد عبور (PIN) را وارد می‌کند.

    4. سیستم کد عبور (PIN) را تأیید می‌کند.

    5. مشتری گزینه «برداشت نقدی» را انتخاب می‌کند.

    6. مشتری مبلغ را وارد می‌کند.

    7. سیستم موجودی را بررسی می‌کند.

    8. نقدیات توزیع می‌شود.

    9. چک (گزارش) چاپ می‌شود (اختیاری).

    10. تراکنش تکمیل شد.

📌 شامل شودگسترش‌های کلیدی:

  • موجودی ناکافی

  • کارت منقضی شده

  • حد مجاز برداشت روزانه تجاوز کرده است

✅ مرحله 3: تقسیم کردن موارد مورد استفاده

هر مورد مورد استفاده را به صورت3 تا 10+ برش عمودی. از این الگوهای برش استفاده کنید:

الگو هدف
برش پایه مسیر موفق با حداقل عملکرد
تیکه پیش‌شرایط احراز هویت، تنظیمات یا ورود
گزینه ساده یک تغییر (مثلاً موجودی کافی نیست)
تیکه خطا/حالت لبه مدیریت شکست (مثلاً تایم‌اوت، خطای شبکه)
تیکه بهبود افزودن ویژگی‌ها (مثلاً رسید، چند ارز)

📌 مثال: تیکه‌های «برداشت نقدی»

  1. احراز هویت کاربر + مشاهده موجودی (بنیاد)

  2. برداشت مبلغ معتبر ≤ موجودی → صادر کردن نقدی (هسته)

  3. برداشت → موجودی کافی نیست → نمایش پیام خطا

  4. برداشت → محدودیت روزانه تجاوز کرده → مسدود کردن تراکنش

  5. چاپ رسید پس از برداشت

  6. پشتیبانی از برداشت چند ارزی

هر تیکه اکنون یک آیتم لیست پیش‌نیاز آماده برنامه‌ریزی اسپرینت.

✅ مرحله ۴: جزئیات تیکه‌ها (به اندازه کافی)

برای هر تیکه تعیین کنید:

  • معیارهای پذیرش (به فرمت گریکین/BDD):

    اگر مشتری کارت معتبر داشته باشد
    وقتی کد عبور معتبر را وارد کنند
    و گزینه «برداشت نقدی» برای ۵۰ دلار را انتخاب کنند
    و موجودی کافی داشته باشند
    سپس نقدی باید صادر شود
    و یک رسید باید چاپ شود
    
  • طرح‌های UI/UX (در صورت نیاز)

  • سناریوهای آزمون (خودکار یا دستی)

  • وابستگی‌ها (مثلاً ادغام درگاه پرداخت)

📌 بیش از حد مستندسازی نکنید!فقط آنچه که برای ساخت و تست لازم است را شامل شوید.

✅ مرحله ۵: برنامه‌ریزی و اولویت‌بندی

  • تکه‌ها را به لیست پروژه.

  • اولویت‌بندی بر اساس:

    • ارزش کسب‌وکار

    • ریسک (نگاه اولیه به ریسک)

    • وابستگی‌ها (اول مسیرهای حیاتی را بسازید)

    • تأثیر بر مشتری

از بررسی کلی موارد مورد استفاده برای حفظ زمینه — از اینکه جنگل را از دست بدهید، جلوگیری کنید.

🧭 نکته حرفه‌ای: از نماهای مورد استفاده یا نقشه‌های بصری (مثلاً Miro، Confluence) برای نشان دادن روابط بین موارد مورد استفاده و تکه‌ها.

✅ مرحله ۶: توسعه تدریجی

  • تکه‌ها را به اسپرینت‌ها بکشید.

  • پیاده‌سازی کامل تکه عمودی: رابط کاربری + پس‌زمینه + پایگاه داده + آزمون‌ها.

  • عملکرد کارآمد را در پایان هر اسپرینت نشان دهید.

  • جمع بازخورد و بهبود بخشد.

✅ هر اسپرینت با یک پایان می‌یابدافزایش کارآمد، آزموده شده و احتمالاً قابل ارسال.

✅ مرحله 7: تأیید و انطباق

پیگیری پیشرفت هر بخش با استفاده ازانتقال‌های حالت:

حالت معنی
تعیین محدوده شناسایی و اولویت‌بندی شده
آماده شده جزئیات با معیارهای پذیرش، آزمون‌ها و طراحی
انجام شده کد نوشته شده و یکپارچه شده
تأیید شده آزمون‌ها موفقیت‌آمیز بود، نمایش داده شد و پذیرفته شد
دیگر نیازی نیست یا منسوخ شده دیگر نیازی نیست یا منسوخ شده

از این ردیابی برای پیگیری پیشرفت و شناسایی موانع استفاده کنید.


🔹 5. مثال واقعی: فروشگاه آنلاین کتاب

بیایید Use-Case 2.0 را به یک سیستم واقعی اعمال کنیم.

📚 مورد استفادهخرید کتاب

هدف:

اجازه دادن به مشتری برای خرید کتاب آنلاین با فرآیند تسویه حساب بدون قطعیت.

📝 سناریوی موفق اصلی:

  1. مشتری کتاب‌ها را مرور یا جستجو می‌کند.

  2. جزئیات کتاب را مشاهده و به سبد خرید اضافه می‌کند.

  3. به صفحه پرداخت حرکت می‌کند.

  4. اطلاعات ارسال و پرداخت را وارد می‌کند.

  5. سفارش را تأیید می‌کند.

  6. تاییدیه سفارش را دریافت می‌کند (ایمیل و روی صفحه).


🔪 تکه‌های مورد استفاده (آیتم‌های لیست پیش‌نیاز)

هر تکه یک افزایش عمودی و قابل ارسال است:

تکه توضیحات ارزش ارائه‌شده
تکه ۱: مرور و جستجوی کتاب‌ها مشتری می‌تواند کتاب‌ها را بر اساس عنوان، نویسنده یا دسته‌بندی جستجو کند (نیازی به ورود به سیستم نیست). توانایی پایه‌ای کشف
تکه ۲: مشاهده جزئیات کتاب و افزودن به سبد خرید مشتری توضیحات کتاب، قیمت و آن را به سبد خرید اضافه می‌کند. جریان اصلی خرید
تکه ۳: مشاهده سبد خرید و به‌روزرسانی مقدار مشتری سبد خرید را مشاهده و مقدار آیتم‌ها را ویرایش می‌کند. شخصی‌سازی و کنترل
تکه ۴: خرید بدون ثبت‌نام (پایه‌ای) مشتری بدون حساب ورودی خرید می‌کند؛ اطلاعات پایه‌ای ارسال و پرداخت را وارد می‌کند. نقطه ورود کم‌محدودیت
تکه ۵: ورود کاربر ثبت‌نام‌شده و آدرس‌های ذخیره‌شده کاربران ورودی می‌توانند آدرس‌ها را ذخیره کنند و به طور خودکار پر کنند. قابلیت استفاده مجدد و راحتی
برش 6: ادغام درگاه پرداخت واقعی اتصال به Stripe/PayPal؛ مدیریت تراکنش‌های امن اعتماد و تکمیل
برش 7: ایمیل تأیید سفارش سیستم ایمیل حاوی خلاصه سفارش و ردیابی را ارسال می‌کند. اعتماد پس از خرید
برش 8: مدیریت پرداخت ناموفق و تلاش مجدد مشتری خطای را می‌بیند، می‌تواند دوباره تلاش کند یا روش پرداخت را تغییر دهد. استحکام و بهبود تجربه کاربری

✅ هر برش می‌تواند به طور مستقل آزمون، نمایش و انتشار شود.


🔹 6. مقایسه کاربردی 2.0 در مقابل داستان‌های کاربری: مقایسه کنار هم

ویژگی داستان کاربر خالص برش Use-Case 2.0
فرمت «به عنوان [نقش]، می‌خواهم [اهداف] تا [منفعت]» «بخشی از «خرید کتاب» — برداشت مبلغ معتبر»
متن منزوی؛ ممکن است ارتباط خود را با جریان‌های بزرگتر از دست بدهد در یک کاربرد جاسازی شده — روابط را نشان می‌دهد
قابل ردیابی ضعیف (پیوند دادن داستان‌ها دشوار است) قوی (برش‌ها به کاربرد بازگشت می‌یابند)
مدیریت پیچیدگی مشکلاتی با سناریوهای چندمرحله‌ای و شاخه‌ای دارد در موارد افزودنی‌ها، جایگزین‌ها و مسیرهای خطا بسیار خوب عمل می‌کند
آزمون اغلب پس از اجرا تعریف می‌شود آزمون‌ها تعریف شده‌اندقبل ازکدنویسی (اولویت BDD)
مقیاس‌پذیری در مقیاس بزرگ شکست می‌خورد (تعداد زیادی داستان) به خوبی از طریق بسته‌های مورد استفاده و سلسله مراتب مقیاس‌پذیر می‌شود

 مورد استفاده 2.0جایگزین داستان‌های کاربری نیست — بلکه یک بهبود است.
به شما امکان می‌دهد تاانعطاف‌پذیری داستان‌های کاربریباساختار و شفافیت موارد استفاده.


🔹 7. نکات موفقیت و مقیاس‌پذیری

🎯 شروع سبک، مقیاس‌گذاری هوشمندانه

  • باکارت‌های شاخصیابرگه‌های تک‌صفحه‌ای.

  • ازتابلوهای سیاه دیجیتال (Miro، FigJam، Confluence) برای همکاری.

  • از طراحی بیش از حد در مراحل اولیه خودداری کنید.

🖼️ استفاده از تصاویر به صورت استراتژیک

  • نمودارهای مورد استفاده: نشان دادن مرزهای سیستم سطح بالا و روابط بین اکتورها.

  • نمودارهای فعالیت: مدل‌سازی جریان‌های پیچیده (مثلاً فرآیند خرید چند مرحله‌ای).

  • نقشه‌های برش‌ها: نمایش اینکه برش‌ها چگونه در مورد استفاده بزرگتر جای می‌گیرند.

🏢 مقیاس‌بندی برای پروژه‌های بزرگ

  • گروه‌بندی موارد استفاده مرتبط درون بسته‌های مورد استفاده (مثلاً «مدیریت سفارش»، «حساب کاربری»).

  • استفاده از موارد استفاده کسب‌وکار برای برنامه‌ریزی سطح سازمانی (مثلاً «ثبت مشتری جدید»).

  • پیاده‌سازی معماری ماژولار برای پشتیبانی از برش عمودی.

🛠️ ابزارهای پیشنهادی

ابزار مورد استفاده
ویژوال پارادایم مدل‌سازی کامل UML، نمودارهای مورد استفاده، ردیابی
ارکیتکت سازمانی مدل‌سازی پیشرفته، ادغام با ابزارهای ALM
مایرو / فیج‌جام کارگاه مشترک، نقشه‌برداری برش‌ها
جیرا / آژور دوپس مدیریت لیست انتظار، ردیابی اسپرینت، انتقال حالت‌ها
کامبیو / اسپکفلو آزمون BDD با سینتکس Gherkin

✅ نکته حرفه‌ای: استفاده کنید Gherkin برای معیارهای پذیرش — قابل خواندن برای هر دو توسعه‌دهنده و ذینفعان غیرفنی است.

⚠️ اشتباهات رایجی که باید اجتناب کنید

  1. تعداد زیادی برش در هر مورد استفاده → مرگ به دلیل جزئیات.
    → رفع: محدود به ۳ تا ۱۰ برش؛ تمرکز بر ارزش، نه جزئیات.

  2. تعداد کم برش → داستان‌های بزرگ و غیرقابل آزمون.
    → رفع: جریان‌های بزرگ را به برش‌های نازک عمودی تقسیم کنید.

  3. نادیده گرفتن گسترش‌ها و خطاها → سیستم‌های ناپایدار.
    → رفع: حداقل یک برش خطا/جایگزین در هر مورد استفاده شامل شود.

  4. در نظر گرفتن موارد استفاده به عنوان مشخصات نهایی → ضد-آگیل.
    → رفع: آن‌ها را به عنوان آثار زنده در نظر بگیرید — هنگام یادگیری بهبود بخشید.


🔹 نتیجه‌گیری: آینده الزامات اینجا است

مورد استفاده ۲.۰ فقط یک روش‌شناسی نیست — تغییری در ذهنیت است.

این پاسخی به تنش قدیمی بین شفافیتوانعطاف‌پذیری، بینساختاروسرعت. با ترکیب:

  • اینتمرکز بر اهدافاستفاده از موارد مورد نیاز،

  • اینطبیعت سبک و تکراریداستان‌های کاربر،

  • ایناولویت آزمون، برش عمودیروش‌های نوین آگیل،

…Use-Case 2.0 روشی قدرتمند و آینده‌نگر برای نیازهای نرم‌افزار ارائه می‌کند.

✅ دلایلی که تیم‌ها آن را در سال ۲۰۲۶ دوست دارند:

  • ✅ زمان کوتاه‌تر به ارزش– ویژگی‌های کاربردی را به زودی ارائه دهید.

  • ✅ همکاری بهتر– درک مشترک در بین محصول، توسعه‌دهندگان و آزمون کیفیت.

  • ✅ کمترین عیب– آزمون‌ها قبل از کد نوشته می‌شوند.

  • ✅ مقیاس‌گیری آسان‌تر – برای استارتاپ‌ها و شرکت‌های بین‌المللی کار می‌کند.

  • ✅ تحویل ردیابی‌شده – هر ویژگی به یک هدف کاربر بازمی‌گردد.

📚 مطالعه بیشتر:

  • Use-Case 2.0: راهنمای موفقیت در استفاده از موارد مورد استفاده توسط ایوار یاکوبسون، ایان اسپنس و کورت بیتنر

  • دانلود رایگان: https://www.ivarjacobson.com

  • کاوش کنید ایوار یاکوبسون اینترنشنال سایت برای آموزش، ابزارها و جامعه.


📌 فکر نهایی

«نیازها را بنویسید — ارزش تحویل دهید.»
Use-Case 2.0 اهداف مبهم را به افزایش‌های قابل لمس، آزموده و ارزشمند تبدیل می‌کند — یک برش در هر بار.

چه بخواهید یک اپلیکیشن فین‌تک، یک پلتفرم تجارت الکترونیک یا یک سیستم کلیدی سازمانی بسازید، Use-Case 2.0 شما را با چارچوبی برای ساخت هوشمندانه‌تر، سریع‌تر و با اطمینان بیشتر تجهیز می‌کند.


🚀 شاد برش‌دهی!
برو و ارزش را تحویل بده — یک برش عمودی در هر بار.

This post is also available in English, Español, Français, English and Bahasa Indonesia.