منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مهر ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

نیازمندی‌های غیرکارکردی (Non-Functional Requirements) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

دو اپ خرید بلیت را کنار هم بگذارید. هر دو جست‌وجوی مسیر دارند، انتخاب صندلی دارند و پرداخت آنلاین. روی کاغذ، فهرست قابلیت‌هایشان یکی است.

ولی یکی روی اینترنت همراه در یک ثانیه نتیجه می‌دهد و دیگری در هشت ثانیه. یکی با صفحه‌خوان کار می‌کند و دیگری نه. یکی شب عید از دسترس خارج می‌شود و دیگری سر پا می‌ماند.

کاربر این دو را یک محصول نمی‌بیند. فرقشان در کیفیت است، و نیازمندی‌های غیرکارکردی همین کیفیت را می‌نویسند.

نیازمندی غیرکارکردی چیست؟

نیازمندی غیرکارکردی می‌گوید سیستم یک کار را با چه کیفیتی انجام دهد. نیازمندی کارکردی می‌گوید سیستم چه کاری انجام دهد. اولی دربارهٔ «چقدر خوب» است و دومی دربارهٔ «چه».

الگوی جمله‌شان هم فرق دارد. نیازمندی کارکردی معمولاً به شکل «سیستم باید فلان کار را بکند» نوشته می‌شود. نیازمندی غیرکارکردی به شکل «سیستم باید فلان‌طور باشد» یا «باید به فلان سطح کیفیت برسد».

«کاربر بتواند عکس بارگذاری کند» کارکردی است. «بارگذاری عکس زیر سه ثانیه تمام شود» غیرکارکردی است. به این دسته «صفت‌های کیفی» یا «محدودیت‌های طراحی» هم می‌گویند.

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

شش کیفیتی که کاربر حس می‌کند

منبع شش دسته را نام می‌برد که مستقیم به تجربهٔ کاربر می‌رسند. کاربر اسم هیچ‌کدام را نمی‌داند، ولی همه را حس می‌کند.

کارایی: زمان بارگذاری، زمان پاسخ به یک کنش، و اینکه سیستم زیر بار چند درخواست را تحمل می‌کند.

کاربردپذیری: اینکه کاربر تازه‌وارد چقدر طول می‌کشد اولین کارش را تمام کند، و چند درصد کاربران بی‌کمک به پایان می‌رسند.

دسترس‌پذیری: کنتراست رنگ، کار با صفحه‌کلید، سازگاری با صفحه‌خوان و متن جایگزین تصویر. اینجا معیار آماده وجود دارد، یعنی سطح AA در WCAG. همین معیار مثلاً برای متن معمولی کنتراست دست‌کم ۴٫۵ به ۱ می‌خواهد.

امنیت: روش ورود، قاعدهٔ رمز، زمان پایان نشست و رمزنگاری داده.

اطمینان‌پذیری: درصد در دسترس بودن، سقف خطا و زمان بازگشت بعد از خرابی. منبع نکتهٔ درستی دارد: رفتار پایدار اعتمادی می‌سازد که هیچ قابلیت چشمگیری نمی‌سازد.

سازگاری: مرورگرها، سیستم‌عامل‌ها، اندازهٔ صفحه‌ها و شرایط شبکه‌ای که محصول باید در آن‌ها کار کند. این دسته تعیین می‌کند محصول به دست چه کسانی اصلاً می‌رسد.

دو کیفیت دیگر هم هست که کاربر مستقیم نمی‌بیند: نگهداشت‌پذیری و مقیاس‌پذیری. اولی می‌گوید تغییر دادن سیستم چقدر ارزان است و دومی می‌گوید با دو برابر شدن کاربران چه می‌شود. این دو دیر یا زود به شکل کندی یا باگ به تجربه می‌رسند.

از «سریع» تا عدد

