de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

مقدمه

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

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

Use-Case 2.0: Agile Evolution of Requirements

این مطالعه موردی به بررسی این موضوع می‌پردازد که مورد استفاده 2.0 چگونه جمع‌آوری نیازمندی‌ها، طراحی و توسعه را تبدیل می‌کند. با بررسی اصول اصلی، کاربردهای عملی و هم‌افزایی آن با ابزارهای نوظهور توسعه کمک‌شده توسط هوش مصنوعی، نشان می‌دهیم که این روش چگونه به تیم‌ها اجازه می‌دهد تا سیستم درست سیستم به طور کارآمد بسازند و اطمینان حاصل کنند که ارزش در هر افزایش تحویل داده شود.


تکامل مهندسی نیازمندی‌ها

برای تقریباً سی سال، موارد استفاده به عنوان سنگ بنای مهندسی نیازمندی‌ها عمل کرده‌اند و به تیم‌ها کمک کرده‌اند تا درک بهتری از نحوه تعامل کاربران با سیستم‌ها برای دستیابی به اهداف خود داشته باشند. این موارد، بسیاری از تکنیک‌های مدرن، از جمله داستان‌های کاربر، الهام بخشیده‌اند. اما در سال‌های اخیر، چیزی شگفت‌انگیز رخ داده است—الهام از جهت دیگر جریان یافته است.

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

«مورد استفاده 2.0 تمام ارزش‌های محبوب گذشته را دارد—نه تنها نیازمندی‌ها را پشتیبانی می‌کند، بلکه معماری، طراحی، آزمون و تجربه کاربری را نیز شامل می‌شود—و در مدل‌سازی کسب‌وکار و بازاستفاده نرم‌افزار بسیار مؤثر است.»

چه چیزی مورد استفاده 2.0 را متفاوت می‌کند؟

روش سنتی مورد استفاده شامل ایجاد مستندات دقیق مورد استفاده بود که رفتار سیستم را شامل توضیحات کوتاه، شرایط پیش‌نیاز، شرایط پس‌نیاز و تعاملات با کاربران ثبت می‌کرد. اگرچه این روش مؤثر بود، اما اغلب به سمت مستندات سنگین حرکت کرد و در تطبیق با تکرار سریع توسعه آگیل مشکل داشت.

مورد استفاده 2.0 بر این پایه ساخته شده و در عین حال چندین نوآوری معرفی می‌کند:

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

  • یکپارچه‌سازی داستان‌های کاربر: ادغام داستان‌های کاربر به عنوان روشی سبک برای ثبت نیازهای کاربر و ایجاد درک مشترک

  • برش‌های مورد استفاده: تقسیم موارد استفاده پیچیده به واحدهای کوچک‌تر و قابل مدیریت که می‌توانند به صورت مستقل پیاده‌سازی و آزمون شوند

  • مدل‌های بصری: تأکید بر نمودارهای جریان، نمودارهای فعالیت و نمودارهای توالی برای درک جامع سیستم

  • توسعه تکراری: آزمون هر جزء هنگام ساخته شدن، که امکان شناسایی زودهنگام مشکلات را فراهم می‌کند

در هسته خود، مورد استفاده 2.0 مفهوم جدید و حیاتی‌ای معرفی می‌کند: برش مورد استفاده. برش، بخشی دقیق و انتخاب‌شده از یک مورد استفاده است که می‌تواند به صورت مستقل پردازش شود—این برش نه تنها نیازمندی‌ها، بلکه طراحی، پیاده‌سازی، موارد آزمون و نتایج آزمون را نیز شامل می‌شود.

Visual representation of Use-Case 2.0 structure showing the relationship between actors, use cases, and slices.

شکل ۱: نمایش بصری ساختار Use-Case 2.0 که رابطه بین بازیگران، موارد استفاده و برش‌ها را نشان می‌دهد.


شش اصل Use-Case 2.0

