Non-Functional Requirement یا نیازمندی نان‌فانکشنال درباره کیفیت و محدودیت‌های عملکرد نرم‌افزار است. این نیازمندی پاسخ می‌دهد سیستم با چه سرعت، پایداری، امنیت، ظرفیت و شرایط عملیاتی باید قابلیت‌هایش را ارائه کند. یک NFR خوب باید تا حد ممکن قابل اندازه‌گیری و آزمایش باشد.
دسته‌های رایج نیازمندی‌های نان‌فانکشنال
| کیفیت | نمونه نیازمندی قابل بررسی |
|---|---|
| Performance | زمان پاسخ P95 API کاتالوگ زیر ۳۰۰ میلی‌ثانیه برای بار تعریف‌شده |
| Availability | دسترس‌پذیری سرویس سفارش ۹۹٫۹ درصد در ۳۰ روز |
| Scalability | پردازش سه برابر ترافیک عادی بدون کاهش فراتر از SLO |
| Security | کاربران فقط سفارش متعلق به خود را ببینند و ارتباط TLS باشد |
| Reliability | پس از شکست Worker، پیام‌های پردازش‌نشده از بین نروند |
| Maintainability | استقرار نسخه جدید بدون ویرایش دستی داده‌های عملیاتی انجام شود |
| Accessibility | فرم ثبت سفارش با کیبورد و صفحه‌خوان قابل استفاده باشد |
| Observability | هر درخواست شناسه ردیابی و متریک خطا داشته باشد |
چگونه NFR مبهم را به معیار روشن تبدیل کنیم؟
عبارت «سیستم باید سریع باشد» مبهم است. بهتر است بنویسیم «در آزمون بار با ۱۰۰ درخواست هم‌زمان و داده آزمایشی مشخص، زمان پاسخ P95 مسیر GET /products کمتر از ۳۰۰ میلی‌ثانیه باشد». حتی این عبارت نیز به محیط سخت‌افزار، منطقه و نوع داده وابسته است.
تفاوت با SLO و SLA
NFR می‌تواند هدف کیفیت محصول را در کل طراحی مشخص کند. SLO معمولاً هدف عملیاتی یک سرویس را با تکیه بر SLI تعیین می‌کند و SLA تعهد قراردادی است. این مفاهیم می‌توانند به هم مرتبط باشند، اما جای یکدیگر را نمی‌گیرند.
مهم‌ترین خطای تحلیل نیازمندی
افزودن عبارت «امن و مقیاس‌پذیر» به سند بدون تعریف مدل تهدید، بار کاری و معیار پذیرش، تضمین فنی ایجاد نمی‌کند. NFR باید قابل آزمایش و متناسب با بودجه پروژه باشد.
اصطلاحات فنی: نیازمندی فانکشنال، سیستم دیزاین، اس‌ال‌او، نیازمندی نان‌فانکشنال، مدیریت تهدیدات.