واحد 2 / 12

تجزیه و تحلیل نیازمندی ها و طراحی نرم افزار

سود:

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

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

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

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

از درخواست مبهم تا نیاز قابل آزمایش

یک نیاز خوب قابل اندازه گیری و تأیید است. نه "اجازه دهید سیستم سریع باشد"، بلکه "اجازه دهید نتایج جستجو در عرض 500 میلی ثانیه برگردند". در اینجا یک روش گام به گام برای استفاده از هوش مصنوعی برای کاهش عدم اطمینان آورده شده است:

  1. درخواست را همانطور که هست ارائه دهید و سوال ایجاد شود. راه حل را از هوش مصنوعی نپرسید، بلکه ابتدا «هر چیزی که در این درخواست نامشخص است را به عنوان سؤال فهرست کنید».
  2. شما جواب ها را بدهید. فقط شما زمینه را می دانید. به سوالات هوش مصنوعی با محدودیت های تجاری واقعی خود پاسخ دهید.
  3. آن را به داستان های کاربر و معیارهای پذیرش ترجمه کنید. نیاز روشن شده را به موارد قابل آزمایش ترجمه کنید.
  4. موارد لبه و سناریوهای منفی را اضافه کنید. "نتیجه خالی"، "کاربر غیرمجاز"، "فایل خیلی بزرگ" و غیره.

درخواست استخراج ابهام: "ما درخواست تجاری زیر را به یک نیاز نرم افزاری تبدیل می کنیم. هنوز راه حلی پیشنهاد نکنید. ابتدا همه ابهامات و فرضیات پنهانی که در این درخواست پاسخ داده نشده اند را به عنوان لیستی از سوالات استخراج کنید. سوالات را تحت عناوین زیر گروه بندی کنید: محدوده، کاربر/مرجع، حجم داده، عملکرد، سابقه سفارش بارگیری مجدد به عنوان "AL".

داستان کاربر + معیارهای پذیرش: "نیاز روشن شده زیر را به داستان های کاربری که با اصول INVEST مطابقت دارند تقسیم کنید. برای هر داستان 3-5 معیار پذیرش قابل آزمایش بنویسید (در قالب Given-When-Then). حداقل 2 سناریو منفی (دسترسی غیرمجاز، داده های خالی) اضافه کنید. نیاز: [نیاز روشن شده را اینجا بنویسید]."

مقایسه تصمیمات طراحی با هوش مصنوعی

طراحی یک مبادله ثابت است: سرعت در مقابل انعطاف پذیری، سادگی در مقابل مقیاس پذیری؟ هوش مصنوعی این مبادلات را در یک صفحه گسترده سریع قرار می دهد. برای مثال، برای ویژگی «ارسال اعلان»، می‌توانید در مورد استفاده از رویکرد همزمان (ارسال در صورت درخواست) یا ناهمزمان (صف، ارسال در پس‌زمینه) بحث کنید.

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

محور

انتقال سنکرون

ناهمزمان (صف)

زمان انتظار کاربر

طولانی (در انتظار حمل و نقل)

کوتاه (فوراً برمی گردد)

تحمل خطا

کم (اگر ارسال منفجر شود، درخواست منفجر می شود)

بالا (امتحان مجدد ممکن است)

پیچیدگی

پایین

متوسط به بالا (زیرساخت صف)

هزینه زیرساخت

پایین

اجزای اضافی مورد نیاز است

جایی که مناسب است

حجم کم، برنامه ساده

حجم بالا، تحویل بحرانی

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

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

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

تفاوت یک اعلان قدرتمند؛ مقیاس (500 سفارش در روز)، قانون تجاری (قیمت گذشته باید حفظ شود) و فرمت خروجی مورد نظر. یک جمله مانند "قیمت گذشته باید حفظ شود" طراحی را کاملاً تغییر می دهد. اگر این را مشخص نکنید، هوش مصنوعی یک نمودار نادرست اما قابل قبول ایجاد می کند.

موارد کوچک

مورد 1 - فرض پنهان. یک تیم مستقیماً درخواست «کاربر می‌تواند عکس نمایه را آپلود کند» را کد می‌کند. تیم دیگری در مورد عدم قطعیت از هوش مصنوعی پرسید: "حداکثر اندازه؟ فرمت های مجاز؟ کنترل محتوای نامناسب؟ حذف عکس قدیمی؟" 8 سوال مانند. هنگامی که فایل های 20 مگابایتی سرور را پر می کند، اولین تیم از مشکل در تولید مطلع می شود. تیم دوم آن را در طراحی حل می کند.

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

مورد 3 - شکاف معیارهای پذیرش. "اگر پرداخت ناموفق باشد چه اتفاقی می افتد؟" از آنجایی که این سوال هرگز پرسیده نشد، یک سیستم سفارش همچنان در صورت پرداخت ناموفق، سفارش را به عنوان "تأیید شده" علامت گذاری می کند. فهرست سناریوهای منفی ایجاد شده توسط هوش مصنوعی این شکاف را نشان می دهد. معیار پذیرش 1 خط مانع از دست دادن پول واقعی می شود.

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

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

به طور خلاصه

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

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

یک درخواست شغلی تک جمله ای از زمینه خود انتخاب کنید. ابتدا اعلان ابهام را در هوش مصنوعی اعمال کنید و به سوالات با محدودیت های واقعی خود پاسخ دهید. سپس نیاز روشن شده را به حداقل 2 داستان کاربر و 3 معیار پذیرش برای هر کدام ترجمه کنید. حداقل 1 سناریوی منفی را شامل شود. در نهایت یک جدول مقایسه برای تصمیم طراحی (همگام/ناهمزمان، ساختار جدول و ...) ایجاد کنید و تصمیم خود را در 2 جمله بنویسید.

چک لیست

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