ایوار جاکوبسون، ایان اسپنس و کورت بیتنر شش اصل بنیادی را شناسایی کردند که پایه‌ای برای پذیرش موفق موارد استفاده هستند:

۱. ساده نگه داشتن با روایت داستان‌ها

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

۲. درک کلی تصویر

چه سیستم شما بزرگ باشد یا کوچک، درک کلی تصویر ضروری است. بدون این دیدگاه کلی، تیم‌ها نمی‌توانند تصمیمات صحیحی در مورد محدوده، هزینه یا ارزش بگیرند. یک نمودار مورد استفاده راهی ساده برای ارائه دید کلی نیازمندی‌های یک سیستم ارائه می‌دهد—که تمام راه‌های استفاده از سیستم، کسی که تعامل را آغاز می‌کند و هرگونه طرف دیگری که درگیر است را نشان می‌دهد.

A sample use-case diagram illustrating actors and their interactions with the system.

شکل ۲: یک نمودار مورد استفاده نمونه که بازیگران و تعاملات آن‌ها با سیستم را نشان می‌دهد.

۳. تمرکز بر ارزش

ارزش تنها زمانی ایجاد می‌شود که یک سیستم واقعاً استفاده شود. به جای تمرکز بر لیست‌های طولانی از عملکردها یا ویژگی‌ها، موارد استفاده بر نحوه استفاده از سیستم برای دستیابی به اهداف خاص برای کاربران خاص تمرکز دارند. جریان اصلی ساده‌ترین راه برای دستیابی به هدف را توصیف می‌کند، در حالی که جریان‌های جایگزین گزینه‌ها و مدیریت خطاها را اضافه می‌کنند. تیم‌ها می‌توانند جریان اصلی را اول ارسال کنند و گزینه‌های جایگزین را بعداً اضافه کنند—این به صورت طراحی افزایشی است.

۴. ساخت سیستم به صورت برش‌های کوچک

اکثر سیستم‌ها نیازمند کارهای گسترده‌ای هستند تا قابل استفاده شوند. ساخت چنین سیستمی به صورت یکجا اشتباه است. در عوض، سیستم‌ها باید به صورت برش‌های کوچک ساخته شوند که هر کدام ارزش مشخصی برای کاربران ایجاد کنند.

دستورالعمل ساده است:

  1. چیز مفیدترینی که سیستم باید انجام دهد را شناسایی کنید

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

  3. موارد آزمون را تعریف کنید که نماینده پذیرش این برش‌ها باشند

  4. برش مرکزی‌ترین را انتخاب کنید که از کل مفهوم عبور می‌کند

  5. آن را به صورت تیمی تخمین بزنید و شروع به ساخت کنید

۵. تحویل سیستم به صورت افزایشی

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

۶. انطباق با نیازهای تیم

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


ساختار داخلی Use-Case 2.0: برش‌ها، سناریوها و وظایف

سه مفهوم کلیدی نحوه عملکرد Use-Case 2.0 در عمل را تعریف می‌کنند:

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

سناریوهامسیرهای مختلفی را که کاربران ممکن است برای انجام وظایف درون یک برش طی کنند، نشان می‌دهند:

  • مسیر عادی: توالی انتظار داشته یا استاندارد عملیات (مسیر «خوشحالی»)

  • مسیرهای جایگزین: تغییرات یا راه‌های متفاوت برای دستیابی به هدف یکسان

  • مسیرهای استثنا: خطاها یا موقعیت‌های غیرعادی که ممکن است رخ دهد

وظایفاقدامات خاصی هستند که کاربران باید در یک سناریو انجام دهند تا به هدف برسند. این اقدامات مراحل فردی را که بخشی از یک سناریو هستند، نشان می‌دهند.