مشکل اصلی نیازمندی غیرکارکردی این نیست که فراموش می‌شود. مشکل این است که به شکل یک صفت نوشته می‌شود. «سیستم باید سریع باشد»، «امن باشد»، «کاربرپسند باشد».

هیچ‌کس با این جمله‌ها مخالف نیست و مشکل همین است. جمله‌ای که مخالف ندارد، تصمیمی هم نمی‌گیرد و در پایان پروژه نمی‌شود گفت برآورده شده یا نه.

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

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

قدم دوم، عدد: «نتیجه زیر یک ثانیه بیاید». عدد را هم نباید از هوا گرفت. جیکوب نیلسن سال‌ها پیش سه آستانه برای زمان پاسخ گذاشت. یک‌دهم ثانیه مرز حس آنی بودن است و یک ثانیه مرزی که رشتهٔ فکر کاربر پاره نمی‌شود. ده ثانیه هم مرزی است که بعد از آن توجهش را از دست می‌دهیم.

قدم سوم، سهم: «برای ۹۵ درصد درخواست‌ها». هیچ سیستمی همیشه زیر یک ثانیه جواب نمی‌دهد. اگر سهم را ننویسید، یک درخواست کند کافی است تا نیازمندی نقض شود، یا برعکس، میانگین خوب همهٔ درخواست‌های کند را پنهان کند. گوگل هم برای سنجه‌های Core Web Vitals صدک ۷۵ بارگذاری‌ها را ملاک می‌گیرد، نه میانگین.

قدم چهارم، شرایط: «روی اینترنت همراه». یک ثانیه روی وای‌فای دفتر با یک ثانیه روی گوشی میان‌رده در مترو یکی نیست. شرایط را که ننویسید، تیم ناخواسته بهترین شرایط را فرض می‌کند.

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

پیشنهاد دیگر منبع به نظرم از خود قالب مهم‌تر است: نیازمندی را به یک آدم واقعی گره بزنید. «ورود زیر سه ثانیه» یک عدد است. «کارمندی که ساعتی دویست پرونده ثبت می‌کند و هر بار باید دوباره وارد شود» دلیل آن عدد است. عدد بدون دلیل، اولین جایی است که زیر فشار زمان بندی کنار گذاشته می‌شود. برای اینکه این عددها بعد از انتشار هم پایش شوند، سراغ سنجه‌های تجربهٔ کاربری بروید.

هر عدد یک تصمیم طراحی است

این بخش در منبع نیست. معمولاً نیازمندی غیرکارکردی را کار مهندسی می‌دانند، چیزی که طراح تحویل می‌دهد و تیم فنی برآورده می‌کند. به نظر من برعکس است. این عددها شکل رابط را تعیین می‌کنند.

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

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

درصد در دسترس بودن هم یک تصمیم طراحی است. ۹۹٫۹ درصد در سال یعنی حدود هشت ساعت و ۴۵ دقیقه از کار افتادن مجاز. پس سؤال طراحی این است که کاربر در آن هشت ساعت چه می‌بیند. یک صفحهٔ خطای خالی، یا پیامی که می‌گوید کی برگردد و سبد خریدش سر جایش است؟

پس نیازمندی غیرکارکردی باید پیش از طراحی نوشته شود، نه بعد از آن. اگر در مشخصات طراحی یا لحظهٔ تحویل طراحی تازه معلوم شود که پاسخ سرور چهار ثانیه طول می‌کشد، طرحی که برای پاسخ آنی کشیده شده باید دوباره کشیده شود.

وقتی کیفیت‌ها با هم می‌جنگند

منبع در جمع‌بندی‌اش فقط یک جمله دربارهٔ موازنه دارد: موازنه‌ها را آگاهانه انجام دهید. این بخش تلاش من است برای اینکه بگویم آن موازنه‌ها کجا هستند.

شناخته‌شده‌ترین کشمکش میان امنیت و کاربردپذیری است. مثال خود منبع را ببینید: حساب بعد از پنج تلاش ناموفق در پانزده دقیقه قفل شود. این جلوی حدس زدن رمز را می‌گیرد. ولی کاربری که رمزش را فراموش کرده هم پشت در می‌ماند و تماس‌های پشتیبانی بالا می‌رود.

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

