تجزیه و تحلیل نیازمندی ها و تجزیه و تحلیل نیازهای ذینفعان

سود:

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

تجزیه و تحلیل نیازمندی ها وظیفه تعریف کامل، واضح و قابل تایید است که یک سیستم باید چه کاری انجام دهد. این یکی از مراحلی است که متخصص MIS بیشترین ارزش را دارد. زیرا یک اشتباه در اینجا به طور تصاعدی در پایان پروژه افزایش می یابد. دو نوع اساسی تحلیل نیازمندی ها وجود دارد. الزامات عملکردی کاری را که سیستم باید انجام دهد توصیف می کند: "سیستم باید هنگام تایید سفارش به مشتری ایمیل بزند." الزامات غیرعملکردی نحوه عملکرد سیستم را توصیف می کند: کیفیت هایی مانند عملکرد، امنیت، قابلیت استفاده و دسترسی. "صفحه گزارش باید در کمتر از 2 ثانیه در بارگذاری متوسط ​​باز شود" یک نیاز غیر کاربردی است.

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

داستان کاربر و معیارهای پذیرش

یک قالب رایج در نوشتن نیازمندی های مدرن، داستان کاربر است: "به عنوان یک [نقش]، برای [هدف]، من [ویژگی] را می خواهم." مثال: "من به عنوان یک نماینده فروش، می خواهم تخفیف را از صفحه موبایل محاسبه کنم تا بتوانم قیمت های سریع را در این زمینه انجام دهم." داستان کوتاه و تجاری است. راه حل فنی را تحمیل نمی کند.

هر داستانی باید معیارهای پذیرش داشته باشد: شرایط قابل آزمایشی که باید برای داستان "ok" در نظر گرفته شود. یک الگوی پرکاربرد الگوی "داده شده/وقتی/پس" است: "با توجه به: مشتری در بخش VIP است. زمانی که: بیش از 10000 لیر سفارش می دهد. سپس: سیستم 5٪ تخفیف اعمال می کند." این الگو ابهام را از بین می برد زیرا به وضوح شرایط و نتیجه مورد انتظار را به هم مرتبط می کند.

نکته: هنگام نوشتن داستان کاربری برای هوش مصنوعی، حتماً بگویید "حداقل 2 معیار پذیرش در قالب Given/When/Then برای هر داستان ایجاد کنید." هنگامی که مدل مجبور به تولید معیارها می شود، شکاف های پنهان در نیاز قابل مشاهده می شوند.

گام به گام: استخراج نیازمندی ها به کمک هوش مصنوعی

مرحله 1 - ورودی خام را جمع آوری کنید. گزارش تماس ها، ایمیل ها، اسکرین شات های موجود، لیست شکایات. ورودی واقعی بیشتر، ساخت کمتر است.

مرحله 2 - اولین مجموعه داستان ها را استخراج کنید. به هوش مصنوعی ورودی خام بدهید و از آن بخواهید پیش نویس داستان کاربر را تولید کند. این مرحله یک لیست کامل نیست، بلکه اولین مرحله است.

مرحله 3 - معیارهای پذیرش را اضافه کنید. برای هر داستان معیارهای داده شده/وقتی/پس ایجاد کنید. داستانی که نمی توان برای آن معیار تولید کرد، در واقع به این معناست که به اندازه کافی تعریف نشده است.

مرحله 4 - بررسی تناقضات و شکاف ها. از هوش مصنوعی بپرسید "آیا تضاد، تکرار یا موقعیت های تعریف نشده ای بین این الزامات وجود دارد؟" بپرسید و آن را بررسی کنید. نتیجه را به عنوان یک انسان فیلتر کنید.

مرحله 5 - اولویت بندی و تأیید کنید. داستان ها را با ذینفعان بر اساس ارزش تجاری و فوریت اولویت بندی کنید. تصمیم اولویت متعلق به واحد تجاری است نه هوش مصنوعی.

الزامات غیر کاربردی را فراموش نکنید

