وقتی می‌گوییم «کاربر باید بتواند سفارش ثبت کند»، رفتار مورد انتظار نرم‌افزار را مشخص کرده‌ایم؛ اما هنوز معلوم نیست ثبت سفارش باید چقدر سریع باشد، زیر چه باری درست کار کند و در صورت قطع ارتباط چه اتفاقی بیفتد. این پرسش‌ها به نیازمندی‌های غیرعملکردی یا NFR مربوط‌اند. جست‌وجوی nfr معمولاً از همین مسئله شروع می‌شود: چگونه انتظارهایی مثل سرعت، امنیت و پایداری را به معیارهایی تبدیل کنیم که بتوان درباره پذیرش یا رد آن‌ها تصمیم گرفت؟
یک NFR خوب فقط صفتی مانند «سریع» یا «امن» ندارد؛ محدوده، شرایط، معیار پذیرش و روش ارزیابی آن روشن است. همین تفاوت، نیازمندی را از یک خواسته مبهم به ورودی قابل‌استفاده برای توسعه و تست تبدیل می‌کند.
nfr چیست و چه تفاوتی با نیازمندی عملکردی دارد؟
NFR مخفف Non-Functional Requirement، یعنی نیازمندی غیرعملکردی است. این نیازمندی‌ها معمولاً کیفیت ارائه رفتارهای سیستم یا محدودیت‌های حاکم بر آن را بیان می‌کنند.
نیازمندی عملکردی می‌گوید سیستم چه کاری انجام دهد؛ نیازمندی غیرعملکردی مشخص می‌کند آن کار با چه کیفیت و تحت چه شرایطی انجام شود.
| نیازمندی عملکردی | نیازمندی غیرعملکردی مرتبط |
|---|---|
| کاربر بتواند وارد حساب شود. | ورود تحت بار مشخص، در محدوده زمان پاسخ تعیین‌شده انجام شود. |
| مدیر بتواند گزارش سفارش‌ها را دریافت کند. | تولید گزارش با حجم داده تعریف‌شده، از زمان مجاز بیشتر نشود. |
| کاربر بتواند نشانی خود را ویرایش کند. | کاربر نتواند نشانی متعلق به حساب دیگری را تغییر دهد. |
| سیستم نسخه پشتیبان تهیه کند. | بازیابی از نسخه پشتیبان در محدوده زمان و میزان ازدست‌رفتن داده توافق‌شده ممکن باشد. |
مرز این دو همیشه قطعی نیست. برای مثال، کنترل دسترسی می‌تواند هم به‌صورت یک رفتار عملکردی و هم بخشی از نیازمندی امنیتی توصیف شود. مهم‌تر از دسته‌بندی، این است که انتظار قابل‌فهم، قابل‌ردیابی و قابل‌آزمون باشد.
غیرعملکردی به معنی کم‌اهمیت نیست. ممکن است تمام قابلیت‌های یک سامانه کار کنند، اما کندی، دسترس‌پذیری نامناسب یا ضعف امنیتی، استفاده از آن را ناممکن کند.
انواع نیازمندی‌های غیرعملکردی
برای کشف NFRها، بهتر است کیفیت‌های مهم محصول را جداگانه بررسی کنید:
- کارایی: زمان پاسخ، توان عملیاتی، نرخ خطا و مصرف منابع.
- مقیاس‌پذیری: رفتار سیستم هنگام افزایش کاربر، درخواست یا حجم داده.
- دسترس‌پذیری سرویس: میزان در دسترس بودن خدمت و شرایط محاسبه آن.
- قابلیت اطمینان و تاب‌آوری: رفتار هنگام خطا، قطع وابستگی یا اجرای طولانی‌مدت.
- امنیت و حریم خصوصی: کنترل دسترسی، حفاظت از داده و ثبت رویدادهای حساس.
- کاربردپذیری و دسترس‌پذیری رابط: امکان انجام کار توسط کاربران هدف، از جمله کاربران دارای نیازهای دسترسی متفاوت.
- نگهداشت‌پذیری و قابلیت مشاهده: سهولت تشخیص خطا، تغییر نرم‌افزار و بررسی وضعیت آن.
- سازگاری و قابلیت تعامل: کارکرد در مرورگرها، سیستم‌عامل‌ها و اتصال‌های تعیین‌شده.
همه محصولات به یک مجموعه یکسان نیاز ندارند. در سامانه پرداخت، یکپارچگی داده و کنترل دسترسی ممکن است اولویت بالاتری داشته باشد؛ در سامانه گزارش‌گیری، زمان تولید گزارش و حجم داده اهمیت بیشتری پیدا کند. انتخاب باید از ریسک و نیاز واقعی کسب‌وکار بیاید، نه از کپی‌کردن یک فهرست عمومی.
چرا NFRهای مبهم قابل تست نیستند؟
عبارت‌هایی مانند «سیستم باید سریع باشد» یا «رابط باید کاربرپسند باشد» برای شروع گفت‌وگو مفیدند، اما معیار پذیرش نیستند. توسعه‌دهنده، تستر و صاحب محصول ممکن است برداشت‌های متفاوتی از آن‌ها داشته باشند.
حتی افزودن یک عدد همیشه مشکل را حل نمی‌کند. «زمان پاسخ کمتر از دو ثانیه باشد» هنوز چند پرسش باز دارد:
- برای کدام عملیات؟
- زمان از چه نقطه‌ای تا چه نقطه‌ای اندازه‌گیری می‌شود؟
- چند کاربر یا چه نرخ درخواستی فعال است؟
- حجم داده و وضعیت کش چگونه است؟
- این حد برای همه درخواست‌هاست یا درصد مشخصی از آن‌ها؟
- خطاها، زمان انتظار و پاسخ‌های ناموفق چگونه محاسبه می‌شوند؟
قابلیت تست حاصل عددگذاری صرف نیست؛ حاصل حذف ابهام است. بعضی NFRها نیز با معیار دودویی یا بررسی شواهد ارزیابی می‌شوند، نه با یک شاخص عددی؛ مثلاً ممنوعیت ثبت رمز عبور در لاگ.
چگونه نیازمندی غیرعملکردی قابل تست بنویسیم؟
۱. از پیامد کسب‌وکاری شروع کنید
ابتدا روشن کنید چه مشکلی باید پیشگیری شود. «سرویس باید پایدار باشد» بسیار کلی است؛ «در صورت قطع سرویس پیامک، سفارش ثبت‌شده نباید از بین برود» به یک ریسک مشخص اشاره دارد.
پرسش‌های مفید عبارت‌اند از:
- چه اختلالی بیشترین آسیب را به کاربر می‌زند؟
- کدام داده نباید از دست برود یا افشا شود؟
- چه زمان یا شرایطی برای استفاده حیاتی است؟
- چه تعهد قراردادی، سازمانی یا قانونی باید رعایت شود؟
الزامات قانونی را بدون تعیین حوزه کاربرد و بررسی مسئول مربوط، به‌صورت حکم عمومی ننویسید.
۲. محدوده و شرایط را مشخص کنید
نام قابلیت، نسخه، محیط، داده و وابستگی‌های مؤثر را بنویسید. نتیجه تست یک API در محیط آزمایشی لزوماً بیانگر تجربه کامل کاربر در مرورگر نیست.
در نیازمندی کارایی، الگوی بار هم مهم است. «تعداد کاربران هم‌زمان» به‌تنهایی مشخص نمی‌کند هر کاربر چه کاری انجام می‌دهد یا چند درخواست می‌فرستد. ترکیب عملیات، نرخ درخواست و مدت اجرای آزمون باید متناسب با سناریو تعریف شوند.
۳. معیار پذیرش مناسب انتخاب کنید
برای زمان پاسخ، میانگین ممکن است تأخیرهای شدید بخشی از درخواست‌ها را پنهان کند. بسته به نیاز، صدک‌هایی مانند P95 می‌توانند مناسب‌تر باشند؛ یعنی زمان پاسخ ۹۵ درصد نمونه‌های اندازه‌گیری‌شده از حد تعیین‌شده بیشتر نباشد.
برای امنیت یا بازیابی، معیار متفاوت است: درخواست غیرمجاز رد شود، داده حساس در خروجی مشخص دیده نشود یا بازیابی در زمان توافق‌شده کامل شود.
آستانه را براساس نیاز کاربر، تعهد خدمت، داده موجود و امکان فنی تعیین کنید؛ نه صرفاً چون عددی رایج به نظر می‌رسد.
۴. روش ارزیابی و شاهد قبولی را بنویسید
مشخص کنید نیازمندی با چه روشی بررسی می‌شود: تست بار، تست منفی امنیتی، تمرین بازیابی، بررسی پیکربندی یا ارزیابی کاربردپذیری.
همه NFRها فقط با اجرای تست نرم‌افزاری اثبات نمی‌شوند. برخی به بازبینی معماری، بررسی مستندات یا پایش عملیاتی نیاز دارند. شاهد قبولی می‌تواند گزارش آزمون، لاگ پالایش‌شده یا صورت‌جلسه تمرین بازیابی باشد.
۵. مسئول، اولویت و ارتباط‌ها را ثبت کنید
هر NFR باید شناسه، مسئول تأیید و ارتباط با قابلیت‌های مربوط داشته باشد. همچنین روشن کنید عدم تحقق آن مانع انتشار است یا با پذیرش ریسک مستند می‌توان انتشار را انجام داد.
قالب پیشنهادی برای ثبت NFR
قالب زیر را می‌توان در سند نیازمندی یا ابزار مدیریت تست استفاده کرد:
| فیلد | محتوای مورد انتظار |
|---|---|
| شناسه و عنوان | شناسه یکتا و عنوان مشخص |
| هدف و ریسک | دلیل نیازمندی و پیامد عدم تحقق |
| محدوده | قابلیت، کاربران و اجزای مشمول |
| شرایط ارزیابی | محیط، داده، بار و وابستگی‌ها |
| معیار پذیرش | آستانه عددی یا نتیجه قابل‌بررسی |
| روش و شواهد | شیوه ارزیابی و خروجی لازم |
| مسئول و اولویت | تأییدکننده و اثر بر انتشار |
| ارتباط‌ها | نیازمندی، تست‌کیس، نقص و ریلیز مرتبط |
یک الگوی ساده برای جمله اصلی نیز این است:
«[قابلیت یا جزء] باید در [شرایط مشخص]، معیار [کیفیت موردنظر] را با [حد پذیرش] برآورده کند؛ این موضوع با [روش ارزیابی] بررسی می‌شود.»
نمونه نیازمندی‌های غیرعملکردی قابل تست
اعداد زیر صرفاً آموزشی‌اند و پیشنهاد عمومی برای همه محصولات نیستند. آستانه واقعی باید با ذی‌نفعان تعیین شود.
نمونه کارایی
مبهم: جست‌وجوی محصولات باید سریع باشد.
قابل تست: در محیط آزمون توافق‌شده، با یک میلیون رکورد محصول و بار ۵۰ درخواست جست‌وجو در ثانیه طی ۲۰ دقیقه، صدک ۹۵ زمان پاسخ API جست‌وجو حداکثر ۸۰۰ میلی‌ثانیه و نسبت پاسخ‌های خطادار حداکثر یک درصد باشد.
برای تکمیل این نیازمندی، ترکیب عبارت‌های جست‌وجو، وضعیت کش، دوره گرم‌شدن و تعریف پاسخ خطادار باید در سناریوی آزمون ثبت شود.
نمونه امنیت
مبهم: اطلاعات کاربران باید امن باشد.
قابل تست: کاربر دارای نقش مشتری، با تغییر شناسه سفارش در درخواست مشاهده جزئیات، نتواند اطلاعات سفارش متعلق به مشتری دیگری را دریافت کند؛ پاسخ نباید شامل داده شخصی یا محتوای سفارش هدف باشد.
ارزیابی باید نقش‌ها و مسیرهای دسترسی مرتبط را پوشش دهد. عبور از این تست، به‌تنهایی اثبات‌کننده امنیت کل سامانه نیست.
نمونه بازیابی
مبهم: سیستم باید قابلیت بازیابی داشته باشد.
قابل تست: در سناریوی خرابی تعریف‌شده پایگاه داده، خدمت سفارش‌گیری حداکثر طی ۶۰ دقیقه بازیابی شود و داده ازدست‌رفته از ۱۵ دقیقه بیشتر نباشد.
این دو حد به‌ترتیب با RTO، هدف زمان بازیابی، و RPO، هدف نقطه بازیابی، مرتبط‌اند. تأیید آن‌ها به تمرین بازیابی و بررسی صحت داده نیاز دارد؛ وجود فایل پشتیبان کافی نیست.
نمونه دسترس‌پذیری رابط
مبهم: فرم خرید باید برای همه قابل استفاده باشد.
قابل تست: در مرورگرهای مشمول، تکمیل فرم خرید بدون ماوس ممکن باشد؛ ترتیب فوکوس منطقی، نشانگر فوکوس قابل‌مشاهده و پیام خطا به فیلد مربوط متصل باشد.
این معیار فقط بخشی از دسترس‌پذیری را پوشش می‌دهد و جایگزین ارزیابی کامل براساس استاندارد توافق‌شده نیست.
از نیازمندی تا تست و تصمیم انتشار
پس از نوشتن NFR، مسیر اجرای آن را روشن کنید:
نیازمندی ← سناریوی ارزیابی ← تست‌کیس ← اجرا و شواهد ← نقص احتمالی ← تصمیم انتشار
برای هر نیازمندی، فقط سناریوی عادی ننویسید. شرایط مرزی و خرابی را هم بررسی کنید: افزایش بار، کندی وابستگی، داده حجیم یا دسترسی غیرمجاز.
آزمون‌های سریع و تکرارپذیر را می‌توان، در صورت امکان، وارد CI/CD کرد. تست‌های سنگین بار، تمرین بازیابی یا ارزیابی انسانی ممکن است برنامه جداگانه بخواهند.
در گزارش نتیجه، محیط، نسخه، شرایط و استثناها را حفظ کنید. برای مثال، یک تست کوتاه پایداری نمی‌تواند تعهد دسترس‌پذیری یک دوره طولانی را به‌تنهایی اثبات کند؛ چنین تعهدی معمولاً به تعریف روش محاسبه و شواهد عملیاتی نیز نیاز دارد.
خطاهای رایج در تدوین NFR
- ترکیب چند انتظار در یک جمله: «سریع، امن و پایدار» را به نیازمندی‌های مستقل بشکنید.
- تعیین راهکار به‌جای هدف: استفاده از یک فناوری خاص لزوماً کیفیت را تضمین نمی‌کند؛ اگر محدودیت معماری است، آن را جدا ثبت کنید.
- نبود الگوی بار واقعی: تعداد کاربر بدون رفتار و نرخ درخواست کافی نیست.
- تعیین حد بدون مسئول تأیید: عدد باید به نیاز و ریسک قابل‌توضیح متصل باشد.
- نادیده‌گرفتن تعارض‌ها: افزایش کنترل امنیتی یا کاهش مصرف منابع ممکن است بر تجربه و کارایی اثر بگذارد؛ مصالحه را مستند کنید.
تست‌ریل چگونه مدیریت NFRها را ساده‌تر می‌کند؟
پس از تعریف معیارها، چالش بعدی حفظ ارتباط میان نیازمندی، تست و نتیجه هر انتشار است. تست‌ریل تأمین‌کننده مستقل لایسنس رسمی TestRail و مجری استقرار آن در ایران است؛ مالکیت محصول TestRail متعلق به شرکت سازنده آن است.
با مدیریت تست‌کیس‌ها، Test Run و Test Plan می‌توان ارزیابی‌های مرتبط با NFRها را سامان داد. قابلیت ردیابی از نیازمندی تا ریلیز، اتصال به Jira و داشبورد و گزارش نیز به پیگیری پوشش آزمون‌ها و نتایج کمک می‌کنند. برای تست‌های خودکار، قابلیت‌های اتصال به اتوماسیون و CI/CD قابل‌استفاده‌اند؛ البته ابزار مدیریت تست جایگزین ابزار تولید بار یا ارزیابی تخصصی امنیت نیست.
مثلاً برای نیازمندی زمان پاسخ جست‌وجو، تیم می‌تواند تست‌کیس مرتبط را تعریف کند، اجرای آن را در برنامه تست ریلیز قرار دهد و نقص ناشی از عبور از آستانه را پیگیری کند.
خدمات تست‌ریل شامل تأمین لایسنس رسمی بدون کرک و نسخه Nulled، استقرار Cloud یا Server، مهاجرت از اکسل یا ابزار قبلی، آموزش و پشتیبانی فارسی است. امکان ماندن داده‌ها روی سرور داخلی شما یا ابر داخلی نیز وجود دارد. هزینه به مدل استقرار، تعداد کاربر و دوره لایسنس وابسته است و پس از نیازسنجی، پیش‌فاکتور مکتوب ارائه می‌شود؛ پرداخت ریالی و فاکتور رسمی نیز فراهم است.
سوالات متداول
آیا همه NFRها باید عددی باشند؟
خیر. برخی با معیار دودویی، چک‌لیست یا شواهد مشخص ارزیابی می‌شوند. مهم این است که تصمیم پذیرش به برداشت شخصی وابسته نباشد.
چه کسی مسئول نوشتن NFR است؟
معمولاً همکاری صاحب محصول، تحلیلگر، توسعه، QA و مسئولان زیرساخت یا امنیت لازم است. مسئول تأیید هر نیازمندی باید مشخص باشد.
تفاوت NFR با معیار پذیرش چیست؟
NFR یک انتظار کیفی یا محدودیت است؛ معیار پذیرش، شرط تحقق آن را مشخص می‌کند. یک NFR می‌تواند چند معیار پذیرش داشته باشد.
آیا NFRها فقط قبل از انتشار بررسی می‌شوند؟
خیر. برخی از ابتدا در طراحی اثر دارند، برخی در طول توسعه ارزیابی می‌شوند و برخی، مانند دسترس‌پذیری خدمت، به پایش پس از انتشار نیاز دارند.
آیا ابزار مدیریت تست، NFR مبهم را قابل تست می‌کند؟
خیر. ابتدا باید محدوده، شرایط و معیار پذیرش روشن شود. ابزار، ثبت، اجرا و پیگیری این توافق را منظم‌تر می‌کند.
برای شروع، یک NFR پرریسک محصول را انتخاب کنید و آن را تا مرحله معیار پذیرش و شاهد قبولی کامل کنید. اگر می‌خواهید این مسیر را در سطح تیم منظم کنید، از طریق شروع کار با تست‌ریل گزینه «درخواست برآورد» یا «مشاهده دمو» را بررسی کنید تا انتخاب ابزار و مدل استقرار براساس نیاز واقعی شما انجام شود.