همهٔ کیفیت‌ها هم با هم دعوا ندارند. دسترس‌پذیری و کاربردپذیری تقریباً همیشه هم‌جهت‌اند. کنتراست بهتر، هدف لمسی بزرگ‌تر و برچسب روشن برای همه کار می‌کند، نه فقط برای کاربر کم‌بینا. کارایی هم معمولاً به کاربردپذیری کمک می‌کند.

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

کی و کجا وارد کار می‌شوند

منبع روشن می‌گوید این نیازمندی‌ها را باید در همان برنامه‌ریزی اولیه شناخت، پیش از آنکه معماری سیستم قطعی شود. عوض کردن زمان پاسخ در هفتهٔ آخر معمولاً یعنی عوض کردن معماری.

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

شکایت کاربران از رقبا هم منبع خوبی است. گفت‌وگو با تیم امنیت و پشتیبانی محدودیت‌هایی را نشان می‌دهد که طراح نمی‌داند. داده‌های استفاده هم می‌گویند کاربران با چه دستگاهی می‌آیند و کجا کار را رها می‌کنند.

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

در بافت فارسی

چند نیازمندی غیرکارکردی در محصول فارسی وزن متفاوتی دارند و در منبع نیامده‌اند.

یک: کارایی را روی شبکهٔ واقعی بسنجید. کاربر ایرانی اغلب با اینترنت همراه، در ساعت شلوغ و گاهی با فیلترشکن روشن وارد می‌شود. فیلترشکن مسیر درخواست را طولانی‌تر می‌کند. بعضی سرویس‌های خارجی هم ممکن است از داخل در دسترس نباشند یا فقط گاهی باز شوند. پس بخش شرایط در نیازمندی کارایی باید همین وضعیت را بنویسد. هر وابستگی به سرویس خارجی، مثل فونت یا اسکریپت تحلیل یا نقشه، را هم یک خطر برای اطمینان‌پذیری ببینید.

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

سه: ورودی فارسی را بی‌قید بپذیرید. کاربر شمارهٔ موبایلش را گاهی با ارقام فارسی می‌نویسد و گاهی با لاتین. صفحه‌کلیدهای عربی هم «ی» و «ک» عربی تولید می‌کنند که با نسخهٔ فارسی یکی به نظر می‌رسند و در جست‌وجو یکی نیستند. این‌ها را معمولاً باگ می‌دانند، ولی در اصل یک نیازمندی سازگاری‌اند. بنویسید که همهٔ این شکل‌ها پذیرفته و یکسان‌سازی شوند. جزئیاتش را در قالب بخشنده آورده‌ایم.

چهار: اطمینان‌پذیری تا برگشت از درگاه بانک ادامه دارد. در پرداخت اینترنتی، کاربر به صفحهٔ بانک می‌رود و باید به محصول شما برگردد. اگر این برگشت شکست بخورد، ممکن است پول از حساب کم شده باشد و سفارشی ثبت نشده باشد. این بدترین لحظهٔ اعتماد است. نیازمندی در دسترس بودن شما باید این مسیر را هم پوشش دهد. یعنی بنویسید اگر پاسخ بانک نرسید، سیستم وضعیت را چطور پیگیری می‌کند و کاربر در این فاصله چه می‌بیند.

جمع‌بندی

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

بزرگ‌ترین خطر این نیازمندی‌ها صفت ماندنشان است. «سریع» و «امن» تا عدد و سهم و شرایط و روش سنجش نگیرند، فقط آرزو هستند.

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

اگر بخواهم یک پرسش بگذارم: در سند نیازمندی محصولتان، چند جمله هست که با «باید سریع باشد» یا «باید امن باشد» تمام می‌شود و هیچ عددی ندارد؟