FRS چیست؟ راهنمای کامل Functional Requirements Specification

در یک پروژه نرم‌افزاری، قبل از اینکه توسعه‌دهندگان شروع به پیاده‌سازی قابلیت‌های سیستم کنند، باید مشخص باشد که نرم‌افزار دقیقاً چه کاری باید انجام دهد و در برابر ورودی‌ها و شرایط مختلف چه رفتاری باید داشته باشد. اگر این نیازمندی‌ها به‌صورت شفاف و قابل بررسی مستند نشوند، احتمال برداشت‌های متفاوت بین Business، Product، Developer و Tester افزایش پیدا می‌کند.

یکی از اسنادی که برای مستندسازی این نیازمندی‌ها مورد استفاده قرار می‌گیرد، FRS یا Functional Requirements Specification است. سند FRS نیازمندی‌ها و عملکردهای مورد انتظار سیستم را با جزئیات مشخص می‌کند و می‌تواند به‌عنوان مرجعی برای توسعه و تست نرم‌افزار مورد استفاده قرار گیرد.

اما FRS چیست و دقیقاً چه چیزی را مشخص می‌کند؟ آیا FRS همان SRS یا FRD است؟ چه اطلاعاتی باید در یک سند FRS نوشته شود؟ چه کسی مسئول تهیه آن است و یک Software Tester چگونه می‌تواند از روی FRS، Test Scenario و Test Case طراحی کند؟

در این مقاله ابتدا مفهوم FRS و Functional Requirements Specification را بررسی می‌کنیم، سپس ساختار و محتوای یک سند FRS، نحوه نوشتن آن، یک نمونه واقعی و تفاوت آن با اسنادی مانند SRS، FRD، BRD و PRD را توضیح می‌دهیم. همچنین بررسی می‌کنیم که FRS چه نقشی در Software Testing و تبدیل Requirementها به تست‌های قابل اجرا دارد.

FRS چیست؟

FRS مخفف Functional Requirements Specification است و به سندی گفته می‌شود که عملکردها و رفتارهای مورد انتظار یک سیستم یا نرم‌افزار را به‌صورت مشخص و قابل بررسی مستند می‌کند.

به زبان ساده، FRS پاسخ می‌دهد:

سیستم باید چه کارهایی انجام دهد و در شرایط مختلف چگونه رفتار کند؟

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

FR-LOGIN-001: سیستم باید به کاربر اجازه دهد با وارد کردن شماره موبایل و رمز عبور معتبر وارد حساب کاربری خود شود.

این Requirement فقط نمی‌گوید «قابلیت Login وجود داشته باشد»، بلکه یک رفتار مورد انتظار سیستم را مشخص می‌کند که در ادامه می‌تواند مبنای توسعه، بررسی Requirement و طراحی تست قرار گیرد.

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

FRS مخفف چیست؟

FRS مخفف Functional Requirements Specification است.

معادل فارسی آن را می‌توان «سند مشخصات نیازمندی‌های عملکردی» یا «مشخصات نیازمندی‌های عملکردی» در نظر گرفت.

در برخی منابع و پروژه‌ها ممکن است شکل Functional Requirement Specification نیز برای نام FRS استفاده شود. همچنین اصطلاحاتی مانند Functional Specification، Functional Specification Document (FSD) و Functional Requirements Document (FRD) نیز در برخی سازمان‌ها برای اسناد مشابه به کار می‌روند. بنابراین هنگام مقایسه این اسناد باید به استاندارد و اصطلاحات مورد استفاده در همان پروژه توجه کرد.

Functional Requirements چیست؟

Functional Requirement یا نیازمندی عملکردی مشخص می‌کند که سیستم باید چه Function یا رفتاری را ارائه دهد.

برای مثال:

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

در واقع Functional Requirement درباره کاری است که سیستم باید انجام دهد، نه درباره نحوه پیاده‌سازی آن.

برای مثال، این Requirement مناسب است:

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

اما این مورد بیشتر به Implementation مربوط می‌شود:

سیستم باید برای احراز هویت از یک کلاس خاص در Backend استفاده کند.

FRS باید عمدتاً مشخص کند چه چیزی باید اتفاق بیفتد، نه اینکه توسعه‌دهنده دقیقاً چگونه آن را پیاده‌سازی کند. Functional Specification بر رفتار قابل مشاهده و نیازمندی‌های سیستم تمرکز دارد، نه جزئیات داخلی Implementation.

FRS چه چیزی را مشخص می‌کند؟

یک FRS می‌تواند جزئیات مختلفی درباره رفتار و عملکرد سیستم ارائه دهد، از جمله:

• قابلیت‌هایی که سیستم باید ارائه دهد
• ورودی‌هایی که سیستم دریافت می‌کند
• خروجی‌های مورد انتظار
• رفتار سیستم در شرایط مختلف
• قوانین کسب‌وکار مرتبط با Functionality
• شرایط خطا و Exceptionها
• تعامل با کاربران و سیستم‌های دیگر
• وابستگی‌ها و محدودیت‌های مرتبط با عملکرد سیستم

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

بنابراین یک FRS خوب فقط فهرستی از Featureها نیست؛ بلکه باید به اندازه‌ای دقیق باشد که تیم توسعه بتواند رفتار مورد انتظار سیستم را بفهمد و تیم تست بتواند آن رفتار را بررسی و Verify کند.

هدف از تهیه سند FRS چیست؟

تهیه سند FRS فقط برای ثبت کردن نیازمندی‌ها روی کاغذ نیست. هدف اصلی آن این است که رفتار و عملکرد مورد انتظار سیستم به شکلی شفاف، قابل فهم و قابل بررسی برای اعضای مختلف تیم مشخص شود.

در یک پروژه نرم‌افزاری، افراد مختلف ممکن است یک نیازمندی را از دیدگاه متفاوتی تفسیر کنند. Business Analyst ممکن است نیاز کسب‌وکار را یک‌طور برداشت کند، Developer بر اساس همان توضیحات راهکار دیگری در نظر بگیرد و Tester نیز انتظار متفاوتی از رفتار سیستم داشته باشد.

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

ایجاد درک مشترک از نیازمندی‌ها

یکی از مهم‌ترین اهداف FRS ایجاد یک زبان مشترک بین اعضای پروژه است.

برای مثال، عبارت زیر چندان دقیق نیست:

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

اما در یک FRS می‌توان این نیازمندی را دقیق‌تر بیان کرد:

سیستم باید به کاربر دارای نقش Customer Service اجازه دهد سفارش‌های ثبت‌شده را مشاهده و وضعیت آن‌ها را بر اساس قوانین تعریف‌شده تغییر دهد.

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

تبدیل نیاز کسب‌وکار به نیازمندی قابل اجرا

نیازهای اولیه کسب‌وکار معمولاً در سطحی کلی بیان می‌شوند. FRS کمک می‌کند این نیازها به رفتارها و Functionalityهای مشخص سیستم تبدیل شوند.

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

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

نیازمندی عملکردی:

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

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

ایجاد مبنایی برای توسعه نرم‌افزار

Developer برای پیاده‌سازی یک قابلیت باید بداند رفتار مورد انتظار سیستم چیست.

FRS می‌تواند به‌عنوان یکی از مراجع مورد استفاده در زمان Development قرار گیرد تا تیم توسعه بتواند Functionalityهای مورد نیاز را بر اساس Requirementهای مشخص پیاده‌سازی کند.

البته FRS لزوماً نباید جزئیات فنی Implementation را مشخص کند. تمرکز اصلی آن بر رفتار و قابلیت مورد انتظار سیستم است.

ایجاد مبنایی برای Software Testing

FRS از دید یک Software Tester اهمیت ویژه‌ای دارد؛ زیرا Requirementهای موجود در آن می‌توانند مبنایی برای طراحی تست باشند.

برای مثال، اگر FRS مشخص کند:

سیستم باید پس از ورود موفق کاربر، او را به Dashboard هدایت کند.

Tester می‌تواند بر اساس این Requirement سناریوهایی مانند موارد زیر را بررسی کند:

• ورود با اطلاعات صحیح
• ورود با رمز عبور اشتباه
• ورود با Username نامعتبر
• ورود با فیلدهای خالی
• رفتار سیستم پس از Login موفق
• رفتار سیستم در صورت خطای سرویس احراز هویت

بنابراین ارتباط میان FRS و تست را می‌توان به شکل زیر در نظر گرفت:

FRS → Test Scenario → Test Case → Test Execution → Defect

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

کاهش ابهام و اختلاف در طول پروژه

هرچه Requirementها مبهم‌تر باشند، احتمال بروز اختلاف نظر در مراحل بعدی بیشتر می‌شود.

فرض کنید در Requirement نوشته شده باشد:

سیستم باید سریع باشد.

این جمله از نظر تست و توسعه ابهام زیادی دارد. «سریع» دقیقاً یعنی چه؟

اما اگر نیازمندی به شکل قابل اندازه‌گیری تعریف شود:

سیستم باید نتیجه درخواست جستجوی محصول را حداکثر در 2 ثانیه، تحت شرایط مشخص‌شده، نمایش دهد.

اکنون Requirement بسیار واضح‌تر شده و می‌توان درباره نحوه پیاده‌سازی و تست آن تصمیم گرفت.

البته چنین Requirementی ممکن است دیگر صرفاً Functional Requirement نباشد و جنبه Non-Functional / Performance Requirement پیدا کند. بنابراین در FRS باید نوع و ماهیت هر Requirement نیز به‌درستی مشخص شود.

فراهم کردن امکان Traceability

یکی دیگر از اهداف مهم FRS، ایجاد ارتباط میان Requirementها و سایر فعالیت‌های پروژه است.

برای مثال:

Business Requirement
↓
Functional Requirement
↓
Test Scenario
↓
Test Case
↓
Test Result
↓
Defect

وجود شناسه‌های یکتا برای Requirementها مانند FR-LOGIN-001 کمک می‌کند بتوان هر Requirement را در مراحل بعدی پروژه دنبال کرد.

این موضوع در Requirements Traceability Matrix (RTM) اهمیت بیشتری پیدا می‌کند؛ زیرا می‌توان بررسی کرد که آیا Requirementهای تعریف‌شده به Test Caseهای مناسب مرتبط شده‌اند یا خیر.

FRS شامل چه اطلاعاتی است؟

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