اکثر پروژه ها در زمینه مشکل دارند زیرا در هنگام نوشتن الزامات عملکردی، موارد غیر کاربردی را فراموش می کنند. یک گزارش ممکن است "درست" کار کند، اما اگر باز کردن آن 45 ثانیه طول بکشد، هیچ کس از آن استفاده نخواهد کرد. جدول زیر انواع نیازمندی های غیر کاربردی که معمولا نادیده گرفته می شوند و نمونه های نوشتاری قابل اندازه گیری را نشان می دهد.

ژانر

بیان بد

بیان قابل اندازه گیری

عملکرد

"باید سریع بود"

"پاسخ پرس و جو < 2 ثانیه در بارگذاری متوسط"

دسترسی

"همه باید بتوانند از آن استفاده کنند"

"سازگار با WCAG 2.1 AA؛ ناوبری کامل صفحه کلید"

امنیت

"باید ایمن باشد"

"داده های شخصی در حالت استراحت رمزگذاری می شوند؛ دسترسی مبتنی بر نقش است"

در دسترس بودن

"باید آسان باشد"

"کاربر جدید سفارش را در 3 مرحله بدون آموزش کامل می کند"

در دسترس بودن/تداوم

"نباید تصادف کرد"

"زمان کار ماهانه ≥ 99.5٪"

سه مورد کوچک: با اعداد

مورد 1 - قیمت یک نیاز غیر قابل اندازه گیری. صفحه نمایشی که در یک بانک با این شرط که "صفحه گزارش باید سریع باز شود" ساخته شده بود، در 22 ثانیه تحت بارگذاری میدانی باز شد. توسعه دهنده فکر می کرد که کلمه "سریع" را در محیط خود ارائه می دهد (2 ثانیه). اگر شرط به صورت "< 3 ثانیه در ساعت پیک، توان عملیاتی واقعی" نوشته شده بود، مشکل در آزمایش مشخص می شد. هزینه بازسازی 3 هفته و هزینه اضافی قابل اندازه گیری.

مورد 2 - شکاف با معیارهای پذیرش گرفته شده است. در حین نوشتن معیارهای پذیرش داستان «سیستم تخفیف اعمال می‌کند» در یک پروژه تجارت الکترونیک، ذینفع متوجه شد که اگر تخفیف با کوپن و تخفیف VIP مغایرت داشته باشد، چه اتفاقی می‌افتد. یک سوال تکی Given/When/Then از خطای تخفیف مضاعف قبل از پخش زنده جلوگیری کرد. این خطا باعث از دست دادن درآمد جدی در پروژه های مشابه شد.

مورد 3 - قانون ساخته شده توسط هوش مصنوعی. در یک پروژه منابع انسانی، هوش مصنوعی جمله "درخواست مرخصی به طور خودکار ظرف 24 ساعت تایید می شود" را به پیش نویس الزامات اضافه کرد. در این جلسه چنین تاییدیه خودکار مورد بحث قرار نگرفت. این مدل قانونی وضع کرده بود که «معقول» به نظر می رسید. در کنار هر شرط، کارشناس می نویسد: «منبع: کدام مصاحبه/سند؟» با افزودن ستون، 4 جمله بدون منبع را حذف کرد.

اعلان ضعیف / اعلان قوی

اعلان ضعیف:

داستان های کاربری را برای این پروژه بنویسید.

اعلان قدرتمند:

نقش شما: شما یک تحلیلگر تجاری MIS هستید. داستان های کاربر را از یادداشت مصاحبه زیر استخراج کنید. قوانین: - قالب: "به عنوان [نقش]، برای [هدف]، [ویژگی] را می خواهم."- حداقل 2 معیار پذیرش برای هر داستان را در قالب Given/When/Then بنویسید.- یک جمله "Source" را اضافه کنید. که در یادداشت مشخص نیست. برازش.- الزامات غیر کاربردی قابل اندازه گیری (عملکرد، امنیت، دسترسی) را در بخش جداگانه بنویسید. یادداشت مصاحبه: [متن]

اعلان قدرتمند قالب داستان، معیارهای پذیرش، قابلیت ردیابی منبع و الزامات غیر کاربردی را به یکباره اعمال می کند. این امر کنترل خروجی را آسان تر می کند.

