خانه / توسعه‌ نرم‌افزار / نیازمندی های عملکردی (FR) و نیازمندی‌های غیر عملکردی (NFR) چیست؟

نیازمندی های عملکردی (FR) و نیازمندی‌های غیر عملکردی (NFR) چیست؟

نیازمندی های عملکردی (FR) و نیازمندی‌های غیر عملکردی (NFR) چیست؟

نویسنده:

زمان مطالعه 10 دقیقه

انتشار:

به‌روزرسانی:

تعداد نظرات: 0

در هر پروژه حضور یک کارفرما به عنوان درخواست‌دهنده و یک تیم متخصص برای تحقق بخشیدن به اهداف، بدیهی است. تعریف دقیق و رسیدن به درکی مشترکی از (FR) Functional requirement و   (NFR) Non-Functional requirement به کارفرما و تیم پروژه این امکان را می‌دهد که نیازها را به درستی شناسایی و از بسیاری از هزینه‌ها و مشکلات آتی پیشگیری کنند. در این مقاله، نیازمندی‌های عملکردی یا Functional requirement را به اختصار FR و نیازمندی‌های غیر عملکردی Non-Functional requirement را به اختصار NFR می‌نامیم. با ما همراه باشید تا دو مفهوم FR و NFR را به صورت کامل بررسی کنیم. 

منظور از FR و NFR چیست؟  

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

در مقابل NFR یا همان نیازمندی های غیرعملکردی می‌گوید برای هر کدام از این نیازها، چه مواردی باید پیش‌بینی شود تا نرم‌افزار بتواند نیازمندی‌های کارفرما را به درستی پوشش دهد. 

به عنوان مثال کارفرما می‌گوید سامانه‌ای نیاز دارد تا دانشجویان بتوانند انتخاب واحد خود را به صورت آنلاین انجام دهند، حال تیم پروژه باید بتواند شرایطی ایجاد کند که در روزهای شلوغ ترم که تعداد زیادی از دانشجویان قصد انتخاب واحد دارند، سرویس‌دهی سامانه مطلوب باشد و با کندی مواجه نشود (NFR: Performance)، از طرف دیگر، اطلاعات واحدهای انتخاب شده توسط دانشجویان امن باشد و کسی نتواند واحدهای انتخاب‌شده سایر دانشجویان را ببیند یا دستکاری کند (NFR: Security).

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

نیازمندی غیر عملکردی نحوه عملکرد سیستم و چگونگی رفتار آن و همچنین محدودیت‌های آن را تعیین می‌کند. در حقیقت NFR نیازمندی‌هایی را نشان می‌دهد که توسط FR پوشش داده نشده‌ است. 

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

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

اهمیت NFR چیست؟

NFRها مولفه‌های کیفی سیستم هستند که روی انتظارات تمرکز می‌کنند. می‌توان گفت NFRها روی UX سیستم تاثیر می‌گذارند. در حقیقت آن‌ها کمک می‌کنند سیستم کاربری بهینه و آسانی داشته باشد و کارایی آن را بالا می‌برند. 

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

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

اهمیت NFR چیست؟

چه مواردی در FR باید در نظر گرفته شوند؟

در ادامه فهرستی از مواردی را که لازم است در FR به آن‌ها توجه ویژه داشته باشید، بیان خواهیم کرد: 

 نیازهای کسب و کار  (Business Requirements)

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

نیازهای اجرایی (Administrative Requirement)

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

نیازهای سیستم (System Requirements)

این نیاز می‌تواند شامل مشخصات نرم‌افزاری و سخت‌افزاری سیستم در حال طراحی باشد؛ سوالاتی مانند سیستم عامل لینوکس مورد نیاز است یا ویندوز؟ دیتابیس مورد نیاز Oracle باشد یا SQL Server؟  از چه ابزاری می‌خواهم استفاده کنم؟ سیستم را با چه IDE توسعه می‌دهم؟ سرعت شبکه چقدر باید باشد؟ در صورتی که برنامه روی اینترنت استفاده می‌شود، چه فایروال‌هایی نیاز دارد؟ در بحث امنیتی چه اتفاق‌هایی قرار است بیفتد؟ 

نیازهای کاربر (User Requirements)

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

نیازهای کاربر (User Requirements)

چه مواردی در NFR باید در نظر گرفته شوند؟

موارد قابل توجه در NFR به شرح زیر هستند:

کاربردی بودن (Usability)

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

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

قابل اطمینان بودن (Reliability)

بعضی از سیستم‌ها لازم است که ۳۶۵ روز سال، ۱۲ ماه، ۷ روز هفته و ۲۴ ساعته کار کنند. به طور مثال سیستم بآشگاه مشتریان آگاه باید همیشه در دسترس باشد. یعنی این سیستم نباید در طول شبانه‌روز از دسترس خارج شود. 

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

قابل اطمینان بودن، برای ادامه فعالیت، جلب اعتماد کاربران و موفقیت سیستم بسیار مهم و حیاتی است.

عملکرد (Performance)

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

قابلیت پشتیبانی (Supportability)

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

مقیاس‌پذیری (Scalability)

هنگام طراحی یک سیستم باید این موارد را در نظر داشت: ممکن است تعداد کاربران این سیستم افزایش پیدا کند؟ آیا سیستم طراحی‌شده امکان پردازش حجم اطلاعات زیادی را دارد؟ حداکثر ظرفیت پردازش چقدر است؟ پیش‌بینی‌هایی از این دست هنگام طراحی سیستم باعث می‌شود تجربه کاربری مناسبی ایجاد شود و از مشکلات احتمالی پیشگیری به عمل آید. برای مثال افزایش ناگهانی تعداد کاربرانی که از نرم‌افزارهای بورسی استفاده می‌کنند کاملا قابل لمس است. باید تمهیدات لازم برای سرویس‌دهی مناسب و مقایس‌پذیری در ابتدای پروژه انجام شود.

امنیت (Security)

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

جمع‌بندی

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

با ما همراه شوید!

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

علیرضا تابش نیم‌رخ

سوالات متداول

دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *