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

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

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

«یک توستر با دو شکاف.» این یک نیازمندی کارکردی است.

«توستر باید با برق ۲۲۰ ولت کار کند.» این یکی نیست — و اگر فراموشش کنید، توستر دوشکافهٔ شما در خانهٔ مشتری روشن نمی‌شود.

تعریف

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

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

در برابر نیازمندی غیرکارکردی

• - کارکردی: سیستم چه می‌کند. «وب‌سایت باید پرداخت آنلاین را امن پردازش کند.» یا «اپ به کاربر اجازه دهد عکس بارگذاری کند و پروفایلش را به‌روز کند.»
• - غیرکارکردی: سیستم چطور باید کار کند — یعنی صفت‌های کیفی. «وب‌سایت باید در کمتر از ۳ ثانیه بارگذاری شود.» یا «اپ باید رابط شهودی و ناوبری آسان داشته باشد.»

و ویلیام هادسون، راهبرد تجربهٔ کاربری و بنیان‌گذار سینتگم، نیازمندی‌های غیرکارکردی را همان محدودیت‌ها می‌داند.

و همین واژه بهترین راه فهمیدنشان است. محدودیت چیزی است که فهرست کارکردها را تغییر نمی‌دهد و می‌تواند همه‌شان را بی‌فایده کند.

از کجا می‌آیند

چهار منبع اصلی دارند:

• - پژوهش کاربر: مصاحبه، نظرسنجی، پرسش‌نامه، گروه کانونی.
• - پژوهش بازار: روندها، رقبا، استانداردهای صنعت.
• - پرسونا.
• - نقشهٔ سفر مشتری.

و بعد در قالب‌های مشخصی نوشته می‌شوند: داستان کاربر · مورد کاربرد · معیار پذیرش · سناریوی کاربر.

نیازمندی خوب چه شکلی است

• - اولویت‌بندی‌شده بر اساس اثرش بر کاربر.
• - روشن و مشخص، تا بتواند تصمیم طراحی را هدایت کند.
• - هم‌راستا با نیاز کاربر و هدف کسب‌وکار.
• - سنجش‌پذیر. مثل «۹۰ درصد کاربران باید کارهای کلیدی را در ۶۰ ثانیه یا کمتر تمام کنند.»
• - مستند، همراه با دلیلش.
• - و آزموده‌شده با نمونهٔ اولیه و آزمون کاربر.

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

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

وقتی اشتباه می‌شوند

ریسک نیازمندی‌های جاافتاده یا ناهم‌خوان، فهرست مشخصی از پیامدها دارد:

• - محصول نیاز کاربر را برآورده نمی‌کند.
• - رضایت و درگیری کاربر پایین می‌آید.
• - بازطراحی و دوباره‌کاری پرهزینه لازم می‌شود.
• - و زمان و هزینهٔ توسعه بالا می‌رود.

و مشکل‌های رایج جمع‌آوری هم شناخته‌شده‌اند: توازن میان نیاز کاربر و هدف کسب‌وکار · ناهم‌راستایی ذی‌نفعان · تغییر انتظارها · محدودیت منابع · و خزش دامنه.

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

یک آزمون برای هر نیازمندی

این بخش افزودهٔ من است، چون بیشتر سندهای نیازمندی پر از جمله‌هایی هستند که شبیه نیازمندی‌اند و نیستند.

هر جمله را با این بسنجید: «از کجا می‌فهمیم انجام شده؟»

«کاربر باید تجربهٔ خوبی داشته باشد» از این آزمون رد نمی‌شود. «کاربر باید بتواند سفارشش را بی تماس با پشتیبانی لغو کند» می‌شود.

و یک آزمون دوم هم لازم است، چون نیازمندی‌ها اغلب راه‌حل را جا می‌زنند: «این نیاز است یا راه‌حل؟»

«یک منوی کشویی برای انتخاب شهر بگذارید» راه‌حل است. نیاز، «کاربر باید بتواند سریع شهرش را انتخاب کند» بود — و برای شهرهای زیاد، منوی کشویی بدترین پاسخ به آن است.

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

در بافت فارسی

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

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

دو: راست‌به‌چپ‌بودن یک نیازمندی است، نه یک تنظیم. اگر در سند نیامده باشد، در تخمین هم نیامده — و بعد به‌عنوان «باگ ظاهری» ظاهر می‌شود.

و همین دربارهٔ تاریخ شمسی و ارقام فارسی و ترتیب نام هم صادق است. این‌ها ویژگی‌اند، نه محلی‌سازی.

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

پس یا ابزار سنجش را هم بخشی از نیازمندی کنید، یا معیار را به چیزی ببرید که بتوانید ببینید. مثلاً «در آزمون با پنج کاربر، هیچ‌کدام نپرسند این دکمه چه‌کار می‌کند».

چهار: نیازمندی شفاهی، مسئلهٔ اصلی است. بسیاری از تصمیم‌ها در جلسه گرفته می‌شوند و در هیچ سندی نمی‌نشینند.

و راه‌حلش سنگین نیست: یک فهرست ساده، با یک ستون برای دلیل و یک ستون برای اینکه چطور می‌فهمیم انجام شده. همین دو ستون، بیشتر دعواهای پایان پروژه را حذف می‌کند.

جمع‌بندی

• - نیازمندی کارکردی می‌گوید سیستم چه می‌کند · نیازمندی غیرکارکردی می‌گوید چطور باید کار کند
• - هادسون نیازمندی غیرکارکردی را همان محدودیت می‌داند · و محدودیت چیزی است که فهرست کارکردها را عوض نمی‌کند و می‌تواند همه‌شان را بی‌فایده کند
• - چهار منبع: پژوهش کاربر · پژوهش بازار · پرسونا · نقشهٔ سفر — و قالب‌ها: داستان کاربر، مورد کاربرد، معیار پذیرش، سناریو
• - نیازمندی خوب: اولویت‌بندی‌شده · روشن · هم‌راستا · سنجش‌پذیر · مستند با دلیل · و آزموده‌شده
• - سنجش‌پذیری بحث سلیقه‌ای را تمام می‌کند · و نیازمندی بی‌دلیل، شش ماه بعد قابل بازبینی نیست
• - ریسک جاافتادن: نارضایتی · بازطراحی پرهزینه · و بالارفتن زمان و هزینه · و برای تعارض، ماسکو
• - دو آزمون: «از کجا می‌فهمیم انجام شده؟» و «این نیاز است یا راه‌حل؟»
• - و در فارسی: نیازمندی نظارتی را اول فهرست کنید · راست‌به‌چپ ویژگی است نه تنظیم · سنجش‌پذیری بی ابزار سنجش بی‌معناست · و دو ستون دلیل و آزمون، بیشتر دعواها را حذف می‌کند