به بیان ساده، وقتی یک Requirement در FRS نوشته می‌شود، باید تا حد امکان مشخص باشد:

چه کسی؟ → چه کاری؟ → با چه ورودی‌ای؟ → تحت چه شرایطی؟ → چه نتیجه‌ای دریافت می‌کند؟

برای مثال، به‌جای اینکه فقط بنویسیم:

کاربر بتواند سفارش خود را لغو کند.

بهتر است Requirement جزئیات بیشتری داشته باشد:

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

اکنون رفتار مورد انتظار سیستم بسیار واضح‌تر است و Tester نیز اطلاعات بیشتری برای طراحی تست در اختیار دارد.

عملکردهای اصلی سیستم

مهم‌ترین بخش FRS، مشخص کردن Functionalityهایی است که سیستم باید ارائه دهد.

برای مثال، در یک فروشگاه اینترنتی ممکن است Functionalityهای زیر تعریف شوند:

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

هر Functionality می‌تواند یک یا چند Requirement مستقل داشته باشد و بهتر است برای هر Requirement یک شناسه یکتا در نظر گرفته شود.

مثلاً:

FR-ORDER-001
FR-ORDER-002
FR-ORDER-003

این شناسه‌ها بعداً در Test Case، Bug Report یا Requirements Traceability Matrix نیز قابل استفاده هستند.

ورودی‌های سیستم

FRS باید مشخص کند سیستم چه Inputهایی را دریافت می‌کند و در صورت نیاز، شرایط مربوط به آن‌ها چیست.

برای مثال در Login:

• شماره موبایل
• رمز عبور

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

مثلاً:

شماره موبایل باید در قالب معتبر وارد شود.

یا:

رمز عبور باید حداقل شامل 8 کاراکتر باشد.

این اطلاعات برای Tester اهمیت زیادی دارند، زیرا می‌توانند مبنای طراحی تست‌های Valid، Invalid، Boundary و Negative قرار بگیرند.

خروجی و نتیجه مورد انتظار

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

برای مثال:

پس از پرداخت موفق، سیستم باید وضعیت سفارش را به «پرداخت‌شده» تغییر دهد.

یا:

در صورت ورود موفق، سیستم باید کاربر را به Dashboard هدایت کند.

خروجی می‌تواند شامل موارد مختلفی باشد:

• نمایش یک پیام
• تغییر وضعیت یک Entity
• ایجاد یک رکورد
• ارسال Notification
• انتقال کاربر به صفحه دیگر
• بازگرداندن Response مشخص از API
• انجام یک عملیات در سیستم دیگر

جریان‌های اصلی و جایگزین

بسیاری از Functionalityها فقط یک مسیر اجرای ساده ندارند.

برای همین FRS می‌تواند Main Flow و Alternative Flow را مشخص کند.

برای مثال در فرآیند پرداخت:

Main Flow:

1. کاربر سفارش را ثبت می‌کند.
2. سیستم مبلغ سفارش را محاسبه می‌کند.
3. کاربر به درگاه پرداخت هدایت می‌شود.
4. پرداخت با موفقیت انجام می‌شود.
5. سیستم نتیجه موفق را دریافت می‌کند.
6. وضعیت سفارش به «پرداخت‌شده» تغییر می‌کند.

اما ممکن است مسیرهای دیگری نیز وجود داشته باشد:

Alternative Flow:

• پرداخت ناموفق باشد.
• کاربر پرداخت را لغو کند.
• ارتباط با درگاه قطع شود.
• پاسخ درگاه دریافت نشود.
• مبلغ پرداخت‌شده با مبلغ سفارش مطابقت نداشته باشد.

این موارد برای طراحی تست بسیار ارزشمند هستند، زیرا Tester فقط مسیر موفق (Happy Path) را بررسی نمی‌کند.

Business Rules

گاهی عملکرد سیستم به قوانین کسب‌وکار وابسته است. این قوانین باید در FRS یا سند مرتبط به‌صورت واضح مشخص شوند.

برای مثال:

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

یا:

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

Business Ruleها می‌توانند مستقیماً روی رفتار سیستم تأثیر بگذارند و در نتیجه باید به شکلی نوشته شوند که قابل درک و در صورت امکان قابل تست باشند.

شرایط خطا و Exceptionها

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

برای مثال، در Login:

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

برای هرکدام از این شرایط ممکن است رفتار متفاوتی تعریف شود.

مثلاً:

پس از پنج تلاش ناموفق متوالی، سیستم باید حساب کاربر را برای مدت 15 دقیقه موقتاً مسدود کند.

این نوع Requirement بسیار ارزشمندتر از عبارتی مانند «سیستم باید در برابر خطاها رفتار مناسبی داشته باشد» است؛ زیرا رفتار مورد انتظار را مشخص می‌کند.

تعامل با سیستم‌های دیگر

اگر یک Functionality به سیستم یا سرویس دیگری وابسته باشد، این تعامل نیز ممکن است در FRS مشخص شود.

برای مثال در یک فروشگاه اینترنتی:

Online Store → Payment Gateway

یا:

Application → SMS Service

یا:

Application → Shipping Service

برای هر تعامل ممکن است مواردی مانند این‌ها مشخص شوند:

• چه زمانی درخواست ارسال می‌شود؟
• چه اطلاعاتی ارسال می‌شود؟
• پاسخ موفق چیست؟
• پاسخ ناموفق چیست؟
• اگر سرویس خارجی در دسترس نباشد چه اتفاقی می‌افتد؟

جزئیات فنی این تعامل ممکن است در اسناد دیگری مانند API Specification یا Technical Design Document قرار بگیرد؛ بنابراین FRS نباید الزاماً به جزئیات Implementation وارد شود.

محدودیت‌ها و وابستگی‌های مرتبط با عملکرد

برخی Functionalityها تحت تأثیر محدودیت یا Dependency خاصی هستند.

برای مثال:

امکان ارسال سفارش فقط در صورتی فعال باشد که آدرس معتبر برای کاربر ثبت شده باشد.

یا:

امکان پرداخت آنلاین تنها در صورت در دسترس بودن سرویس پرداخت فعال باشد.

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

آیا FRS باید Non-Functional Requirements را هم شامل شود؟

پاسخ به این سؤال همیشه یکسان نیست.

در برخی سازمان‌ها FRS عمدتاً روی Functional Requirements تمرکز دارد و Non-Functional Requirements در سند جداگانه‌ای مانند SRS یا NFR Specification مدیریت می‌شوند. در برخی پروژه‌ها نیز ممکن است بخشی از نیازمندی‌های غیرعملکردی در همان مجموعه مستندات Functional Specification قرار بگیرد.

بنابراین بهتر است نگوییم FRS همیشه فقط شامل Functional Requirements است یا همیشه شامل Functional و Non-Functional Requirements می‌شود. ساختار FRS به روش مستندسازی و استاندارد مورد استفاده در پروژه بستگی دارد.

اما اگر هدف سند، مستندسازی Functional Requirements باشد، تمرکز اصلی آن باید روی رفتار و قابلیت‌های مورد انتظار سیستم باقی بماند.

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

ساختار استاندارد سند FRS چگونه است؟

ساختار یک Functional Requirements Specification (FRS) می‌تواند بر اساس نوع پروژه، سازمان و روش مستندسازی متفاوت باشد و نمی‌توان یک قالب واحد را برای تمام پروژه‌ها استاندارد دانست. با این حال، یک FRS خوب باید ساختاری داشته باشد که خواننده بتواند از طریق آن، محدوده سیستم، نیازمندی‌های عملکردی، قوانین مرتبط و رفتار مورد انتظار سیستم را به‌صورت منظم دنبال کند.

یک ساختار عملی می‌تواند از بخش‌های زیر تشکیل شود:

Introduction و هدف سند

در ابتدای FRS باید مشخص شود این سند برای چه منظوری تهیه شده و چه سیستمی را توصیف می‌کند.

معمولاً این بخش می‌تواند شامل موارد زیر باشد:

• هدف سند
• نام و توضیح کوتاه سیستم
• مخاطبان سند
• محدوده کلی سند
• اصطلاحات و اختصارات مهم
• References یا اسناد مرتبط

برای مثال:

هدف این سند، تعریف نیازمندی‌های عملکردی سامانه فروش آنلاین و مشخص کردن رفتار مورد انتظار سیستم در فرآیند ثبت و مدیریت سفارش است.

این بخش بهتر است کوتاه باشد و وارد جزئیات Requirementها نشود.

Scope

در بخش Scope مشخص می‌شود FRS دقیقاً چه قسمت‌هایی از سیستم را پوشش می‌دهد و چه مواردی خارج از محدوده آن هستند.

برای مثال، اگر FRS مربوط به سیستم فروشگاه اینترنتی باشد، Scope می‌تواند شامل این موارد باشد:

In Scope:

• ثبت سفارش
• پرداخت
• مدیریت سفارش
• لغو سفارش

Out of Scope:

• مدیریت انبار
• حسابداری
• مدیریت منابع انسانی

مشخص کردن Scope از ایجاد انتظارهای اشتباه درباره محتوای سند جلوگیری می‌کند.

Functional Requirements

این قسمت معمولاً مهم‌ترین بخش FRS است.

در این بخش، Functionalityهای مورد انتظار سیستم به‌صورت Requirementهای مشخص و قابل بررسی مستند می‌شوند.

بهتر است هر Requirement یک Unique ID داشته باشد.

FR-LOGIN-001
FR-LOGIN-002
FR-LOGIN-003

برای هر Requirement نیز می‌توان اطلاعاتی مانند موارد زیر ثبت کرد:

ID	Functional Requirement	Priority
FR-LOGIN-001	سیستم باید امکان ورود کاربر با شماره موبایل و رمز عبور معتبر را فراهم کند.	High
FR-LOGIN-002	سیستم باید در صورت ورود رمز عبور اشتباه، پیام خطای مناسب نمایش دهد.	High
FR-LOGIN-003	سیستم باید پس از پنج تلاش ناموفق متوالی، حساب کاربر را موقتاً مسدود کند.	Medium

استفاده از شناسه یکتا باعث می‌شود Requirementها در مراحل بعدی پروژه راحت‌تر Trace شوند.

Business Rules

اگر رفتار سیستم تحت تأثیر قوانین کسب‌وکار باشد، این قوانین باید به‌صورت واضح مشخص شوند.

