مقالات تجربه کاربری - نیازمندیهای کارکردی
نیازمندیهای کارکردی
نیازمندیهای کارکردی 
نیازمندیهای کارکردی (Functional Requirements) چیست؟
💡 این متن «بازنویسی آزاد» است: ایدهها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثالهای تازه بازگو شدهاند و ترجمهٔ کلمهبهکلمه نیست. بخشهای افزودهٔ مترجم در جعبهٔ منبع مشخص شدهاند.
«یک توستر با دو شکاف.» این یک نیازمندی کارکردی است.
«توستر باید با برق ۲۲۰ ولت کار کند.» این یکی نیست — و اگر فراموشش کنید، توستر دوشکافهٔ شما در خانهٔ مشتری روشن نمیشود.
تعریف
نیازمندیهای کارکردی مجموعهای از رهنمودهاست که کارکردها و قابلیتها و ویژگیهای لازم یک راهحل را مشخص میکند تا نیاز کاربر و هدف کسبوکار برآورده شود.
و بهطور مشخص، نیازمندی کارکردی میگوید سیستم چه میکند — یعنی چه کنش یا رفتاری در پاسخ به چه ورودیای نشان میدهد.
در برابر نیازمندی غیرکارکردی
- - کارکردی: سیستم چه میکند. «وبسایت باید پرداخت آنلاین را امن پردازش کند.» یا «اپ به کاربر اجازه دهد عکس بارگذاری کند و پروفایلش را بهروز کند.»
- - غیرکارکردی: سیستم چطور باید کار کند — یعنی صفتهای کیفی. «وبسایت باید در کمتر از ۳ ثانیه بارگذاری شود.» یا «اپ باید رابط شهودی و ناوبری آسان داشته باشد.»
و ویلیام هادسون، راهبرد تجربهٔ کاربری و بنیانگذار سینتگم، نیازمندیهای غیرکارکردی را همان محدودیتها میداند.
و همین واژه بهترین راه فهمیدنشان است. محدودیت چیزی است که فهرست کارکردها را تغییر نمیدهد و میتواند همهشان را بیفایده کند.
و این تفاوت یک پیامد سازمانی دارد که کمتر گفته میشود. نیازمندی کارکردی صاحب دارد و نیازمندی غیرکارکردی معمولاً ندارد.
کسی مسئول است که «کاربر بتواند سفارش را لغو کند» ساخته شود. ولی «صفحه در کمتر از سه ثانیه بیاید» یا «با صفحهخوان کار کند» معمولاً کار هیچکس نیست — کار همه است، که یعنی کار هیچکس.
و نتیجهاش قابلپیشبینی است: نیازمندیهای غیرکارکردی تا وقتی نقض نشدهاند دیده نمیشوند، و وقتی نقض میشوند، در انتهای پروژهاند و اصلاحشان گران است.
و درمانش هم ساده است و کم اجرا میشود: برای هر نیازمندی غیرکارکردی هم یک نفر را بنویسید. نه یک تیم — یک نام.
از کجا میآیند
چهار منبع اصلی دارند:
- - پژوهش کاربر: مصاحبه، نظرسنجی، پرسشنامه، گروه کانونی.
- - پژوهش بازار: روندها، رقبا، استانداردهای صنعت.
- - پرسونا.
- - نقشهٔ سفر مشتری.
و بعد در قالبهای مشخصی نوشته میشوند: داستان کاربر · مورد کاربرد · معیار پذیرش · سناریوی کاربر.
و انتخاب میان این قالبها دلبخواه نیست.
داستان کاربر وقتی خوب کار میکند که نیاز روشن است و راهحل باز. جملهاش کوتاه است و عمداً جزئیات را نمیگوید، تا فضای طراحی باز بماند.
مورد کاربرد وقتی لازم میشود که مسیر شاخه دارد. اگر جریان شما شش «اگر» دارد، داستان کاربر آنها را پنهان میکند و مورد کاربرد مجبورتان میکند بنویسیدشان.
و معیار پذیرش قالب نیست؛ ضمیمه است. به هر کدام از دوتای بالا وصل میشود و میگوید از کجا میفهمیم تمام شده.
و خطای رایج، نوشتن هر سه برای هر چیزی است. سندی که همهچیزش با یک دقت نوشته شده، وقتِ زیادی صرف بخشهای بیاهمیت کرده — و همان وقت از بخشهای شاخهدار کم آمده.
نیازمندی خوب چه شکلی است
- - اولویتبندیشده بر اساس اثرش بر کاربر.
- - روشن و مشخص، تا بتواند تصمیم طراحی را هدایت کند.
- - همراستا با نیاز کاربر و هدف کسبوکار.
- - سنجشپذیر. مثل «۹۰ درصد کاربران باید کارهای کلیدی را در ۶۰ ثانیه یا کمتر تمام کنند.»
- - مستند، همراه با دلیلش.
- - و آزمودهشده با نمونهٔ اولیه و آزمون کاربر.
و صفت چهارم بیشترین کار را میکند. نیازمندی سنجشپذیر، بحث سلیقهای را تمام میکند — چون یا عدد بهدست آمده یا نیامده.
و صفت پنجم کمارزشترین بهنظر میرسد و نیست. نیازمندی بیدلیل، شش ماه بعد قابل بازبینی نیست، چون کسی نمیداند برای چه اضافه شده بود.
و یک صفت هفتم هم هست که در فهرستهای متعارف کمتر میآید: نیازمندی خوب یک چیز را میگوید.
جملهای مثل «کاربر باید بتواند سفارشش را ببیند و لغو کند و پیگیری کند» سه نیازمندی است که با «و» به هم چسبیدهاند. و پیامدش عملی است: نمیشود جداگانه اولویتبندیشان کرد، نمیشود جداگانه تخمینشان زد، و وقتی دوتایش انجام شد و سومی نه، وضعیت آن سطر معلوم نیست.
و آزمونش ساده است: هر «و» در یک نیازمندی را نگاه کنید و بپرسید آیا میشود یکی از دو طرفش را بدون دیگری تحویل داد. اگر میشود، دو نیازمندی است.
وقتی اشتباه میشوند
ریسک نیازمندیهای جاافتاده یا ناهمخوان، فهرست مشخصی از پیامدها دارد:
- - محصول نیاز کاربر را برآورده نمیکند.
- - رضایت و درگیری کاربر پایین میآید.
- - بازطراحی و دوبارهکاری پرهزینه لازم میشود.
- - و زمان و هزینهٔ توسعه بالا میرود.
و مشکلهای رایج جمعآوری هم شناختهشدهاند: توازن میان نیاز کاربر و هدف کسبوکار · ناهمراستایی ذینفعان · تغییر انتظارها · محدودیت منابع · و خزش دامنه.
و برای نیازمندیهای متعارض، ابزار پیشنهادی روش ماسکوست، بههمراه درگیرکردن ذینفعان و تحلیل موازنه و مستندکردن دلیل تصمیم.
یک آزمون برای هر نیازمندی
این بخش افزودهٔ من است، چون بیشتر سندهای نیازمندی پر از جملههایی هستند که شبیه نیازمندیاند و نیستند.
هر جمله را با این بسنجید: «از کجا میفهمیم انجام شده؟»
«کاربر باید تجربهٔ خوبی داشته باشد» از این آزمون رد نمیشود. «کاربر باید بتواند سفارشش را بی تماس با پشتیبانی لغو کند» میشود.
و یک آزمون دوم هم لازم است، چون نیازمندیها اغلب راهحل را جا میزنند: «این نیاز است یا راهحل؟»
«یک منوی کشویی برای انتخاب شهر بگذارید» راهحل است. نیاز، «کاربر باید بتواند سریع شهرش را انتخاب کند» بود — و برای شهرهای زیاد، منوی کشویی بدترین پاسخ به آن است.
و همانطور که در مشخصات طراحی نوشتم، نیازمندی که راهحل را از قبل تعیین کرده، فضای طراحی را پیش از شروع بسته است.
و یک آزمون سوم هم هست که بهندرت اجرا میشود و بیشترین چیز را نشان میدهد: «اگر این را نسازیم چه میشود؟»
در بیشتر سندها، پاسخ صادقانهٔ این پرسش برای بخش بزرگی از سطرها «هیچچیز خاصی» است. آن سطرها از سر عادت، از سر مقایسه با رقیب، یا از سر یک جلسهٔ فراموششده آنجا هستند.
و نکتهٔ ظریفش این است که این پرسش را باید پیش از اولویتبندی پرسید، نه در حینش. اولویتبندی فرض میگیرد همهٔ سطرها لازماند و فقط ترتیبشان مسئله است. این پرسش، فرض را میشکند.
نیازمندی از کجا خراب میشود
و در عمل، نیازمندیها معمولاً غلط نوشته نمیشوند؛ درست نوشته میشوند و بعد از واقعیت جدا میافتند.
چهار مسیر رایج برای این جدایی هست.
یک: تصمیم در پیادهسازی گرفته میشود و به سند برنمیگردد. توسعهدهنده به موردی میخورد که سند دربارهٔ آن ساکت است، انتخابی میکند، و کار جلو میرود. آن انتخاب حالا رفتار محصول است و در هیچ سندی نیست.
دو: نیازمندی حذف میشود ولی دلیلش نه. سطری از دامنه بیرون میرود و کسی نمینویسد چرا. شش ماه بعد کسی همان را دوباره پیشنهاد میدهد و بحث از اول شروع میشود.
سه: قید بیرونی عوض میشود. قاعدهای که نیازمندی بر پایهاش نوشته شده بود دیگر برقرار نیست، و نیازمندی هنوز سر جایش است — درست بهنظر میرسد و دیگر معنا ندارد.
چهار: سند به دو نسخه تبدیل میشود. یکی که رسمی است و یکی که در پیامرسان زندگی میکند. و تیم به دومی عمل میکند.
و درمان هر چهارتا یکی است و ساده: سند باید یک جای مشخص داشته باشد و تغییرش باید ارزان باشد. سندی که بهروزکردنش سخت است، بهروز نمیشود — و بعد نبودنش بهتر از بودنش بود، چون کسی به سند غلط اعتماد میکند.
در بافت فارسی
یک: نیازمندیهای نظارتی اینجا وزن بیشتری دارند و دیرتر معلوم میشوند. الزام احراز هویت، سقف تراکنش، قاعدهٔ درگاه، نگهداشت داده.
و بیشترشان غیرکارکردیاند، پس در جلسههای محصول کمتر مطرح میشوند. یک بار در ابتدای پروژه صریح فهرستشان کنید، وگرنه در هفتهٔ آخر خودشان را نشان میدهند.
دو: راستبهچپبودن یک نیازمندی است، نه یک تنظیم. اگر در سند نیامده باشد، در تخمین هم نیامده — و بعد بهعنوان «باگ ظاهری» ظاهر میشود.
و همین دربارهٔ تاریخ شمسی و ارقام فارسی و ترتیب نام هم صادق است. اینها ویژگیاند، نه محلیسازی.
سه: سنجشپذیرکردن اینجا سختتر است، چون داده کمتر است. اگر ابزار سنجش ندارید، «۹۰ درصد در ۶۰ ثانیه» فقط یک جملهٔ زیباست.
پس یا ابزار سنجش را هم بخشی از نیازمندی کنید، یا معیار را به چیزی ببرید که بتوانید ببینید. مثلاً «در آزمون با پنج کاربر، هیچکدام نپرسند این دکمه چهکار میکند».
چهار: نیازمندی شفاهی، مسئلهٔ اصلی است. بسیاری از تصمیمها در جلسه گرفته میشوند و در هیچ سندی نمینشینند.
و راهحلش سنگین نیست: یک فهرست ساده، با یک ستون برای دلیل و یک ستون برای اینکه چطور میفهمیم انجام شده. همین دو ستون، بیشتر دعواهای پایان پروژه را حذف میکند.
پنج: تخمین اینجا اغلب پیش از نیازمندی خواسته میشود. «چقدر طول میکشد؟» قبل از اینکه معلوم باشد دقیقاً چه چیزی قرار است ساخته شود.
و پاسخ حرفهایاش نه «نمیدانم» است و نه یک عدد از هوا. یک بازه بدهید و بگویید چه چیزی آن را باریک میکند: «بین دو تا شش هفته؛ اگر تا پنجشنبه معلوم شود احراز هویت چطور کار میکند، میشود دو تا سه.»
و همین جمله دو کار میکند. عدد را میدهد، و هزینهٔ نامعلومبودن نیازمندی را قابلدیدن میکند — که تنها راه واقعی برای گرفتن وقتِ نوشتن آن است.
جمعبندی
- - نیازمندی کارکردی میگوید سیستم چه میکند · نیازمندی غیرکارکردی میگوید چطور باید کار کند
- - هادسون نیازمندی غیرکارکردی را همان محدودیت میداند · و محدودیت چیزی است که فهرست کارکردها را عوض نمیکند و میتواند همهشان را بیفایده کند
- - چهار منبع: پژوهش کاربر · پژوهش بازار · پرسونا · نقشهٔ سفر — و قالبها: داستان کاربر، مورد کاربرد، معیار پذیرش، سناریو
- - نیازمندی خوب: اولویتبندیشده · روشن · همراستا · سنجشپذیر · مستند با دلیل · و آزمودهشده
- - سنجشپذیری بحث سلیقهای را تمام میکند · و نیازمندی بیدلیل، شش ماه بعد قابل بازبینی نیست
- - ریسک جاافتادن: نارضایتی · بازطراحی پرهزینه · و بالارفتن زمان و هزینه · و برای تعارض، ماسکو
- - دو آزمون: «از کجا میفهمیم انجام شده؟» و «این نیاز است یا راهحل؟»
- - و در فارسی: نیازمندی نظارتی را اول فهرست کنید · راستبهچپ ویژگی است نه تنظیم · سنجشپذیری بی ابزار سنجش بیمعناست · و دو ستون دلیل و آزمون، بیشتر دعواها را حذف میکند
منبع
این نوشته «بازنویسی آزاد» است از مطلب What are Functional Requirements? در وبسایت بنیاد طراحی تعامل (Interaction Design Foundation — IxDF؛ بدون نام نویسندهٔ مشخص). مفاهیم پایه — تعریف نیازمندیهای کارکردی و اینکه سیستم چه میکند در پاسخ به ورودی، تفکیک از نیازمندی غیرکارکردی بههمراه هر چهار مثال پرداخت امن و بارگذاری عکس و بارگذاری زیر سه ثانیه و رابط شهودی، قیاس توستر با شکافها و ولتاژ، معرفی ویلیام هادسون بنیانگذار سینتگم و دیدگاهش دربارهٔ محدودیتبودن نیازمندی غیرکارکردی، هر چهار منبع جمعآوری یعنی پژوهش کاربر و پژوهش بازار و پرسونا و نقشهٔ سفر، قالبهای نوشتن شامل داستان کاربر و مورد کاربرد و معیار پذیرش و سناریو، همهٔ صفتهای نیازمندی خوب شامل اولویتبندیشده و روشن و همراستا و سنجشپذیر با مثال ۹۰ درصد در ۶۰ ثانیه و مستند با دلیل و آزمودهشده، فهرست پیامدهای نیازمندی جاافتاده یا ناهمخوان، فهرست مشکلهای رایج جمعآوری از جمله خزش دامنه، و پیشنهاد روش ماسکو برای نیازمندیهای متعارض بههمراه درگیرکردن ذینفعان و تحلیل موازنه و مستندکردن دلیل — از این منبع گرفته شده. متن فارسی، ساختار بخشها و همهٔ تحلیلها کاملاً مستقل نوشته شدهاند.
متن مطلب اصلی تحت هیچ لایسنس بازی منتشر نشده است؛ به همین دلیل اینجا ترجمهٔ کلمهبهکلمه ارائه نشده و متن کامل انگلیسی (بههمراه همهٔ منابع مرتبط) در لینک زیر در دسترس است.
بخشهای افزودهٔ مترجم: صورتبندی آغازین با توستر دوشکافه و برق ۲۲۰ ولت؛ برجستهکردن واژهٔ «محدودیت» بهعنوان بهترین راه فهم نیازمندی غیرکارکردی و صورتبندیاش بهعنوان چیزی که فهرست کارکردها را عوض نمیکند و میتواند همهشان را بیفایده کند؛ استدلال اینکه سنجشپذیری بحث سلیقهای را تمام میکند و اینکه نیازمندی بیدلیل شش ماه بعد قابل بازبینی نیست؛ کل بخش «دو آزمون» شامل «از کجا میفهمیم انجام شده؟» و «این نیاز است یا راهحل؟» با مثال منوی کشویی انتخاب شهر و نتیجهاش دربارهٔ بستهشدن فضای طراحی؛ و کل بخش بافت فارسی شامل وزن بیشتر و دیرتر معلومشدن نیازمندی نظارتی و غیرکارکردیبودنشان، نیازمندیبودن راستبهچپ و تاریخ شمسی و ارقام فارسی بهجای محلیسازی، سختتر بودن سنجشپذیری در نبودِ ابزار سنجش و دو راهحلش، و مسئلهٔ نیازمندی شفاهی و راهحل دو ستونی دلیل و آزمون؛ پیامد سازمانی تفاوت کارکردی و غیرکارکردی یعنی بیصاحبماندن نیازمندی غیرکارکردی و درمانش با نوشتن یک نام؛ راهنمای انتخاب میان داستان کاربر و مورد کاربرد و معیار پذیرش و خطای نوشتن هر سه برای هر چیزی؛ افزودن صفت هفتم یعنی «یک چیز را میگوید» بههمراه آزمون «و» و پیامدهایش برای اولویتبندی و تخمین؛ و آزمون سوم «اگر این را نسازیم چه میشود؟» و اینکه باید پیش از اولویتبندی پرسیده شود نه در حینش؛ بخش «نیازمندی از کجا خراب میشود» شامل چهار مسیر جدایی سند از واقعیت — تصمیم پیادهسازینشده در سند، حذف بیدلیل، تغییر قید بیرونی، و دونسخهشدن سند — و درمان مشترکشان یعنی ارزانبودن بهروزرسانی؛ و نکتهٔ پنجم بافت فارسی دربارهٔ خواستهشدن تخمین پیش از نیازمندی و پاسخ بازهای مشروط که هزینهٔ نامعلومبودن را قابلدیدن میکند
تصاویر: هیچ تصویری از مطلب اصلی بازتولید نشده است. هر سه نمودار این صفحه طراحی مستقل مترجم است.
مشاهدهٔ مطلب اصلی
مترجم: سپنتا پویا
طراح ارشد محصول. مقالات تخصصی UI/UX را با حفظ ساختار و لحن نسخهٔ اصلی به فارسی برمیگردانم.
دربارهٔ من