مهندسی نیازمندی
نیازمندی نرم‌افزار اختصاصی را چگونه بنویسیم؟
نیازمندی خوب رفتار مورد انتظار و دلیل آن را قابل آزمون می‌کند؛ نه اینکه رابط یا راه‌حل را پیش از شناخت مسئله قطعی فرض کند.
انتشار: · آخرین به‌روزرسانی:
نویسنده: تحریریه پیکا — پژوهش و ویرایش با کمک ابزارهای هوش مصنوعی؛ مسئولیت انتشار با پیکا است
نیازمندی نرم‌افزار اختصاصی توصیف قابل آزمونی از نیاز کاربر، رفتار سامانه، محدودیت یا کیفیت مورد انتظار است که به یک هدف کسب‌وکار متصل می‌شود. سند خوب فقط نمی‌گوید چه صفحه‌ای ساخته شود؛ روشن می‌کند چه کسی، در چه زمینه‌ای، با چه داده‌ای، چه نتیجه‌ای می‌خواهد و پذیرش آن چگونه سنجیده می‌شود.
پیش از نوشتن نیازمندی چه چیزی باید کشف شود؟
راهنمای توسعه نرم‌افزار اختصاصی با شناخت فرایند، کاربر، داده و محدودیت شروع می‌شود. چند نمونه واقعی کار را از آغاز تا پایان دنبال کنید و تفاوت مسیر رسمی با روش عملی را ثبت کنید. مسئله، پیامد، خط پایه، مالک و دلیل نیاز به تغییر باید پیش از نام صفحه یا فناوری روشن باشند؛ وگرنه سند، راه‌حل فرضی را دقیق‌تر می‌کند نه مسئله را.
- هدف و شاخص کسب‌وکار
- نقش‌ها و کاربران واقعی، نه فقط عنوان واحد
- مسیر اصلی، استثنا و میان‌برهای فعلی
- منبع داده، کیفیت و مالک آن
- محدودیت حقوقی، امنیتی، فنی و زمانی
- سامانه‌های وابسته و مسئول هر اتصال
نیازمندی خوب چه ویژگی‌هایی دارد؟
ISO/IEC/IEEE 29148 فرایندها و اقلام اطلاعاتی مهندسی نیازمندی را در چرخه عمر پوشش می‌دهد و بر نیازمندی متنی خوش‌ساخت تأکید دارد. در عمل، هر نیازمندی باید ضروری، روشن، منفرد، سازگار، شدنی، قابل ردیابی و قابل راستی‌آزمایی باشد. واژه‌هایی مانند سریع، ساده، امن و هوشمند بدون مقدار، زمینه یا آزمون، قابل تحویل نیستند.
بازنویسی خواسته مبهم
| خواسته مبهم | صورت قابل آزمون |
|---|---|
| گزارش سریع باز شود | گزارش ماه جاری برای حجم مرجع در صدک ۹۵ زیر زمان هدف باز شود |
| مدیر همه چیز را ببیند | مدیر فقط رکورد واحدهای تحت مسئولیت و فیلدهای مجاز را ببیند |
| سیستم پیام بدهد | پس از تغییر وضعیت، اعلان با الگو و کانال مشخص ثبت و ارسال شود |
| اطلاعات تکراری ثبت نشود | شناسه مرجع یکتا باشد و درخواست تکراری نتیجه قبلی را بازگرداند |
سناریوی کاربر و قاعده کسب‌وکار چگونه نوشته می‌شوند؟
سناریو محرک، نقش، پیش‌شرط، مسیر اصلی، استثنا و نتیجه را توضیح می‌دهد. قاعده کسب‌وکار باید جدا از چیدمان رابط ثبت شود تا بتوان آن را در API، واردات یا اجرای خودکار نیز اعمال کرد. راهنمای اتوماسیون فرایند کسب‌وکار برای تعیین مرز، مالک، ورودی، خروجی و استثناهای یک جریان چندمرحله‌ای مفید است.
- محرک
چه رویدادی سناریو را آغاز می‌کند؟
- نقش
کاربر یا خدمت با چه مجوزی عمل می‌کند؟
- داده
ورودی از کجا می‌آید و چه اعتباری دارد؟
- رفتار
مسیر عادی و قواعد تصمیم چیست؟
- استثنا
خطا، رد، تکرار یا نبود داده چگونه مدیریت می‌شود؟
- نتیجه
چه رکورد یا اثر قابل مشاهده‌ای پایان را اثبات می‌کند؟
نیازمندی غیرعملکردی چگونه قابل سنجش می‌شود؟
نیازمندی غیرعملکردی کیفیت و محدودیت را تعریف می‌کند: کارایی، دسترس‌پذیری، امنیت، حریم خصوصی، بازیابی، دسترس‌پذیری انسانی، نگهداری و مشاهده‌پذیری. مقدار باید با سناریوی بار و ریسک متناسب باشد. الزام بسیار سخت بدون نیاز واقعی هزینه می‌سازد و عبارت کلی نیز قابل پذیرش نیست. NIST SSDF ثبت و ردیابی نیازها و ریسک‌های امنیتی را در فرایند توسعه قرار می‌دهد.
نمونه معیار کیفیت
| کیفیت | اجزای تعریف |
|---|---|
| کارایی | عملیات، حجم، صدک، زمان و محیط |
| دسترس‌پذیری | بازه خدمت، استثنا، اندازه‌گیری و جبران |
| بازیابی | هدف زمانی، نقطه بازیابی و سناریوی آزمون |
| امنیت | دارایی، تهدید، کنترل و شواهد آزمون |
| دسترس‌پذیری انسانی | کاربر، وظیفه، معیار و ابزار آزمون |
داده و API چگونه به نیازمندی تبدیل می‌شوند؟
راهنمای یکپارچه‌سازی نرم‌افزارها برای هر اتصال منبع حقیقت، طرح داده، مالک، هویت، تناوب، محدودیت نرخ، خطا و تکرار امن را مشخص می‌کند. برای هر فیلد مهم، نوع، اجباری‌بودن، اعتبار، محرمانگی، نگهداری و رفتار تغییر تعریف شود. عبارت «اتصال به CRM» بدون عملیات، جهت، حجم و سناریوی خطا نیازمندی محسوب نمی‌شود.
معیار پذیرش چگونه از نیازمندی مشتق می‌شود؟
معیار پذیرش پیش از ساخت می‌گوید چه شواهدی تحویل را اثبات می‌کند. برای هر سناریو داده آغاز، اقدام، نتیجه، مجوز و رفتار خطا بنویسید. معیار باید برای تیم کسب‌وکار قابل فهم و برای آزمون تکرارپذیر باشد. یک دمو با داده تمیز، آزمون مهاجرت، حجم، امنیت و استثنا را جایگزین نمی‌کند.
اولویت و تغییر نیازمندی چگونه مدیریت می‌شود؟
GAO در راهنمای Agile مدیریت نیازمندی را فعالیتی پیوسته می‌داند که ردیابی از نیاز کسب‌وکار تا طراحی و آزمون را حفظ می‌کند. اولویت را با ارزش، ریسک، وابستگی و هزینه تأخیر تعیین کنید؛ سپس تغییر را با دلیل، اثر روی زمان و هزینه، مالک تصمیم و نسخه ثبت کنید. قفل‌کردن همه جزئیات در ابتدا و تغییر بی‌رد هر دو خطرناک‌اند.
الگوی کوتاه ثبت نیازمندی چیست؟
- شناسه و عنوان یکتا
- هدف یا نیاز کسب‌وکاری پشتیبان
- نقش و سناریوی استفاده
- رفتار یا قاعده مورد انتظار
- داده، منبع و سطح حساسیت
- استثنا و رفتار خطا
- معیار پذیرش و داده آزمون
- اولویت، مالک و وابستگی
- نسخه، وضعیت و تاریخ تصمیم
این الگو می‌تواند پیوست نمونه RFP نرم‌افزار اختصاصی باشد تا همه پیشنهاددهندگان یک دامنه و روش پاسخ یکسان داشته باشند. لازم نیست صدها ردیف از روز اول نوشته شود؛ سناریوهای حیاتی و ریسک‌های بزرگ را زودتر دقیق کنید و جزئیات نزدیک به اجرا را با کاربر و تیم تحویل پالایش کنید.
پرسش‌های پرتکرار
آیا User Story برای نیازمندی کافی است؟
برای زمینه کاربر مفید است، اما قواعد، داده، کیفیت، استثنا و معیار پذیرش ممکن است به اقلام مکمل نیاز داشته باشند.
چه کسی باید نیازمندی را تأیید کند؟
مالک کسب‌وکاری نتیجه و اولویت را تأیید می‌کند؛ کاربران، داده، امنیت و فنی نیز بخش مربوط به خود را بازبینی می‌کنند.
آیا همه نیازمندی‌ها باید قبل از قرارداد کامل باشند؟
خیر، اما هدف، دامنه، سناریوهای حیاتی، ریسک‌های بزرگ، روش کشف و قرارداد تغییر باید برای برآورد و انتخاب روشن باشند.
چگونه از افزایش بی‌پایان دامنه جلوگیری کنیم؟
با خط مبنای نسخه، اولویت روشن، ثبت درخواست تغییر، تحلیل اثر و تصمیم صریح درباره جایگزینی یا افزودن کار.