برای مثال:

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

یا:

کد تخفیف فقط برای سفارش‌هایی با مبلغ بیشتر از مقدار تعیین‌شده قابل استفاده است.

Business Rule ممکن است مستقیماً یک Functionality نباشد، اما می‌تواند تعیین کند سیستم در شرایط مختلف چگونه رفتار کند.

به همین دلیل، ارتباط میان Functional Requirement و Business Rule باید در صورت نیاز قابل ردیابی باشد.

External Interfaces

اگر سیستم با سرویس‌ها یا سیستم‌های دیگری تعامل دارد، این تعاملات باید در سطح مورد نیاز پروژه مشخص شوند.

برای مثال:

• Payment Gateway
• SMS Service
• Email Service
• Shipping System
• Authentication Service

برای هر Interface می‌توان مشخص کرد:

• سیستم چه زمانی درخواست ارسال می‌کند؟
• چه داده‌ای ارسال می‌شود؟
• چه Responseای مورد انتظار است؟
• در صورت دریافت Response ناموفق چه اتفاقی می‌افتد؟
• در صورت در دسترس نبودن سرویس چه رفتاری انتظار می‌رود؟

جزئیات فنی مانند Endpoint، Header و Schema ممکن است در مستندات تخصصی API قرار بگیرند و لازم نیست همه آن‌ها در FRS تکرار شوند.

Input و Output

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

مثلاً برای ثبت سفارش:

Input:

• شناسه کاربر
• اقلام سفارش
• آدرس ارسال
• روش پرداخت

Output:

• شماره سفارش
• مبلغ نهایی
• وضعیت سفارش

این اطلاعات به Developer و Tester کمک می‌کنند مرزهای Functionality را بهتر درک کنند.

Error Handling

رفتار سیستم در شرایط خطا نیز باید تا حد لازم مشخص شود.

برای مثال:

اگر پرداخت توسط درگاه رد شود، سیستم نباید وضعیت سفارش را به «پرداخت‌شده» تغییر دهد.

یا:

اگر سرویس ارسال در دسترس نباشد، سیستم باید خطای مناسب نمایش داده و از ثبت نهایی درخواست جلوگیری کند.

این قسمت برای Software Testing اهمیت زیادی دارد، زیرا بسیاری از Defectها در مسیرهای Exception و Error Scenario کشف می‌شوند.

Dependencies و Constraints

در این قسمت می‌توان وابستگی‌ها و محدودیت‌هایی را که روی عملکرد سیستم تأثیر می‌گذارند مشخص کرد.

برای مثال:

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

یا:

پرداخت آنلاین به در دسترس بودن سرویس Payment Gateway وابسته است.

این موارد کمک می‌کنند Requirementها خارج از Context واقعی خود تفسیر نشوند.

Requirement Traceability

در پروژه‌های بزرگ‌تر بهتر است Requirementها قابلیت Traceability داشته باشند.

BR-ORDER-001
      ↓
FR-ORDER-005
      ↓
TC-ORDER-012
      ↓
BUG-1042

در این زنجیره می‌توان ارتباط بین Business Requirement، Functional Requirement، Test Case و Defect را دنبال کرد.

این موضوع مستقیماً با Requirements Traceability Matrix (RTM) مرتبط است و می‌تواند به بررسی Requirement Coverage کمک کند.

یک نکته مهم درباره ساختار FRS

همه این بخش‌ها الزاماً در یک سند FRS با همین نام یا همین ترتیب وجود ندارند.

برای مثال، در یک سازمان ممکن است Business Rules در سند جداگانه‌ای نگهداری شوند یا Traceability در ابزار مدیریت Requirements و Test انجام شود.

بنابراین بهتر است به‌جای حفظ کردن یک Template ثابت، این اصل را در نظر بگیریم:

ساختار FRS باید به اندازه‌ای اطلاعات ارائه دهد که عملکرد مورد انتظار سیستم برای افراد مرتبط با پروژه، به‌خصوص Business Analyst، Developer و Tester، واضح و قابل بررسی باشد.

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

چگونه یک FRS بنویسیم؟

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

فرآیند تهیه FRS بسته به پروژه متفاوت است، اما می‌توان آن را به چند مرحله اصلی تقسیم کرد.

نیازمندی‌ها را شناسایی و جمع‌آوری کنید

اولین مرحله، درک نیاز واقعی کسب‌وکار و کاربران است.

اطلاعات مورد نیاز ممکن است از منابع مختلفی به دست آید، از جمله:

• Business Requirementها
• نیازهای کاربران
• جلسات با Stakeholderها
• Product Requirementها
• User Storyها
• قوانین کسب‌وکار
• فرآیندهای موجود سیستم
• مستندات قبلی
• محدودیت‌ها و وابستگی‌های پروژه

برای مثال، فرض کنید Stakeholder چنین درخواستی مطرح می‌کند:

مشتری باید بتواند سفارش خود را لغو کند.

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

بنابراین باید Requirement را بیشتر تحلیل کنیم.

محدوده Functionality را مشخص کنید

قبل از نوشتن Requirement باید مشخص شود Functionality موردنظر دقیقاً چه محدوده‌ای دارد.

برای مثال، در قابلیت Cancel Order باید مشخص شود:

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

بدون پاسخ به این سؤالات، Requirement ممکن است بیش از حد کلی باشد.

Functional Requirement را دقیق و مشخص بنویسید

پس از مشخص شدن Scope، باید نیازمندی را به شکلی بنویسیم که رفتار مورد انتظار سیستم را بیان کند.

Requirement مبهم:

سیستم باید امکان لغو سفارش را فراهم کند.

Requirement دقیق‌تر:

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

و در صورت نیاز می‌توان آن را دقیق‌تر کرد:

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

در این حالت، Requirement اطلاعات بیشتری درباره شرط، Action و Expected Result ارائه می‌دهد.

Requirementها را قابل تست بنویسید

یکی از مهم‌ترین ویژگی‌های یک Requirement خوب این است که بتوان بررسی کرد آیا سیستم آن را برآورده کرده است یا خیر.

مثلاً:

سیستم باید سریع باشد.

این Requirement به‌راحتی قابل تست نیست؛ چون مشخص نیست «سریع» دقیقاً به چه معناست.

اما اگر نیاز واقعی پروژه این باشد:

سیستم باید نتیجه جستجوی محصول را حداکثر در 2 ثانیه تحت شرایط تعریف‌شده نمایش دهد.

اکنون معیار مشخص‌تری برای بررسی وجود دارد.

در مورد Functional Requirement نیز همین اصل برقرار است.

Requirement مبهم:

سیستم باید پیام مناسبی نمایش دهد.

Requirement دقیق‌تر:

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

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

شرایط اصلی و Alternative Flowها را مشخص کنید

یک Requirement خوب نباید فقط Happy Path را توصیف کند.

برای هر Functionality مهم باید بررسی کنیم اگر شرایط متفاوتی اتفاق افتاد، سیستم چه رفتاری باید داشته باشد.

برای مثال، در Login:

Main Flow:

کاربر اطلاعات معتبر وارد می‌کند → سیستم کاربر را احراز هویت می‌کند → کاربر وارد Dashboard می‌شود.

اما باید موارد دیگری نیز مشخص شوند:

• رمز عبور اشتباه
• Username نامعتبر
• فیلد خالی
• حساب مسدود
• تعداد تلاش ناموفق بیش از حد مجاز
• در دسترس نبودن سرویس Authentication

این موارد بعداً مستقیماً به Test Scenarioهای مختلف تبدیل می‌شوند.

Business Rules را مشخص کنید

گاهی یک Requirement بدون درک Business Ruleهای مرتبط، ناقص خواهد بود.

مثلاً:

کاربر می‌تواند سفارش را لغو کند.

اما Business Rule ممکن است بگوید:

سفارش فقط تا قبل از شروع فرآیند ارسال قابل لغو است.

بنابراین Requirement نهایی باید این قانون را در نظر بگیرد.

Business Ruleها باید به‌گونه‌ای مستند شوند که مشخص باشد در چه شرایطی یک Functionality مجاز یا غیرمجاز است.

Requirementها را Unique IDگذاری کنید

بهتر است هر Requirement یک شناسه یکتا داشته باشد.

FR-LOGIN-001
FR-LOGIN-002
FR-ORDER-001
FR-ORDER-002

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

برای مثال:

FR-LOGIN-001

ممکن است به موارد زیر مرتبط شود:

Test Scenario: TS-LOGIN-001
Test Case: TC-LOGIN-001
Bug: BUG-1042

در نتیجه می‌توان ارتباط Requirement با تست و Defect را دنبال کرد.

Requirementها را Review و Validate کنید

پس از تهیه FRS، سند نباید مستقیماً وارد Development شود.

Requirementها باید توسط افراد مرتبط Review شوند تا مواردی مانند زیر شناسایی شوند:

• ابهام
• Requirement ناقص
• تناقض بین Requirementها
• Requirement تکراری
• عدم تطابق با Business Need
• Requirement غیرقابل تست
• Missing Scenario
• Missing Error Handling

در این مرحله حضور Business Analyst، Product Owner، Developer و Tester بسته به نوع پروژه می‌تواند بسیار ارزشمند باشد.

Tester نیز می‌تواند از دید تست‌پذیری Requirementها را بررسی کند.

برای مثال، اگر Requirement نوشته باشد:

سیستم باید عملکرد مناسبی داشته باشد.

Tester باید سؤال کند:

عملکرد مناسب دقیقاً یعنی چه؟

این نوع سؤال‌ها می‌توانند قبل از شروع Development، ابهام‌های مهم را آشکار کنند.

Requirementها را Trace کنید

در نهایت، Requirementها باید در صورت نیاز با منابع و خروجی‌های مرتبط قابل ردیابی باشند.

یک مسیر ساده می‌تواند به این شکل باشد:

Business Need → Functional Requirement → Test Scenario → Test Case → Test Result → Defect

این Traceability به تیم کمک می‌کند بفهمد هر Requirement چگونه پیاده‌سازی و تست شده است و آیا Requirementی وجود دارد که هنوز برای آن Test Case یا Test Coverage مناسبی تعریف نشده باشد.

جمع‌بندی فرآیند نوشتن FRS