به عنوان مثال، در بخش «مرور محصولات» یک پلتفرم تجارت الکترونیک:

  • مسیر عادی: کاربر جستجو می‌کند، نتایج را مشاهده می‌کند، محصول را انتخاب می‌کند، به سبد خرید اضافه می‌کند و به صفحه پرداخت حرکت می‌کند

  • مسیر جایگزین: کاربر روش پرداخت متفاوتی را انتخاب می‌کند (پی‌پال به جای کارت اعتباری)

  • مسیر استثنا: پرداخت به دلیل کسر بودن موجودی یا آدرس فاکتور نادرست رد می‌شود

 

Detailed breakdown of a use-case slice showing normal, alternative, and exception paths.

شکل 3: تجزیه و تحلیل دقیق یک بخش کاربردی که مسیرهای عادی، جایگزین و استثنا را نشان می‌دهد.


کاربردها در مقابل داستان‌های کاربری: چرا هر دو مهم هستند

اینجاست که Use-Case 2.0 راه‌حل جذابی برای یک چالش رایج آگیل ارائه می‌دهد.

یک داستان کاربری یک مورد مستقل است—هیچ رابطه داخلی با داستان‌های دیگر ندارد. یک لیست پروژه با 200 داستان کاربری بدون مکانیزم‌های گروه‌بندی اضافی مانند اپیک یا موضوعات، به سختی قابل مدیریت می‌شود. داستان‌ها می‌توانند از زمینه خود بیفتند و تیم‌ها اغلب تست‌های پذیرش را بیش از حد دیر می‌نویسند.

یک کاربرد متفاوت است. تمام داستان‌های مرتبط را زیر یک هدف گروه‌بندی می‌کند، با:

  • هدف واضح (خود کاربرد)

  • جریان گام به گام (جریان اصلی)

  • تغییرات تعریف شده (جریان‌های جایگزین)

  • معیارهای پذیرش (موارد آزمون)

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

User Stories vs Use Cases
شکل 4: نمودار مقایسه‌ای که تفاوت‌ها و طبیعت مکمل داستان‌های کاربری و کاربردها را برجسته می‌کند.


Use-Case 2.0 در عمل آگیل: مثال‌های واقعی دنیای واقعی

Use-Case 2.0 ساختاری برای تیم‌های آگیل که با چالش‌های رایج مواجه هستند، فراهم می‌کند:

پلتفرم تجارت الکترونیک: کاربردهای یک سیستم خرید آنلاین شامل مرور محصولات، جستجوی محصولات، افزودن به سبد خرید، ادامه به پرداخت و انجام پرداخت هستند. نمودار کاربردی اولیه جریان‌های گم‌شده—مانند «پرداخت مهمان»—را آشکار می‌کند که می‌توانند قبل از تعهد به اسپرینت اضافه شوند و از مشکلات ترک سبد خرید در محیط تولید جلوگیری کنند.

اپلیکیشن بانکداری موبایل: مستندسازی جریان‌های جایگزین مانند «اعتبارسنجی نامعتبر → بازگشت به چندعاملی» به زودی شکاف‌های امنیتی را کشف می‌کند، از پچ‌های گران‌قیمت پس از راه‌اندازی جلوگیری می‌کند و اعتماد کاربر را تقویت می‌کند.

سرویس اشتراک خودرو: قطعات مورد استفاده جریان توسعه MVP را هدایت می‌کنند—با درخواست، پذیرش و پرداخت شروع کنید؛ سپس در نسخه‌های بعدی امتیازدهی و شکایات را اضافه کنید. این امر امکان ارائه سریع ارزش با اولویت‌بندی واضح را فراهم می‌کند.

پلتفرم برنامه‌ریزی مراجعات پزشکی: بررسی جریان‌های مورد استفاده توسط ذینفعان، نیازمندی‌های مربوط به «مدیریت عدم حضور» را آشکار می‌کند. می‌توان برنامه‌ریزی مجدد خودکار را اضافه کرد که احتمالاً کاهش مراجعات غیرحضوری را به همراه دارد.

Example of an Agile team using use-case slices to plan sprints.

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


اتصال هوش مصنوعی: مورد استفاده 2.0 با توسعه کمک‌شده توسط هوش مصنوعی

مورد استفاده 2.0 ابتدا در سال 2011 توسعه داده شد، مدتی قبل از اینکه کمک‌کننده‌های کدنویسی هوش مصنوعی وجود داشته باشند. اما اصول آن به اثبات رسیده است که ترکیبی عالی با توسعه کمک‌شده توسط هوش مصنوعی است.

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

  • هدف واضحی برای درک هوش مصنوعی

  • جریان مرحله‌به‌مرحله‌ای برای اجرای هوش مصنوعی

  • تنوع‌های تعریف‌شده برای مدیریت هوش مصنوعی

  • معیارهای پذیرش برای رضایت‌بخشی هوش مصنوعی

چهار مرحله توسعه کمک‌شده توسط هوش مصنوعی به طور طبیعی بر اصول مورد استفاده 2.0 منطبق می‌شوند:

  • آغاز → «درک تصویر کلی» — نیازمندی‌های کسب‌وکار و نمودارهای اولیه مورد استفاده ایجاد کنید

  • گسترش → «تمرکز بر ارزش» — مشخصات را با جریان‌های اصلی و جایگزین بنویسید

  • ساخت → «ساخت سیستم به صورت قطعات» — با هوش مصنوعی، واحد کار می‌تواند کل مشخصات مورد استفاده باشد، نه فقط یک قطعه

  • انتقال → «ارائه سیستم به صورت افزایشی» — آزمون پذیرش کاربر نشان می‌دهد که موارد استفاده نیازهای ذینفعان را برآورده می‌کنند

Illustration of how AI assistants integrate with Use-Case 2.0 workflows.

شکل 6: نمایشی از نحوه یکپارچه‌سازی کمک‌کننده‌های هوش مصنوعی با جریان‌های کاری مورد استفاده 2.0


شروع کار با مورد استفاده 2.0

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

  1. یک نمودار مورد استفاده رسم کنید — اکنون افراد و موارد استفاده سیستم خود را شناسایی کنید. این کار 30 دقیقه طول می‌کشد و تصویر کلی را به شما می‌دهد.

  2. یک داستان مورد استفاده بنویسید — مهم‌ترین مورد استفاده را انتخاب کنید. جریان اصلی را به صورت یک فهرست نقطه‌ای بنویسید. جریان‌های جایگزین را ابتدا فقط با نام‌ها فهرست کنید.

  3. اولین مورد استفاده خود را پیاده‌سازی کنید — چه از توسعه دستی و چه از کمک هوش مصنوعی استفاده کنید، مورد استفاده را راهنمای پیاده‌سازی خود قرار دهید.

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


نتیجه‌گیری

موارد استفاده 2.0 جایگزین داستان‌های کاربری نیست—بلکه تکمیل‌کننده آن است. موارد استفاده به شما تصویر کلی و ساختار می‌دهند. موارد آزمون به شما تعریف واضحی از اتمام کار می‌دهند. در توسعه دستی، برش‌ها به شما واحدهای کاری مناسب اندازه می‌دهند.

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

The Integration of AI and Use Case 2.0

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


منابع

  1. موارد استفاده 2.0: تحول آگیل مهندسی نیازمندی‌ها: مرور جامعی از اصول و روش‌های موارد استفاده 2.0.

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

  3. قدرت برش‌های مورد استفاده: توضیح دقیقی از تکنیک‌های برش‌بندی در موارد استفاده 2.0.

  4. توسعه کمک‌شده توسط هوش مصنوعی و نیازمندی‌های ساختاریافته: بررسی اینکه ابزارهای هوش مصنوعی چگونه از موارد استفاده ساختاریافته بهره می‌برند.

  5. مدل‌سازی بصری در پروژه‌های آگیل: بهترین روش‌ها برای استفاده از نمودارها در محیط‌های آگیل.