چهار قالب قابل کپی

1) توضیح الزامات:

الزامات زیر را بررسی کنید. هر عبارتی را که مبهم، غیرقابل قیاس یا برای بیش از یک تفسیر است علامت گذاری کنید و برای هر کدام یک سوال روشن کننده بنویسید. جواب را جعل نکنید مورد نیاز: [متن]

2) اسکن تضاد:

در فهرست الزامات زیر، مواردی را بیابید که با یکدیگر تناقض دارند، تکراری هستند یا شکاف های منطقی ایجاد می کنند. هر یافته را با شماره موارد و یک توجیه یک جمله ای گزارش دهید. فهرست: [متن]

3) ایجاد معیارهای پذیرش:

حداقل 4 معیار پذیرش برای داستان کاربری زیر را در قالب Given/When/Then بنویسید، از جمله موارد محدودیت و استثنا. همچنین نکاتی را که نامشخص باقی می‌مانند فهرست کنید. داستان: [متن]

4) طرح کلی محدوده:

موارد «در محدوده» و «خارج از محدوده» را به عنوان یک جدول دو ستونی با توجه به شرایط زیر پیش نویس کنید. برای هر موردی که از آن مطمئن نیستید برچسب [تأیید لازم است] را بزنید. مورد نیاز: [متن]

اشتباهات رایج

• فکر کردن به راه حل یک نیاز است. "افزودن یک منوی کشویی" یک راه حل است، نه یک الزام. این الزام می گوید "کاربر باید بتواند کشور را از لیست تعریف شده انتخاب کند". تیم فناوری اطلاعات راه حل را طراحی می کند.
• نادیده گرفتن موارد غیر کاربردی به سادگی نوشتن "چه باید کرد" و فراموش کردن "چگونه بودن" (سرعت، امنیت، دسترسی) رایج ترین و گران ترین راه گریز است.
• استفاده از صفت های غیر قابل اندازه گیری کلماتی مانند "سریع، آسان، ایمن، کاربر پسند" بدون آستانه نامعتبر هستند.
• توجه نکردن به قانونی که هوش مصنوعی ایجاد کرده است. این مدل ممکن است قواعد «معقول» را اضافه کند، اما در واقع قواعد گفته نشده باشد. برای هر نیازی منابع بخواهید.
• اولویت بندی را به هوش مصنوعی واگذار کنید. اولین کاری که باید انجام داد یک تصمیم ارزش تجاری است. واحد تجاری این را می دهد.

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

به طور خلاصه

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

وظیفه کاربردی

یک درخواست تجاری تک پاراگرافی برای یک «سیستم قرار آنلاین» خیالی بنویسید (به عنوان مثال، «مشتریان باید بتوانند به صورت آنلاین قرار ملاقات بگذارند، کارکنان باید بتوانند تقویم‌ها را ببینند»). (1) حداقل 5 داستان کاربر و 2 معیار پذیرش برای هر کدام با یک درخواست قوی از این درخواست ایجاد کنید. (2) حداقل 2 شکاف پنهان را در معیارهای تولید شده توسط مدل بیابید (مثلاً قرار ملاقات دوگانه در همان زمان، قانون لغو). (3) شامل حداقل 3 الزامات غیرعملکردی به شکل قابل اندازه گیری باشد. (4) حداقل 3 مورد را به عنوان "خارج از محدوده" شناسایی کنید. (5) قاعده ای را که ممکن است مدل ساخته باشد علامت بزنید و بنویسید که چگونه آن را تأیید می کنید.

چک لیست

• [ ] الزامات کاربردی و غیر کاربردی را جداگانه نوشتم.
• [ ] هر الزامی واضح، قابل اندازه گیری و آزمایش است.
• [ ] هر داستان دارای معیارهای پذیرش / زمانی / سپس.
• [ ] من می توانم منبع (مکالمه/سند) هر نیاز را ردیابی کنم.
• [ ] قوانین احتمالی را که هوش مصنوعی ساخته بود علامت زدم و آنها را برای تأیید گذاشتم.
• [ ] اولویت بندی را همراه با واحد تجاری انجام دادم.