به‌طور خلاصه، می‌توان فرآیند تهیه FRS را این‌گونه در نظر گرفت:

جمع‌آوری نیازمندی‌ها → تعیین Scope → تحلیل Functionality → نوشتن Functional Requirement → تعریف Business Rules و Error Scenarios → Unique IDگذاری → Review و Validation → Traceability

نکته مهم این است که FRS خوب الزاماً FRS طولانی نیست. هدف، تولید سندی است که رفتار مورد انتظار سیستم را بدون ابهام و با جزئیات کافی برای افراد مرتبط با پروژه مشخص کند.

نمونه FRS برای یک سیستم واقعی

برای درک بهتر ساختار و نحوه نوشتن Functional Requirements Specification، یک سامانه فروشگاهی را در نظر بگیریم که کاربران می‌توانند در آن وارد حساب کاربری خود شوند و سفارش ثبت کنند.

در این مثال، روی فرآیند ورود کاربر (Login) تمرکز می‌کنیم.

هدف این مثال نشان دادن شکل نوشتن Requirement است؛ بنابراین قرار نیست یک FRS کامل برای یک سیستم واقعی با ده‌ها صفحه تهیه کنیم.

تعریف Functionality

Functionality: User Login

هدف: کاربر بتواند با استفاده از اطلاعات معتبر وارد حساب کاربری خود شود.

Actor: Registered User

Precondition: کاربر قبلاً در سیستم ثبت‌نام کرده باشد.

نمونه Functional Requirements

اکنون می‌توانیم Requirementهای مربوط به Login را به شکل مشخص تعریف کنیم:

ID	Requirement
FR-LOGIN-001	سیستم باید امکان ورود کاربر ثبت‌نام‌شده با شماره موبایل و رمز عبور را فراهم کند.
FR-LOGIN-002	سیستم باید معتبر بودن اطلاعات ورود را قبل از ایجاد Session بررسی کند.
FR-LOGIN-003	در صورت صحیح بودن اطلاعات ورود، سیستم باید کاربر را احراز هویت کرده و او را به Dashboard هدایت کند.
FR-LOGIN-004	در صورت اشتباه بودن رمز عبور، سیستم باید پیام خطای مناسب نمایش دهد و از ورود کاربر جلوگیری کند.
FR-LOGIN-005	پس از پنج تلاش ناموفق متوالی، سیستم باید حساب کاربر را مطابق سیاست امنیتی سیستم به‌صورت موقت مسدود کند.

در اینجا Requirementها دیگر صرفاً یک Feature را نام نمی‌برند؛ بلکه رفتار مورد انتظار سیستم را مشخص می‌کنند.

Business Rules

برای Login ممکن است قوانین کسب‌وکار یا قوانین سیستم نیز وجود داشته باشد.

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

این قوانین باید در FRS یا سند مرتبط به شکلی ثبت شوند که Requirementهای مربوط به Login بتوانند بر اساس آن‌ها تفسیر و تست شوند.

Main Flow

جریان اصلی Login می‌تواند به این شکل تعریف شود:

1. کاربر صفحه Login را باز می‌کند.
2. شماره موبایل خود را وارد می‌کند.
3. رمز عبور را وارد می‌کند.
4. درخواست Login را ارسال می‌کند.
5. سیستم اطلاعات کاربر را بررسی می‌کند.
6. اطلاعات معتبر هستند.
7. سیستم Session یا مکانیزم احراز هویت موردنظر را ایجاد می‌کند.
8. کاربر به Dashboard هدایت می‌شود.

این جریان، Happy Path سیستم را نشان می‌دهد.

Alternative و Error Flow

اما یک FRS خوب نباید فقط مسیر موفق را مشخص کند.

رمز عبور اشتباه

1. کاربر اطلاعات Login را ارسال می‌کند.
2. سیستم اطلاعات را بررسی می‌کند.
3. رمز عبور صحیح نیست.
4. سیستم از ورود کاربر جلوگیری می‌کند.
5. پیام خطای مناسب نمایش داده می‌شود.

حساب مسدود

1. کاربر اطلاعات صحیح را وارد می‌کند.
2. سیستم وضعیت حساب را بررسی می‌کند.
3. حساب کاربر در وضعیت Locked قرار دارد.
4. سیستم اجازه Login نمی‌دهد.
5. پیام مناسب به کاربر نمایش داده می‌شود.

تلاش‌های ناموفق بیش از حد مجاز

1. کاربر چند بار اطلاعات اشتباه وارد می‌کند.
2. تعداد تلاش‌های ناموفق به حد تعیین‌شده می‌رسد.
3. سیستم حساب را موقتاً مسدود می‌کند.
4. کاربر تا پایان مدت Lock نمی‌تواند وارد حساب شود.

این سناریوها بعدها می‌توانند مستقیماً به Test Scenario و Test Case تبدیل شوند.

Input و Output

برای این Functionality می‌توان ورودی‌ها و خروجی‌های اصلی را نیز مشخص کرد.

Input:

• شماره موبایل
• رمز عبور

Output در حالت موفق:

• احراز هویت موفق
• ایجاد Session یا Token
• انتقال کاربر به Dashboard

Output در حالت ناموفق:

• عدم ایجاد Session
• نمایش پیام خطا
• ثبت تلاش ناموفق، در صورت وجود چنین Requirementی

تبدیل Requirement به Test Scenario

اکنون می‌توانیم ببینیم چرا FRS برای Tester اهمیت دارد.

برای مثال از Requirement زیر:

FR-LOGIN-001: سیستم باید امکان ورود کاربر ثبت‌نام‌شده با شماره موبایل و رمز عبور را فراهم کند.

می‌توان Test Scenarioهایی مانند موارد زیر استخراج کرد:

Test Scenario	هدف
TS-LOGIN-001	ورود با شماره موبایل و رمز عبور صحیح
TS-LOGIN-002	ورود با رمز عبور اشتباه
TS-LOGIN-003	ورود با شماره موبایل نامعتبر
TS-LOGIN-004	ورود با فیلدهای خالی
TS-LOGIN-005	ورود با حساب مسدود
TS-LOGIN-006	بررسی رفتار سیستم پس از چند تلاش ناموفق

بنابراین یک Requirement مناسب، نقطه شروع طراحی تست است؛ اما Tester نباید فقط متن Requirement را به Test Case تبدیل کند. برای پوشش مناسب باید Business Rules، Risk، Boundary Conditions، Error Scenarios و سایر اطلاعات مرتبط نیز بررسی شوند.

یک Requirement خوب چه تفاوتی با Requirement ضعیف دارد؟

مقایسه زیر تفاوت را بهتر نشان می‌دهد:

Requirement ضعیف:

سیستم باید Login خوبی داشته باشد.

مشکلات:

• «خوب» تعریف نشده است.
• رفتار مورد انتظار مشخص نیست.
• قابل تست نیست.
• شرایط خطا مشخص نیست.
• معیار پذیرش ندارد.

Requirement بهتر:

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

این Requirement بسیار مشخص‌تر است؛ با این حال ممکن است هنوز برای برخی پروژه‌ها نیاز به جزئیات بیشتری مانند Acceptance Criteria، Error Handling، Session Management یا Security Rules داشته باشد.

این مثال نشان می‌دهد FRS صرفاً یک فهرست از Featureها نیست. یک FRS مناسب باید رفتار مورد انتظار سیستم را به اندازه‌ای مشخص کند که تیم توسعه بتواند آن را پیاده‌سازی و تیم تست بتواند آن را بررسی کند.

FRS از دید Software Tester

FRS فقط یک سند برای Developer یا Business Analyst نیست. برای Software Tester نیز یکی از منابع مهم برای درک رفتار مورد انتظار سیستم و طراحی تست محسوب می‌شود.

Tester با مطالعه FRS باید بتواند به سؤالاتی مانند این‌ها پاسخ دهد:

• سیستم دقیقاً چه کاری باید انجام دهد؟
• چه ورودی‌هایی معتبر هستند؟
• در برابر ورودی نامعتبر چه اتفاقی باید بیفتد؟
• شرایط موفقیت و شکست چیست؟
• چه Business Ruleهایی باید بررسی شوند؟
• چه حالت‌های مرزی یا Exceptionهایی وجود دارند؟
• آیا Requirement به اندازه کافی واضح و قابل تست است؟
• چگونه می‌توان Requirement را به Test Scenario و Test Case تبدیل کرد؟

به همین دلیل، Tester بهتر است FRS را فقط پس از پایان Development مطالعه نکند؛ بلکه در مرحله Review Requirementها نیز درگیر شود.

Tester در FRS به دنبال چه چیزهایی است؟

یکی از مهم‌ترین وظایف Tester هنگام Review یک FRS، بررسی کامل بودن و قابل تست بودن Requirementها است.

برای مثال، فرض کنید Requirement زیر نوشته شده باشد:

سیستم باید امکان ثبت سفارش را فراهم کند.

Tester باید سؤال‌های بیشتری مطرح کند:

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

این سؤال‌ها نشان می‌دهند Requirement اولیه احتمالاً هنوز برای طراحی تست کافی نیست.

چگونه Requirementهای قابل تست را تشخیص دهیم؟

یک Requirement باید تا حد امکان به شکلی نوشته شود که بتوان مشخص کرد آیا سیستم Requirement را برآورده کرده است یا خیر.

برای مثال:

سیستم باید سریع باشد.

این Requirement قابل تست نیست، زیرا مشخص نشده «سریع» یعنی چه.

اما:

سیستم باید نتیجه جستجو را حداکثر ظرف 2 ثانیه تحت شرایط مشخص‌شده نمایش دهد.

معیار مشخص‌تری برای Verification ایجاد می‌کند.

در Functional Requirement نیز همین موضوع وجود دارد.

Requirement ضعیف:

سیستم باید پیام مناسبی به کاربر نمایش دهد.

Requirement بهتر:

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

البته در پروژه‌های واقعی ممکن است متن دقیق پیام در UI Specification تعریف شده باشد؛ بنابراین Tester باید بررسی کند که Requirement به یک منبع معتبر دیگر وابسته نباشد یا این Dependency به‌درستی مشخص شده باشد.

چگونه از FRS، Test Scenario استخراج کنیم؟

بعد از بررسی Requirementها، Tester می‌تواند Functionalityها و شرایط مختلف را به Test Scenario تبدیل کند.

برای مثال:

سیستم باید به کاربر اجازه دهد با شماره موبایل و رمز عبور معتبر وارد حساب خود شود.

از این Requirement می‌توان سناریوهای مختلفی استخراج کرد:

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

بنابراین Tester نباید فقط Positive Scenario را در نظر بگیرد.

یک Requirement می‌تواند Test Scenarioهای مربوط به Positive + Negative + Boundary + Error + Alternative Flow ایجاد کند.

چگونه از FRS، Test Case ایجاد کنیم؟

پس از شناسایی Test Scenarioها، می‌توان برای آن‌ها Test Case طراحی کرد.

برای مثال:

Requirement:

FR-LOGIN-001

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

Test Case:

مورد	مقدار
Test Case ID	TC-LOGIN-001
Requirement ID	FR-LOGIN-001
Title	Login با اطلاعات معتبر
Preconditions	کاربر ثبت‌نام‌شده باشد
Test Data	شماره موبایل و رمز عبور معتبر
Steps	ورود اطلاعات و انتخاب Login
Expected Result	کاربر با موفقیت وارد Dashboard شود

در اینجا ارتباط میان Requirement و Test Case کاملاً مشخص است.

بررسی Business Rules و شرایط مرزی

Tester نباید فقط متن Functional Requirement را بخواند.

Business Ruleها نیز می‌توانند منبع مهمی برای طراحی تست باشند.

مثلاً:

کاربر فقط تا قبل از ارسال سفارش می‌تواند آن را لغو کند.

این Requirement یک Boundary مهم ایجاد می‌کند.

Tester باید حداقل این شرایط را بررسی کند:

• سفارش قبل از ارسال → امکان لغو
• سفارش در حال آماده‌سازی → بسته به Rule پروژه
• سفارش در حال ارسال → عدم امکان لغو
• سفارش ارسال‌شده → عدم امکان لغو

این نوع تحلیل کمک می‌کند Test Coverage فقط به مسیرهای معمول محدود نشود.

بررسی Error Handling

یکی از نقاط مهم Review FRS، بررسی رفتار سیستم در شرایط خطا است.

برای مثال، اگر FRS درباره پرداخت نوشته باشد:

سیستم باید پرداخت آنلاین را انجام دهد.

این Requirement احتمالاً ناقص است.

Tester باید بررسی کند:

• پرداخت موفق چه نتیجه‌ای دارد؟
• پرداخت ناموفق چه نتیجه‌ای دارد؟
• کاربر پرداخت را Cancel کند چه اتفاقی می‌افتد؟
• Gateway Timeout شود چه می‌شود؟
• اگر Response از Gateway دریافت نشود چه می‌شود؟
• پرداخت موفق باشد ولی Callback دریافت نشود چه می‌شود؟
• آیا سفارش در این شرایط Paid می‌شود یا Pending؟

این موارد ممکن است باعث شوند Requirementهای بیشتری به FRS اضافه شوند.

بررسی Requirementهای متناقض یا ناقص

Tester در مرحله Review می‌تواند تناقض میان Requirementها را نیز پیدا کند.

برای مثال:

FR-ORDER-001:

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

اما در Requirement دیگری نوشته شده:

FR-ORDER-008:

پس از ثبت سفارش، امکان لغو آن وجود ندارد.

این دو Requirement با یکدیگر تناقض دارند و باید قبل از Development مشخص شود کدام Rule صحیح است.

همچنین ممکن است یک Functionality اصلاً Requirement نداشته باشد.

برای مثال، FRS فقط Login موفق را توضیح دهد اما هیچ Requirementی برای موارد زیر نداشته باشد:

• رمز عبور اشتباه
• حساب مسدود
• Session Expiration

Tester می‌تواند این Requirement Gapها را در مرحله Review مطرح کند.

بررسی Traceability

Tester باید بتواند در صورت وجود Traceability، ارتباط میان Requirement و Test را دنبال کند.

FR-LOGIN-001
      ↓
TS-LOGIN-001
      ↓
TC-LOGIN-001
      ↓
Test Result

اگر یک Requirement مهم هیچ Test Case مرتبطی نداشته باشد، ممکن است نشان‌دهنده یک Coverage Gap باشد.

در پروژه‌های بزرگ‌تر، این ارتباط معمولاً از طریق Requirements Traceability Matrix (RTM) یا ابزارهای مدیریت Requirements و Test انجام می‌شود.

آیا Tester باید FRS را قبل از Development بررسی کند؟

بله، در رویکردهای مدرن توسعه نرم‌افزار، بهتر است Tester فقط منتظر نسخه نهایی نرم‌افزار نماند.

اگر Tester در مرحله Requirement Review حضور داشته باشد، می‌تواند قبل از شروع Development مواردی مانند زیر را شناسایی کند:

• Ambiguity
• Missing Requirement
• Contradiction
• Untestable Requirement
• Missing Error Scenario
• Missing Boundary Condition

این موضوع با رویکرد Shift Left Testing نیز هم‌راستا است؛ زیرا بخشی از فعالیت‌های کیفیت و تست به مراحل ابتدایی SDLC منتقل می‌شوند.

جمع‌بندی FRS از دید Software Tester

از دید Tester، FRS فقط سندی برای فهمیدن «چه چیزی باید ساخته شود» نیست؛ بلکه یکی از منابع اصلی برای فهمیدن «چه چیزی باید تست شود» نیز هست.

به همین دلیل، یک جریان منطقی می‌تواند به شکل زیر باشد:

FRS → Requirement Review → Test Scenario → Test Case → Test Execution → Defect Report

هرچه Requirementهای FRS واضح‌تر، کامل‌تر، سازگارتر و قابل تست‌تر باشند، طراحی و اجرای تست نیز هدفمندتر خواهد بود.

تفاوت FRS با SRS، FRD، BRD و PRD چیست؟

در پروژه‌های نرم‌افزاری اصطلاحات مختلفی برای مستندسازی نیازمندی‌ها استفاده می‌شود؛ از جمله BRD، PRD، SRS، FRS و FRD.

یکی از دلایل سردرگمی این است که این اصطلاحات در همه سازمان‌ها با یک تعریف کاملاً یکسان استفاده نمی‌شوند. به‌خصوص FRS و FRD در برخی پروژه‌ها تقریباً به یک معنا و در برخی سازمان‌ها برای دو سطح متفاوت از مستندات استفاده می‌شوند.

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

سند	تمرکز اصلی	سؤال کلیدی
BRD	نیاز و هدف کسب‌وکار	چرا این محصول یا قابلیت لازم است؟
PRD	نیاز محصول و رفتار مورد انتظار از دید محصول	محصول چه چیزی باید ارائه دهد؟
SRS	نیازمندی‌های سیستم	سیستم چه الزاماتی باید برآورده کند؟
FRS	نیازمندی‌های عملکردی	سیستم از نظر عملکردی چه کاری باید انجام دهد؟
FRD	نیازمندی‌های عملکردی و جزئیات عملکرد	قابلیت‌ها و رفتارهای عملکردی سیستم چگونه باید تعریف شوند؟

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

ارتباط این اسناد با یکدیگر

برای درک بهتر می‌توان مسیر تبدیل نیاز کسب‌وکار به نیازمندی قابل تست را به شکل زیر تصور کرد:

Business Need → BRD → PRD → SRS / FRS / FRD → Development → Software Testing

اما این ترتیب نیز در همه پروژه‌ها یکسان نیست. ممکن است یک سازمان فقط از BRD و SRS استفاده کند، سازمان دیگری PRD و FRS داشته باشد و سازمانی دیگر همه این اسناد را با ساختار متفاوتی مدیریت کند.

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

FRS در مقایسه با BRD

BRD (Business Requirements Document) بیشتر از دید کسب‌وکار به مسئله نگاه می‌کند.

برای مثال:

کاربران باید بتوانند از طریق وب‌سایت محصولات را خریداری کنند.

این Requirement بیشتر بیان‌کننده یک نیاز کسب‌وکار است.

اما در FRS، تمرکز روی رفتار عملکردی مورد انتظار سیستم بیشتر می‌شود:

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

بنابراین به‌صورت ساده:

BRD → چرا این قابلیت برای کسب‌وکار لازم است؟

FRS → سیستم برای برآورده کردن این نیاز چه عملکردی باید ارائه دهد؟

FRS در مقایسه با PRD

PRD (Product Requirements Document) معمولاً از دید محصول به نیازها و قابلیت‌هایی می‌پردازد که محصول باید ارائه کند.

برای مثال، در PRD ممکن است مشخص شود:

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

در FRS، این نیاز می‌تواند به رفتارهای عملکردی دقیق‌تری تبدیل شود:

سیستم باید امکان مشاهده وضعیت فعلی سفارش را برای کاربر فراهم کند.

و سپس ممکن است Requirementهای جزئی‌تری تعریف شوند:

• سیستم باید وضعیت سفارش را نمایش دهد.
• سیستم باید شماره سفارش را نمایش دهد.
• سیستم باید آخرین وضعیت ثبت‌شده سفارش را نمایش دهد.
• در صورت نبود اطلاعات وضعیت، سیستم باید پیام مناسب نمایش دهد.

در نتیجه، PRD معمولاً بیشتر روی محصول و قابلیت‌های آن تمرکز دارد، در حالی که FRS بیشتر روی رفتار عملکردی مورد انتظار سیستم متمرکز می‌شود.

FRS در مقایسه با SRS

SRS (Software Requirements Specification) معمولاً سندی جامع‌تر برای مشخص کردن نیازمندی‌های نرم‌افزار یا سیستم است.

بسته به روش مستندسازی سازمان، SRS می‌تواند شامل مجموعه‌ای از نیازمندی‌های Functional و Non-Functional باشد.

در این حالت:

SRS می‌تواند تصویر جامع‌تری از نیازمندی‌های نرم‌افزار ارائه دهد، در حالی که FRS تمرکز مشخص‌تری روی Functional Requirements دارد.

برای مثال:

Functional Requirement:

سیستم باید امکان جستجوی محصول را بر اساس نام محصول فراهم کند.

Non-Functional Requirement:

سیستم باید نتیجه جستجو را در شرایط تعریف‌شده حداکثر ظرف 2 ثانیه نمایش دهد.

اولی درباره کاری است که سیستم انجام می‌دهد و دومی درباره ویژگی یا محدودیت عملکرد سیستم است.

البته اینکه این دو مورد دقیقاً در چه سندی قرار بگیرند، به ساختار مستندات پروژه بستگی دارد.

FRS در مقایسه با FRD

تفاوت FRS و FRD یکی از مواردی است که بیشترین ابهام را ایجاد می‌کند.

در بسیاری از سازمان‌ها:

FRS = Functional Requirements Specification

و

FRD = Functional Requirements Document

عملاً برای یک نوع سند یا دو نام متفاوت برای مستندسازی Functional Requirements استفاده می‌شوند.

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

بنابراین نمی‌توان گفت:

«FRS همیشه یک سند است و FRD همیشه سند دیگری است.»

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

برای همین، هنگام ورود به یک پروژه واقعی، Tester یا Developer باید تعریف داخلی سازمان از FRS و FRD را بررسی کند.

خلاصه تفاوت‌ها

• BRD: نیاز کسب‌وکار چیست و چرا وجود دارد؟
• PRD: محصول چه قابلیت‌ها و ارزشی باید ارائه دهد؟
• SRS: نرم‌افزار چه نیازمندی‌هایی را باید برآورده کند؟
• FRS: سیستم از نظر عملکردی چه کارهایی باید انجام دهد؟
• FRD: بسته به سازمان، سندی برای Functional Requirements است که ممکن است با FRS هم‌معنا یا نزدیک به آن باشد.

از دید Software Tester، مهم‌ترین نکته این است که بتواند از هر سندی که به عنوان منبع Requirement تعریف شده، نیازمندی‌های قابل تست را شناسایی کند و ارتباط آن‌ها را تا Test Scenario و Test Case دنبال کند.

FRS در SDLC چه نقشی دارد؟

سند FRS فقط در مرحله تحلیل نیازمندی‌ها کاربرد ندارد. اگر این سند به‌درستی تهیه و نگهداری شود، می‌تواند در مراحل مختلف Software Development Life Cycle (SDLC) به‌عنوان یک مرجع مشترک برای تیم‌های مختلف مورد استفاده قرار گیرد.

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

نقش FRS را می‌توان در چهار مرحله اصلی بررسی کرد:

Requirements → Development → Testing → Acceptance

FRS در مرحله Requirements

مهم‌ترین نقش FRS در مرحله Requirements، تبدیل نیازهای اولیه به Functional Requirements مشخص و قابل بررسی است.

در این مرحله، اطلاعاتی که از منابع مختلف مانند:

• Business Requirements
• Product Requirements
• User Needs
• Stakeholder Interviews
• Business Rules

به دست آمده‌اند، می‌توانند به Requirementهای عملکردی تبدیل شوند.

برای مثال، یک نیاز کسب‌وکار ممکن است این باشد:

مشتری باید بتواند سفارش خود را به‌صورت آنلاین ثبت کند.

در FRS این نیاز می‌تواند به Requirementهای دقیق‌تری تبدیل شود:

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

در این مرحله، Requirementها باید از نظر Completeness، Consistency، Clarity و Testability نیز بررسی شوند.

یکی از مزیت‌های مهم حضور Tester در این مرحله این است که بسیاری از ابهام‌ها و Requirement Gapها قبل از شروع Development شناسایی می‌شوند.

FRS در Development

پس از مشخص شدن Requirementها، FRS می‌تواند به‌عنوان یکی از منابع مهم برای تیم Development مورد استفاده قرار گیرد.

Developer بر اساس Requirementها متوجه می‌شود:

• چه Functionalityهایی باید پیاده‌سازی شوند؟
• سیستم در شرایط مختلف چه رفتاری باید داشته باشد؟
• چه Inputهایی دریافت می‌شود؟
• چه Outputهایی باید تولید شود؟
• Business Ruleهای مرتبط چیست؟
• در شرایط خطا چه اتفاقی باید رخ دهد؟
• سیستم چگونه باید با سرویس‌های دیگر تعامل کند؟

برای مثال، اگر FRS مشخص کند:

سیستم باید پس از ورود موفق کاربر، او را به Dashboard هدایت کند.

Developer باید این رفتار را در پیاده‌سازی در نظر بگیرد و Tester نیز می‌تواند همین Requirement را به‌عنوان مبنای طراحی تست استفاده کند.

به این ترتیب، FRS می‌تواند یک مرجع مشترک میان Requirement و Implementation باشد.

FRS در Software Testing

یکی از مهم‌ترین کاربردهای FRS برای تیم QA و Testing است.

Tester می‌تواند FRS را برای موارد زیر به کار ببرد:

• Requirement Review
• Test Scenario Design
• Test Case Design
• Test Data Design
• Functional Testing
• Negative Testing
• Boundary Testing
• Regression Testing
• Requirements Traceability

برای مثال، اگر Requirement این باشد:

سیستم باید به کاربر اجازه دهد حداکثر 5 محصول را به یک سفارش اضافه کند.

Tester می‌تواند شرایط مختلفی را بررسی کند:

وضعیت	انتظار
1 محصول	مجاز
4 محصول	مجاز
5 محصول	مجاز
6 محصول	غیرمجاز
0 محصول	بررسی رفتار تعریف‌شده در Requirement
مقدار نامعتبر	بررسی Error Handling

در اینجا FRS فقط به Tester نمی‌گوید چه چیزی را تست کند؛ بلکه می‌تواند به شناسایی شرایط مرزی و رفتار مورد انتظار نیز کمک کند.

اگر Requirementها به‌صورت مناسب نوشته شده باشند، طراحی تست نیز دقیق‌تر خواهد بود.

FRS در Acceptance

در مرحله Acceptance نیز FRS می‌تواند به‌عنوان یکی از منابع بررسی عملکرد سیستم مورد استفاده قرار گیرد.

در این مرحله سؤال اصلی این است:

آیا Functionalityهای پیاده‌سازی‌شده با Requirementهای مورد توافق مطابقت دارند؟

برای مثال، اگر Requirement مشخص کرده باشد:

کاربر باید بتواند سفارش خود را تا قبل از ارسال لغو کند.

در Acceptance باید بررسی شود که سیستم دقیقاً همین رفتار مورد انتظار را دارد.

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

بنابراین FRS یکی از منابع تصمیم‌گیری است، نه لزوماً تنها منبع Acceptance.

FRS و جریان Requirement تا Test

یکی از مهم‌ترین مزایای داشتن Requirementهای مشخص در FRS، ایجاد ارتباط میان بخش‌های مختلف فرآیند توسعه و تست است.

یک جریان معمول می‌تواند به شکل زیر باشد:

Business Need → Functional Requirement → Development → Test Scenario → Test Case → Test Execution → Defect

در صورت استفاده از Requirements Traceability Matrix (RTM)، این ارتباط می‌تواند ساختارمندتر شود:

FR-ORDER-001
      ↓
TS-ORDER-001
      ↓
TC-ORDER-001
      ↓
Test Result
      ↓
Defect (در صورت وجود)

این Traceability کمک می‌کند مشخص شود هر Requirement چگونه پیاده‌سازی و تست شده است و آیا Requirement مهمی بدون پوشش تست باقی مانده یا خیر.

FRS و Shift Left Testing

نقش FRS در SDLC ارتباط مستقیمی با رویکرد Shift Left Testing نیز دارد.

در رویکرد سنتی، ممکن است Tester عمدتاً پس از آماده شدن نرم‌افزار وارد فرآیند شود و مشکلات را در زمان اجرای تست پیدا کند.

اما در Shift Left، Tester می‌تواند از مراحل ابتدایی‌تر وارد شود و خود Requirementها را Review کند.

برای مثال، Tester می‌تواند قبل از Development متوجه شود که Requirement زیر ناقص است:

سیستم باید پرداخت را انجام دهد.

سؤال‌های مهمی که باید مشخص شوند عبارت‌اند از:

• پرداخت موفق چه وضعیتی ایجاد می‌کند؟
• پرداخت ناموفق چه اتفاقی ایجاد می‌کند؟
• Timeout چگونه مدیریت می‌شود؟
• اگر مبلغ از حساب کم شود ولی پاسخ موفق دریافت نشود چه می‌شود؟
• آیا کاربر می‌تواند دوباره پرداخت را انجام دهد؟
• وضعیت سفارش در هر حالت چیست؟

اگر این ابهام‌ها قبل از Development مشخص شوند، احتمال ایجاد Defect ناشی از سوءبرداشت Requirement کاهش پیدا می‌کند.

بنابراین، FRS می‌تواند یکی از نقاط مهم ورود فعالیت‌های QA به مراحل ابتدایی SDLC باشد.

جمع‌بندی نقش FRS در SDLC

FRS در SDLC می‌تواند نقش یک مرجع مشترک برای تعریف و بررسی رفتار مورد انتظار سیستم را داشته باشد.

به‌صورت خلاصه:

• در Requirements، نیازمندی‌های عملکردی را مشخص و قابل بررسی می‌کند.
• در Development، رفتار مورد انتظار سیستم را برای تیم توسعه روشن می‌کند.
• در Testing، مبنایی برای Requirement Review و طراحی Test Scenario و Test Case فراهم می‌کند.
• در Acceptance، یکی از منابع بررسی انطباق محصول با نیازمندی‌های تعریف‌شده است.
• در Traceability، ارتباط Requirement با Test و نتیجه آن را قابل پیگیری‌تر می‌کند.

به همین دلیل، کیفیت FRS می‌تواند مستقیماً روی کیفیت مراحل بعدی SDLC تأثیر بگذارد.

اشتباهات رایج در نوشتن FRS

کیفیت FRS تأثیر مستقیمی بر مراحل بعدی پروژه دارد. Requirementهای مبهم یا ناقص می‌توانند باعث شوند Developer برداشت متفاوتی از نیازمندی داشته باشد و Tester نیز نتواند رفتار مورد انتظار سیستم را به‌درستی مشخص کند.

بسیاری از Defectها در مراحل بعدی، در واقع ریشه در Requirementهای ناقص، مبهم یا متناقض دارند.

در ادامه، مهم‌ترین اشتباهاتی را بررسی می‌کنیم که هنگام تهیه FRS باید از آن‌ها اجتناب شود.

نوشتن Requirementهای مبهم

یکی از رایج‌ترین مشکلات در FRS، استفاده از کلماتی است که تفسیرهای مختلفی دارند.

سیستم باید عملکرد خوبی داشته باشد.

سیستم باید سریع باشد.

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

بهتر است Requirement تا حد امکان با معیار قابل بررسی نوشته شود.

سیستم باید نتیجه جستجو را در شرایط تعریف‌شده حداکثر ظرف 2 ثانیه نمایش دهد.

در این حالت، معیار مشخص‌تری برای Verification و Testing وجود دارد.

کلماتی مانند موارد زیر، اگر بدون معیار یا تعریف دقیق استفاده شوند، می‌توانند Requirement را مبهم کنند:

• سریع
• مناسب
• آسان
• کاربرپسند
• بهینه
• در اسرع وقت
• اطلاعات کافی

استفاده از Requirementهای غیرقابل تست

یک Requirement زمانی برای Tester مشکل‌ساز می‌شود که نتوان مشخص کرد سیستم آن را برآورده کرده است یا خیر.

سیستم باید تجربه کاربری مناسبی ارائه دهد.

بدون تعریف معیار مشخص، Tester نمی‌تواند یک Expected Result دقیق برای این Requirement تعیین کند.

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

بنابراین هنگام Review FRS باید از خود بپرسیم:

آیا می‌توان بر اساس این Requirement یک Expected Result مشخص تعریف کرد؟

اگر پاسخ منفی باشد، Requirement احتمالاً نیاز به شفاف‌سازی دارد.

مخلوط کردن Functional و Non-Functional Requirements

یکی دیگر از اشتباهات رایج، ترکیب بدون ساختار انواع مختلف Requirementها است.

سیستم باید امکان ثبت سفارش را فراهم کند و صفحه ثبت سفارش نیز باید در کمتر از 2 ثانیه بارگذاری شود.

قسمت اول یک Functional Requirement است؛ یعنی مشخص می‌کند سیستم چه کاری باید انجام دهد.

قسمت دوم بیشتر یک Non-Functional Requirement مربوط به Performance است.

قرار گرفتن این دو در یک Requirement لزوماً همیشه اشتباه نیست، اما می‌تواند باعث شود Requirementها:

• سخت‌تر مدیریت شوند.
• سخت‌تر Trace شوند.
• سخت‌تر تست شوند.
• مسئولیت‌ها و معیارهای پذیرش آن‌ها نامشخص‌تر شود.

بهتر است در صورت نیاز، این موارد به Requirementهای مستقل و قابل ردیابی تقسیم شوند.

FR-ORDER-001
سیستم باید امکان ثبت سفارش را فراهم کند.

NFR-PERF-001
صفحه ثبت سفارش باید در شرایط تعریف‌شده حداکثر ظرف 2 ثانیه بارگذاری شود.

البته اینکه Functional و Non-Functional Requirements در یک سند یا اسناد جداگانه قرار بگیرند، به ساختار پروژه بستگی دارد.

نادیده گرفتن Error Scenarios

گاهی FRS فقط Happy Path را توضیح می‌دهد و شرایط خطا نادیده گرفته می‌شوند.

کاربر می‌تواند با وارد کردن اطلاعات کارت بانکی، پرداخت را انجام دهد.

اما مشخص نشده اگر:

• موجودی کافی نباشد،
• اطلاعات کارت اشتباه باشد،
• Gateway در دسترس نباشد،
• درخواست Timeout شود،
• پرداخت انجام شود ولی پاسخ صحیح دریافت نشود،

چه اتفاقی باید رخ دهد.

این موضوع می‌تواند باعث شود Developer و Tester برداشت‌های متفاوتی داشته باشند.

بنابراین برای Functionalityهای مهم، علاوه بر Main Flow باید Alternative Flow و Error Flow نیز بررسی و در صورت نیاز مستند شوند.

نداشتن Requirement ID

اگر Requirementها شناسه مشخصی نداشته باشند، مدیریت و Trace کردن آن‌ها دشوار می‌شود.

FR-LOGIN-001
FR-LOGIN-002
FR-ORDER-001
FR-ORDER-002

داشتن ID باعث می‌شود بتوان Requirement را در بخش‌های مختلف پروژه دنبال کرد.

FR-ORDER-001
      ↓
Test Scenario
      ↓
Test Case
      ↓
Test Result
      ↓
Defect

همچنین اگر Requirement تغییر کند، پیدا کردن Test Caseها و سایر موارد مرتبط ساده‌تر خواهد بود.

نبود Traceability

یکی دیگر از مشکلات مهم، نبود ارتباط میان Requirementها و مواردی است که بر اساس آن‌ها ایجاد شده‌اند.

برای مثال ممکن است Requirement زیر وجود داشته باشد:

FR-PAY-001
سیستم باید امکان پرداخت آنلاین سفارش را فراهم کند.

اما مشخص نباشد:

• چه Test Scenarioهایی برای آن وجود دارد؟
• چه Test Caseهایی آن را پوشش می‌دهند؟
• آیا Defect مرتبطی وجود داشته است؟
• آیا Requirement تغییر کرده است؟
• نسخه فعلی Test Case بر اساس کدام Requirement نوشته شده است؟

استفاده از Requirements Traceability Matrix (RTM) می‌تواند این ارتباط را ساختارمندتر کند.

تکرار یا تناقض بین Requirementها

گاهی یک Requirement در چند بخش مختلف FRS تکرار می‌شود و نسخه‌های مختلف آن با یکدیگر سازگار نیستند.

FR-USER-005:

کاربر پس از 5 تلاش ناموفق Login مسدود می‌شود.

FR-SEC-003:

حساب کاربر پس از 3 تلاش ناموفق Login مسدود می‌شود.

این تناقض باید قبل از Development مشخص شود.

در غیر این صورت ممکن است:

• Developer یک Requirement را اجرا کند.
• Tester Requirement دیگری را مبنای تست قرار دهد.
• Stakeholder انتظار متفاوتی داشته باشد.

بنابراین در Review FRS باید Consistency بین Requirementها نیز بررسی شود.

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

گاهی یک Functional Requirement به سیستم، سرویس یا Requirement دیگری وابسته است، اما این وابستگی در FRS مشخص نشده است.

سیستم باید وضعیت پرداخت را نمایش دهد.

اما وضعیت پرداخت از یک Payment Gateway خارجی دریافت می‌شود.

در این حالت باید مشخص باشد:

• منبع اطلاعات چیست؟
• چه زمانی اطلاعات دریافت می‌شود؟
• اگر سرویس خارجی در دسترس نباشد چه اتفاقی می‌افتد؟
• آیا آخرین وضعیت ذخیره‌شده نمایش داده می‌شود؟
• وضعیت نامشخص چگونه مدیریت می‌شود؟

مشخص کردن چنین Dependencyهایی برای Development و Testing اهمیت زیادی دارد.

تغییر Requirement بدون بررسی تأثیر آن

Requirementها ممکن است در طول پروژه تغییر کنند. اما تغییر یک Requirement نباید فقط به اصلاح متن FRS محدود شود.

باید بررسی شود این تغییر چه اثری روی موارد دیگر دارد.

Requirement
   ↓
Design
   ↓
Code
   ↓
Test Scenario
   ↓
Test Case
   ↓
Test Data

اگر Requirement تغییر کند، ممکن است چند مورد از این زنجیره نیز نیاز به بازبینی داشته باشند.

به همین دلیل Versioning و Traceability در پروژه‌های بزرگ اهمیت بیشتری پیدا می‌کنند.

جمع‌بندی اشتباهات رایج

یک FRS مناسب باید تا حد امکان:

• واضح و بدون ابهام باشد.
• Requirementهای قابل تست داشته باشد.
• Functional Requirements را به‌صورت مشخص تعریف کند.
• Main Flow و در صورت نیاز Alternative و Error Flow را پوشش دهد.
• Business Ruleهای مرتبط را مشخص کند.
• Requirement ID داشته باشد.
• بین Requirementها Consistency برقرار باشد.
• Dependencyها و Constraints مهم را مشخص کند.
• امکان Traceability را فراهم کند.
• در صورت تغییر، تحت کنترل و قابل پیگیری باشد.

از دید Tester، یک سؤال ساده می‌تواند بخش بزرگی از مشکلات FRS را آشکار کند:

«اگر این Requirement را به من بدهند، آیا می‌توانم بر اساس آن یک Test Case با Expected Result مشخص طراحی کنم؟»

اگر پاسخ این سؤال منفی باشد، احتمالاً Requirement هنوز به اندازه کافی شفاف و قابل تست نیست.

FRS Template و نمونه سند

ساختار FRS می‌تواند با توجه به نوع پروژه، سازمان و روش مستندسازی متفاوت باشد. بنابراین یک Template واحد و اجباری برای تمام پروژه‌ها وجود ندارد.

با این حال، می‌توان یک ساختار استاندارد و کاربردی طراحی کرد که بخش‌های اصلی موردنیاز برای مستندسازی Functional Requirements را پوشش دهد.

FRS Template پیشنهادی

ساختار زیر می‌تواند به‌عنوان نقطه شروع برای تهیه یک سند FRS استفاده شود:

FRS Document
│
├── 1. Document Information
│   ├── Document Title
│   ├── Version
│   ├── Author
│   ├── Date
│   └── Revision History
│
├── 2. Introduction
│   ├── Purpose
│   └── Objectives
│
├── 3. Scope
│   ├── In Scope
│   └── Out of Scope
│
├── 4. Functional Requirements
│   ├── FR-001
│   ├── FR-002
│   └── FR-003
│
├── 5. Business Rules
│
├── 6. Main Flow
│
├── 7. Alternative & Error Flows
│
├── 8. Input & Output
│
├── 9. External Interfaces
│
├── 10. Dependencies & Constraints
│
└── 11. Requirements Traceability

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

نمونه FRS برای سیستم فروشگاه اینترنتی

برای درک بهتر Template، فرض کنیم قرار است یک Functionality برای ثبت سفارش در یک فروشگاه اینترنتی تعریف کنیم.

Document Information

Field	Value
Document	Functional Requirements Specification
Project	Online Shopping System
Version	1.0
Status	Draft
Author	Business Analyst
Last Updated	2026-10-07

Scope

In Scope:

• افزودن محصول به سبد خرید
• مشاهده سبد خرید
• ثبت سفارش
• پرداخت آنلاین
• مشاهده وضعیت سفارش

Out of Scope:

• مدیریت موجودی انبار
• مدیریت پنل فروشندگان
• فرآیند ارسال فیزیکی کالا

Functional Requirements

Requirementها بهتر است دارای ID مشخص باشند.

ID	Functional Requirement
FR-ORDER-001	سیستم باید به کاربر اجازه دهد محصول موجود را به سبد خرید اضافه کند.
FR-ORDER-002	سیستم باید تعداد محصولات موجود در سبد خرید را محاسبه و نمایش دهد.
FR-ORDER-003	سیستم باید مبلغ نهایی سفارش را قبل از پرداخت نمایش دهد.
FR-ORDER-004	سیستم باید پس از پرداخت موفق، سفارش را ثبت کند.
FR-ORDER-005	سیستم باید وضعیت سفارش ثبت‌شده را به کاربر نمایش دهد.

وجود ID باعث می‌شود هر Requirement بتواند در مراحل بعدی پروژه به‌صورت مستقل Trace شود.

Business Rules

در کنار Functional Requirements، قوانین کسب‌وکار مرتبط نیز باید مشخص شوند.

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

Business Ruleها می‌توانند روی طراحی Test Scenario و Test Case تأثیر مستقیم داشته باشند.

Main Flow

برای مثال، Main Flow ثبت سفارش می‌تواند به این شکل باشد:

1. کاربر وارد حساب کاربری خود می‌شود.
2. محصول را انتخاب می‌کند.
3. محصول را به سبد خرید اضافه می‌کند.
4. وارد صفحه سبد خرید می‌شود.
5. اطلاعات سفارش را بررسی می‌کند.
6. آدرس ارسال را انتخاب می‌کند.
7. روش پرداخت را انتخاب می‌کند.
8. وارد درگاه پرداخت می‌شود.
9. پرداخت را با موفقیت انجام می‌دهد.
10. سیستم سفارش را ثبت می‌کند.
11. سیستم شماره سفارش را نمایش می‌دهد.

این Flow به Tester کمک می‌کند مسیر اصلی Functionality را بهتر درک کند.

Alternative و Error Flow

Main Flow به‌تنهایی برای طراحی تست کافی نیست.

Alternative Flow 1 — محصول ناموجود

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

Error Flow 2 — پرداخت ناموفق

کاربر وارد درگاه پرداخت می‌شود
        ↓
پرداخت ناموفق است
        ↓
سیستم نباید سفارش را به‌عنوان پرداخت‌شده ثبت کند
        ↓
وضعیت مناسب به کاربر نمایش داده می‌شود

Error Flow 3 — Timeout

درخواست پرداخت ارسال می‌شود
        ↓
پاسخ در زمان مورد انتظار دریافت نمی‌شود
        ↓
سیستم وضعیت تراکنش را مطابق Business Rule مدیریت می‌کند

این بخش برای Tester اهمیت زیادی دارد، زیرا بسیاری از Defectها در شرایطی رخ می‌دهند که Main Flow را دنبال نمی‌کنند.

Input و Output

برای هر Functionality مهم، مشخص کردن Input و Output می‌تواند ابهام را کاهش دهد.

Input:

• Product ID
• Quantity
• Shipping Address
• Payment Method

Output:

• Order ID
• Order Status
• Total Amount
• Payment Status

همچنین در صورت وجود Validation، بهتر است شرایط معتبر و نامعتبر نیز مشخص شوند.

External Interfaces

اگر Functionality با سیستم دیگری ارتباط دارد، این وابستگی باید مشخص شود.

Online Shopping System
        ↓
Payment Service
        ↓
Bank Gateway

در این حالت FRS می‌تواند مشخص کند:

• چه داده‌ای به سرویس ارسال می‌شود؟
• چه نتیجه‌ای انتظار می‌رود؟
• وضعیت موفقیت چگونه مشخص می‌شود؟
• خطا چگونه مدیریت می‌شود؟
• اگر سرویس خارجی در دسترس نباشد چه اتفاقی رخ می‌دهد؟

جزئیات فنی Interface ممکن است در مستندات دیگری مانند API Specification قرار داشته باشد؛ بنابراین FRS لازم نیست الزاماً تمام جزئیات فنی API را در خود جای دهد.

Requirement Traceability

در نهایت می‌توان Requirementها را به Test Scenario و Test Case متصل کرد.

Requirement ID	Test Scenario	Test Case
FR-ORDER-001	افزودن محصول موجود	TC-ORDER-001
FR-ORDER-001	افزودن محصول ناموجود	TC-ORDER-002
FR-ORDER-004	پرداخت موفق	TC-ORDER-010
FR-ORDER-004	پرداخت ناموفق	TC-ORDER-011
FR-ORDER-004	Payment Timeout	TC-ORDER-012

این ارتباط پایه‌ای برای Requirements Traceability است و در پروژه‌های بزرگ‌تر می‌تواند در قالب RTM یا ابزارهای مدیریت Requirements و Testing پیاده‌سازی شود.

یک Template ساده و قابل استفاده

اگر بخواهیم کل ساختار را به یک قالب ساده برای استفاده روزمره تبدیل کنیم، می‌توان از این الگو استفاده کرد:

FUNCTIONAL REQUIREMENTS SPECIFICATION

1. Document Information
   - Project:
   - Version:
   - Author:
   - Date:
   - Status:

2. Purpose
   - هدف این سند چیست؟

3. Scope
   - In Scope:
   - Out of Scope:

4. Functional Requirements

   ID:
   Title:
   Description:
   Preconditions:
   Main Flow:
   Alternative Flow:
   Error Flow:
   Input:
   Output:
   Business Rules:
   Dependencies:
   Constraints:

5. External Interfaces

6. Requirements Traceability

7. Revision History

این Template را می‌توان با توجه به نیاز پروژه ساده‌تر یا کامل‌تر کرد.

نکته مهم این است که هدف FRS پر کردن یک Template ثابت نیست؛ هدف اصلی این است که Functional Requirements به شکلی مستند شوند که برای Stakeholder، Developer و Tester واضح، قابل بررسی و قابل پیگیری باشند.

منابع

• ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering
• ISO/IEC/IEEE 29148:2018 — Online Browsing Platform
• NASA Software Engineering Handbook — Software Requirements Specification (SWE-109)
• NASA Software Engineering Handbook — SRS: Software Requirements Specification
• NASA Systems Engineering Handbook — Requirements Engineering References and Checklists
• IBM Documentation — Requirement Documents

سوالات متداول درباره FRS

FRS چیست؟

FRS مخفف Functional Requirements Specification است و سندی برای مستندسازی نیازمندی‌های عملکردی یک سیستم یا نرم‌افزار محسوب می‌شود. این سند مشخص می‌کند سیستم از نظر عملکردی چه کارهایی باید انجام دهد و در شرایط مختلف چه رفتاری باید داشته باشد.

FRS مخفف چیست؟

FRS مخفف Functional Requirements Specification است که می‌توان آن را «مشخصات نیازمندی‌های عملکردی» ترجمه کرد.

Functional Requirements Specification چیست؟

Functional Requirements Specification سندی است که عملکردها و رفتارهای مورد انتظار سیستم را مشخص می‌کند. این سند می‌تواند شامل Functional Requirements، Business Rules، جریان‌های اصلی و جایگزین، شرایط خطا، ورودی‌ها، خروجی‌ها و وابستگی‌های مرتبط باشد.

تفاوت FRS و SRS چیست؟

SRS معمولاً سندی جامع‌تر برای مشخص کردن نیازمندی‌های نرم‌افزار است و بسته به ساختار پروژه می‌تواند Functional و Non-Functional Requirements را پوشش دهد. FRS تمرکز مشخص‌تری بر Functional Requirements دارد. البته ساختار و مرزبندی این اسناد در سازمان‌های مختلف می‌تواند متفاوت باشد.

تفاوت FRS و FRD چیست؟

FRS مخفف Functional Requirements Specification و FRD مخفف Functional Requirements Document است. در بسیاری از پروژه‌ها این دو اصطلاح برای اسناد مشابه یا حتی یکسان استفاده می‌شوند، اما برخی سازمان‌ها برای آن‌ها نقش یا سطح جزئیات متفاوتی تعریف می‌کنند. بنابراین تعریف داخلی پروژه تعیین‌کننده است.

چه کسی سند FRS را تهیه می‌کند؟

تهیه FRS معمولاً با مشارکت نقش‌هایی مانند Business Analyst، System Analyst، Product Manager و سایر Stakeholderهای مرتبط انجام می‌شود. بسته به ساختار سازمان، Developer و Tester نیز ممکن است در Review و تکمیل Requirementها مشارکت داشته باشند.

آیا Tester باید FRS را بررسی کند؟

بله. بررسی FRS توسط Tester می‌تواند به شناسایی Requirementهای مبهم، ناقص، متناقض یا غیرقابل تست قبل از شروع Development کمک کند. Tester همچنین می‌تواند از FRS برای استخراج Test Scenario و طراحی Test Case استفاده کند.

آیا FRS شامل Non-Functional Requirements هم می‌شود؟

این موضوع به ساختار مستندسازی پروژه بستگی دارد. در برخی سازمان‌ها FRS عمدتاً روی Functional Requirements تمرکز دارد و Non-Functional Requirements در سند دیگری مانند SRS مستند می‌شوند. در برخی پروژه‌ها ممکن است هر دو نوع Requirement در یک سند قرار بگیرند.

آیا FRS در Agile استفاده می‌شود؟

بله، اما شکل مستندسازی آن می‌تواند با پروژه‌های سنتی متفاوت باشد. در Agile ممکن است بخشی از Functional Requirements در قالب User Story، Acceptance Criteria، Backlog Item یا مستندات تکمیلی نگهداری شوند و الزاماً یک سند FRS حجیم و مستقل وجود نداشته باشد.

آیا FRS همان FRD است؟

نه لزوماً. در بسیاری از سازمان‌ها FRS و FRD برای یک نوع سند یا اسناد بسیار مشابه استفاده می‌شوند، اما در برخی پروژه‌ها تعریف و سطح جزئیات آن‌ها متفاوت است. بنابراین برای تشخیص تفاوت باید فرآیند مستندسازی همان پروژه یا سازمان را بررسی کرد.