سند نیازمندی‌های نرم افزار SRS چیست؟ راهنمای جامع Software Requirements Specification

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

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

اینجاست که SRS یا Software Requirements Specification اهمیت پیدا می‌کند.

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

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

«کاربر باید بتواند به‌صورت آنلاین خرید کند.»

برای شروع توسعه کافی نیست.

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

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

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

در این مقاله، SRS را از پایه تا سطح کاربردی بررسی می‌کنیم؛ از تعریف و ساختار سند نیازمندی‌های نرم‌افزار گرفته تا Functional Requirement، Non-Functional Requirement، ویژگی‌های یک Requirement خوب، نحوه Review سند SRS و نقش تستر در بررسی و استفاده از آن.

در موضوعاتی مانند BRD، PRD، Acceptance Criteria، Verification و Validation نیز فقط به اندازه‌ای پیش می‌رویم که ارتباط آن‌ها با SRS روشن شود و برای مباحث تخصصی‌تر، به مقالات جداگانه مرتبط ارجاع خواهیم داد.

SRS چیست؟

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

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

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

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

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

• قابلیت‌ها و عملکردهای مورد انتظار سیستم
• رفتار سیستم در شرایط مختلف
• نیازمندی‌های عملکردی یا Functional Requirements
• نیازمندی‌های غیرعملکردی یا Non-Functional Requirements
• محدودیت‌های سیستم
• وابستگی‌ها و پیش‌فرض‌ها
• رابط‌های موردنیاز با سیستم‌های دیگر
• قوانین کسب‌وکار مرتبط با سیستم
• معیارهای قابل قبول بودن برخی قابلیت‌ها

بنابراین SRS صرفاً فهرستی از قابلیت‌های نرم‌افزار نیست؛ بلکه باید تصویری نسبتاً دقیق از نیازمندی‌های محصول و رفتار مورد انتظار سیستم ارائه دهد.

یک مثال ساده از سند نیازمندی‌های نرم‌افزار

فرض کنیم یک تیم قرار است یک فروشگاه اینترنتی ایجاد کند.

یکی از نیازهای اولیه کسب‌وکار این است:

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

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

مثلاً:

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

این همان جایی است که سند نیازمندی‌های نرم‌افزار اهمیت پیدا می‌کند.

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

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

حالا این Requirement اطلاعات بیشتری در اختیار تیم قرار می‌دهد.

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

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

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

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

چرا SRS مهم است؟

فرض کنید یک پروژه بدون یک سند نیازمندی‌های مشخص پیش می‌رود.

Product Manager یک انتظار خاص از سیستم دارد، توسعه‌دهنده برداشت دیگری از همان نیازمندی دارد و تستر نیز بر اساس برداشت خودش تست‌ها را طراحی می‌کند.

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

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

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

مهم‌ترین مزایای SRS

۱. ایجاد درک مشترک

SRS می‌تواند یک مرجع مشترک برای Business Analyst، Product Manager، Developer، Tester و سایر ذی‌نفعان باشد.

۲. کاهش ابهام

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

۳. کمک به توسعه نرم‌افزار

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

۴. کمک به تست نرم‌افزار

تستر می‌تواند از نیازمندی‌های موجود در SRS برای طراحی Test Scenario و Test Case استفاده کند.

۵. فراهم کردن مبنایی برای ارزیابی محصول

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

۶. شناسایی زودهنگام مشکلات

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

آیا SRS فقط برای توسعه‌دهنده است؟

خیر.

یکی از تصورات اشتباه درباره سند نیازمندی‌های نرم‌افزار این است که این سند صرفاً برای برنامه‌نویسان تهیه می‌شود.

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

نقش	کاربرد SRS
Business Analyst	تحلیل، شفاف‌سازی و مستندسازی نیازمندی‌ها
Product Manager	بررسی انطباق نیازمندی‌ها با اهداف محصول
Developer	درک رفتار و قابلیت‌های مورد انتظار سیستم
Software Tester	بررسی Testability و طراحی سناریوهای تست
Project Manager	درک محدوده و نیازمندی‌های پروژه
Stakeholder	بررسی اینکه نیازهای مورد انتظار در محصول لحاظ شده‌اند

برای تستر نرم‌افزار، SRS اهمیت ویژه‌ای دارد؛ زیرا Requirement می‌تواند یکی از مبناهای اصلی فعالیت‌های تست باشد.

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

«سیستم باید نتیجه جستجو را حداکثر در ۲ ثانیه نمایش دهد.»

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

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

«سیستم باید سرعت مناسبی داشته باشد.»

مشخص نیست منظور از «سرعت مناسب» دقیقاً چیست و چگونه باید آن را اندازه‌گیری کرد.

این موضوع به مفهوم Testability یا قابلیت تست‌پذیری Requirement مربوط می‌شود که در ادامه مقاله به آن خواهیم پرداخت.

SRS چه زمانی تهیه می‌شود؟

سند SRS معمولاً در مرحله تحلیل و مستندسازی نیازمندی‌های نرم‌افزار تهیه می‌شود؛ یعنی زمانی که تیم باید مشخص کند محصول قرار است چه چیزی ارائه دهد و سیستم چه رفتارهایی باید داشته باشد.

به‌صورت ساده می‌توان ارتباط این مرحله با مراحل بعدی را چنین نمایش داد:

Business / Product Needs → Requirements → SRS → Development → Testing → Release

البته این فرآیند در همه پروژه‌ها دقیقاً به همین شکل اجرا نمی‌شود.

برای مثال، در پروژه‌هایی که از روش‌های Agile استفاده می‌کنند، ممکن است نیازمندی‌ها به شکل تدریجی و در قالب‌هایی مانند User Story، Acceptance Criteria و سایر Artefactهای محصول مدیریت شوند و الزاماً یک SRS سنتی و یکپارچه وجود نداشته باشد.

بنابراین نباید تصور کرد که SRS همیشه یک سند بزرگ و ثابت است که فقط یک بار در ابتدای پروژه نوشته می‌شود.

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

در ادامه، ابتدا بررسی می‌کنیم SRS چه تفاوتی با BRD و PRD دارد و سپس به سراغ ساختار و اجزای یک سند نیازمندی‌های نرم‌افزار می‌رویم.

SRS چه تفاوتی با BRD و PRD دارد؟

یکی از سؤال‌های رایج هنگام مطالعه مستندات نیازمندی این است که SRS، BRD و PRD چه تفاوتی با یکدیگر دارند؟

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

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

BRD → چرا این محصول یا قابلیت موردنیاز است؟

PRD → محصول قرار است چه چیزی ارائه دهد؟

SRS → نرم‌افزار چه نیازمندی‌هایی را باید برآورده کند؟

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

BRD چیست؟

BRD مخفف Business Requirements Document یا سند نیازمندی‌های کسب‌وکار است.

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

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

«نرخ رها کردن سبد خرید در فروشگاه اینترنتی زیاد است و باید فرآیند خرید ساده‌تر شود.»

این یک نیاز کسب‌وکاری است.

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

بنابراین BRD معمولاً بیشتر به سؤال «چرا؟» پاسخ می‌دهد.

PRD چیست؟

PRD مخفف Product Requirements Document یا سند نیازمندی‌های محصول است.

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

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

• خرید در چند مرحله ساده‌تر
• نمایش خلاصه سفارش
• ذخیره آدرس کاربر
• نمایش روش‌های پرداخت
• امکان ادامه پرداخت پس از خطا

بنابراین PRD معمولاً به سؤال «محصول چه چیزی باید ارائه دهد؟» نزدیک‌تر است.

SRS چه جایگاهی دارد؟

SRS بیشتر روی نیازمندی‌های دقیق نرم‌افزار و رفتار مورد انتظار سیستم تمرکز دارد.

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

FR-ORD-001: سیستم باید به کاربر احراز هویت‌شده اجازه دهد محصولات موجود را به سبد خرید اضافه کرده و پس از انتخاب روش پرداخت، سفارش خود را ثبت کند.

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

بنابراین SRS بیشتر به این سؤال پاسخ می‌دهد:

«سیستم نرم‌افزاری دقیقاً چه نیازمندی‌هایی را باید برآورده کند؟»

مقایسه BRD، PRD و SRS

ویژگی	BRD	PRD	SRS
نام کامل	Business Requirements Document	Product Requirements Document	Software Requirements Specification
تمرکز اصلی	نیاز کسب‌وکار	نیازمندی محصول	نیازمندی نرم‌افزار
سؤال اصلی	چرا؟	چه چیزی؟	سیستم چه چیزی باید انجام دهد؟
سطح نگاه	کسب‌وکار	محصول و کاربر	سیستم و نرم‌افزار
مخاطبان اصلی	ذی‌نفعان و تیم کسب‌وکار	Product Team و ذی‌نفعان	تحلیلگر، توسعه‌دهنده، تستر و تیم فنی
جزئیات فنی	معمولاً کم	متوسط	معمولاً بیشتر
کاربرد در تست	غیرمستقیم	مستقیم‌تر	بسیار مهم

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

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

ارتباط BRD، PRD و SRS چگونه است؟

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

مرحله اول: نیاز کسب‌وکار

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

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

مشکل کسب‌وکار چیست و چرا باید برای آن راه‌حلی ایجاد شود؟

این موضوع می‌تواند در BRD مطرح شود.

مرحله دوم: نیاز محصول

تیم محصول تصمیم می‌گیرد فرآیند Checkout را ساده‌تر کند.

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

مرحله سوم: نیاز نرم‌افزار

حالا باید مشخص شود سیستم دقیقاً چه رفتارهایی باید داشته باشد.

برای مثال:

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

این Requirement می‌تواند در SRS با جزئیات دقیق‌تر مستند شود.

بنابراین یک مدل ساده از ارتباط آن‌ها چنین است:

Business Need → Product Requirement → Software Requirement

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

آیا BRD، PRD و SRS همیشه باید سه سند جدا باشند؟

خیر.

این نکته مهمی است که هنگام مطالعه درباره SRS باید در نظر داشته باشیم.

هیچ قانون عمومی‌ای وجود ندارد که همه پروژه‌ها الزاماً باید سه فایل جداگانه با نام‌های BRD، PRD و SRS داشته باشند.

یک سازمان ممکن است:

• هر سه سند را داشته باشد.
• BRD و PRD را در یک سند ترکیب کند.
• PRD را به‌عنوان سند اصلی محصول استفاده کند.
• SRS جداگانه تهیه نکند و Requirementها را در ابزار مدیریت پروژه ثبت کند.
• از User Story و Acceptance Criteria به جای یک SRS سنتی استفاده کند.

بنابراین SRS یک مفهوم و رویکرد برای مشخص‌کردن نیازمندی‌های نرم‌افزار است، نه صرفاً نام یک فایل خاص.

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

چرا تستر باید تفاوت BRD، PRD و SRS را بداند؟

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

فرض کنید در SRS نوشته شده است:

«کاربر باید بتواند پرداخت آنلاین انجام دهد.»

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

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

در این حالت تستر می‌تواند هنگام بررسی Requirement سؤال‌های دقیق‌تری مطرح کند:

• آیا فرآیند پرداخت باید ساده باشد؟
• در صورت شکست پرداخت چه اتفاقی برای سفارش می‌افتد؟
• آیا کاربر می‌تواند بدون از دست دادن اطلاعات سفارش، دوباره پرداخت کند؟
• آیا روش‌های پرداخت مورد انتظار در Requirementها مشخص شده‌اند؟
• آیا رفتار سیستم برای خطاهای پرداخت نیز تعریف شده است؟

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

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

ساختار SRS چیست؟

حالا که با مفهوم SRS یا سند نیازمندی‌های نرم‌افزار و تفاوت آن با BRD و PRD آشنا شدیم، سؤال مهم بعدی این است:

یک SRS استاندارد چه بخش‌هایی دارد؟

ساختار SRS بسته به نوع پروژه، سازمان، روش توسعه و استاندارد مورد استفاده می‌تواند متفاوت باشد. بنابراین نباید انتظار داشته باشیم همه شرکت‌ها دقیقاً از یک قالب یکسان استفاده کنند.

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

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

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

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

۱. مقدمه و هدف SRS

در ابتدای سند نیازمندی‌های نرم‌افزار معمولاً اطلاعاتی درباره خود سند و هدف آن ارائه می‌شود.

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

• هدف تهیه این سند چیست؟
• این سند مربوط به کدام محصول یا سیستم است؟
• مخاطبان اصلی سند چه کسانی هستند؟
• این سند چه محدوده‌ای را پوشش می‌دهد؟
• نسخه فعلی سند چیست؟
• چه تغییراتی در نسخه‌های مختلف ایجاد شده است؟

برای مثال:

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

این قسمت شاید مستقیماً به طراحی Test Case کمک نکند، اما برای مشخص کردن Context و Scope سند اهمیت دارد.

۲. محدوده نرم‌افزار (Software Scope)

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

برای مثال، فرض کنید قرار است یک سامانه فروش اینترنتی ساخته شود.

در محدوده پروژه:

• ثبت‌نام کاربران
• جستجوی محصولات
• سبد خرید
• ثبت سفارش
• پرداخت آنلاین
• پیگیری سفارش

خارج از محدوده پروژه:

• مدیریت انبار فیزیکی
• سیستم حسابداری
• ارسال کالا توسط شرکت لجستیکی

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

برای تستر نیز این موضوع اهمیت دارد؛ زیرا یکی از سؤال‌های مهم هنگام طراحی تست این است:

آیا این قابلیت اصلاً در محدوده نسخه موردنظر قرار دارد؟

۳. معرفی کلی محصول

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

هدف این بخش این نیست که تمام Requirementها را با جزئیات توضیح دهد؛ بلکه باید به خواننده کمک کند بفهمد سیستم چیست و چه کاری انجام می‌دهد.

برای مثال:

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

همچنین ممکن است در این قسمت مواردی مانند موارد زیر معرفی شوند:

• هدف کلی محصول
• کاربران اصلی
• محیط استفاده
• وابستگی‌های مهم
• ارتباط کلی سیستم با سایر سامانه‌ها

۴. کاربران و ذی‌نفعان سیستم

هر نرم‌افزار برای گروهی از کاربران یا ذی‌نفعان ساخته می‌شود.

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

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

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

این اطلاعات در مراحل بعدی برای تحلیل Requirementها و طراحی تست اهمیت پیدا می‌کنند.

برای مثال، تستر باید بداند Requirement مربوط به لغو سفارش برای کدام Role قابل دسترسی است.

۵. Functional Requirements چیست؟

یکی از مهم‌ترین بخش‌های SRS، Functional Requirements یا نیازمندی‌های عملکردی است.

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

مثلاً:

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

یا:

FR-ORD-001: سیستم باید پس از پرداخت موفق، سفارش کاربر را با وضعیت «پرداخت‌شده» ثبت کند.

این نوع Requirementها معمولاً مستقیماً برای تستر اهمیت دارند؛ زیرا می‌توان بر اساس آن‌ها شرایط مختلف سیستم را تحلیل و سناریوهای تست طراحی کرد.

مثال‌هایی از Functional Requirement

فرض کنیم برای یک فروشگاه اینترنتی Requirementهای زیر در SRS نوشته شده‌اند:

FR-001

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

FR-002

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

FR-003

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

FR-004

سیستم باید پس از پرداخت موفق، سفارش را ثبت کند.

FR-005

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

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

Functional Requirement خوب چه ویژگی‌هایی دارد؟

یک Functional Requirement مناسب نباید صرفاً بگوید:

«سیستم باید قابلیت پرداخت داشته باشد.»

این جمله بیش از حد کلی است.

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

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

۶. Non-Functional Requirements چیست؟

دسته مهم دیگری از نیازمندی‌ها، Non-Functional Requirements یا نیازمندی‌های غیرعملکردی هستند.

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

برای مثال:

Functional Requirement:

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

Non-Functional Requirement:

سیستم باید نتایج جستجو را حداکثر در ۲ ثانیه برای ۹۵ درصد درخواست‌ها نمایش دهد.

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

نمونه‌هایی از Non-Functional Requirements

نیازمندی‌های غیرعملکردی می‌توانند حوزه‌های مختلفی را پوشش دهند، از جمله:

Performance

سیستم باید در شرایط بار تعریف‌شده، پاسخ جستجو را حداکثر در ۲ ثانیه ارائه دهد.

Security

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

Availability

سامانه باید در طول ماه حداقل ۹۹.۹ درصد در دسترس باشد.

Usability

کاربر جدید باید بتواند بدون آموزش قبلی فرآیند ثبت سفارش را تکمیل کند.

Scalability

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

نکته مهم این است که Non-Functional Requirement نیز باید تا حد امکان قابل اندازه‌گیری و قابل تست باشد.

برای مثال:

«سیستم باید خیلی سریع باشد.»

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

اما:

«۹۵ درصد درخواست‌ها باید در کمتر از ۲ ثانیه پاسخ داده شوند.»

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

تفاوت Functional و Non-Functional Requirement

ویژگی	Functional Requirement	Non-Functional Requirement
تمرکز	رفتار و قابلیت سیستم	ویژگی و کیفیت سیستم
سؤال اصلی	سیستم چه کاری انجام دهد؟	سیستم با چه ویژگی یا سطحی آن کار را انجام دهد؟
مثال	کاربر بتواند سفارش ثبت کند	ثبت سفارش در کمتر از ۲ ثانیه انجام شود
قابلیت تست	معمولاً بله	بله، در صورت تعریف معیار مشخص

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

۷. رابط‌های خارجی (External Interfaces)

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

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

• درگاه پرداخت
• سرویس پیامک
• سرویس ارسال
• سرویس احراز هویت
• سامانه مالی

برای مثال:

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

این اطلاعات برای توسعه‌دهنده و تستر اهمیت زیادی دارند؛ زیرا رفتار سیستم‌های وابسته می‌تواند روی نتیجه تست تأثیر بگذارد.

۸. قوانین کسب‌وکار (Business Rules)

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

برای مثال:

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

یا:

کاربر فقط تا ۲۴ ساعت پس از ثبت سفارش می‌تواند درخواست لغو سفارش را ثبت کند.

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

۹. محدودیت‌ها (Constraints)

در هر پروژه ممکن است محدودیت‌هایی وجود داشته باشد که طراحی، توسعه یا اجرای سیستم را تحت تأثیر قرار دهند.

برای مثال:

• استفاده از یک فناوری خاص
• محدودیت‌های قانونی
• محدودیت زیرساخت
• محدودیت سخت‌افزاری
• محدودیت امنیتی
• محدودیت‌های سازمانی

مثلاً:

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

این مورد می‌تواند یک Constraint برای تیم توسعه ایجاد کند و در طراحی و اجرای تست نیز مورد توجه قرار گیرد.

۱۰. فرضیات و وابستگی‌ها

گاهی SRS بر اساس فرض‌هایی نوشته می‌شود که باید در طول پروژه برقرار باشند.

مثلاً:

فرض می‌شود سرویس ارسال در زمان ثبت سفارش در دسترس باشد.

یا:

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

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

برای تستر نیز شناخت این وابستگی‌ها اهمیت دارد؛ زیرا ممکن است یک Failure ناشی از خود سیستم نباشد و به یک Dependency خارجی مربوط شود.

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

نباید تصور کنیم هر SRS باید دقیقاً همین ترتیب و همین تعداد بخش را داشته باشد.

ساختار سند نیازمندی‌های نرم‌افزار باید متناسب با پروژه انتخاب شود.

یک پروژه ساده ممکن است SRS کوتاه و نسبتاً ساده‌ای داشته باشد؛ در حالی که یک سیستم بانکی، درمانی یا سازمانی پیچیده ممکن است نیازمند مستندات گسترده‌تر، شناسه‌های دقیق Requirement، قوانین کسب‌وکار، Interface Specification، Security Requirements و معیارهای متعدد پذیرش باشد.

همچنین برخی اطلاعات مانند Acceptance Criteria، اولویت Requirementها و Traceability ممکن است در خود SRS، در اسناد مرتبط یا در ابزارهای مدیریت نیازمندی و پروژه نگهداری شوند.

بنابراین مهم‌تر از تعداد صفحات SRS، کیفیت Requirementهای موجود در آن است.

در بخش بعدی، روی یکی از مهم‌ترین موضوعات SRS تمرکز می‌کنیم:

یک Requirement خوب چه ویژگی‌هایی دارد و چگونه می‌توان Requirementهای مبهم، ناقص یا غیرقابل تست را در SRS شناسایی کرد؟

این موضوع برای تسترهای نرم‌افزار اهمیت ویژه‌ای دارد، زیرا کیفیت تست تا حد زیادی به کیفیت Requirementهایی وابسته است که تست بر اساس آن‌ها طراحی می‌شود.

یک Requirement خوب در SRS چه ویژگی‌هایی دارد؟

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

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

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

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

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

بنابراین یکی از مهم‌ترین ویژگی‌های یک Requirement مناسب، قابل فهم و قابل تست بودن آن است.

در ادامه مهم‌ترین ویژگی‌هایی را بررسی می‌کنیم که معمولاً برای ارزیابی کیفیت Requirementها در نظر گرفته می‌شوند.

۱. واضح و شفاف بودن (Clear)

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

مثلاً:

❌ نامناسب:

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

عبارت «به‌درستی» مشخص نمی‌کند منظور دقیقاً چیست.

✅ بهتر:

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

در Requirement دوم مشخص است که چه اطلاعاتی باید نمایش داده شوند.

۲. بدون ابهام بودن (Unambiguous)

یک Requirement نباید بتواند چند تفسیر متفاوت داشته باشد.

برای مثال:

سیستم باید سفارش را سریع پردازش کند.

کلمه «سریع» برای افراد مختلف می‌تواند معنای متفاوتی داشته باشد.

یک Requirement دقیق‌تر می‌تواند این باشد:

سیستم باید پس از دریافت درخواست ثبت سفارش، نتیجه ثبت سفارش را حداکثر در ۳ ثانیه به کاربر نمایش دهد.

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

چرا این موضوع برای تستر مهم است؟

تستر باید بتواند بر اساس Requirement تصمیم بگیرد:

Pass یا Fail؟

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

۳. کامل بودن (Complete)

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

مثلاً:

سیستم باید کاربران را مسدود کند.

این Requirement ناقص است. سؤال‌های زیادی وجود دارد:

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

یک Requirement کامل‌تر می‌تواند چنین باشد:

سیستم باید پس از پنج تلاش ناموفق متوالی برای ورود، حساب کاربر را به مدت ۱۵ دقیقه غیرفعال کند و پیام مناسبی به کاربر نمایش دهد.

حالا رفتار سیستم بسیار مشخص‌تر شده است.

۴. سازگار بودن (Consistent)

Requirementها نباید با یکدیگر تناقض داشته باشند.

فرض کنید در یک قسمت SRS نوشته شده:

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

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

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

این دو Requirement بدون توضیح بیشتر با یکدیگر تناقض دارند.

تستر هنگام Review SRS باید بتواند چنین تناقض‌هایی را شناسایی کند. این یکی از دلایلی است که بررسی Requirementها قبل از شروع تست اجرایی اهمیت زیادی دارد.

۵. قابل تست بودن (Testable)

یکی از مهم‌ترین ویژگی‌های Requirement برای تستر، Testability یا تست‌پذیری است.

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

برای مثال:

❌ مبهم و دشوار برای تست:

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

«مناسب» معیار مشخصی ندارد.

✅ قابل تست‌تر:

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

یا در مورد Performance:

❌

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

✅

سیستم باید در شرایط بار مشخص، ۹۵ درصد درخواست‌های جستجو را در کمتر از ۲ ثانیه پاسخ دهد.

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

۶. امکان‌پذیر بودن (Feasible)

هر Requirement باید با توجه به محدودیت‌های فنی، زمانی، مالی و منابع پروژه قابل تحقق باشد.

برای مثال:

سیستم باید در تمام شرایط و برای هر تعداد کاربر، بدون هیچ‌گونه کاهش Performance پاسخ‌دهی آنی داشته باشد.

این Requirement احتمالاً بیش از حد ایده‌آل‌گرایانه است و نیاز به بررسی Feasibility دارد.

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

تستر نیز نباید فقط به این سؤال فکر کند که:

«آیا سیستم این Requirement را پاس می‌کند؟»

بلکه در Review می‌تواند درباره واقع‌بینانه بودن Requirement نیز سؤال مطرح کند.

۷. قابل ردیابی بودن (Traceable)

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

• FR-001
• FR-002
• NFR-001
• SEC-001

برای مثال:

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

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

برای مثال می‌توان ارتباطی مانند زیر میان Requirement و سایر Artefactهای پروژه برقرار کرد:

Requirement → Design → Development → Test Case → Test Result

این ارتباط را Traceability می‌نامیم.

Requirement	Test Case	نتیجه
FR-AUTH-001	TC-AUTH-001	Pass
FR-AUTH-001	TC-AUTH-002	Pass
FR-AUTH-002	TC-AUTH-003	Fail

در اینجا می‌توانیم بفهمیم هر Test Case مربوط به کدام Requirement است.

۸. اولویت‌دار بودن (Prioritized)

همه Requirementها اهمیت یکسانی ندارند.

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

Requirement	Priority
ثبت سفارش	Critical
پرداخت آنلاین	Critical
جستجوی محصول	High
تغییر تصویر پروفایل	Medium
شخصی‌سازی رنگ صفحه	Low

مشخص کردن Priority به تیم کمک می‌کند در شرایط محدودیت زمانی یا منابع، روی Requirementهای مهم‌تر تمرکز کند.

برای تستر نیز Priority می‌تواند در Test Planning و Test Execution اهمیت داشته باشد.

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

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

مثال اول

❌ Requirement ضعیف:

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

مشکلات:

• سریع یعنی چه؟
• در چه شرایطی؟
• برای چه عملیاتی؟
• برای چند کاربر؟
• معیار Pass/Fail چیست؟

Requirement بهتر:

سیستم باید در شرایط بار ۱۰۰۰ کاربر هم‌زمان، ۹۵ درصد درخواست‌های جستجو را حداکثر در ۲ ثانیه پاسخ دهد.

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

مثال دوم

❌ Requirement ضعیف:

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

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

Requirement بهتر:

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

حالا مسیر اصلی رفتار سیستم مشخص‌تر است.

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

آیا تستر باید Requirementها را اصلاح کند؟

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

اگر تستر در زمان Review متوجه شود Requirement:

• مبهم است،
• ناقص است،
• با Requirement دیگری تناقض دارد،
• قابل تست نیست،
• یا رفتار سیستم در یک حالت مهم را مشخص نکرده است،

باید این موضوع را با تیم مطرح کند.

مثلاً اگر در SRS نوشته شده:

«سیستم باید در صورت خطای پرداخت، سفارش را مدیریت کند.»

تستر می‌تواند سؤال کند:

منظور از «مدیریت کند» چیست؟ آیا سفارش لغو می‌شود؟ در وضعیت Pending قرار می‌گیرد؟ آیا کاربر می‌تواند دوباره پرداخت کند؟

این نوع سؤال‌ها می‌توانند قبل از شروع Test Execution به شفاف شدن Requirement کمک کنند.

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

یک Checklist ساده برای بررسی کیفیت Requirement

هنگام Review یک Requirement در SRS می‌توان این سؤال‌ها را مطرح کرد:

• آیا Requirement واضح است؟
• آیا فقط یک برداشت منطقی از آن وجود دارد؟
• آیا اطلاعات ضروری را در اختیار خواننده قرار می‌دهد؟
• آیا با سایر Requirementها سازگار است؟
• آیا قابل تست است؟
• آیا معیار مشخصی برای Pass/Fail وجود دارد؟
• آیا از نظر فنی و اجرایی امکان‌پذیر است؟
• آیا شناسه مشخصی دارد؟
• آیا Priority آن مشخص است؟
• آیا می‌توان آن را به Test Case یا Test Scenario مرتبط کرد؟

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

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

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

تا اینجا درباره مفهوم SRS، ساختار سند نیازمندی‌های نرم‌افزار و ویژگی‌های یک Requirement خوب صحبت کردیم. حالا می‌توانیم سراغ یک سؤال عملی‌تر برویم:

چگونه باید یک SRS بنویسیم؟

نوشتن SRS صرفاً به معنی قرار دادن چند Requirement در یک فایل Word یا ابزار مدیریت پروژه نیست. مهم این است که نیازهای نرم‌افزار به شکلی شفاف، ساختاریافته، قابل بررسی و قابل تست مستند شوند.

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

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

«کاربر باید بتواند از طریق سایت خرید کند.»

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

مرحله اول: هدف و نیاز اصلی را مشخص کنید

قبل از نوشتن Requirement باید بدانیم چه نیازی قرار است برطرف شود.

مثلاً:

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

در این مرحله هنوز وارد جزئیات فنی نمی‌شویم.

سؤال‌هایی که می‌توان مطرح کرد عبارت‌اند از:

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

این اطلاعات کمک می‌کنند Requirementها از هدف اصلی محصول فاصله نگیرند.

مرحله دوم: کاربران و نقش‌های درگیر را مشخص کنید

یک Requirement بدون مشخص کردن Actor یا نقش مربوطه ممکن است ناقص باشد.

مثلاً:

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

اما منظور از «کاربر» چیست؟

• مشتری؟
• مدیر فروشگاه؟
• اپراتور پشتیبانی؟

اگر منظور مشتری باشد، بهتر است Requirement دقیق‌تر نوشته شود:

FR-ORD-005: مشتری باید بتواند سفارش خود را تا پیش از تغییر وضعیت سفارش به «در حال ارسال»، لغو کند.

حالا هم Actor مشخص است و هم شرط مهمی برای انجام عملیات تعیین شده است.

مرحله سوم: رفتار مورد انتظار سیستم را مشخص کنید

در این مرحله باید مشخص کنیم سیستم دقیقاً چه کاری باید انجام دهد.

برای مثال، به جای:

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

می‌توان Requirement دقیق‌تری نوشت:

FR-PAY-001: سیستم باید پس از تأیید اطلاعات سفارش، امکان انتخاب یکی از روش‌های پرداخت فعال را برای کاربر فراهم کند.

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

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

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

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

یکی از مشکلات رایج در Requirementها این است که فقط Happy Path را پوشش می‌دهند.

مثلاً:

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

اما در دنیای واقعی همیشه همه چیز موفق پیش نمی‌رود.

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

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

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

این مرحله برای تستر اهمیت زیادی دارد، زیرا بسیاری از Defectهای مهم در Edge Caseها و Exception Flowها ظاهر می‌شوند.

مرحله پنجم: Requirement را قابل اندازه‌گیری و تست کنید

یکی از مهم‌ترین مراحل نوشتن SRS، تبدیل عبارت‌های مبهم به Requirementهای Testable است.

مثلاً:

❌

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

این Requirement معیار مشخصی برای اندازه‌گیری ندارد.

بهتر است بگوییم:

سیستم باید ۹۵ درصد درخواست‌های جستجو را در شرایط بار تعریف‌شده، حداکثر در ۲ ثانیه پاسخ دهد.

حالا تستر می‌تواند معیار مشخصی برای ارزیابی این Requirement در نظر بگیرد.

همین موضوع درباره عبارت‌هایی مانند موارد زیر نیز صدق می‌کند:

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

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

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

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

FR-AUTH-001
FR-AUTH-002
FR-ORD-001
FR-PAY-001
NFR-PERF-001
NFR-SEC-001

این شناسه بعداً در بخش‌های مختلف پروژه استفاده می‌شود.

مثلاً FR-PAY-001 می‌تواند در موارد زیر مورد استفاده قرار گیرد:

• طراحی Test Scenario
• Test Case
• Defect
• Traceability Matrix
• Test Report
• Release Documentation

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

مرحله هفتم: Priority را مشخص کنید

در پروژه‌های واقعی ممکن است تعداد Requirementها زیاد باشد و همه آن‌ها اهمیت یکسانی نداشته باشند.

بنابراین بهتر است Priority مشخص شود.

Requirement	Priority
ثبت سفارش	Critical
پرداخت آنلاین	Critical
جستجوی محصول	High
تغییر اطلاعات پروفایل	Medium
شخصی‌سازی ظاهر سایت	Low

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

برای تستر، Requirementهای با Priority بالاتر معمولاً می‌توانند در تعیین اولویت تست‌ها نیز اثرگذار باشند؛ البته Priority کسب‌وکار لزوماً همیشه معادل Risk تست نیست.

مرحله هشتم: Requirement را با تیم Review کنید

نوشتن Requirement پایان کار نیست.

Requirement باید توسط افراد مرتبط بررسی شود.

• Business Analyst
• Product Owner
• Developer
• Software Tester
• Subject Matter Expert
• سایر ذی‌نفعان

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

مثلاً Developer ممکن است بپرسد:

آیا این Requirement از نظر فنی قابل پیاده‌سازی است؟

تستر ممکن است بپرسد:

چگونه باید این Requirement را تست کنم؟

Business Analyst ممکن است بپرسد:

آیا Requirement واقعاً نیاز کسب‌وکار را پوشش می‌دهد؟

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

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

حالا کل فرآیند را روی یک مثال اجرا کنیم.

نیاز اولیه

کاربر باید بتواند محصول خریداری کند.

این جمله برای شروع خوب است، اما برای SRS کافی نیست.

تحلیل نیاز

سؤال‌های زیر مطرح می‌شوند:

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

بعد از بررسی این موارد می‌توان Requirementهای دقیق‌تری تعریف کرد.

Requirement 1

FR-ORD-001: سیستم باید به کاربران احراز هویت‌شده اجازه دهد محصولات موجود را به سبد خرید اضافه کنند.

Requirement 2

FR-ORD-002: سیستم باید قبل از ثبت سفارش، اطلاعات ارسال شامل نام گیرنده، شماره تماس و آدرس را از کاربر دریافت کند.

Requirement 3

FR-PAY-001: سیستم باید پس از تأیید اطلاعات سفارش، روش‌های پرداخت فعال را به کاربر نمایش دهد.

Requirement 4

FR-PAY-002: سیستم باید پس از دریافت پاسخ موفق از درگاه پرداخت، سفارش را با وضعیت «پرداخت‌شده» ثبت کند.

Requirement 5

FR-PAY-003: سیستم باید در صورت دریافت پاسخ ناموفق از درگاه پرداخت، وضعیت پرداخت را «ناموفق» ثبت کرده و امکان تلاش مجدد برای پرداخت را برای کاربر فراهم کند.

حالا نیاز اولیه به چند Requirement مشخص تبدیل شده است.

تستر چگونه از این Requirementها استفاده می‌کند؟

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

فرض کنیم Requirement زیر را داریم:

FR-PAY-002: سیستم باید پس از دریافت پاسخ موفق از درگاه پرداخت، سفارش را با وضعیت «پرداخت‌شده» ثبت کند.

تستر می‌تواند بر اساس این Requirement سناریوی اصلی را در نظر بگیرد:

Precondition:

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

Test Action:

پرداخت با موفقیت انجام شود.

Expected Result:

سفارش با وضعیت «پرداخت‌شده» ثبت شود.

اما تستر نباید فقط مسیر موفق را ببیند.

ممکن است Requirementهای دیگری برای حالت‌های زیر لازم باشند:

• پرداخت ناموفق
• Timeout درگاه
• قطع ارتباط
• دوبار کلیک کردن روی دکمه پرداخت
• دریافت پاسخ تکراری
• پرداخت موفق اما عدم دریافت صحیح Callback

اگر رفتار مورد انتظار سیستم در این شرایط در SRS مشخص نشده باشد، تستر می‌تواند این موضوع را در Requirement Review مطرح کند.

این یکی از ارزش‌های مهم بررسی SRS قبل از Test Execution است.

آیا SRS باید تمام جزئیات پیاده‌سازی را مشخص کند؟

معمولاً نه.

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

مثلاً:

سیستم باید نتیجه جستجو را حداکثر در ۲ ثانیه نمایش دهد.

یک Requirement مناسب است.

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

به عبارت ساده:

SRS بیشتر روی «چه چیزی باید وجود داشته باشد» و «سیستم چه رفتاری باید داشته باشد» تمرکز می‌کند، نه اینکه الزاماً «چگونه کدنویسی شود».

این تفکیک کمک می‌کند Requirementها بیش از حد به جزئیات Implementation وابسته نشوند؛ مگر اینکه یک محدودیت فنی یا معماری واقعاً بخشی از نیاز پروژه باشد.

SRS خوب چه نتیجه‌ای ایجاد می‌کند؟

اگر فرآیند تهیه SRS به‌درستی انجام شود، در پایان باید بتوانیم از یک Requirement به بخش‌های مختلف پروژه حرکت کنیم:

Business Need

↓

Requirement

↓

Design / Development

↓

Test Scenario

↓

Test Case

↓

Test Result

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

در بخش بعدی، به یکی از مهم‌ترین کاربردهای SRS برای تسترها می‌پردازیم:

تستر نرم‌افزار دقیقاً چگونه SRS را Review می‌کند و چه مشکلاتی را باید هنگام بررسی Requirementها پیدا کند؟

نقش تستر نرم‌افزار در بررسی SRS چیست؟

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

اما یک سؤال مهم وجود دارد:

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

خیر.

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

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

چرا تستر باید SRS را Review کند؟

تستر نرم‌افزار فقط مسئول پیدا کردن Bug در نرم‌افزار اجراشده نیست.

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

فرض کنید در SRS نوشته شده است:

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

تستر بلافاصله می‌تواند سؤال‌های زیر را مطرح کند:

• «سریع» یعنی چند ثانیه؟
• این شرط برای چه تعداد کاربر هم‌زمان است؟
• آیا همه جستجوها باید این زمان پاسخ را داشته باشند؟
• معیار قبولی چیست؟
• اگر سیستم در شرایط بار بالا کند شود، Pass است یا Fail؟

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

تستر هنگام Review SRS چه چیزهایی را بررسی می‌کند؟

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

۱. کامل بودن Requirement

آیا اطلاعات موردنیاز برای درک رفتار سیستم وجود دارد؟

مثلاً:

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

این Requirement سؤال‌های مهمی را بدون پاسخ می‌گذارد:

• چند تلاش ناموفق؟
• برای چه مدت؟
• آیا کاربر پیام دریافت می‌کند؟
• آیا مدیر سیستم می‌تواند محدودیت را بردارد؟
• آیا تلاش‌های ناموفق باید ثبت شوند؟

تستر می‌تواند این ابهام‌ها را در زمان Review مطرح کند تا رفتار مورد انتظار سیستم پیش از توسعه شفاف‌تر شود.

۲. واضح بودن Requirement

آیا Requirement برای افراد مختلف یک معنی دارد؟

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

برای مثال:

❌ نامناسب:

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

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

۳. بدون تناقض بودن Requirementها

فرض کنید در SRS نوشته شده است:

فقط کاربران ثبت‌نام‌شده می‌توانند سفارش ثبت کنند.

اما در قسمت دیگری آمده است:

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

این دو Requirement باید بررسی و تعیین تکلیف شوند. وجود چنین تناقض‌هایی یکی از دلایلی است که Review نیازمندی‌ها پیش از Test Execution اهمیت دارد.

۴. قابل تست بودن Requirement

یکی از مهم‌ترین سؤال‌هایی که تستر هنگام Review می‌تواند بپرسد این است:

اگر این Requirement پیاده‌سازی شود، چگونه می‌توانم بفهمم که سیستم آن را برآورده کرده است؟

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

برای مثال:

❌

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

تستر نمی‌تواند به‌سادگی معیار مشخصی برای Pass یا Fail تعیین کند.

اما:

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

رفتار مشخص‌تری دارد و می‌توان برای آن Test Case طراحی کرد.

۵. بررسی شرایط مثبت و منفی

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

فرض کنیم نوشته شده است:

کاربر باید بتواند با کارت بانکی پرداخت کند.

تستر می‌تواند سؤال‌های زیر را مطرح کند:

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

اگر رفتار مورد انتظار در این شرایط مشخص نشده باشد، Requirement ممکن است ناقص باشد.

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

۶. بررسی Testability

Testability یا تست‌پذیری یکی از ویژگی‌های مهم Requirement خوب است.

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

برای مثال:

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

این Requirement تست‌پذیری پایینی دارد.

اما:

SRS و Acceptance Criteria چه ارتباطی دارند؟

یکی از موضوعاتی که هنگام کار با سند نیازمندی‌های نرم‌افزار (SRS) ممکن است باعث سردرگمی شود، تفاوت بین Requirement و Acceptance Criteria است.

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

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

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

برای مثال، فرض کنید Requirement زیر در SRS وجود دارد:

FR-ORD-001: سیستم باید به کاربر اجازه دهد سفارش خود را به‌صورت آنلاین ثبت کند.

این Requirement قابلیت مورد انتظار را مشخص می‌کند، اما هنوز معیارهای دقیقی برای پذیرش آن ارائه نشده است.

می‌توان معیارهایی مانند موارد زیر را برای آن در نظر گرفت:

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

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

Acceptance Criteria چه نقشی در کنار SRS دارد؟

Acceptance Criteria یا معیارهای پذیرش مجموعه‌ای از شرایط مشخص است که باید برآورده شوند تا یک قابلیت یا Requirement قابل قبول در نظر گرفته شود.

به زبان ساده، Acceptance Criteria به این سؤال پاسخ می‌دهد:

از کجا بفهمیم این قابلیت همان چیزی است که انتظار داشتیم؟

برای مثال، Requirement می‌گوید:

کاربر باید بتواند رمز عبور خود را تغییر دهد.

اما معیارهای پذیرش می‌توانند مشخص کنند:

1. کاربر باید ابتدا رمز عبور فعلی خود را وارد کند.
2. رمز عبور جدید باید حداقل ۸ کاراکتر داشته باشد.
3. رمز عبور جدید و تکرار آن باید یکسان باشند.
4. پس از تغییر موفق، سیستم باید پیام موفقیت نمایش دهد.
5. رمز عبور قبلی نباید برای ورود مجدد معتبر باشد.

در این حالت، Requirement تصویر کلی قابلیت را مشخص کرده و Acceptance Criteria شرایط قابل قبول بودن آن را دقیق‌تر می‌کند.

تفاوت Requirement و Acceptance Criteria

این دو مفهوم به یکدیگر مرتبط‌اند، اما نباید آن‌ها را یکسان در نظر گرفت.

مورد	Requirement	Acceptance Criteria
هدف	تعریف نیاز یا قابلیت مورد انتظار	تعریف شرایط پذیرش
سؤال اصلی	سیستم چه چیزی باید ارائه دهد؟	چه زمانی این قابلیت قابل قبول است؟
سطح جزئیات	می‌تواند کلی‌تر باشد	معمولاً مشخص‌تر و قابل ارزیابی‌تر
کاربرد	تحلیل، طراحی، توسعه و تست	بررسی تحقق قابلیت و پذیرش آن
مثال	کاربر بتواند سفارش ثبت کند	سفارش فقط پس از پرداخت موفق ثبت شود

البته در پروژه‌های مختلف ممکن است مرز میان این دو متفاوت باشد و Acceptance Criteria بخشی از Requirement یا مستندات مرتبط با آن باشد.

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

آیا Acceptance Criteria باید داخل SRS باشد؟

پاسخ به این سؤال به فرآیند سازمان و نوع پروژه بستگی دارد.

در بعضی پروژه‌ها Acceptance Criteria مستقیماً در SRS یا در کنار Requirementها نوشته می‌شود. در برخی پروژه‌ها نیز این معیارها در مستند جداگانه، ابزار مدیریت نیازمندی، User Story یا ابزار مدیریت پروژه ثبت می‌شوند.

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

«هر SRS حتماً باید یک بخش جداگانه به نام Acceptance Criteria داشته باشد.»

اما از نظر محتوایی، مشخص بودن شرایط پذیرش Requirementها ارزش زیادی دارد.

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

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

می‌توان معیارهای پذیرش را در کنار آن قرار داد:

Acceptance Criteria:

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

این ساختار باعث می‌شود Requirement برای توسعه و تست قابل استفاده‌تر شود.

Acceptance Criteria چه کمکی به تستر می‌کند؟

برای تستر، Acceptance Criteria می‌تواند منبع مفیدی برای تعیین Expected Result باشد.

فرض کنید Requirement این است:

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

اگر فقط همین جمله را داشته باشیم، تستر باید جزئیات زیادی را از منابع دیگر به دست آورد.

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

مثلاً:

شرط پذیرش:

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

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

• رمز عبور ۸ کاراکتری
• رمز عبور کمتر از ۸ کاراکتر
• رمز عبور بیشتر از ۸ کاراکتر
• رمز عبور خالی

بنابراین Acceptance Criteria می‌تواند مرزهای رفتاری مورد انتظار سیستم را برای تستر شفاف‌تر کند.

Acceptance Criteria و Happy Path

یکی از اشتباهات رایج این است که Acceptance Criteria فقط مسیر موفق را پوشش دهد.

مثلاً:

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

این فقط Happy Path را توصیف می‌کند.

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

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

لازم نیست تمام Edge Caseهای ممکن در Acceptance Criteria نوشته شوند، اما رفتارهای مهم و مورد انتظار باید تا حد لازم مشخص باشند.

این موضوع برای تستر اهمیت زیادی دارد، زیرا اگر Expected Result مشخص نباشد، تعیین Pass یا Fail دشوار می‌شود.

یک مثال کامل از Requirement تا Acceptance Criteria و Test

فرض کنیم نیاز کسب‌وکار این است:

مشتری باید بتواند محصولات فروشگاه را خریداری کند.

این نیاز هنوز برای توسعه و تست بسیار کلی است.

Requirement در SRS

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

حالا معیارهای پذیرش را مشخص می‌کنیم.

Acceptance Criteria

• AC-001: کاربر باید حداقل یک محصول موجود در سبد خرید داشته باشد.
• AC-002: کاربر باید اطلاعات ضروری ارسال را تکمیل کند.
• AC-003: کاربر باید یک روش پرداخت معتبر انتخاب کند.
• AC-004: پس از پرداخت موفق، سیستم باید سفارش را ثبت کند.
• AC-005: سفارش ثبت‌شده باید دارای شماره سفارش یکتا باشد.
• AC-006: پس از ثبت موفق سفارش، وضعیت آن باید «پرداخت‌شده» باشد.
• AC-007: در صورت ناموفق بودن پرداخت، سفارش نباید با وضعیت «پرداخت‌شده» ثبت شود.

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

Acceptance Criteria	سناریوی تست
AC-001	ثبت سفارش با سبد خرید خالی
AC-002	ثبت سفارش بدون آدرس
AC-003	ثبت سفارش بدون انتخاب روش پرداخت
AC-004	ثبت سفارش پس از پرداخت موفق
AC-005	بررسی یکتا بودن شماره سفارش
AC-006	بررسی وضعیت سفارش پس از پرداخت
AC-007	بررسی وضعیت سفارش پس از پرداخت ناموفق

در اینجا یک زنجیره واضح ایجاد شده است:

Requirement → Acceptance Criteria → Test Scenario → Test Case

این ارتباط برای تستر بسیار ارزشمند است.

آیا Acceptance Criteria همان Test Case است؟

خیر. Acceptance Criteria و Test Case دو مفهوم متفاوت هستند.

Acceptance Criteria می‌گوید:

چه شرطی باید برقرار باشد تا قابلیت قابل قبول باشد؟

Test Case مشخص می‌کند:

چگونه این شرط را بررسی کنیم؟

مثلاً:

Acceptance Criteria:

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

اما Test Case می‌تواند شامل موارد زیر باشد:

Test Case ID: TC-ORD-015

Precondition: کاربر سفارش معتبر دارد.

Test Data: اطلاعات پرداخت معتبر

Steps:

1. ورود به حساب
2. انتخاب محصول
3. تکمیل اطلاعات ارسال
4. ورود به مرحله پرداخت
5. انجام پرداخت موفق

Expected Result: شماره سفارش یکتا به کاربر نمایش داده شود.

بنابراین Acceptance Criteria می‌تواند مبنایی برای طراحی Test Case باشد، اما خود Test Case نیست.

Acceptance Criteria و Requirement Review

تستر هنگام بررسی SRS می‌تواند از وجود یا نبود معیارهای پذیرش نیز برای شناسایی ابهام استفاده کند.

برای مثال:

سیستم باید سفارش را پس از پرداخت موفق ثبت کند.

تستر می‌تواند سؤال کند:

• «پرداخت موفق» دقیقاً بر چه اساسی مشخص می‌شود؟
• آیا پاسخ موفق از درگاه کافی است؟
• اگر مبلغ از حساب کسر شود ولی Callback دریافت نشود چه اتفاقی باید بیفتد؟
• آیا شماره سفارش باید به کاربر نمایش داده شود؟
• وضعیت اولیه سفارش چیست؟
• آیا ارسال Notification نیز بخشی از Requirement است؟

این پرسش‌ها ممکن است باعث شوند Requirement و شرایط پذیرش آن دقیق‌تر شوند.

بنابراین Acceptance Criteria فقط برای زمان بعد از توسعه مفید نیست؛ می‌تواند در زمان تحلیل و Review Requirement نیز به شفاف شدن نیازمندی کمک کند.

Acceptance Criteria در Agile و SRS

در پروژه‌های Agile معمولاً Acceptance Criteria در کنار User Story نقش مهمی دارد.

برای مثال:

As a customer, I want to reset my password so that I can regain access to my account.

سپس Acceptance Criteria مشخص می‌کند این User Story تحت چه شرایطی قابل قبول است.

در چنین پروژه‌ای ممکن است یک SRS سنتی و یکپارچه وجود نداشته باشد و نیازمندی‌ها در User Storyها، Acceptance Criteria، مستندات API و سایر Artefactها توزیع شده باشند.

بنابراین نباید تصور کنیم:

Agile = بدون مستندات نیازمندی

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

آیا تستر Acceptance Criteria را می‌نویسد؟

همانند SRS، مسئولیت نوشتن Acceptance Criteria نیز بسته به فرآیند سازمان متفاوت است.

ممکن است Product Owner، Business Analyst یا تیم محصول آن را تهیه کند و تستر در Review آن مشارکت داشته باشد.

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

• آیا این معیار قابل تست است؟
• آیا Expected Result مشخص است؟
• آیا شرایط منفی مهم پوشش داده شده‌اند؟
• آیا این معیار با Requirement اصلی سازگار است؟
• آیا می‌توان بر اساس آن Pass یا Fail تعیین کرد؟

بنابراین نقش تستر الزاماً نویسندگی نیست؛ بلکه مشارکت در شفاف و قابل تست شدن معیارهای پذیرش اهمیت زیادی دارد.

یک نکته مهم برای تستر

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

اما اگر تستر هنگام طراحی Test Case متوجه شود که نمی‌داند Expected Result چیست، باید یک سؤال مهم بپرسد:

آیا مشکل از Test Case من است یا Requirement به اندازه کافی مشخص نشده است؟

گاهی پاسخ، مورد دوم است.

در چنین شرایطی، بهترین اقدام لزوماً نوشتن یک Test Case پیچیده‌تر نیست؛ بلکه باید Requirement یا Acceptance Criteria را شفاف کرد.

جمع‌بندی

می‌توان رابطه این مفاهیم را به شکل زیر خلاصه کرد:

Business Need

↓

Requirement

↓

Acceptance Criteria

↓

Test Scenario

↓

Test Case

↓

Test Execution

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

در عین حال، Acceptance Criteria لزوماً نباید همیشه به‌عنوان یک بخش جداگانه داخل SRS قرار گیرد. آنچه اهمیت دارد این است که شرایط قابل قبول بودن Requirementها در جایی مناسب و به شکلی شفاف مستند شده باشند.

در بخش بعدی به موضوع مهم دیگری می‌پردازیم: SRS و Verification و Validation؛ اما تمرکز را روی جایگاه این دو مفهوم در فرآیند بررسی نیازمندی‌ها نگه می‌داریم و وارد آموزش کامل Verification و Validation نمی‌شویم.

SRS و Verification و Validation چه ارتباطی دارند؟

وقتی درباره SRS یا سند نیازمندی‌های نرم‌افزار صحبت می‌کنیم، خیلی زود به دو مفهوم مهم Verification و Validation می‌رسیم.

اما یک نکته مهم وجود دارد:

Verification و Validation خودِ SRS نیستند؛ بلکه فعالیت‌ها و مفاهیمی هستند که در مراحل مختلف چرخه توسعه و تست نرم‌افزار برای بررسی درستی و کفایت محصول و نیازمندی‌ها مورد استفاده قرار می‌گیرند.

برای همین در این بخش فقط ارتباط آن‌ها با SRS را بررسی می‌کنیم و وارد جزئیات کامل این دو مفهوم نمی‌شویم.

برای مطالعه عمیق‌تر این موضوع می‌توان به مقاله تخصصی Verification و Validation در STLC مراجعه کرد.

Verification در ارتباط با SRS چیست؟

Verification را می‌توان به‌صورت ساده این‌گونه در نظر گرفت:

آیا Requirementها و Artefactها طبق مشخصات و قواعد مورد انتظار به‌درستی تهیه شده‌اند؟

در مورد SRS، سؤال‌هایی مانند این‌ها مطرح می‌شوند:

• آیا Requirementها واضح هستند؟
• آیا Requirementها کامل هستند؟
• آیا Requirementها با یکدیگر تناقض ندارند؟
• آیا Requirementها قابل تست هستند؟
• آیا قالب و ساختار سند رعایت شده است؟
• آیا Requirementهای نوشته‌شده با اطلاعات ورودی و تصمیم‌های تأییدشده سازگارند؟

مثلاً فرض کنید در SRS نوشته شده:

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

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

مثلاً:

• روش ورود مشخص است؟
• شرایط ورود مشخص است؟
• رفتار در صورت اطلاعات اشتباه مشخص است؟
• Requirement قابل تست است؟

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

Validation در ارتباط با SRS چیست؟

Validation بیشتر به این سؤال نزدیک است:

آیا چیزی که به‌عنوان نیازمندی تعریف کرده‌ایم، واقعاً نیاز درست و مورد انتظار کاربر یا کسب‌وکار را بیان می‌کند؟

فرض کنید در SRS نوشته شده:

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

از نظر ساختاری ممکن است Requirement کاملاً واضح و قابل تست باشد.

اما ممکن است کسب‌وکار اصلاً چنین روشی را نخواهد و تصمیم گرفته باشد کاربران با شماره تلفن و OTP وارد شوند.

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

بنابراین باید پرسید:

آیا چیزی که داریم می‌سازیم همان چیزی است که واقعاً باید ساخته شود؟

این سؤال به Validation نزدیک است.

تفاوت Verification و Validation در یک مثال

فرض کنیم Requirement زیر را داریم:

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

Verification

بررسی می‌کنیم:

• آیا Requirement واضح است؟
• آیا ابهام ندارد؟
• آیا قابل تست است؟
• آیا با سایر Requirementها تناقض ندارد؟
• آیا اطلاعات ضروری آن مشخص شده است؟

اگر این موارد مناسب باشند، Requirement از این نظر وضعیت خوبی دارد.

Validation

حالا سؤال دیگری می‌پرسیم:

آیا اصلاً ورود با نام کاربری و رمز عبور چیزی است که کاربران و کسب‌وکار نیاز دارند؟

اگر نیاز واقعی محصول ورود با OTP باشد، Requirement ما نیاز واقعی را منعکس نمی‌کند.

پس ممکن است یک Requirement:

از نظر Verification مناسب باشد، اما از نظر Validation مشکل داشته باشد.

این تفاوت بسیار مهم است.

آیا Requirement Review همان Verification است؟

نه، بهتر است این دو را دقیقاً معادل یکدیگر ندانیم.

Requirements Review یک فعالیت مشخص برای بررسی Requirementهاست.

Verification و Validation مفاهیم گسترده‌تری هستند که می‌توانند در مراحل و Artefactهای مختلف مورد استفاده قرار گیرند.

در عمل، Requirement Review می‌تواند شامل فعالیت‌هایی باشد که به Verification یا Validation کمک می‌کنند.

بنابراین بهتر است بگوییم:

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

نه اینکه:

«هر Requirement Review دقیقاً همان Verification است.»

تستر در این میان چه نقشی دارد؟

تستر می‌تواند در هر دو نوع بررسی نقش داشته باشد، اما نقش او بسته به پروژه و فرآیند سازمان متفاوت است.

برای مثال، هنگام Review SRS، تستر ممکن است بپرسد:

از دید Verification

• آیا این Requirement قابل تست است؟
• آیا Requirement ابهام دارد؟
• آیا رفتار سیستم در حالت خطا مشخص شده است؟
• آیا Requirement با Requirement دیگری تناقض دارد؟

از دید Validation

• آیا این قابلیت واقعاً برای کاربر موردنظر لازم است؟
• آیا Requirement نیاز واقعی کسب‌وکار را پوشش می‌دهد؟
• آیا سناریوی تعریف‌شده با فرآیند واقعی کسب‌وکار سازگار است؟

تستر ممکن است پاسخ همه این سؤال‌ها را به‌تنهایی نداشته باشد؛ اما می‌تواند ابهام یا ریسک را شناسایی و با افراد مسئول مطرح کند.

یک مثال واقعی‌تر: سامانه فروشگاهی

فرض کنیم کسب‌وکار می‌گوید:

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

این نیاز وارد SRS می‌شود:

FR-ORD-007: سیستم باید امکان لغو سفارش را برای مشتری فراهم کند.

Verification

تستر سؤال می‌کند:

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

فرض کنیم Requirement تکمیل می‌شود:

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

از نظر Verification وضعیت بهتر شده است.

Validation

حالا سؤال دیگری مطرح می‌شود:

آیا واقعاً کسب‌وکار می‌خواهد مشتری بتواند سفارش را تا این مرحله لغو کند؟

ممکن است فرآیند واقعی کسب‌وکار بگوید:

پس از تأیید سفارش، مشتری دیگر امکان لغو مستقیم ندارد و باید با پشتیبانی تماس بگیرد.

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

اینجا اهمیت Validation مشخص می‌شود.

چرا این موضوع برای SRS مهم است؟

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

ممکن است یک Requirement:

• واضح باشد،
• کامل باشد،
• بدون ابهام باشد،
• قابل تست باشد،
• شناسه داشته باشد،
• معیار پذیرش داشته باشد،

اما اصلاً Requirement درستی نباشد.

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

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

Verification و Validation در کجای مسیر قرار می‌گیرند؟

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

Business Need

↓

Requirements Elicitation

↓

Requirement Analysis

↓

SRS

↓

Requirements Review

↓

Development

↓

Testing

↓

Release

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

پس Verification و Validation را نباید صرفاً به مرحله‌ای به نام Test Execution محدود کرد.

همچنین این‌طور نیست که:

Verification فقط قبل از توسعه است و Validation فقط بعد از توسعه.

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

یک سوءتفاهم رایج درباره Validation

گاهی گفته می‌شود:

«هدف تست نرم‌افزار این است که Requirementها را Verify کند، پس تست Validation نیست.»

این برداشت بیش از حد ساده‌سازی شده است.

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

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

به همین دلیل است که:

درست ساختن محصول (Verification) و ساختن محصول درست (Validation) دو زاویه متفاوت برای نگاه کردن به کیفیت هستند.

برای توضیح کامل این مفاهیم، مثال‌ها و جایگاه آن‌ها در STLC، بهتر است به مقاله تخصصی Verification و Validation مراجعه شود تا این مقاله SRS بیش از حد وارد یک موضوع مستقل نشود.

SRS، Verification و Validation را چگونه در ذهن نگه داریم؟

یک مدل ساده:

SRS → چه چیزی باید ساخته شود؟

Verification → آیا Requirement و محصول مطابق مشخصات تعریف‌شده ساخته شده‌اند؟

Validation → آیا چیزی که ساخته‌ایم واقعاً نیاز موردنظر را برآورده می‌کند؟

البته این سه جمله صرفاً یک مدل ساده برای درک ارتباط مفاهیم هستند و تمام جزئیات حرفه‌ای Verification و Validation را پوشش نمی‌دهند.

یک نکته مهم برای تسترهای نرم‌افزار

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

«چه Test Caseهایی بنویسم؟»

بلکه قبل از آن بپرسد:

«آیا چیزی که قرار است تست کنم، از ابتدا درست و به‌اندازه کافی مشخص شده است؟»

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

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

نیازمندی‌های عملکردی و غیرعملکردی در SRS چگونه باید نوشته شوند؟

در آن بخش بررسی می‌کنیم چه تفاوتی میان Functional Requirement و Non-Functional Requirement وجود دارد، هرکدام چگونه در SRS مستند می‌شوند و برای تستر چه اهمیتی دارند.

۹. Functional و Non-Functional Requirements در SRS

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

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

به همین دلیل، در سند نیازمندی‌های نرم‌افزار معمولاً با دو مفهوم مهم روبه‌رو می‌شویم:

• Functional Requirements یا نیازمندی‌های عملکردی
• Non-Functional Requirements یا نیازمندی‌های غیرعملکردی

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

Functional Requirement مشخص می‌کند سیستم چه قابلیت‌ها و رفتارهایی باید داشته باشد؛ Non-Functional Requirement ویژگی‌های کیفی، محدودیت‌ها یا شرایطی را مشخص می‌کند که سیستم باید هنگام ارائه این قابلیت‌ها رعایت کند.

Functional Requirement چیست؟

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

یعنی مشخص می‌کند:

سیستم در پاسخ به یک ورودی، رویداد یا شرایط مشخص، چه کاری باید انجام دهد؟

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

FR-001: سیستم باید به کاربر اجازه دهد محصول را به سبد خرید اضافه کند.

یا:

FR-002: سیستم باید پس از پرداخت موفق، سفارش را ثبت کند.

یا:

FR-003: سیستم باید امکان لغو سفارش را تا قبل از ارسال برای کاربر فراهم کند.

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

اجزای یک Functional Requirement خوب

یک Functional Requirement معمولاً بهتر است اطلاعاتی مانند موارد زیر را مشخص کند:

• Actor یا کاربر
• Trigger یا رویداد آغازکننده
• شرایط اولیه
• رفتار مورد انتظار سیستم
• داده‌های ورودی
• خروجی مورد انتظار
• شرایط خاص یا محدودیت‌های مرتبط

مثلاً به جای:

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

می‌توان نوشت:

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

در اینجا مشخص‌تر شده است:

• چه کسی؟ کاربر ثبت‌نام‌شده
• چه کاری؟ ورود به حساب
• با چه اطلاعاتی؟ شماره تلفن و رمز عبور معتبر

مثال‌هایی از Functional Requirement

برای یک فروشگاه اینترنتی می‌توان Requirementهای زیر را در نظر گرفت:

احراز هویت

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

جستجو

FR-PROD-001: سیستم باید محصولات را بر اساس عبارت جستجوی واردشده نمایش دهد.

سبد خرید

FR-CART-001: سیستم باید به کاربر اجازه دهد محصولات موجود را به سبد خرید اضافه کند.

سفارش

FR-ORD-001: سیستم باید پس از تأیید اطلاعات ارسال و پرداخت موفق، سفارش را ثبت کند.

لغو سفارش

FR-ORD-002: سیستم باید به مشتری اجازه دهد سفارش را تا پیش از تغییر وضعیت به «در حال ارسال» لغو کند.

هرکدام از این Requirementها می‌توانند مبنایی برای طراحی Test Scenario و Test Case قرار بگیرند.

Non-Functional Requirement چیست؟

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

برای مثال:

سیستم باید ۹۵ درصد درخواست‌های جستجو را در کمتر از ۲ ثانیه پاسخ دهد.

در اینجا قابلیت اصلی همان جستجو است، اما Requirement درباره Performance آن صحبت می‌کند.

یا:

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

این Requirement جنبه‌ای از Security سیستم را مشخص می‌کند.

بنابراین Non-Functional Requirementها می‌توانند حوزه‌هایی مانند این موارد را پوشش دهند:

• Performance
• Security
• Availability
• Reliability
• Usability
• Scalability
• Maintainability
• Compatibility

چند مثال از Non-Functional Requirement

Performance

NFR-PERF-001: سیستم باید در شرایط بار تعریف‌شده، ۹۵ درصد درخواست‌های جستجو را در کمتر از ۲ ثانیه پاسخ دهد.

Availability

NFR-AVL-001: سامانه باید در طول هر ماه حداقل ۹۹.۹ درصد در دسترس باشد.

Security

NFR-SEC-001: سیستم باید پس از پنج تلاش ناموفق متوالی برای ورود، حساب کاربر را به مدت ۱۵ دقیقه محدود کند.

Compatibility

NFR-COMP-001: سامانه وب باید در نسخه‌های پشتیبانی‌شده مرورگرهای اعلام‌شده توسط سازمان به‌درستی کار کند.

Scalability

NFR-SCAL-001: سیستم باید امکان پشتیبانی از افزایش تعداد کاربران هم‌زمان تا مقدار تعیین‌شده را بدون کاهش Performance فراتر از معیار تعریف‌شده فراهم کند.

نکته مهم این است که صرفاً نوشتن نام‌هایی مانند Performance یا Security در SRS کافی نیست.

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

چرا «سیستم باید سریع باشد» یک NFR ضعیف است؟

فرض کنید در SRS نوشته شده:

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

مشکل این Requirement چیست؟

• سریع یعنی چند ثانیه؟
• برای کدام عملیات؟
• با چند کاربر؟
• در چه شرایطی؟
• چند درصد درخواست‌ها باید این معیار را رعایت کنند؟
• در چه محیطی اندازه‌گیری شود؟

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

Pass یا Fail؟

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

سیستم باید در شرایط بار ۱۰۰۰ کاربر هم‌زمان، حداقل ۹۵ درصد درخواست‌های جستجو را در کمتر از ۲ ثانیه پاسخ دهد.

حالا معیار مشخص‌تری برای ارزیابی داریم.

آیا Non-Functional Requirement واقعاً «غیرعملکردی» است؟

یک نکته ظریف در اینجا وجود دارد.

عبارت Non-Functional ممکن است این تصور را ایجاد کند که این Requirementها به عملکرد واقعی سیستم ارتباطی ندارند.

در حالی که چنین نیست.

برای مثال:

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

این Requirement مستقیماً روی رفتار واقعی سیستم تأثیر دارد.

اصطلاح Non-Functional بیشتر به این معناست که Requirement لزوماً یک Business Function یا قابلیت مشخص را تعریف نمی‌کند، بلکه ویژگی یا Constraint مربوط به سیستم را مشخص می‌کند.

آیا یک Requirement می‌تواند هم Functional و هم Non-Functional باشد؟

گاهی مرز میان این دو کاملاً ساده نیست.

مثلاً:

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

این یک Functional Requirement است.

اما:

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

یک Requirement غیرعملکردی مرتبط با همان قابلیت است.

بنابراین ممکن است یک Feature مشخص، هم Requirementهای عملکردی و هم غیرعملکردی مرتبط داشته باشد.

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

اهمیت Functional و Non-Functional Requirements برای تستر

از دید تستر، این دو نوع Requirement مسیرهای تست متفاوتی ایجاد می‌کنند.

فرض کنیم:

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

تستر می‌تواند Functional Testing انجام دهد و مواردی مانند این‌ها را بررسی کند:

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

اما اگر SRS همچنین گفته باشد:

۹۵ درصد درخواست‌های ثبت سفارش باید در کمتر از ۳ ثانیه پاسخ داده شوند.

حالا تستر باید Performance Requirement را نیز در نظر بگیرد.

در نتیجه:

Functional Requirement → چه رفتار یا قابلیت‌هایی باید بررسی شوند؟

Non-Functional Requirement → این قابلیت‌ها باید تحت چه شرایط کیفی یا محدودیت‌هایی عمل کنند؟

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

اشتباه رایج: تمرکز فقط روی Functional Requirements

در برخی پروژه‌ها، تیم Requirementها را فقط به شکل قابلیت‌ها تعریف می‌کند:

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

اما مواردی مانند:

• Performance
• Security
• Availability
• Compatibility
• Reliability

نادیده گرفته می‌شوند.

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

مثلاً:

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

از نظر Functional ممکن است درست باشد.

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

بنابراین یک SRS حرفه‌ای باید علاوه بر «چه کاری؟»، در موارد لازم «با چه سطحی از کیفیت؟» را نیز مشخص کند.

آیا هر Non-Functional Requirement باید عدد داشته باشد؟

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

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

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

یک نکته مهم درباره مقاله‌های تخصصی دیگر

در این مقاله هدف ما این نیست که تمام حوزه‌های Performance Testing، Security Testing، Usability Testing یا Compatibility Testing را آموزش دهیم.

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

در SRS فقط لازم است بدانیم:

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

مثلاً در مقاله SRS می‌گوییم:

سیستم باید ۹۵ درصد درخواست‌ها را در کمتر از ۲ ثانیه پاسخ دهد.

اما روش طراحی Performance Test و تحلیل نتایج آن، موضوع مقاله تخصصی Performance Testing است.

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

چگونه Functional و Non-Functional Requirements را در SRS سازمان‌دهی کنیم؟

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

Functional Requirements

FR-AUTH-001
FR-AUTH-002
FR-PROD-001
FR-CART-001
FR-ORD-001
FR-PAY-001

Non-Functional Requirements

NFR-PERF-001
NFR-SEC-001
NFR-AVL-001
NFR-COMP-001

این دسته‌بندی باعث می‌شود پیدا کردن Requirementها و ایجاد Traceability در مراحل بعدی آسان‌تر شود.

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

یک نمونه کوچک از SRS

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

FR-ORD-001

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

FR-ORD-002

سیستم باید پس از تأیید اطلاعات ارسال و پرداخت موفق، سفارش را ثبت کند.

NFR-PERF-001

سیستم باید ۹۵ درصد درخواست‌های ثبت سفارش را در شرایط بار تعریف‌شده در کمتر از ۳ ثانیه پردازش کند.

NFR-SEC-001

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

حالا تصویر کامل‌تری از نیازمندی داریم:

چه کاری؟

ثبت سفارش.

با چه ویژگی‌هایی؟

Performance و Security مورد انتظار نیز مشخص شده‌اند.

جمع‌بندی

در SRS، Functional و Non-Functional Requirements مکمل یکدیگر هستند.

Functional Requirements مشخص می‌کنند:

سیستم چه قابلیت‌ها و رفتارهایی باید داشته باشد؟

و Non-Functional Requirements مشخص می‌کنند:

سیستم این قابلیت‌ها را با چه ویژگی‌ها، محدودیت‌ها یا سطح کیفیتی باید ارائه کند؟

برای تستر نیز هر دو اهمیت دارند؛ زیرا تست نرم‌افزار فقط بررسی این نیست که «آیا قابلیت کار می‌کند؟» بلکه در بسیاری از پروژه‌ها باید بررسی شود که «آیا قابلیت با کیفیت و شرایط مورد انتظار نیز کار می‌کند؟»

در بخش بعدی سراغ Business Rules در SRS می‌رویم؛ موضوعی که به‌خصوص برای تسترها مهم است، چون بسیاری از سناریوهای مثبت، منفی و Boundary در واقع از قوانین کسب‌وکار ناشی می‌شوند.

۱۰. Business Rules در SRS چیست و چه ارتباطی با Requirement دارد؟

یکی از بخش‌هایی که در بسیاری از پروژه‌ها باعث ایجاد ابهام در نیازمندی‌ها می‌شود، Business Rule یا قانون کسب‌وکار است.

فرض کنید در SRS یک فروشگاه اینترنتی نوشته شده:

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

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

• آیا کد تخفیف تاریخ انقضا دارد؟
• حداقل مبلغ خرید چقدر است؟
• آیا هر کاربر فقط یک بار می‌تواند از آن استفاده کند؟
• آیا روی همه محصولات قابل استفاده است؟
• آیا با تخفیف دیگری قابل ترکیب است؟

پاسخ این سؤال‌ها معمولاً در قالب Business Rules مشخص می‌شود.

Business Rule چیست؟

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

مثلاً:

• مشتری فقط یک بار می‌تواند از کد تخفیف Welcome استفاده کند.
• سفارش‌هایی که مبلغ آن‌ها کمتر از ۵۰۰ هزار تومان است، مشمول ارسال رایگان نیستند.
• مشتری VIP می‌تواند تا سقف مشخصی از اعتبار خود برای خرید استفاده کند.

این‌ها الزاماً یک «قابلیت» مستقل نیستند؛ بلکه قواعدی هستند که رفتار قابلیت‌ها را محدود یا تعیین می‌کنند.

تفاوت Business Rule و Functional Requirement

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

Functional Requirement

می‌گوید:

سیستم باید چه کاری انجام دهد؟

مثلاً:

FR-ORDER-001: سیستم باید امکان لغو سفارش را برای مشتری فراهم کند.

Business Rule

می‌گوید:

این قابلیت تحت چه قانون یا شرط کسب‌وکاری باید عمل کند؟

مثلاً:

BR-ORDER-001: مشتری فقط تا قبل از ارسال سفارش مجاز به لغو آن است.

پس می‌توان رابطه را این‌گونه دید:

Business Rule → محدودیت یا منطق کسب‌وکار

Functional Requirement → رفتاری که سیستم برای پیاده‌سازی نیازمندی ارائه می‌کند

یک مثال کامل

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

Business Need

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

Business Rule

سفارش پس از تغییر وضعیت به «در حال ارسال» قابل لغو نیست.

Functional Requirement

FR-ORD-005: سیستم باید به مشتری اجازه دهد سفارش را در وضعیت‌های مجاز لغو کند.

Acceptance Criteria

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

حالا Requirement بسیار دقیق‌تر شده است.

چرا Business Rules برای تستر مهم هستند؟

برای تستر، Business Ruleها یکی از منابع مهم طراحی تست هستند.

فرض کنیم Rule این است:

سفارش فقط تا قبل از ارسال قابل لغو است.

حالا تستر باید حداقل مرزهای مهم این Rule را بررسی کند:

• سفارش قبل از ارسال
• سفارش در لحظه تغییر وضعیت
• سفارش پس از ارسال

این موضوع به‌خصوص برای Boundary Value Testing و طراحی سناریوهای منفی اهمیت پیدا می‌کند.

وضعیت سفارش	انتظار
ثبت‌شده	لغو مجاز
تأییدشده	لغو مجاز
آماده ارسال	طبق Rule پروژه
در حال ارسال	لغو غیرمجاز
تحویل‌شده	لغو غیرمجاز

در اینجا Business Rule مستقیماً روی Test Design تأثیر گذاشته است.

Business Ruleها معمولاً از کجا می‌آیند؟

Business Rule می‌تواند از منابع مختلفی به دست آید، مانند:

• قوانین داخلی سازمان
• قراردادها
• سیاست‌های کسب‌وکار
• قوانین و مقررات
• تصمیم‌های مدیران کسب‌وکار
• فرآیندهای سازمانی
• محدودیت‌های مالی
• سیاست‌های قیمت‌گذاری
• قوانین مربوط به کاربران

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

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

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

آیا Business Rule باید داخل SRS نوشته شود؟

الزاماً یک پاسخ واحد برای همه پروژه‌ها وجود ندارد.

در بعضی سازمان‌ها Business Rules مستقیماً در SRS ثبت می‌شوند.

در بعضی پروژه‌ها نیز یک Business Rules Document یا مستند جداگانه وجود دارد و SRS به آن ارجاع می‌دهد.

مثلاً:

BR-PAY-004: سقف انتقال روزانه مطابق سیاست مالی سازمان است.

و در Requirement نوشته می‌شود:

سیستم باید سقف انتقال روزانه را مطابق BR-PAY-004 اعمال کند.

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

چرا جدا کردن Business Rule از Requirement می‌تواند مفید باشد؟

فرض کنید قانون زیر در سیستم وجود دارد:

هر کاربر فقط یک بار می‌تواند از کد تخفیف Welcome استفاده کند.

حالا این Rule در چند قسمت سیستم استفاده می‌شود:

• ثبت سفارش
• محاسبه تخفیف
• لغو سفارش
• بازگشت وجه

اگر Rule را در همه Requirementها تکرار کنیم، احتمال دارد بعداً یکی از آن‌ها تغییر کند و دیگری فراموش شود.

اما اگر Rule شناسه مشخصی داشته باشد:

BR-DISCOUNT-001

Requirementهای مختلف می‌توانند به آن ارجاع دهند.

این کار به Traceability و مدیریت تغییرات کمک می‌کند.

Business Rule و حالت‌های منفی

یکی از ارزشمندترین کاربردهای Business Rule برای تستر، پیدا کردن Negative Scenario است.

مثلاً:

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

تستر نباید فقط این سناریو را بررسی کند:

موجودی کافی → برداشت موفق

بلکه Rule باعث ایجاد سناریوی مهم دیگری می‌شود:

موجودی ناکافی → برداشت نباید انجام شود.

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

• اگر موجودی دقیقاً برابر مبلغ برداشت باشد چه؟
• اگر یک ریال کمتر باشد چه؟
• اگر چند درخواست برداشت هم‌زمان ارسال شود چه؟
• اگر موجودی هنگام پردازش تغییر کند چه؟

بنابراین Business Ruleها می‌توانند منبع بسیار خوبی برای شناسایی Negative Case، Boundary Case و Edge Case باشند.

Business Rule و Requirement قابل تست

یک Business Rule خوب باید تا حد امکان قابل بررسی باشد.

مثلاً:

❌

مشتریان ویژه باید از مزایای بیشتری برخوردار شوند.

این Rule مبهم است.

اما:

مشتریانی که در گروه VIP قرار دارند، در سفارش‌های بالاتر از ۲ میلیون تومان ۱۰ درصد تخفیف دریافت می‌کنند.

قابل بررسی‌تر است.

تستر می‌تواند سناریوهایی برای آن طراحی کند:

• مشتری VIP + مبلغ کمتر از ۲ میلیون
• مشتری VIP + مبلغ دقیقاً ۲ میلیون
• مشتری VIP + مبلغ بیشتر از ۲ میلیون
• مشتری عادی + مبلغ بیشتر از ۲ میلیون

در نتیجه Business Rule نیز مانند Requirement باید تا حد امکان واضح، بدون ابهام و قابل ارزیابی باشد.

یک اشتباه رایج: مخلوط کردن Rule و Implementation

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

مثلاً:

مشتری VIP باید ۱۰ درصد تخفیف دریافت کند.

یک Business Rule است.

اما:

سیستم باید با استفاده از کلاس VipDiscountCalculator و الگوریتم X تخفیف را محاسبه کند.

دیگر یک Business Rule نیست؛ بلکه وارد جزئیات Implementation شده است.

در SRS بهتر است تا زمانی که دلیلی وجود ندارد، نیازمندی و قانون کسب‌وکار را از جزئیات غیرضروری پیاده‌سازی جدا نگه داریم.

Business Rule و Acceptance Criteria چه تفاوتی دارند؟

این سه مفهوم ممکن است کنار هم دیده شوند:

• Requirement
• Business Rule
• Acceptance Criteria

اما نقششان یکی نیست.

Requirement

سیستم باید امکان استفاده از کد تخفیف را فراهم کند.

Business Rule

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

Acceptance Criteria

اگر مشتری قبلاً از کد Welcome استفاده کرده باشد، سیستم نباید امکان استفاده مجدد از آن را فراهم کند.

در اینجا:

Requirement قابلیت را تعریف می‌کند.

Business Rule منطق کسب‌وکار را مشخص می‌کند.

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

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

Business Rule در SRS چگونه مستند شود؟

یکی از روش‌های مناسب این است که برای Ruleها شناسه مشخص تعریف کنیم.

ID	Business Rule
BR-DIS-001	هر مشتری فقط یک بار می‌تواند از کد Welcome استفاده کند.
BR-DIS-002	کد تخفیف پس از تاریخ انقضا قابل استفاده نیست.
BR-ORD-001	سفارش پس از ارسال قابل لغو نیست.
BR-PAY-001	پرداخت باید قبل از تغییر سفارش به وضعیت Paid تأیید شود.

سپس Requirementها می‌توانند به Ruleهای مرتبط ارجاع دهند.

مثلاً:

FR-DIS-001: سیستم باید امکان استفاده از کد تخفیف را مطابق BR-DIS-001 و BR-DIS-002 فراهم کند.

این ساختار به‌خصوص در پروژه‌های بزرگ بسیار مفید است.

یک مثال از ارتباط همه اجزا

بیایید کل زنجیره را با یک مثال ببینیم.

Business Need

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

Business Rule

BR-ORD-001: سفارش پس از تغییر وضعیت به «در حال ارسال» قابل لغو نیست.

Functional Requirement

FR-ORD-010: سیستم باید امکان لغو سفارش را برای مشتری در وضعیت‌های مجاز فراهم کند.

Acceptance Criteria

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

Test Scenarios

• لغو سفارش قبل از ارسال
• تلاش برای لغو سفارش در حال ارسال
• بررسی وضعیت سفارش پس از لغو

Test Cases

برای هر Scenario می‌توان Test Caseهای دقیق‌تری طراحی کرد.

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

Business Need

↓

Business Rule

↓

Functional Requirement

↓

Acceptance Criteria

↓

Test Scenario

↓

Test Case

این زنجیره برای تستر بسیار ارزشمند است، زیرا نشان می‌دهد منطق تست از کجا آمده است.

یک نکته مهم برای تستر

وقتی تستر یک Test Case را طراحی می‌کند، همیشه نباید فقط به متن Functional Requirement نگاه کند.

گاهی مهم‌ترین منبع سناریوهای تست، Business Rule است.

مثلاً اگر Requirement بگوید:

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

این جمله به‌تنهایی Test Design محدودی ایجاد می‌کند.

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

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

ناگهان تعداد زیادی سناریوی تست به وجود می‌آید.

بنابراین:

Business Rules می‌توانند منبع مهمی برای استخراج Test Condition و طراحی سناریوهای منفی و مرزی باشند.

جمع‌بندی

Business Ruleها بخش مهمی از منطق کسب‌وکار هستند و می‌توانند در SRS یا در مستندات مرتبط با آن ثبت شوند.

تفاوت کلی را می‌توان این‌گونه خلاصه کرد:

Requirement: سیستم چه کاری باید انجام دهد؟

Business Rule: چه قانون کسب‌وکاری باید رعایت شود؟

Acceptance Criteria: چه شرایطی نشان می‌دهد قابلیت قابل قبول است؟

Test Case: چگونه این شرایط را بررسی کنیم؟

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

در بخش بعدی سراغ SRS، Use Case و User Story می‌رویم و بررسی می‌کنیم این سه مفهوم چه رابطه‌ای با هم دارند و چرا در پروژه‌های Agile، مستندات نیازمندی ممکن است شکل متفاوتی نسبت به پروژه‌های سنتی داشته باشند.

۱۱. SRS و Use Case و User Story چه ارتباطی دارند؟

در پروژه‌های نرم‌افزاری، Requirementها ممکن است با روش‌های مختلفی بیان و مستند شوند. SRS یکی از قالب‌های شناخته‌شده برای مستندسازی نیازمندی‌های نرم‌افزار است، اما تنها روش موجود نیست.

دو مفهوم دیگری که احتمالاً هنگام مطالعه Requirementها با آن‌ها روبه‌رو می‌شوید عبارت‌اند از:

• Use Case
• User Story

از آنجا که هر دو موضوع می‌توانند به‌صورت مستقل و مفصل بررسی شوند، در این مقاله وارد آموزش نحوه نوشتن Use Case یا User Story نمی‌شویم. هدف این بخش فقط روشن کردن رابطه آن‌ها با SRS است.

SRS در مقابل Use Case و User Story

در نگاه اول ممکن است تصور کنیم:

SRS، Use Case و User Story سه نوع مختلف از یک سند هستند.

اما چنین برداشتی دقیق نیست.

این مفاهیم می‌توانند سطوح و روش‌های متفاوتی برای بیان نیازمندی باشند و در یک پروژه حتی در کنار یکدیگر استفاده شوند.

برای مثال:

Business Need

↓

Requirement

↓

Use Case / User Story

↓

Acceptance Criteria

↓

Test Case

البته این زنجیره در همه پروژه‌ها دقیقاً به همین شکل اجرا نمی‌شود.

SRS و Use Case

Use Case معمولاً برای توصیف تعامل Actor با سیستم استفاده می‌شود.

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

مشتری می‌خواهد یک محصول خریداری کند.

Use Case می‌تواند تعاملات مختلف این فرآیند را توصیف کند:

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

اما SRS می‌تواند مجموعه گسترده‌تری از Requirementها را در خود داشته باشد.

برای مثال:

• Functional Requirements
• Non-Functional Requirements
• Business Rules
• Constraints
• External Interfaces
• داده‌ها و رفتارهای مورد انتظار

بنابراین:

Use Case معمولاً یک روش برای توصیف تعامل کاربر و سیستم است، در حالی که SRS می‌تواند مجموعه جامع‌تری از نیازمندی‌های نرم‌افزار را مستند کند.

آیا Use Case بخشی از SRS است؟

می‌تواند باشد.

در بعضی ساختارهای SRS، Use Caseها به‌عنوان بخشی از مستندات نیازمندی قرار می‌گیرند.

SRS
│
├── Introduction
├── Scope
├── Functional Requirements
├── Non-Functional Requirements
├── Business Rules
├── Use Cases
└── External Interfaces

اما این ساختار اجباری نیست.

ممکن است Use Caseها در یک مستند جداگانه نگهداری شوند و SRS فقط به آن‌ها ارجاع دهد.

پس:

Use Case می‌تواند بخشی از SRS باشد، اما SRS الزاماً محدود به Use Case نیست.

SRS و User Story

User Story بیشتر در محیط‌های Agile رایج است.

یک User Story معمولاً نیاز را از دید کاربر بیان می‌کند.

مثلاً:

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

این جمله یک نیاز را از دید کاربر بیان می‌کند.

در کنار آن می‌توان Acceptance Criteria قرار داد تا شرایط پذیرش این قابلیت مشخص شود.

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

آیا User Story جایگزین SRS است؟

این سؤال مهمی است و پاسخ آن:

همیشه نه.

در برخی پروژه‌های Agile، نیازمندی‌ها به‌صورت مجموعه‌ای از:

• User Story
• Acceptance Criteria
• Epic
• Product Backlog Item
• Business Rule
• مستندات فنی

مدیریت می‌شوند و ممکن است یک SRS سنتی و یکپارچه وجود نداشته باشد.

اما این به معنی آن نیست که Agile بدون Requirement یا بدون مستندات است.

در واقع ممکن است اطلاعاتی که در یک پروژه سنتی داخل SRS قرار می‌گرفتند، در Agile بین Artefactهای مختلف توزیع شده باشند.

یک مثال ساده

فرض کنیم نیاز کسب‌وکار این است:

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

در یک رویکرد مستندمحور، ممکن است این نیاز در SRS چنین ثبت شود:

FR-ORD-010: سیستم باید امکان لغو سفارش را برای مشتری فراهم کند.

در یک پروژه Agile ممکن است همین نیاز به شکل User Story بیان شود:

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

سپس Acceptance Criteria مشخص می‌کند:

• سفارش قبل از ارسال قابل لغو باشد.
• سفارش ارسال‌شده قابل لغو نباشد.
• پس از لغو، وضعیت سفارش تغییر کند.

در هر دو حالت، نیاز واقعی سیستم وجود دارد؛ چیزی که تغییر کرده، روش مستندسازی و مدیریت آن است.

برای تستر چه تفاوتی ایجاد می‌شود؟

از دید تستر، مهم‌ترین موضوع این نیست که Requirement در SRS نوشته شده یا در User Story.

سؤال اصلی این است:

آیا اطلاعات کافی برای طراحی تست وجود دارد؟

اگر تستر در SRS یک Requirement واضح داشته باشد، می‌تواند از آن Test Scenario و Test Case استخراج کند.

اگر همان نیاز در قالب User Story باشد، ممکن است از:

User Story + Acceptance Criteria + Business Rules

برای طراحی تست استفاده کند.

بنابراین منابع تست ممکن است متفاوت باشند، اما هدف یکی است:

درک رفتار مورد انتظار سیستم و طراحی تست بر اساس آن.

آیا تستر باید SRS را بلد باشد اگر در پروژه Agile کار کند؟

بله، شناخت SRS همچنان مفید است.

تستر ممکن است در یک پروژه Agile هیچ فایل مشخصی با نام:

Software Requirements Specification

نداشته باشد.

اما همچنان باید مفاهیمی مانند این‌ها را درک کند:

• Requirement
• Functional Requirement
• Non-Functional Requirement
• Business Rule
• Acceptance Criteria
• Scope
• Constraint
• Traceability

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

پس یادگیری SRS فقط برای کار در پروژه‌های Waterfall نیست.

SRS در Waterfall و Agile

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

رویکرد سنتی

ممکن است ابتدا مجموعه بزرگی از Requirementها تحلیل و در یک SRS نسبتاً جامع مستند شود.

Business Requirements
        ↓
Requirements Analysis
        ↓
SRS
        ↓
Design
        ↓
Development
        ↓
Testing

رویکرد Agile

Requirementها ممکن است به‌صورت تدریجی و در طول Iterationها شکل بگیرند:

Product Goal
    ↓
Epic
    ↓
User Story
    ↓
Acceptance Criteria
    ↓
Development
    ↓
Testing

در Agile نیز ممکن است مستندات تکمیلی، Requirementهای Non-Functional، Business Rules و مستندات فنی در کنار این موارد وجود داشته باشند.

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

Waterfall = SRS
Agile = User Story

واقعیت پروژه‌ها بسیار متنوع‌تر از این است.

آیا SRS و User Story می‌توانند هم‌زمان وجود داشته باشند؟

بله.

یک سازمان ممکن است یک SRS سطح بالا داشته باشد و سپس Requirementهای آن را به User Storyهای کوچک‌تر تبدیل کند.

برای مثال:

SRS

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

سپس این نیاز می‌تواند به چند User Story تبدیل شود:

• مشاهده سفارش
• لغو سفارش
• پیگیری سفارش
• دریافت وضعیت سفارش
• مشاهده تاریخچه سفارش‌ها

در این حالت SRS می‌تواند دید جامع‌تری از سیستم ارائه دهد و User Storyها نیازها را به واحدهای کوچک‌تر و قابل توسعه تقسیم کنند.

نکته مهم برای مقاله‌های تخصصی سایت

از آنجا که Use Case و User Story خودشان موضوعات مستقلی هستند، در این مقاله نباید وارد مواردی مانند:

• ساختار کامل Use Case
• Use Case Diagram
• Actor و انواع روابط
• نحوه نوشتن User Story
• INVEST
• Epic و Story
• روش‌های تخمین User Story

شویم.

این مطالب بهتر است در مقالات تخصصی خودشان بررسی شوند.

در مقاله SRS کافی است بدانیم:

SRS یک چارچوب جامع برای مستندسازی نیازمندی‌های نرم‌افزار است و Use Case یا User Story می‌توانند یکی از روش‌های بیان یا مستندسازی بخشی از این نیازمندی‌ها باشند.

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

یک نکته مهم درباره SRS در پروژه‌های واقعی

در پروژه واقعی ممکن است اسم سند اصلاً SRS نباشد.

ممکن است تیم از عباراتی مانند:

• Requirement Specification
• System Requirements
• Product Requirements
• Functional Specification
• Requirements Document

استفاده کند.

همچنین ممکن است اطلاعات Requirement در ابزارهایی مانند ابزارهای مدیریت پروژه و Requirement Management ذخیره شوند.

بنابراین تستر نباید فقط دنبال فایلی با نام SRS بگردد.

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

جمع‌بندی

می‌توان رابطه این مفاهیم را به شکل زیر خلاصه کرد:

مفهوم	تمرکز اصلی
SRS	مستندسازی جامع نیازمندی‌های نرم‌افزار
Use Case	تعامل Actor با سیستم
User Story	بیان نیاز از دید کاربر، به‌خصوص در Agile
Acceptance Criteria	شرایط قابل قبول بودن یک قابلیت یا Requirement

این مفاهیم رقیب یکدیگر نیستند و در یک پروژه می‌توانند در کنار هم استفاده شوند.

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

در بخش بعدی به موضوع Traceability در SRS می‌رسیم؛ جایی که ارتباط بین Requirement، Test Scenario، Test Case و نتیجه تست را بررسی می‌کنیم.

۱۲. Traceability در SRS چیست و چرا برای تستر مهم است؟

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

اما تصور کنید یک سیستم بزرگ دارای صدها یا هزاران Requirement باشد و برای هر Requirement چندین Test Case، Defect و Test Result وجود داشته باشد.

در چنین شرایطی یک سؤال مهم مطرح می‌شود:

از کجا بدانیم هر Requirement دقیقاً چگونه پیاده‌سازی و تست شده است؟

اینجاست که مفهوم Requirement Traceability یا ردیابی نیازمندی‌ها اهمیت پیدا می‌کند.

به زبان ساده، Traceability یعنی بتوانیم ارتباط یک Requirement را با Artefactها و فعالیت‌های مرتبط با آن دنبال کنیم.

برای مثال:

Requirement → Test Case → Test Execution → Test Result

و در پروژه‌های بزرگ‌تر:

Requirement → Design → Development → Test Case → Defect → Test Result

Traceability در SRS یعنی چه؟

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

مثلاً:

FR-LOGIN-001

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

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

حالا Test Caseها می‌توانند به این Requirementها متصل شوند.

Requirement Traceability Matrix یا RTM چیست؟

یکی از روش‌های رایج برای مدیریت Traceability استفاده از Requirement Traceability Matrix (RTM) است.

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

یک نمونه ساده:

Requirement ID	Test Case ID	وضعیت
FR-LOGIN-001	TC-LOGIN-001	Pass
FR-LOGIN-001	TC-LOGIN-002	Pass
FR-LOGIN-002	TC-LOGIN-003	Fail
FR-LOGIN-003	TC-LOGIN-004	Not Run

با چنین جدولی می‌توان سریع‌تر متوجه شد که هر Requirement چه وضعیت تستی دارد.

البته RTM فقط یکی از روش‌های پیاده‌سازی Traceability است و در پروژه‌های مختلف ممکن است Traceability در ابزارهای مدیریت تست یا Requirement Management انجام شود.

چرا Requirement ID اهمیت دارد؟

فرض کنید در SRS نوشته شده:

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

حالا این Requirement را در چندین سند و ابزار دیگر باید پیدا کنیم.

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

اما اگر داشته باشیم:

FR-AUTH-007

می‌توان همین ID را در:

• Test Case
• Test Management Tool
• Defect
• Test Report
• Change Request

استفاده کرد.

در نتیجه:

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

Traceability چه کمکی به تستر می‌کند؟

یکی از مهم‌ترین کاربردهای Traceability برای تستر، بررسی Requirement Coverage است.

تستر می‌تواند بپرسد:

آیا برای همه Requirementهای مهم، Test Case طراحی شده است؟

مثلاً:

Requirement	Test Case
FR-001	TC-001
FR-002	TC-002
FR-003	❌
FR-004	TC-004

در اینجا مشخص است که:

FR-003 هنوز Test Case مرتبط ندارد.

این اطلاعات می‌تواند به شناسایی یک Coverage Gap کمک کند.

Traceability فقط از Requirement به Test Case نیست

گاهی Traceability را فقط این‌گونه تصور می‌کنند:

Requirement → Test Case

اما Traceability می‌تواند گسترده‌تر باشد.

مثلاً:

Business Need
↓
Requirement
↓
Design
↓
Code / Implementation
↓
Test Case
↓
Defect
↓
Test Result

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

به همین دلیل در پروژه‌های بزرگ، Traceability می‌تواند نقش مهمی در Impact Analysis، Change Management و Test Management داشته باشد.

یک مثال کامل

فرض کنیم Requirement زیر را داریم:

FR-PAY-001: پس از دریافت پاسخ موفق از درگاه پرداخت، سیستم باید سفارش را با وضعیت «پرداخت‌شده» ثبت کند.

برای این Requirement چند Test Case طراحی می‌کنیم:

TC-PAY-001

پرداخت موفق

Expected Result:

سفارش با وضعیت «پرداخت‌شده» ثبت شود.

TC-PAY-002

پرداخت ناموفق

Expected Result:

سفارش نباید با وضعیت «پرداخت‌شده» ثبت شود.

TC-PAY-003

Timeout درگاه

Expected Result:

رفتار سیستم مطابق Requirement و Business Rule مشخص باشد.

حالا Traceability می‌تواند چنین ارتباطی داشته باشد:

Requirement	Test Case	نتیجه
FR-PAY-001	TC-PAY-001	Pass
FR-PAY-001	TC-PAY-002	Pass
FR-PAY-001	TC-PAY-003	Fail

اگر TC-PAY-003 Fail شود، تیم می‌تواند سریعاً مشخص کند که Defect مربوط به کدام Requirement است.

Traceability و Defect Management

فرض کنیم تستر یک Bug پیدا کرده است:

پس از پرداخت موفق، وضعیت سفارش همچنان Pending باقی می‌ماند.

اگر Test Case به Requirement متصل باشد، می‌توان مسیر زیر را دنبال کرد:

Defect

↓

Test Case

↓

Requirement

بنابراین مشخص می‌شود Defect مربوط به کدام نیازمندی است.

مثلاً:

DEF-1024 → TC-PAY-001 → FR-PAY-001

این ارتباط برای تحلیل تأثیر Defect بسیار مفید است.

Traceability و تغییر Requirement

یکی از مهم‌ترین کاربردهای Traceability هنگام تغییر Requirement مشخص می‌شود.

فرض کنیم Requirement زیر تغییر کند:

قبل

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

بعد

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

اگر Requirement به Test Caseها متصل باشد، تستر می‌تواند سریعاً پیدا کند:

• کدام Test Caseها تحت تأثیر تغییر قرار گرفته‌اند؟
• کدام Test Data باید تغییر کند؟
• آیا Test Scenario جدیدی لازم است؟
• آیا Test Automation باید اصلاح شود؟

این همان چیزی است که به آن Impact Analysis می‌گوییم.

Traceability و Regression Testing

این موضوع ارتباط مستقیمی با تست رگرسیون نیز دارد.

فرض کنید یک Requirement تغییر کرده است.

با استفاده از Traceability می‌توان Test Caseهای مرتبط را پیدا کرد.

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

ممکن است تغییر یک Requirement روی بخش‌های دیگری از سیستم نیز تأثیر بگذارد.

بنابراین تستر می‌تواند علاوه بر Test Caseهای مستقیم، Test Caseهای مرتبط با بخش‌های تحت تأثیر را نیز برای Regression Testing بررسی کند.

در نتیجه:

Traceability می‌تواند یکی از ورودی‌های مهم برای تصمیم‌گیری درباره دامنه Regression Testing باشد.

برای جزئیات کامل تست رگرسیون، مقاله تخصصی تست رگرسیون جای مناسب‌تری است.

Forward Traceability و Backward Traceability

Traceability می‌تواند در جهت‌های مختلف بررسی شود.

Forward Traceability

از Requirement به سمت تست حرکت می‌کنیم:

Requirement → Test Case → Test Result

مثلاً:

آیا برای این Requirement تستی وجود دارد؟

این نوع Traceability می‌تواند برای بررسی پوشش Requirement مفید باشد.

Backward Traceability

از Test Case به سمت Requirement حرکت می‌کنیم:

Test Case → Requirement

سؤال این است:

این Test Case دقیقاً برای کدام Requirement نوشته شده است؟

اگر یک Test Case هیچ Requirement یا منبع مشخصی نداشته باشد، ممکن است لازم باشد دلیل وجود آن بررسی شود.

البته یک Test Case می‌تواند بر اساس منابع دیگری مانند Risk، Business Rule یا Defect History نیز ایجاد شده باشد؛ بنابراین نبود لینک مستقیم به SRS همیشه به معنی بی‌دلیل بودن Test Case نیست.

Bidirectional Traceability

در پروژه‌های بزرگ معمولاً داشتن Traceability در هر دو جهت ارزشمندتر است:

Requirement ↔ Test Case

یعنی بتوانیم:

• از Requirement به Test Case برسیم.
• از Test Case به Requirement برگردیم.

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

آیا همه Requirementها باید یک Test Case داشته باشند؟

نه لزوماً.

این نکته مهم است.

ممکن است یک Requirement صرفاً برای مستندسازی یک Constraint یا Policy باشد و روش ارزیابی آن متفاوت باشد.

همچنین ممکن است یک Requirement از طریق:

• Test Case
• Inspection
• Review
• Static Analysis
• Performance Test
• Security Assessment

ارزیابی شود.

بنابراین:

Traceability الزاماً به معنی Requirement → Test Case برای همه موارد نیست.

هدف اصلی این است که بتوانیم نشان دهیم Requirement چگونه و با چه روشی مورد ارزیابی یا پوشش قرار گرفته است.

Traceability و Non-Functional Requirements

Traceability فقط برای Functional Requirementها نیست.

مثلاً:

NFR-PERF-001: ۹۵ درصد درخواست‌های جستجو باید در کمتر از ۲ ثانیه پاسخ داده شوند.

این Requirement ممکن است به یک Performance Test متصل شود.

یا:

NFR-SEC-001: سیستم باید پس از پنج تلاش ناموفق حساب را محدود کند.

این Requirement می‌تواند به چند Security Test متصل شود.

پس:

Functional Requirement → Functional Test

و

Non-Functional Requirement → Performance / Security / Usability / … Test

این ارتباط می‌تواند در Traceability ثبت شود.

Traceability چه کمکی به مدیریت پروژه می‌کند؟

Traceability فقط ابزار تستر نیست.

افراد مختلف از آن استفاده می‌کنند.

Business Analyst

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

Developer

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

Tester

می‌تواند Coverage و ارتباط Requirement با تست را بررسی کند.

Project Manager

می‌تواند تأثیر تغییرات Requirement را بهتر ارزیابی کند.

Product Owner

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

بنابراین Traceability یک مفهوم بین‌تیمی است، نه صرفاً یک تکنیک تست.

Traceability در SRS چگونه پیاده‌سازی شود؟

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

ID	Requirement	Priority	Test Case
FR-001	Login	High	TC-001, TC-002
FR-002	Search	Medium	TC-003
FR-003	Checkout	Critical	TC-004, TC-005, TC-006

در پروژه‌های بزرگ‌تر ممکن است این اطلاعات در ابزارهای تخصصی مدیریت Requirement و Test Management نگهداری شود.

بنابراین مهم‌تر از ابزار، وجود یک ارتباط قابل اعتماد و به‌روز میان Requirementها و Artefactهای مرتبط است.

یک نکته مهم: Traceability نباید فقط برای Audit ساخته شود

یکی از اشتباهات رایج این است که تیم فقط برای اینکه در یک Audit یا بررسی رسمی بتواند یک جدول ارائه دهد، RTM ایجاد کند.

در این حالت Traceability تبدیل به یک فعالیت اداری و پرهزینه می‌شود.

هدف واقعی Traceability این است که به تیم کمک کند:

• Coverage را بهتر بفهمد.
• تغییرات را بهتر مدیریت کند.
• Impact Analysis انجام دهد.
• Test Scope را مشخص کند.
• Defectها را به Requirementهای مربوط متصل کند.
• Requirementهای بدون پوشش را پیدا کند.

اگر Traceability این ارزش را ایجاد نکند، احتمالاً روش پیاده‌سازی آن نیاز به بازنگری دارد.

جمع‌بندی

Requirement Traceability یعنی بتوانیم ارتباط یک Requirement را در طول چرخه توسعه و تست دنبال کنیم.

برای تستر، یکی از مهم‌ترین مسیرها این است:

Requirement → Test Scenario → Test Case → Test Execution → Test Result

و در صورت وجود Defect:

Requirement → Test Case → Defect → Retest

Traceability همچنین هنگام تغییر Requirement اهمیت زیادی پیدا می‌کند؛ زیرا می‌تواند به تستر کمک کند Test Caseهای تحت تأثیر را شناسایی کرده و دامنه Regression Testing را بهتر مشخص کند.

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

۱۳. تغییر Requirement و مدیریت تغییرات در SRS

یکی از تصورهای اشتباه درباره SRS (Software Requirements Specification) این است که بعد از نهایی شدن سند، Requirementها دیگر تغییر نمی‌کنند.

در پروژه‌های واقعی معمولاً چنین اتفاقی نمی‌افتد.

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

بنابراین:

SRS یک سند کاملاً ثابت نیست؛ بلکه باید بتوان تغییرات تأییدشده Requirementها را در طول چرخه عمر پروژه مدیریت کرد.

این موضوع برای تستر اهمیت زیادی دارد، چون تغییر یک Requirement می‌تواند مستقیماً روی Test Scenario، Test Case، Test Data، Automation و Regression Testing تأثیر بگذارد.

چرا Requirementها تغییر می‌کنند؟

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

تغییر نیاز کسب‌وکار

مثلاً شرکت تصمیم می‌گیرد شرایط ارسال رایگان را تغییر دهد.

قبل:

سفارش‌های بالاتر از ۱ میلیون تومان شامل ارسال رایگان هستند.

بعد:

سفارش‌های بالاتر از ۲ میلیون تومان شامل ارسال رایگان هستند.

این یک تغییر در Business Rule است که می‌تواند چند Requirement و Test Case را تحت تأثیر قرار دهد.

بازخورد کاربران

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

در نتیجه Requirement تغییر می‌کند.

تغییر قوانین یا مقررات

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

در چنین شرایطی Requirementهای مرتبط نیز باید به‌روزرسانی شوند.

کشف محدودیت فنی

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

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

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

کشف ابهام در Requirement

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

مثلاً:

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

سؤال این است:

چند تلاش؟

ممکن است Requirement بعداً به شکل دقیق‌تری اصلاح شود:

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

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

آیا هر تغییری باید مستقیماً در SRS اعمال شود؟

خیر.

این یکی از نکات مهم در Requirements Change Management است.

فرض کنید یک نفر پیشنهاد دهد:

بهتر است مدت زمان Session از ۳۰ دقیقه به ۶۰ دقیقه تغییر کند.

این صرفاً یک Change Request یا پیشنهاد تغییر است.

نباید بلافاصله SRS را ویرایش کنیم.

ابتدا باید مشخص شود:

• چرا این تغییر لازم است؟
• چه بخش‌هایی تحت تأثیر قرار می‌گیرند؟
• آیا از نظر کسب‌وکار تأیید شده است؟
• آیا از نظر فنی امکان‌پذیر است؟
• چه هزینه‌ای دارد؟
• چه Test Caseهایی باید تغییر کنند؟
• آیا زمان Release تحت تأثیر قرار می‌گیرد؟

پس یک مسیر منطقی می‌تواند چنین باشد:

Change Request → Impact Analysis → Review/Approval → SRS Update → Development/Test Update

Change Request چیست؟

Change Request یا درخواست تغییر، پیشنهادی رسمی برای تغییر یک Requirement، Feature، Rule یا بخش دیگری از سیستم است.

مثلاً:

CR-024: تغییر حداکثر تعداد تلاش ورود ناموفق از ۵ به ۳.

درخواست تغییر می‌تواند شامل اطلاعاتی مانند این موارد باشد:

• شناسه تغییر
• دلیل تغییر
• Requirement تحت تأثیر
• اولویت
• تأثیر احتمالی
• وضعیت تأیید
• فرد یا تیم درخواست‌کننده
• تاریخ

ساختار دقیق Change Request در سازمان‌های مختلف متفاوت است.

Impact Analysis چیست؟

بعد از مطرح شدن تغییر، یکی از مهم‌ترین فعالیت‌ها Impact Analysis یا تحلیل تأثیر تغییر است.

سؤال اصلی این است:

اگر این Requirement تغییر کند، چه چیزهایی تحت تأثیر قرار می‌گیرند؟

فرض کنید:

FR-AUTH-003: پس از پنج تلاش ناموفق، حساب به مدت ۱۵ دقیقه محدود شود.

حالا Requirement تغییر می‌کند:

پس از سه تلاش ناموفق، حساب به مدت ۳۰ دقیقه محدود شود.

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

• کدام Test Caseها تغییر می‌کنند؟
• آیا Test Data باید تغییر کند؟
• آیا Automation Scriptها تحت تأثیر قرار می‌گیرند؟
• آیا Requirement دیگری به این Rule وابسته است؟
• آیا Regression Test جدیدی لازم است؟
• آیا مستندات دیگر باید اصلاح شوند؟

اینجاست که Traceability که در بخش قبل بررسی کردیم، ارزش خود را نشان می‌دهد.

ارتباط Change Management و Traceability

اگر Requirement شناسه داشته باشد و Test Caseها به Requirement متصل باشند، تحلیل تأثیر بسیار ساده‌تر می‌شود.

مثلاً:

FR-AUTH-003

↓

TC-AUTH-011
TC-AUTH-012
TC-AUTH-013

↓

Automation Scripts

حالا وقتی FR-AUTH-003 تغییر می‌کند، تستر می‌تواند سریع‌تر Test Caseهای مرتبط را شناسایی کند.

به همین دلیل:

Traceability فقط برای گزارش Coverage نیست؛ یکی از کاربردهای مهم آن، مدیریت تغییر Requirement است.

Versioning در SRS چیست؟

وقتی SRS تغییر می‌کند، بهتر است نسخه‌های آن قابل شناسایی باشند.

SRS v1.0
SRS v1.1
SRS v1.2
SRS v2.0

اما نحوه Versioning به سیاست سازمان بستگی دارد.

مهم این است که مشخص باشد:

• نسخه فعلی کدام است؟
• چه تغییراتی در آن انجام شده؟
• چه زمانی تغییر کرده؟
• چه کسی تغییر را انجام داده؟
• آیا تغییر تأیید شده است؟

Change Log در SRS

یکی از روش‌های ساده برای ثبت تغییرات، استفاده از Change Log است.

Version	Date	Change	Author
1.0	1405/05/01	نسخه اولیه	BA
1.1	1405/05/10	تغییر قانون ورود	BA
1.2	1405/05/15	اصلاح Requirement پرداخت	Product Team
2.0	1405/06/01	بازنگری عمده Requirementها	Requirements Team

این جدول به تیم کمک می‌کند تاریخچه تغییرات را بهتر دنبال کند.

آیا باید تمام Versionهای SRS را نگه داشت؟

در پروژه‌های حرفه‌ای، معمولاً باید تاریخچه تغییرات به شکلی کنترل‌شده قابل دسترسی باشد.

اما روش نگهداری آن به فرآیند سازمان بستگی دارد.

• Document Management System
• Version Control
• Requirements Management Tool
• Project Management Tool

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

Baseline در SRS چیست؟

در برخی پروژه‌ها پس از بررسی و تأیید مجموعه‌ای از Requirementها، یک نسخه مشخص به‌عنوان Baseline تعیین می‌شود.

Baseline را می‌توان به‌صورت ساده چنین در نظر گرفت:

یک نسخه رسمی و تأییدشده از Requirementها که تغییر آن باید طبق فرآیند مشخصی انجام شود.

مثلاً:

SRS Baseline v1.0

بعد از Baseline، تغییر Requirement ممکن است نیازمند Change Request و Approval باشد.

این موضوع به‌خصوص در پروژه‌هایی که کنترل تغییرات اهمیت زیادی دارد، مهم است.

آیا بعد از Baseline دیگر Requirement نباید تغییر کند؟

خیر.

Baseline به معنی «تغییرناپذیر بودن» نیست.

بلکه یعنی:

تغییر باید کنترل‌شده باشد.

مثلاً:

SRS Baseline 1.0
        ↓
Change Request
        ↓
Impact Analysis
        ↓
Approval
        ↓
SRS Baseline 1.1

بنابراین Baseline به تیم کمک می‌کند بداند:

«در این مرحله، Requirement رسمی و مورد توافق چیست؟»

تغییر Requirement چه اثری روی تست دارد؟

این بخش برای تستر بسیار مهم است.

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

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

Test Case:

پس از تلاش پنجم، حساب باید Block شود.

حالا Requirement تغییر می‌کند:

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

در این حالت فقط متن Requirement تغییر نکرده است.

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

• Test Scenario
• Test Case
• Expected Result
• Test Data
• Automation Script
• Regression Scope
• Test Report
• Traceability Matrix

پس:

هر تغییر Requirement می‌تواند یک تغییر بالقوه در Test Artefactها باشد.

البته میزان تأثیر باید با Impact Analysis مشخص شود و نباید فرض کرد هر تغییر کوچک الزاماً کل مجموعه تست را تحت تأثیر قرار می‌دهد.

تغییر Requirement و Regression Testing

فرض کنید یک Requirement مربوط به فرآیند پرداخت تغییر کرده است.

تستر فقط نباید Test Case مربوط به همان Requirement را دوباره اجرا کند.

باید بررسی شود:

آیا این تغییر می‌تواند روی رفتارهای قبلی سیستم نیز تأثیر بگذارد؟

مثلاً تغییر در منطق پرداخت ممکن است روی:

• ثبت سفارش
• محاسبه موجودی
• صدور فاکتور
• Notification
• Refund

اثر بگذارد.

بنابراین Impact Analysis می‌تواند به تعیین دامنه مناسب Regression Testing کمک کند.

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

Requirement Change و Test Automation

تغییر Requirement ممکن است روی تست‌های خودکار نیز تأثیر بگذارد.

مثلاً Test Automation قبلی فرض می‌کند:

تعداد مجاز تلاش ناموفق = ۵

اما Requirement جدید می‌گوید:

تعداد مجاز تلاش ناموفق = ۳

در این حالت ممکن است:

• Test Data تغییر کند.
• Expected Result تغییر کند.
• Assertionها تغییر کنند.
• Test Script اصلاح شود.

بنابراین تستر یا Automation Engineer باید Test Suite را با Requirement جدید هماهنگ کند.

یک اشتباه رایج: تغییر Requirement بدون اطلاع تستر

فرض کنید تیم Product تصمیم می‌گیرد یک Requirement را تغییر دهد، Developer آن را پیاده‌سازی می‌کند و تستر تازه هنگام اجرای تست متوجه تغییر می‌شود.

این وضعیت می‌تواند باعث شود:

• Test Caseهای قدیمی Fail شوند.
• Bug اشتباه گزارش شود.
• تستر تصور کند Implementation اشتباه است.
• زمان زیادی صرف تحلیل غیرضروری شود.

در حالی که مشکل اصلی، عدم هماهنگی فرآیند Change Management بوده است.

بنابراین تغییر Requirement باید به افراد و Artefactهای مرتبط اطلاع داده شود.

آیا هر Requirement Change یک Bug است؟

خیر.

این تفاوت بسیار مهم است.

فرض کنید Requirement قبلی می‌گفت:

حداکثر ۵ تلاش ناموفق مجاز است.

بعد Requirement به ۳ تغییر می‌کند.

اگر Developer طبق Requirement جدید سیستم را اصلاح کند، Fail شدن Test Case قدیمی الزاماً Bug نیست.

ممکن است:

Test Case به‌روز نشده باشد.

بنابراین تستر قبل از گزارش Defect باید بررسی کند:

آیا این رفتار واقعاً با Requirement فعلی مغایرت دارد؟

یا:

Test Case من هنوز بر اساس Requirement قبلی نوشته شده است؟

یک مثال کامل از Change Management

فرض کنیم SRS نسخه 1.0 این Requirement را دارد:

FR-AUTH-003: پس از پنج تلاش ناموفق، حساب کاربر برای ۱۵ دقیقه محدود شود.

مرحله اول: Change Request

تیم Security پیشنهاد می‌دهد:

تعداد تلاش‌ها به سه کاهش یابد و مدت محدودیت به ۳۰ دقیقه افزایش پیدا کند.

مرحله دوم: Impact Analysis

تیم بررسی می‌کند:

• Requirement تحت تأثیر
• Business Rule مرتبط
• Test Caseهای Login
• Automation Tests
• مستندات مرتبط

مرحله سوم: Approval

تغییر تأیید می‌شود.

مرحله چهارم: SRS Update

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

FR-AUTH-003: پس از سه تلاش ناموفق، حساب کاربر برای ۳۰ دقیقه محدود شود.

مرحله پنجم: Test Update

تستر:

• Test Caseها را اصلاح می‌کند.
• Test Data را تغییر می‌دهد.
• Automation را بررسی می‌کند.
• Regression Scope را تعیین می‌کند.

مرحله ششم: Test Execution

تست‌ها بر اساس Requirement جدید اجرا می‌شوند.

این چرخه نشان می‌دهد که:

SRS یک سند زنده است و تغییرات آن باید با سایر فعالیت‌های پروژه هماهنگ باشد.

Checklist مدیریت تغییر Requirement

• ☐ دلیل تغییر مشخص است.
• ☐ Requirement تحت تأثیر شناسایی شده است.
• ☐ Business Ruleهای مرتبط بررسی شده‌اند.
• ☐ Impact Analysis انجام شده است.
• ☐ تغییر تأیید شده است.
• ☐ نسخه SRS مشخص است.
• ☐ Change Log به‌روزرسانی شده است.
• ☐ Test Caseهای مرتبط شناسایی شده‌اند.
• ☐ Test Automation بررسی شده است.
• ☐ Regression Scope مشخص شده است.
• ☐ Traceability به‌روزرسانی شده است.
• ☐ افراد و تیم‌های مرتبط از تغییر مطلع شده‌اند.

جمع‌بندی

Requirementها در پروژه‌های واقعی ممکن است تغییر کنند و SRS باید بتواند این تغییرات را به‌صورت کنترل‌شده مدیریت کند.

یک فرآیند ساده را می‌توان این‌گونه خلاصه کرد:

Change Request

↓

Impact Analysis

↓

Approval

↓

SRS Update

↓

Test Artefact Update

↓

Regression Testing

در این میان، Traceability نقش مهمی دارد؛ چون به تیم کمک می‌کند تأثیر تغییر یک Requirement را روی Test Caseها و سایر Artefactها بهتر پیدا کند.

از دید تستر نیز یک اصل مهم وجود دارد:

قبل از گزارش Fail شدن یک تست، مطمئن شو که Test Case بر اساس آخرین نسخه معتبر Requirement نوشته شده است.

۱۴. اشتباهات رایج در نوشتن SRS

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

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

مشکل زمانی ایجاد می‌شود که Requirementها:

• مبهم باشند،
• قابل تست نباشند،
• با یکدیگر تناقض داشته باشند،
• اطلاعات مهمی را جا انداخته باشند،
• یا بیش از حد وارد جزئیات Implementation شده باشند.

از دید تستر، کیفیت SRS اهمیت زیادی دارد؛ چون Requirement یکی از مهم‌ترین ورودی‌های Test Analysis و Test Design است.

۱. استفاده از Requirementهای مبهم

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

مثلاً:

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

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

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

مشکل این Requirementها چیست؟

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

برای مثال:

• «سریع» یعنی چند ثانیه؟
• «امن» یعنی چه سطحی از امنیت؟
• «مناسب» بر چه اساسی سنجیده می‌شود؟

Requirement خوب باید تا حد امکان شفاف و قابل ارزیابی باشد.

مثلاً:

سیستم باید ۹۵ درصد درخواست‌های جستجو را در شرایط بار تعریف‌شده در کمتر از ۲ ثانیه پاسخ دهد.

حالا معیار مشخص‌تری داریم.

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

کلماتی مانند:

• سریع
• آسان
• مناسب
• کاربرپسند
• بهینه
• امن
• قابل اعتماد
• در اسرع وقت
• حجم بالا
• تعداد زیاد

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

مثلاً:

❌ سیستم باید تعداد زیادی کاربر را پشتیبانی کند.

بهتر:

سیستم باید در شرایط بار تعریف‌شده از حداقل ۵۰۰۰ کاربر هم‌زمان پشتیبانی کند.

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

۳. مخلوط کردن Requirement با راه‌حل فنی

یکی دیگر از اشتباهات رایج این است که Requirement به جای بیان نیاز مورد انتظار، نحوه پیاده‌سازی را تعیین کند.

مثلاً:

سیستم باید با استفاده از Redis Cache و الگوریتم X اطلاعات را ذخیره کند.

اگر استفاده از این فناوری واقعاً یک Constraint یا الزام معماری نباشد، ممکن است این Requirement بیش از حد وارد جزئیات Solution شده باشد.

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

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

سپس تیم فنی درباره راهکار مناسب تصمیم بگیرد.

البته اگر فناوری خاصی واقعاً یک Constraint باشد، ذکر آن در مستندات می‌تواند کاملاً منطقی باشد.

پس مسئله، «هرگز نام فناوری را در SRS نیاورید» نیست؛ مسئله این است که نباید بدون دلیل، Requirement را با Implementation یکی کنیم.

۴. ناقص بودن Requirement

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

مثلاً:

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

اما سؤال‌های زیادی باقی می‌ماند:

• چه روش‌های پرداختی؟
• در صورت موفق بودن پرداخت چه اتفاقی می‌افتد؟
• در صورت شکست چه؟
• اگر درگاه Timeout شود چه؟
• اگر کاربر دوبار روی پرداخت کلیک کند چه؟
• چه زمانی سفارش Paid می‌شود؟
• اگر پرداخت موفق باشد اما پاسخ به سیستم نرسد چه؟

هرچه Requirement پیچیده‌تر باشد، نیاز به مشخص کردن شرایط و رفتارهای مختلف بیشتر می‌شود.

۵. نادیده گرفتن Exception و Negative Flow

گاهی SRS فقط Happy Path را توصیف می‌کند.

مثلاً:

کاربر رمز صحیح را وارد می‌کند و وارد سیستم می‌شود.

اما سیستم فقط در شرایط ایده‌آل کار نمی‌کند.

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

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

این موارد ممکن است در Requirement، Business Rule یا سایر مستندات مرتبط مشخص شوند.

از دید تستر، این بخش اهمیت زیادی دارد، زیرا بسیاری از Test Scenarioهای منفی از همین شرایط استخراج می‌شوند.

۶. تناقض بین Requirementها

تصور کنید در یک قسمت SRS نوشته شده:

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

اما در بخش دیگری آمده:

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

حالا سؤال این است:

سفارش تأییدشده اما ارسال‌نشده قابل لغو است یا خیر؟

این یک Requirement Conflict است.

چنین تناقض‌هایی می‌توانند برای Developer و Tester مشکلات جدی ایجاد کنند.

بنابراین Requirementها باید در Review بررسی شوند تا:

Consistent باشند.

یعنی با یکدیگر تناقض نداشته باشند.

۷. تکرار یک Requirement در چند جای SRS

فرض کنید یک Rule در پنج قسمت مختلف SRS نوشته شده است:

مشتری VIP باید ۱۰٪ تخفیف دریافت کند.

بعداً مقدار تخفیف از ۱۰٪ به ۱۵٪ تغییر می‌کند.

اگر فقط یکی از پنج مورد اصلاح شود، SRS دچار تناقض می‌شود.

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

BR-DIS-001

و در Requirementهای مختلف به آن ارجاع داد.

این موضوع ارتباط مستقیمی با Traceability دارد.

۸. Requirement بدون شناسه

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

مثلاً:

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

بهتر است داشته باشیم:

FR-ORD-010: سیستم باید امکان لغو سفارش را برای مشتری در شرایط مجاز فراهم کند.

حالا می‌توان به آن در Test Case یا Defect ارجاع داد.

مثلاً:

TC-ORD-022 → FR-ORD-010

این ارتباط در Traceability بسیار ارزشمند است.

۹. Requirementهای غیرقابل تست

یکی از مهم‌ترین ویژگی‌های Requirement خوب این است که بتوانیم مشخص کنیم:

آیا Requirement تحقق یافته است یا خیر؟

مثلاً:

❌ سیستم باید تجربه کاربری بسیار خوبی ارائه دهد.

چگونه آن را Pass یا Fail کنیم؟

اما:

حداقل ۹۰٪ کاربران شرکت‌کننده در آزمون Usability باید بتوانند فرآیند ثبت سفارش را بدون دریافت راهنمایی تکمیل کنند.

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

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

۱۰. استفاده از چند Requirement در یک جمله

گاهی چند نیاز متفاوت در یک جمله قرار می‌گیرند.

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

این جمله احتمالاً شامل چند Requirement مستقل است.

بهتر است آن‌ها را جدا کنیم:

• FR-001: سیستم باید کاربر را احراز هویت کند.
• FR-002: سیستم باید اطلاعات مورد نیاز کاربر را ذخیره کند.
• FR-003: سیستم باید امکان پرداخت را فراهم کند.
• FR-004: سیستم باید پس از پرداخت موفق پیام تأیید ارسال کند.

این کار Traceability و Test Design را نیز ساده‌تر می‌کند.

۱۱. مشخص نبودن Scope

یک SRS خوب فقط نمی‌گوید:

چه چیزی باید ساخته شود؟

گاهی لازم است مشخص کند:

چه چیزی جزو محدوده این سیستم نیست؟

In Scope

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

Out of Scope

• مدیریت حمل‌ونقل توسط شرکت ثالث
• سیستم حسابداری سازمان

این تفکیک می‌تواند از Scope Creep جلوگیری کند.

همچنین برای تستر بسیار مهم است؛ زیرا کمک می‌کند بداند:

چه چیزی باید تست شود و چه چیزی خارج از محدوده تست است؟

۱۲. نادیده گرفتن Non-Functional Requirements

گاهی تیم Requirementها را فقط به قابلیت‌های سیستم محدود می‌کند:

• Login
• Search
• Checkout
• Payment

اما Requirementهایی مانند:

• Performance
• Security
• Availability
• Compatibility
• Reliability

فراموش می‌شوند.

در نتیجه ممکن است سیستم از نظر Functional Testing موفق باشد اما در شرایط واقعی مشکل داشته باشد.

بنابراین SRS باید در صورت نیاز، Non-Functional Requirements مناسب را نیز مشخص کند.

۱۳. استفاده از Requirementهای غیرقابل اولویت‌بندی

همه Requirementها اهمیت یکسانی ندارند.

مثلاً:

ورود کاربر

ممکن است Critical باشد.

در حالی که:

تغییر تصویر پروفایل

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

اگر Priority مشخص نباشد، در شرایط کمبود زمان تصمیم‌گیری دشوارتر می‌شود.

می‌توان از معیارهایی مانند:

• Critical
• High
• Medium
• Low

استفاده کرد.

روش دقیق اولویت‌بندی به فرآیند سازمان بستگی دارد.

۱۴. نادیده گرفتن وابستگی بین Requirementها

گاهی یک Requirement به Requirement دیگری وابسته است.

مثلاً:

FR-ORD-005: سیستم باید امکان ثبت سفارش را فراهم کند.

ممکن است وابسته باشد به:

FR-PAY-002: سیستم باید امکان پرداخت سفارش را فراهم کند.

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

ثبت وابستگی‌ها در پروژه‌های بزرگ می‌تواند به برنامه‌ریزی، Impact Analysis و تست کمک کند.

۱۵. نادیده گرفتن داده‌های ورودی و شرایط مرزی

Requirement گاهی رفتار اصلی را مشخص می‌کند اما محدوده داده‌ها را مشخص نمی‌کند.

مثلاً:

کاربر باید بتواند سن خود را وارد کند.

اما:

• حداقل سن؟
• حداکثر سن؟
• عدد صحیح؟
• مقدار خالی؟
• مقدار منفی؟
• مقدار اعشاری؟

مشخص نیست.

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

این اطلاعات بعدها به طراحی Test Data و Boundary Value Test کمک می‌کنند.

۱۶. نوشتن Requirement با چند تفسیر ممکن

مثلاً:

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

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

بهتر است:

سفارش‌های انتخاب‌شده برای Express Delivery باید حداکثر تا ۲۴ ساعت پس از تأیید پرداخت تحویل شرکت حمل‌ونقل شوند.

اکنون Requirement بسیار مشخص‌تر است.

۱۷. نادیده گرفتن External Interfaceها

برخی سیستم‌ها با سرویس‌های خارجی ارتباط دارند:

• Payment Gateway
• SMS Provider
• Email Service
• Third-Party API
• Identity Provider

اگر این Interfaceها روی رفتار سیستم تأثیر دارند، باید Requirementهای مرتبط با آن‌ها مشخص باشند.

مثلاً:

پس از دریافت پاسخ موفق از Payment Gateway، سیستم باید وضعیت پرداخت را به‌روزرسانی کند.

یا:

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

این موضوع برای طراحی Integration Test نیز اهمیت دارد.

۱۸. نادیده گرفتن شرایط خطا

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

مثلاً:

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

اما اگر سرویس در دسترس نباشد چه؟

اگر Timeout رخ دهد چه؟

اگر پاسخ نامعتبر باشد چه؟

اگر سرویس اطلاعات ناقص برگرداند چه؟

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

۱۹. تغییر Requirement بدون به‌روزرسانی Test Artefactها

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

فرض کنیم Requirement تغییر کرده، اما:

• Test Case همان قبلی مانده.
• RTM به‌روزرسانی نشده.
• Automation تغییر نکرده.
• Test Data اصلاح نشده.

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

به همین دلیل تغییر Requirement باید با Traceability و Change Management همراه باشد.

۲۰. نوشتن SRS بیش از حد طولانی و غیرضروری

یک SRS خوب الزاماً یک SRS بسیار طولانی نیست.

اگر Requirementها در میان صدها صفحه متن غیرضروری گم شوند، استفاده از سند دشوار می‌شود.

هدف SRS این نیست که:

«هر چیزی که درباره محصول می‌دانیم» را در خود جای دهد.

هدف این است که:

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

بنابراین باید بین Completeness و Unnecessary Detail تعادل برقرار کرد.

یک SRS خوب چه ویژگی‌هایی دارد؟

با جمع‌بندی اشتباهات بالا می‌توان گفت یک Requirement خوب باید تا حد امکان:

• Clear — واضح باشد.
• Unambiguous — بدون ابهام باشد.
• Complete — کامل باشد.
• Consistent — با سایر Requirementها سازگار باشد.
• Testable / Verifiable — قابل ارزیابی باشد.
• Traceable — قابل ردیابی باشد.
• Feasible — قابل تحقق باشد.
• Prioritized — در صورت نیاز اولویت داشته باشد.
• Identifiable — شناسه مشخص داشته باشد.

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

یک مثال: Requirement بد در مقابل Requirement بهتر

❌ Requirement ضعیف

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

مشکلات:

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

✅ Requirement بهتر

FR-PAY-001: سیستم باید امکان پرداخت سفارش از طریق درگاه پرداخت مورد تأیید سازمان را فراهم کند.

NFR-PAY-001: سیستم باید نتیجه درخواست پرداخت را در بازه زمانی تعریف‌شده پردازش کند.

BR-PAY-001: سفارش تنها پس از دریافت پاسخ موفق از سرویس پرداخت می‌تواند به وضعیت «پرداخت‌شده» تغییر کند.

حالا سه جنبه از نیازمندی جدا شده‌اند:

• Functional Requirement
• Non-Functional Requirement
• Business Rule

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

نکته مهم برای تستر: SRS را فقط برای پیدا کردن Test Case نخوانید

یک تستر حرفه‌ای هنگام Review کردن SRS فقط به این فکر نمی‌کند که:

«از این Requirement چه Test Caseای بنویسم؟»

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

• آیا Requirement واضح است؟
• آیا چیزی کم دارد؟
• آیا قابل تست است؟
• آیا Exceptionها مشخص شده‌اند؟
• آیا Business Ruleهای مرتبط وجود دارند؟
• آیا Requirement با Requirementهای دیگر تناقض دارد؟
• آیا Requirement شناسه دارد؟
• آیا معیار پذیرش مشخص است؟
• آیا Requirement به نیاز کسب‌وکار قابل ردیابی است؟

این نوع نگاه همان چیزی است که Requirement Review را برای تستر ارزشمند می‌کند.

جمع‌بندی

بسیاری از مشکلات تست از مرحله Test Execution شروع نمی‌شوند؛ بلکه ریشه آن‌ها می‌تواند در Requirement ضعیف باشد.

یک Requirement مبهم می‌تواند باعث شود:

Requirement مبهم → برداشت متفاوت → Implementation متفاوت → Test Failure / Defect / Rework

بنابراین یکی از مهارت‌های مهم تستر این است که بتواند Requirementها را تحلیل و Review کند و ابهام‌ها و نقص‌های آن‌ها را پیش از اجرای تست شناسایی کند.

۱۵. نمونه SRS واقعی؛ از Business Need تا Requirement و Test

تا اینجا درباره ساختار SRS، انواع Requirement، Business Rule، Traceability و مدیریت تغییرات صحبت کردیم. اما برای اینکه تصویر کامل‌تری از سند نیازمندی نرم‌افزار داشته باشیم، بهتر است همه این مفاهیم را در یک مثال کنار هم ببینیم.

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

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

۱۵.۱. معرفی سیستم

فرض کنید یک شرکت قصد دارد فروشگاه اینترنتی خود را راه‌اندازی کند.

کاربر باید بتواند:

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

در کنار این قابلیت‌ها، سیستم باید الزامات مشخصی در زمینه Performance، Security و Availability نیز داشته باشد.

۱۵.۲. Business Need

قبل از نوشتن Requirementهای نرم‌افزار، باید بدانیم چرا این سیستم ساخته می‌شود؟

یک Business Need ساده می‌تواند این باشد:

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

این جمله هنوز Requirement فنی یا Functional Requirement نیست.

بلکه نیاز کسب‌وکار را بیان می‌کند.

۱۵.۳. Scope

در SRS باید مشخص شود سیستم دقیقاً چه بخش‌هایی را پوشش می‌دهد.

In Scope

در محدوده این سیستم:

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

Out of Scope

در این پروژه:

• مدیریت انبار فیزیکی
• سیستم حسابداری سازمان
• مدیریت ناوگان حمل‌ونقل
• پنل داخلی شرکت حمل‌ونقل

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

۱۵.۴. Actors

برای این سیستم چند Actor اصلی داریم:

Actor	نقش
Customer	خرید و مدیریت سفارش
Admin	مدیریت محصولات و سفارش‌ها
Payment Gateway	پردازش پرداخت
Notification Service	ارسال پیام و Notification

در این مقاله وارد جزئیات Use Case نمی‌شویم؛ چون Use Case خودش موضوعی مستقل است و بهتر است در مقاله تخصصی مربوط به آن بررسی شود.

۱۵.۵. Functional Requirements

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

FR-AUTH-001

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

FR-AUTH-002

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

FR-PROD-001

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

FR-CART-001

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

FR-ORD-001

سیستم باید پس از تأیید اطلاعات سفارش و پرداخت موفق، سفارش را ثبت کند.

FR-ORD-002

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

FR-ORD-003

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

در اینجا Requirementها به‌صورت شناسه‌دار تعریف شده‌اند تا بعداً بتوانیم آن‌ها را در Test Case، Defect و Traceability دنبال کنیم.

۱۵.۶. Non-Functional Requirements

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

NFR-PERF-001

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

NFR-SEC-001

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

NFR-AVL-001

سامانه باید حداقل ۹۹.۹ درصد در طول هر ماه در دسترس باشد، به استثنای زمان‌های Maintenance برنامه‌ریزی‌شده.

NFR-COMP-001

سامانه وب باید در مرورگرهای پشتیبانی‌شده سازمان عملکرد مورد انتظار را ارائه دهد.

دقت کنید که اینجا صرفاً نگفتیم:

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

بلکه تا حد امکان معیار قابل ارزیابی تعریف کردیم.

۱۵.۷. Business Rules

حالا قوانین کسب‌وکار را مشخص می‌کنیم.

BR-ORD-001

سفارش پس از تغییر وضعیت به «در حال ارسال» قابل لغو نیست.

BR-ORD-002

مشتری فقط در صورت وجود موجودی کافی می‌تواند سفارش را ثبت کند.

BR-PAY-001

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

BR-DIS-001

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

این قوانین می‌توانند در SRS ثبت شوند یا در مستند جداگانه Business Rules نگهداری شوند و SRS به آن‌ها ارجاع دهد.

۱۵.۸. Acceptance Criteria

برای برخی Requirementها لازم است شرایط پذیرش نیز مشخص باشد.

مثلاً برای:

FR-ORD-003: سیستم باید به کاربر اجازه دهد سفارش را در وضعیت‌های مجاز لغو کند.

می‌توان Acceptance Criteria زیر را تعریف کرد:

AC-ORD-001

اگر سفارش هنوز ارسال نشده باشد، کاربر باید بتواند آن را لغو کند.

AC-ORD-002

اگر سفارش در وضعیت «در حال ارسال» باشد، عملیات لغو نباید امکان‌پذیر باشد.

AC-ORD-003

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

AC-ORD-004

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

در این مقاله وارد بحث کامل Acceptance Criteria نمی‌شویم؛ چون این موضوع خودش می‌تواند یک مقاله تخصصی مستقل باشد.

۱۵.۹. Exceptionها و شرایط خاص

یک SRS خوب فقط Happy Path را مشخص نمی‌کند.

مثلاً در فرآیند پرداخت باید شرایطی مانند این‌ها نیز در نظر گرفته شوند:

حالت عادی

پرداخت موفق است.

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

پرداخت ناموفق

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

Timeout

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

دوبار ارسال درخواست

سیستم نباید باعث ایجاد دو سفارش یا دو تراکنش ناخواسته برای یک درخواست پرداخت شود.

این موارد می‌توانند در Requirement، Business Rule یا مستندات مرتبط تعریف شوند؛ بسته به ساختار پروژه.

۱۵.۱۰. Requirementهای مرتبط با پرداخت

حالا می‌توانیم یک بخش کوچک از SRS را به‌صورت یکپارچه ببینیم.

FR-PAY-001

سیستم باید امکان پرداخت آنلاین سفارش را از طریق Payment Gateway مورد تأیید سازمان فراهم کند.

FR-PAY-002

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

BR-PAY-001

تنها پرداخت‌هایی که نتیجه آن‌ها از سوی Payment Gateway موفق اعلام شده است، باید به‌عنوان پرداخت موفق ثبت شوند.

NFR-PAY-001

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

حالا Requirement، Business Rule و Non-Functional Requirement در کنار هم قرار گرفته‌اند.

۱۵.۱۱. تبدیل Requirement به Test Scenario

یکی از مهم‌ترین کاربردهای SRS برای تستر، تبدیل Requirement به شرایط قابل تست است.

فرض کنیم:

FR-PAY-002: سیستم باید نتیجه تراکنش پرداخت را دریافت و وضعیت سفارش را بر اساس آن به‌روزرسانی کند.

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

Scenario 1

پرداخت موفق

Expected:

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

Scenario 2

پرداخت ناموفق

Expected:

سفارش Paid نشود.

Scenario 3

Timeout

Expected:

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

Scenario 4

پاسخ نامعتبر

Expected:

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

اینجا می‌بینیم که SRS مستقیماً روی Test Analysis تأثیر می‌گذارد.

۱۵.۱۲. Requirement → Test Case

حالا یکی از Scenarioها را به Test Case تبدیل کنیم.

Requirement

FR-PAY-002

Test Case

TC-PAY-001

Title: بررسی ثبت سفارش پس از پرداخت موفق

Precondition:

کاربر یک سفارش معتبر ایجاد کرده است.

Test Data:

یک سفارش با مبلغ مشخص و اطلاعات پرداخت معتبر.

Steps:

1. کاربر وارد صفحه پرداخت شود.
2. پرداخت موفق انجام شود.
3. نتیجه پرداخت دریافت شود.
4. وضعیت سفارش بررسی شود.

Expected Result:

سفارش باید با وضعیت Paid ثبت شود.

Requirement: FR-PAY-002

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

۱۵.۱۳. Traceability Matrix برای همین مثال

می‌توانیم یک RTM ساده ایجاد کنیم:

Requirement	Test Case	نتیجه
FR-AUTH-001	TC-AUTH-001	Pass
FR-AUTH-002	TC-AUTH-002	Pass
FR-PROD-001	TC-PROD-001	Pass
FR-CART-001	TC-CART-001	Pass
FR-ORD-001	TC-ORD-001	Pass
FR-PAY-001	TC-PAY-001	Pass
FR-PAY-002	TC-PAY-002	Fail
FR-ORD-003	TC-ORD-003	Not Run

حالا تیم می‌تواند خیلی سریع ببیند:

• کدام Requirementها تست شده‌اند.
• کدام Test Caseها Fail شده‌اند.
• کدام Requirement هنوز تست نشده است.

۱۵.۱۴. ارتباط Defect با Requirement

فرض کنیم:

TC-PAY-002 Fail شده است.

مشکل:

پس از پرداخت موفق، سفارش همچنان Pending باقی می‌ماند.

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

DEF-1024
    ↓
TC-PAY-002
    ↓
FR-PAY-002

این ارتباط باعث می‌شود مشخص باشد Bug دقیقاً کدام Requirement را تحت تأثیر قرار داده است.

۱۵.۱۵. اگر Requirement تغییر کند چه؟

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

FR-AUTH-003: پس از پنج تلاش ناموفق، حساب برای ۱۵ دقیقه محدود شود.

اما بعداً تغییر می‌کند:

پس از سه تلاش ناموفق، حساب برای ۳۰ دقیقه محدود شود.

حالا تستر با استفاده از Traceability می‌تواند پیدا کند:

• Test Caseهای مرتبط
• Test Data
• Automation Script
• Business Ruleهای مرتبط
• Regression Scope

و آن‌ها را بررسی و در صورت نیاز به‌روزرسانی کند.

این همان ارتباطی است که در بخش Change Management درباره آن صحبت کردیم.

۱۵.۱۶. تصویر کلی یک SRS در پروژه

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

Business Need
      ↓
    Scope
      ↓
Requirements
 ┌───────────────┐
 │ Functional    │
 │ Non-Functional│
 │ Business Rules│
 └───────────────┘
      ↓
Acceptance Criteria
      ↓
Test Scenarios
      ↓
Test Cases
      ↓
Test Execution
      ↓
Test Results
      ↓
Defects / Retest

و Traceability در تمام این مسیر ارتباط میان Artefactها را حفظ می‌کند.

۱۵.۱۷. این مثال چه چیزی را درباره SRS نشان می‌دهد؟

یک نکته بسیار مهم این است که SRS صرفاً مجموعه‌ای از جملات مانند:

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

نیست.

یک SRS خوب باید بتواند در حد مورد نیاز، تصویری روشن از نیازمندی‌های سیستم ایجاد کند.

یعنی مشخص شود:

• چه چیزی باید ساخته شود؟
• چه رفتارهایی انتظار می‌رود؟
• چه محدودیت‌هایی وجود دارد؟
• چه قوانین کسب‌وکاری باید رعایت شوند؟
• چه ویژگی‌های کیفی اهمیت دارند؟
• Requirementها چگونه شناسایی و ردیابی می‌شوند؟
• تغییرات چگونه مدیریت می‌شوند؟

از دید تستر نیز SRS باید بتواند مبنایی برای تحلیل و طراحی تست فراهم کند.

۱۵.۱۸. آیا این نمونه یک SRS کامل است؟

خیر.

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

در یک پروژه واقعی ممکن است بخش‌های بسیار بیشتری وجود داشته باشند، مانند:

• Introduction
• Purpose
• Product Scope
• Definitions
• References
• Overall Description
• System Context
• User Classes
• Functional Requirements
• Non-Functional Requirements
• External Interfaces
• Data Requirements
• Business Rules
• Constraints
• Assumptions
• Dependencies
• Acceptance Information
• Traceability

ساختار دقیق نیز به نوع پروژه، سازمان، صنعت و استاندارد مورد استفاده بستگی دارد.

بنابراین نباید انتظار داشته باشیم یک Template ثابت برای تمام SRSها وجود داشته باشد.

از این مثال چه چیزی برای تستر مهم‌تر است؟

تستر نباید SRS را فقط برای پیدا کردن چند Test Case بخواند.

باید بتواند زنجیره زیر را در Requirementها پیدا کند:

Business Need → Requirement → Business Rule → Acceptance Criteria → Test Condition → Test Case

و سپس بررسی کند:

آیا چیزی در این زنجیره مبهم، ناقص، متناقض یا غیرقابل تست است؟

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

جمع‌بندی

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

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

Functional Requirements

Non-Functional Requirements

Business Rules

Acceptance Criteria

تبدیل شود و سپس این اطلاعات می‌توانند مبنای طراحی:

Test Scenario → Test Case → Test Execution

قرار بگیرند.

در این میان Traceability کمک می‌کند ارتباط این Artefactها حفظ شود و در صورت تغییر Requirement بتوانیم تأثیر آن را سریع‌تر پیدا کنیم.

بنابراین ارزش SRS فقط در «مستندسازی» نیست؛ بلکه در ایجاد یک مرجع مشترک و قابل اتکا برای تیم‌های Business، Development و Testing است.

۱۶. SRS در Agile و Waterfall چه تفاوتی دارد؟

یکی از سؤال‌هایی که بعد از آشنایی با SRS مطرح می‌شود این است:

آیا SRS فقط برای پروژه‌های سنتی مثل Waterfall است؟ در پروژه‌های Agile چه اتفاقی برای سند نیازمندی نرم‌افزار می‌افتد؟

پاسخ کوتاه این است:

خیر؛ Agile به معنی حذف Requirement و مستندات نیازمندی نیست.

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

در پروژه‌های سنتی ممکن است یک SRS نسبتاً جامع در ابتدای پروژه تهیه شود، در حالی که در Agile نیازمندی‌ها معمولاً به‌صورت تدریجی و در طول Iterationها تکمیل و اصلاح می‌شوند.

SRS در رویکرد Waterfall

در یک پروژه Waterfall، معمولاً بخش قابل‌توجهی از Requirementها قبل از شروع Development تحلیل و مستند می‌شوند.

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

Business Requirements
        ↓
Requirements Analysis
        ↓
SRS
        ↓
System Design
        ↓
Development
        ↓
Testing
        ↓
Release

در این رویکرد، SRS می‌تواند نقش یک مرجع رسمی و نسبتاً جامع را داشته باشد.

برای مثال، قبل از شروع توسعه ممکن است Requirementهای مربوط به:

• Login
• Registration
• Search
• Checkout
• Payment
• Reporting
• Security
• Performance

در SRS مشخص شده باشند.

سپس تیم Development و Testing بر اساس نسخه تأییدشده Requirementها فعالیت خود را انجام می‌دهند.

SRS در Agile

در Agile شرایط متفاوت است.

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

محصول در طول زمان تکامل پیدا می‌کند و Requirementها نیز ممکن است با توجه به:

• Feedback کاربران
• تغییر اولویت کسب‌وکار
• نتایج Sprint
• تغییر بازار
• تغییر قوانین
• محدودیت‌های فنی

تغییر کنند.

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

Product Goal
     ↓
Product Backlog
     ↓
Epic / User Story
     ↓
Acceptance Criteria
     ↓
Development
     ↓
Testing
     ↓
Feedback
     ↓
Refinement
     ↓
Updated Requirements

در اینجا Requirementها معمولاً تدریجی و Iterative تکامل پیدا می‌کنند.

آیا در Agile اصلاً SRS نداریم؟

این تصور اشتباه است.

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

ممکن است یک سازمان Agile:

• SRS داشته باشد.
• مستندات Requirement داشته باشد.
• User Story داشته باشد.
• Acceptance Criteria داشته باشد.
• Business Rule داشته باشد.
• مستندات Non-Functional Requirement داشته باشد.

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

بنابراین:

Agile با SRS ناسازگار نیست؛ Agile بیشتر روی نحوه مدیریت و تکامل Requirementها تأکید دارد.

آیا User Story جای SRS را گرفته است؟

نه به‌صورت مطلق.

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

User Story و SRS دقیقاً یک چیز نیستند.

برای مثال:

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

این User Story یک نیاز را از دید کاربر بیان می‌کند.

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

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

این اطلاعات ممکن است در:

• Acceptance Criteria
• Business Rules
• Requirement Documentation
• Technical Documentation

ثبت شوند.

بنابراین:

یک User Story الزاماً تمام اطلاعاتی را که یک سیستم برای پیاده‌سازی و تست نیاز دارد در خود جای نمی‌دهد.

SRS و User Story می‌توانند در کنار هم باشند

فرض کنیم در یک فروشگاه اینترنتی Requirement زیر وجود دارد:

FR-ORD-003

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

در یک تیم Agile ممکن است این Requirement به یک یا چند User Story تبدیل شود.

مثلاً:

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

و برای Story، Acceptance Criteria تعریف شود.

در نتیجه ممکن است ساختار کلی چنین باشد:

High-Level Requirement
        ↓
User Story
        ↓
Acceptance Criteria
        ↓
Development
        ↓
Testing

در این مدل، Requirement سطح بالاتر می‌تواند در یک SRS یا Requirement Document نگهداری شود.

تفاوت اصلی SRS در Agile و Waterfall چیست؟

بهتر است تفاوت را در چند محور ببینیم:

موضوع	Waterfall	Agile
زمان مستندسازی	معمولاً زودتر	تدریجی
تغییر Requirement	کنترل‌شده و رسمی‌تر	مکررتر و Iterative
شکل مستندات	ممکن است SRS جامع باشد	ممکن است بین چند Artefact توزیع شود
User Story	معمولاً نقش مرکزی ندارد	معمولاً مهم است
Acceptance Criteria	ممکن است وجود داشته باشد	معمولاً نقش مهمی دارد
Traceability	معمولاً رسمی‌تر	ممکن است در ابزارها و Backlog مدیریت شود
بازخورد	معمولاً دیرتر	مستمرتر
جزئیات اولیه	معمولاً بیشتر	معمولاً کمتر و تدریجی

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

همچنین Traceability در Agile نیز می‌تواند وجود داشته باشد؛ فقط ممکن است به جای یک RTM رسمی، از ارتباط بین Epic، User Story، Acceptance Criteria، Test Case و Defect در ابزارهای مدیریت پروژه و تست استفاده شود.

یک تفاوت مهم: Big Requirements Up Front

در پروژه‌های سنتی ممکن است تلاش شود بخش زیادی از Requirementها قبل از Development مشخص شوند.

اما در Agile معمولاً فرض بر این نیست که:

«از روز اول همه چیز را دقیقاً می‌دانیم.»

در عوض:

Requirementها در طول توسعه و دریافت Feedback تکامل پیدا می‌کنند.

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

آیا در Agile باید SRS را دائماً تغییر داد؟

اگر سازمان واقعاً از SRS به‌عنوان سند رسمی Requirement استفاده می‌کند، تغییرات مهم باید در آن منعکس شوند.

اما لازم نیست هر تغییر کوچک در هر Conversation یا هر تصمیم جزئی، باعث بازنویسی یک سند بزرگ شود.

در Agile معمولاً تلاش می‌شود مستندات:

به‌اندازه کافی و نه بیش از حد

باشند.

یعنی:

Just Enough Documentation

هدف مستندسازی این نیست که تیم دائماً درگیر به‌روزرسانی اسناد باشد؛ هدف این است که اطلاعات مهم و مورد نیاز، قابل اتکا و در دسترس باشند.

نقش تستر در SRS در پروژه Agile

در Agile، تستر همچنان باید Requirement را تحلیل کند.

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

مثلاً:

Product Goal
     ↓
Epic
     ↓
User Story
     ↓
Acceptance Criteria
     ↓
Business Rules
     ↓
Test Conditions
     ↓
Test Cases

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

«چون SRS نداریم، پس Requirement Analysis نداریم.»

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

اگر در Agile SRS نداریم، تستر Requirement را از کجا پیدا کند؟

این موضوع به فرآیند سازمان بستگی دارد.

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

• Product Backlog
• User Story
• Acceptance Criteria
• Business Rules
• Product Requirements
• Requirement Document
• Design Documentation
• API Documentation
• Specificationهای مرتبط
• تصمیم‌های ثبت‌شده تیم

اما یک نکته مهم وجود دارد:

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

تستر باید بداند Source of Truth یا مرجع معتبر Requirement در پروژه چیست.

Source of Truth در Requirement چیست؟

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

در SRS نوشته شده:

حداکثر ۵ تلاش ناموفق مجاز است.

در User Story نوشته شده:

پس از ۳ تلاش ناموفق، حساب محدود شود.

و یک نفر در جلسه گفته:

فعلاً همان ۵ تلاش را نگه می‌داریم.

تستر با یک Requirement Conflict مواجه شده است.

نباید خودش یکی را انتخاب کند.

باید مشخص شود:

کدام منبع، نسخه معتبر و تأییدشده Requirement است؟

این موضوع به فرآیند Requirement Management سازمان مربوط می‌شود.

SRS و Agile Testing

در Agile، تستر معمولاً خیلی زودتر از مرحله Execution با Requirement درگیر می‌شود.

مثلاً قبل از شروع توسعه یک User Story، تستر می‌تواند سؤال‌هایی مانند این مطرح کند:

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

این فعالیت‌ها می‌توانند باعث شوند ابهام Requirement قبل از Coding شناسایی شود.

این همان مفهوم Shift Left است که در آن فعالیت‌های تست و کیفیت به مراحل ابتدایی‌تر منتقل می‌شوند.

آیا SRS در Agile می‌تواند سطح بالا باشد؟

بله.

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

Product Requirements / SRS
          ↓
        Epic
          ↓
     User Stories
          ↓
Acceptance Criteria
          ↓
       Test Cases

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

SRS در پروژه‌های Hybrid

در دنیای واقعی، همه پروژه‌ها کاملاً Waterfall یا کاملاً Agile نیستند.

بسیاری از سازمان‌ها رویکرد Hybrid دارند.

مثلاً:

• Requirementهای سطح بالا در یک SRS رسمی ثبت می‌شوند.
• Featureها در Product Backlog مدیریت می‌شوند.
• User Storyها در Sprintها توسعه پیدا می‌کنند.
• Acceptance Criteria برای هر Story تعریف می‌شود.
• Test Caseها در Test Management Tool نگهداری می‌شوند.

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

SRS Requirement
      ↓
Epic
      ↓
User Story
      ↓
Acceptance Criteria
      ↓
Test Case

این مدل برای پروژه‌های سازمانی و بزرگ می‌تواند کاملاً منطقی باشد.

یک مثال واقعی‌تر

فرض کنیم در SRS فروشگاه اینترنتی نوشته شده:

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

این Requirement در سطح بالاست.

در Agile ممکن است آن را به چند Story تقسیم کنیم:

Story 1

پرداخت با درگاه بانکی

Story 2

مدیریت پرداخت ناموفق

Story 3

مدیریت Timeout

Story 4

ثبت نتیجه تراکنش

Story 5

Refund

هر Story می‌تواند Acceptance Criteria مخصوص خود را داشته باشد.

در نهایت Test Caseهای مختلف به این Storyها و Requirementهای بالاتر Trace می‌شوند.

SRS می‌تواند دید کلان را حفظ کند، در حالی که Agile Artefactها جزئیات اجرای تدریجی Requirement را مدیریت می‌کنند.

یک نکته مهم برای تستر

اگر در یک آگهی شغلی نوشته شده:

«آشنایی با SRS و Requirement Analysis»

این الزاماً به این معنی نیست که باید در یک پروژه Waterfall با فایل SRS صدصفحه‌ای کار کرده باشید.

ممکن است در یک پروژه Agile باشید و همچنان نیاز باشد بتوانید:

• Requirement را تحلیل کنید.
• ابهام‌ها را پیدا کنید.
• Acceptance Criteria را بررسی کنید.
• Requirement را به Test Condition تبدیل کنید.
• Traceability را برقرار کنید.
• تغییرات Requirement را تحلیل کنید.

بنابراین مهارت Requirement Analysis از خود فایل SRS مهم‌تر است.

SRS، Agile و مستندسازی؛ کدام بهتر است؟

سؤال درست این نیست که:

SRS بهتر است یا User Story؟

سؤال بهتر این است:

برای این پروژه چه سطح و چه نوع مستنداتی لازم است تا تیم بتواند Requirementها را به‌درستی درک، توسعه، تست و مدیریت کند؟

در یک پروژه ممکن است SRS جامع مناسب باشد.

در پروژه دیگری ممکن است ترکیبی از:

Product Requirements + User Stories + Acceptance Criteria + Business Rules

بهتر باشد.

و در یک پروژه بزرگ ممکن است همه این موارد در کنار هم استفاده شوند.

جمع‌بندی

SRS متعلق به Waterfall نیست.

در Agile نیز می‌توان SRS یا سایر مستندات Requirement را داشت؛ تفاوت اصلی در نحوه مدیریت و تکامل Requirementهاست.

در Waterfall ممکن است:

Requirementها → SRS جامع → Development → Testing

در Agile ممکن است:

Product Goal → Backlog → User Story → Acceptance Criteria → Development → Testing → Feedback

و در یک پروژه Hybrid ممکن است هر دو رویکرد در کنار هم استفاده شوند.

از دید تستر، نکته مهم این است که بتواند منبع معتبر Requirement را پیدا کند، آن را تحلیل کند و به شرایط قابل تست تبدیل کند؛ فارغ از اینکه Requirement در SRS، User Story یا ابزار دیگری ثبت شده باشد.

پس SRS یک قالب مستندسازی Requirement است؛ Requirement Analysis یک مهارت است که در هر رویکرد توسعه‌ای اهمیت دارد.

۱۷. SRS برای تستر نرم‌افزار چه کاربردی دارد؟

تا اینجا SRS را بیشتر از دید Requirements Engineering بررسی کردیم؛ اما برای یک تستر نرم‌افزار سؤال مهم‌تری وجود دارد:

من به‌عنوان تستر دقیقاً چه چیزی از SRS به دست می‌آورم؟

پاسخ این است که SRS یکی از مهم‌ترین منابع برای درک رفتار مورد انتظار سیستم است.

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

به همین دلیل، SRS برای تستر هم یک منبع طراحی تست است و هم یک منبع Review و تحلیل Requirement.

SRS چگونه وارد فعالیت تست می‌شود؟

اگر مسیر کلی را ساده کنیم:

SRS
 ↓
Requirement Analysis
 ↓
Test Conditions
 ↓
Test Scenarios
 ↓
Test Cases
 ↓
Test Execution
 ↓
Test Results

یعنی تستر ابتدا Requirement را می‌فهمد، سپس مشخص می‌کند:

چه چیزی باید تست شود؟

بعد:

چگونه باید تست شود؟

و در نهایت:

آیا رفتار واقعی سیستم با رفتار مورد انتظار مطابقت دارد؟

۱۷.۱. تستر از SRS چه اطلاعاتی استخراج می‌کند؟

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

برای مثال:

Functional Requirements

به تستر می‌گویند:

سیستم چه کاری باید انجام دهد؟

مثلاً:

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

Non-Functional Requirements

مشخص می‌کنند:

سیستم با چه ویژگی‌های کیفی باید کار کند؟

مثلاً:

۹۵٪ درخواست‌ها باید در کمتر از ۲ ثانیه پاسخ داده شوند.

Business Rules

مشخص می‌کنند:

چه قوانین کسب‌وکاری باید رعایت شوند؟

مثلاً:

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

Constraints

محدودیت‌های سیستم را مشخص می‌کنند.

مثلاً:

سیستم باید با مرورگرهای مشخصی سازگار باشد.

External Interfaces

نشان می‌دهند سیستم با چه سرویس‌هایی تعامل دارد.

مثلاً:

سیستم باید با Payment Gateway ارتباط برقرار کند.

تمام این اطلاعات می‌توانند روی Test Analysis و Test Design تأثیر بگذارند.

۱۷.۲. تستر هنگام خواندن SRS فقط به دنبال Test Case نیست

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

اما یک تستر حرفه‌ای ابتدا می‌پرسد:

آیا خود Requirement قابل تست و بدون ابهام است؟

مثلاً:

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

قبل از اینکه Test Case بنویسیم، باید سؤال کنیم:

سریع یعنی چقدر؟

پس ممکن است اولین فعالیت تستر اصلاً Test Case Design نباشد؛ بلکه Requirement Review باشد.

۱۷.۳. Requirement Review توسط تستر

تستر می‌تواند SRS را از نظر موارد مختلف بررسی کند.

آیا Requirement واضح است؟

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

آیا Requirement قابل تست است؟

❌ سیستم باید بسیار امن باشد.

آیا Requirement کامل است؟

اگر Login ناموفق باشد چه اتفاقی می‌افتد؟

آیا Requirement با Requirementهای دیگر سازگار است؟

آیا سفارش بعد از تأیید پرداخت قابل لغو است یا خیر؟

آیا Requirement شناسه دارد؟

FR-LOGIN-001

آیا Requirement قابل ردیابی است؟

FR-LOGIN-001 → TC-LOGIN-001

این فعالیت‌ها می‌توانند قبل از شروع Test Execution انجام شوند.

۱۷.۴. استخراج Test Condition از SRS

بعد از اینکه Requirement بررسی شد، تستر می‌تواند Test Conditionها را استخراج کند.

فرض کنیم Requirement این باشد:

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

از همین Requirement چند Test Condition استخراج می‌شود:

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

در این مرحله هنوز لزوماً Test Case کامل ننوشته‌ایم.

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

چه شرایطی باید مورد بررسی قرار بگیرد؟

۱۷.۵. تبدیل Requirement به Test Scenario

حالا Test Conditionها را می‌توان به Test Scenario تبدیل کرد.

Requirement

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

Test Scenario

بررسی محدود شدن حساب پس از پنج تلاش ناموفق ورود.

Scenario دیگر

بررسی عدم امکان ورود در دوره محدودیت.

Scenario دیگر

بررسی امکان ورود پس از پایان دوره محدودیت.

این روند باعث می‌شود Test Design بر اساس Requirement انجام شود، نه صرفاً بر اساس حدس تستر.

۱۷.۶. تبدیل Scenario به Test Case

حالا می‌توانیم یک Test Case طراحی کنیم.

TC-AUTH-005

عنوان:

بررسی محدود شدن حساب پس از پنج تلاش ناموفق

Precondition:

کاربر فعال است.

Steps:

1. اطلاعات ورود نامعتبر وارد شود.
2. این عملیات تا پنج بار تکرار شود.
3. تلاش ششم انجام شود.

Expected Result:

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

Requirement: FR-AUTH-003

اینجا مشخص است Test Case مستقیماً از Requirement تغذیه شده است.

۱۷.۷. SRS و Test Oracle

یکی از مفاهیم مهم در تست این است که تستر باید بداند:

Expected Result را از کجا تعیین می‌کنیم؟

در بسیاری از موارد، Requirement یا Specification یکی از منابع اصلی Test Oracle است.

مثلاً اگر Requirement می‌گوید:

پس از پرداخت موفق، وضعیت سفارش باید Paid شود.

تستر هنگام اجرای تست می‌تواند وضعیت واقعی را با وضعیت مورد انتظار مقایسه کند.

اگر سیستم وضعیت را Pending ثبت کند:

Actual Result ≠ Expected Result

در نتیجه یک Failure داریم که می‌تواند منجر به بررسی Defect شود.

بنابراین:

SRS → Expected Behavior → Test Oracle

یکی از ارتباط‌های مهم میان Requirement و Testing است.

۱۷.۸. SRS و تست‌های مثبت و منفی

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

فرض کنید:

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

Positive Test

سفارش در وضعیت مجاز است.

Expected: لغو موفق باشد.

Negative Test

سفارش در وضعیت Shipped است.

Expected: لغو مجاز نباشد.

این نکته مهم است:

Tester نباید فقط سناریوی موفق Requirement را تست کند.

باید شرایطی را که Requirement برای آن‌ها محدودیت تعیین کرده نیز بررسی کند.

۱۷.۹. SRS و Boundary Value

Requirementها گاهی محدوده مشخص می‌کنند.

مثلاً:

مبلغ سفارش باید بین ۱۰۰٬۰۰۰ تا ۱۰٬۰۰۰٬۰۰۰ تومان باشد.

این Requirement بلافاصله تست‌هایی در اطراف Boundary ایجاد می‌کند:

• ۹۹٬۹۹۹
• ۱۰۰٬۰۰۰
• ۱۰۰٬۰۰۱
• ۹٬۹۹۹٬۹۹۹
• ۱۰٬۰۰۰٬۰۰۰
• ۱۰٬۰۰۰٬۰۰۱

در اینجا Requirement مستقیماً به طراحی تست کمک کرده است.

البته Boundary Value Analysis یک تکنیک مستقل تست است و در این مقاله فقط رابطه آن با Requirement را می‌بینیم.

۱۷.۱۰. SRS و Equivalence Partitioning

فرض کنیم Requirement می‌گوید:

سن قابل قبول کاربر برای ثبت‌نام باید بین ۱۸ تا ۶۵ سال باشد.

می‌توانیم Domain را به گروه‌هایی تقسیم کنیم:

• کمتر از ۱۸
• ۱۸ تا ۶۵
• بیشتر از ۶۵

این اطلاعات از Requirement می‌آیند.

سپس تستر می‌تواند از Equivalence Partitioning برای انتخاب Test Data مناسب استفاده کند.

بنابراین:

Requirement مشخص می‌کند چه محدوده‌ای معتبر است؛ تکنیک تست مشخص می‌کند چگونه آن محدوده را به شکل مؤثرتری تست کنیم.

۱۷.۱۱. SRS و Non-Functional Testing

یکی از مهم‌ترین کاربردهای SRS این است که تستر متوجه شود فقط Functional Testing کافی نیست.

فرض کنیم در SRS آمده:

۹۵٪ درخواست‌های جستجو باید در کمتر از ۲ ثانیه پاسخ داده شوند.

این Requirement دیگر با یک Functional Test ساده قابل ارزیابی نیست.

تستر باید به سمت:

Performance Testing

برود.

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

Security Testing

وجود داشته باشد.

اگر Requirement مربوط به Compatibility باشد:

Compatibility Testing

اهمیت پیدا می‌کند.

پس SRS می‌تواند به تستر کمک کند نوع تست مورد نیاز را نیز شناسایی کند.

۱۷.۱۲. SRS و Test Coverage

یکی از سؤالات مهم تستر:

آیا همه Requirementهای مهم تست شده‌اند؟

با استفاده از Requirement ID و Traceability می‌توان Coverage را بررسی کرد.

Requirement	Test Coverage
FR-001	Covered
FR-002	Covered
FR-003	Not Covered
NFR-001	Covered

در اینجا مشخص است:

FR-003 هنوز Test Coverage ندارد.

البته Coverage صرفاً داشتن یک Test Case را نشان نمی‌دهد؛ کیفیت و عمق تست نیز مهم است.

۱۷.۱۳. SRS و Defect Reporting

فرض کنیم تستر یک Defect پیدا کرده است.

گزارش ضعیف:

پرداخت کار نمی‌کند.

گزارش بهتر:

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

اگر Requirement ID هم ثبت شود:

Requirement: FR-PAY-002

گزارش بسیار قابل‌ردیابی‌تر می‌شود.

در نتیجه Developer و سایر اعضای تیم راحت‌تر می‌توانند بررسی کنند:

رفتار فعلی دقیقاً با کدام Requirement مغایرت دارد؟

۱۷.۱۴. SRS و Regression Testing

وقتی Requirement تغییر می‌کند، تستر باید بررسی کند:

چه تست‌هایی باید دوباره اجرا شوند؟

مثلاً Requirement پرداخت تغییر کرده است.

Traceability می‌تواند Test Caseهای مرتبط را پیدا کند:

FR-PAY-002
    ↓
TC-PAY-001
TC-PAY-002
TC-PAY-003
    ↓
Regression Scope

اما تستر باید فراتر از ارتباط مستقیم نیز فکر کند.

ممکن است تغییر Payment روی:

• Order
• Invoice
• Notification
• Refund

تأثیر بگذارد.

بنابراین Traceability و Impact Analysis می‌توانند در تعیین Regression Scope کمک کنند.

جزئیات خود تست رگرسیون بهتر است در مقاله تخصصی آن بررسی شود.

۱۷.۱۵. SRS و Test Planning

SRS حتی قبل از نوشتن Test Case نیز می‌تواند روی Test Planning تأثیر بگذارد.

مثلاً اگر SRS نشان دهد سیستم دارای:

• Payment
• Security
• Performance
• External API

است، Test Plan باید این نیازها را در نظر بگیرد.

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

• Functional Testing
• Integration Testing
• Performance Testing
• Security Testing
• Compatibility Testing

انجام دهیم.

بنابراین:

SRS می‌تواند یکی از ورودی‌های مهم Test Planning باشد.

۱۷.۱۶. تستر چگونه یک SRS را Review کند؟

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

مرحله اول: درک Scope

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

سیستم چیست و چه چیزی خارج از Scope است؟

مرحله دوم: شناسایی Requirementها

Requirementهای Functional و Non-Functional را پیدا کن.

مرحله سوم: بررسی ابهام

به دنبال کلماتی مانند:

سریع، مناسب، آسان، زیاد، بهینه

مرحله چهارم: بررسی Completeness

ببین:

آیا شرایط خطا و Exceptionها نیز مشخص شده‌اند؟

مرحله پنجم: بررسی Consistency

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

مرحله ششم: بررسی Testability

از خودت بپرس:

آیا می‌توانم بر اساس این Requirement یک Pass/Fail مشخص تعیین کنم؟

مرحله هفتم: بررسی Traceability

ببین:

آیا Requirement شناسه دارد و می‌توان آن را به Test Artefactها متصل کرد؟

مرحله هشتم: استخراج Test Conditions

مشخص کن:

چه چیزهایی باید تست شوند؟

این روند می‌تواند قبل از Test Execution انجام شود.

۱۷.۱۷. آیا تستر می‌تواند Requirement را تغییر دهد؟

تستر معمولاً مالک Requirement نیست.

اما می‌تواند Issue یا Concern مربوط به Requirement را مطرح کند.

مثلاً:

Requirement مشخص نکرده است اگر Payment Gateway Timeout شود چه رفتاری باید رخ دهد.

تستر می‌تواند این موضوع را مطرح کند و از Business Analyst یا Product Owner بخواهد رفتار مورد انتظار مشخص شود.

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

پس نقش تستر:

تصمیم‌گیری درباره نیاز کسب‌وکار نیست؛ شناسایی ابهام و کمک به قابل تست شدن Requirement است.

۱۷.۱۸. Requirement Review و Shift Left

این موضوع یکی از مهم‌ترین نکات برای مسیر حرفه‌ای تستر است.

اگر تستر فقط بعد از Development شروع به کار کند، ممکن است یک Requirement مبهم تازه در زمان تست آشکار شود.

مثلاً:

«سیستم باید در زمان مناسب پاسخ دهد.»

Developer یک برداشت دارد.

Tester برداشت دیگری دارد.

Business Analyst برداشت سوم.

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

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

یک مثال کامل از نگاه تستر

فرض کنیم SRS نوشته:

FR-ORD-003: مشتری باید بتواند سفارش خود را لغو کند.

تستر بلافاصله چند سؤال مطرح می‌کند:

سؤال ۱

آیا همه وضعیت‌های سفارش قابل لغو هستند؟

سؤال ۲

آیا سفارش ارسال‌شده قابل لغو است؟

سؤال ۳

آیا بعد از لغو Refund انجام می‌شود؟

سؤال ۴

اگر Refund شکست بخورد چه؟

سؤال ۵

آیا کاربر مهمان نیز می‌تواند سفارش را لغو کند؟

سؤال ۶

محدودیت زمانی وجود دارد؟

سؤال ۷

پس از لغو چه Notificationای ارسال می‌شود؟

این سؤالات ممکن است باعث شوند Requirement اولیه تکمیل شود.

مثلاً:

FR-ORD-003: مشتری باید بتواند سفارش را تا پیش از تغییر وضعیت آن به Shipped لغو کند.

و:

BR-ORD-004: پس از لغو موفق سفارش، فرآیند Refund باید طبق Rule مالی سازمان انجام شود.

حالا Requirement بسیار قابل فهم‌تر شده است.

۱۷.۱۹. SRS چه زمانی برای تستر کافی نیست؟

SRS مهم است، اما تنها منبع اطلاعات تستر نیست.

بسته به پروژه، تستر ممکن است به منابع دیگری نیز نیاز داشته باشد:

• Business Requirements
• User Story
• Acceptance Criteria
• Business Rules
• UI Specification
• API Documentation
• Architecture Documentation
• Database Specification
• Risk Information
• Change Request

بنابراین:

SRS یک منبع مهم Requirement است، اما تستر باید کل Requirement Context را در نظر بگیرد.

این نکته مخصوصاً در پروژه‌های Agile اهمیت زیادی دارد.

جمع‌بندی بخش ۱۷

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

SRS می‌تواند در مراحل مختلف چرخه تست استفاده شود:

SRS
 ↓
Requirement Review
 ↓
Test Conditions
 ↓
Test Scenarios
 ↓
Test Cases
 ↓
Test Execution
 ↓
Defect Reporting
 ↓
Regression / Retest
 ↓
Coverage & Traceability

تستر حرفه‌ای هنگام مطالعه SRS باید سه سؤال اساسی را در ذهن داشته باشد:

چه چیزی باید تست شود؟

رفتار مورد انتظار دقیقاً چیست؟

آیا Requirement به اندازه‌ای واضح و قابل تست هست که بتوان بر اساس آن Pass/Fail تعیین کرد؟

و شاید مهم‌تر از همه:

اگر Requirement مبهم است، قبل از اینکه آن را به Test Case تبدیل کنیم، باید ابهامش را برطرف کنیم.

۱۸. چک‌لیست بررسی SRS؛ از کجا بفهمیم سند نیازمندی خوبی داریم؟

تا اینجا دیدیم که یک SRS (Software Requirements Specification) فقط مجموعه‌ای از Requirementها نیست. کیفیت SRS می‌تواند مستقیماً روی تحلیل، طراحی، توسعه و تست نرم‌افزار تأثیر بگذارد.

اما یک سؤال عملی باقی می‌ماند:

چطور بفهمیم SRSای که نوشته‌ایم واقعاً خوب است؟

برای پاسخ، می‌توانیم SRS را با یک Checklist مشخص بررسی کنیم.

این چک‌لیست هم برای Business Analyst و Requirements Engineer مفید است و هم برای تستر نرم‌افزار که می‌خواهد Requirement Review انجام دهد.

۱۸.۱. بررسی کلی سند

ابتدا خود سند را بررسی کنیم.

چک‌لیست

• هدف SRS مشخص است.
• Scope سیستم مشخص است.
• موارد خارج از Scope مشخص شده‌اند.
• مخاطبان سند مشخص هستند.
• اصطلاحات تخصصی تعریف شده‌اند.
• منابع و مستندات مرتبط مشخص شده‌اند.
• Version سند مشخص است.
• تاریخ آخرین تغییر مشخص است.
• وضعیت سند مشخص است؛ مثلاً Draft یا Approved.
• مسئول نگهداری سند مشخص است.

این موارد شاید مستقیماً Test Case تولید نکنند، اما برای مدیریت و استفاده صحیح از SRS اهمیت دارند.

۱۸.۲. بررسی Requirementها از نظر وضوح

برای هر Requirement بپرسید:

آیا یک Developer و یک Tester با خواندن آن، تقریباً یک برداشت خواهند داشت؟

مثلاً:

❌

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

این Requirement واضح نیست.

اما:

سیستم باید ۹۵٪ درخواست‌های جستجو را در شرایط بار مشخص‌شده در کمتر از ۲ ثانیه پاسخ دهد.

قابل‌فهم‌تر است.

Checklist

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

۱۸.۳. بررسی Completeness

یکی از سخت‌ترین ویژگی‌های SRS، Completeness یا کامل بودن است.

کامل بودن به این معنی نیست که SRS باید تمام جزئیات ممکن را شامل شود.

بلکه باید اطلاعات ضروری برای درک Requirement وجود داشته باشد.

مثلاً:

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

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

باید مشخص شود:

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

Checklist

• رفتار اصلی مشخص است.
• شرایط مهم مشخص شده‌اند.
• Exceptionهای مهم مشخص شده‌اند.
• محدودیت‌های مهم مشخص شده‌اند.
• وابستگی‌های مهم مشخص شده‌اند.
• اطلاعات ضروری برای تست وجود دارد.

۱۸.۴. بررسی Consistency

Requirementها نباید با یکدیگر تناقض داشته باشند.

مثلاً:

Requirement A

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

Requirement B

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

اگر وضعیت «تأییدشده» و «ارسال‌شده» دو وضعیت متفاوت باشند، Requirementها ممکن است با هم تعارض داشته باشند.

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

باید ابهام به تیم مسئول Requirement منتقل شود.

Checklist

• Requirementها با یکدیگر تناقض ندارند.
• اصطلاحات در سراسر سند یکسان استفاده شده‌اند.
• وضعیت‌های سیستم با یکدیگر سازگار هستند.
• Business Ruleها با Functional Requirementها تضاد ندارند.
• Version فعلی سند با سایر مستندات هماهنگ است.

۱۸.۵. بررسی Testability

این بخش برای تستر اهمیت ویژه‌ای دارد.

از خودتان بپرسید:

آیا می‌توانم بر اساس این Requirement یک Test Result قابل دفاع ایجاد کنم؟

مثلاً:

❌

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

Pass یا Fail این Requirement چگونه تعیین می‌شود؟

در مقابل:

حداقل ۹۰٪ کاربران شرکت‌کننده در آزمون Usability باید بتوانند فرآیند ثبت سفارش را بدون دریافت راهنمایی تکمیل کنند.

معیار مشخص‌تری داریم.

Checklist

• Requirement قابل ارزیابی است.
• Expected Behavior مشخص است.
• معیار Pass/Fail قابل تعیین است.
• در صورت نیاز معیار کمی وجود دارد.
• Test Data مورد نیاز قابل تهیه است.
• شرایط لازم برای Verification یا Validation مشخص است.

در اینجا وارد جزئیات Verification و Validation نمی‌شویم، چون این دو مفهوم موضوع مقاله تخصصی خودشان هستند.

۱۸.۶. بررسی Requirement ID

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

FR-AUTH-001
FR-AUTH-002
FR-ORD-001
NFR-PERF-001
BR-PAY-001

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

FR-PAY-002
      ↓
TC-PAY-001
      ↓
DEF-1024

Checklist

• Requirementهای مهم شناسه یکتا دارند.
• IDها تکراری نیستند.
• Naming Convention مشخص است.
• ID در صورت تغییر متن Requirement حفظ یا طبق سیاست Versioning مدیریت می‌شود.

۱۸.۷. بررسی Traceability

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

برای مثال:

FR-ORD-001 → TC-ORD-001

یعنی Test Case مشخصی برای Requirement وجود دارد.

اما Traceability می‌تواند گسترده‌تر باشد:

Business Requirement
        ↓
System Requirement
        ↓
Test Case
        ↓
Test Result
        ↓
Defect

Checklist

• Requirement به منبع خود قابل ردیابی است.
• Requirement به Test Artefactهای مرتبط متصل است.
• Requirementهای بدون Coverage شناسایی شده‌اند.
• تغییر Requirementها قابل پیگیری است.
• Defectهای مهم به Requirement مرتبط هستند.

۱۸.۸. بررسی Functional Requirements

برای هر Functional Requirement بررسی کنید:

سیستم دقیقاً چه کاری باید انجام دهد؟

مثلاً:

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

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

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

Checklist

• Actor مشخص است.
• Trigger مشخص است.
• رفتار سیستم مشخص است.
• Inputهای مهم مشخص هستند.
• Outputهای مهم مشخص هستند.
• شرایط موفقیت مشخص است.
• شرایط خطا مشخص است.

۱۸.۹. بررسی Non-Functional Requirements

یکی از بخش‌هایی که در SRSها زیاد فراموش می‌شود، Non-Functional Requirements است.

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

• Performance
• Security
• Availability
• Reliability
• Compatibility
• Usability
• Scalability

در صورت نیاز مشخص شده‌اند یا خیر.

اما نکته مهم:

هر پروژه الزاماً به همه این موارد با یک سطح اهمیت نیاز ندارد.

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

Checklist

• Performance بررسی شده است.
• Security بررسی شده است.
• Availability در صورت نیاز مشخص شده است.
• Compatibility در صورت نیاز مشخص شده است.
• سایر Quality Attributeهای مهم شناسایی شده‌اند.
• معیار ارزیابی NFRها تا حد امکان مشخص است.

۱۸.۱۰. بررسی Business Rules

Business Ruleها گاهی داخل Requirementها پنهان می‌شوند.

مثلاً:

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

این یک قانون کسب‌وکار است.

Checklist

• Business Ruleهای مهم شناسایی شده‌اند.
• Ruleها واضح هستند.
• Ruleها با Requirementها سازگارند.
• Ruleهای تغییرپذیر قابل ردیابی هستند.
• Test Caseهای مرتبط قابل شناسایی هستند.

۱۸.۱۱. بررسی Exceptionها

تستر هنگام Review باید به دنبال این سؤال باشد:

اگر همه چیز طبق حالت عادی پیش نرود چه؟

مثلاً در Payment:

• Gateway Down
• Timeout
• Invalid Response
• Duplicate Request
• Failed Transaction

Checklist

• شرایط خطای مهم مشخص شده‌اند.
• Timeoutها در صورت اهمیت مشخص شده‌اند.
• رفتار سیستم هنگام دریافت داده نامعتبر مشخص است.
• رفتار سیستم در صورت در دسترس نبودن Dependencyها مشخص است.
• Duplicate Requestها در صورت اهمیت بررسی شده‌اند.

۱۸.۱۲. بررسی Boundaryها

اگر Requirement محدوده‌ای دارد، باید آن محدوده واضح باشد.

مثلاً:

سن کاربر باید بین ۱۸ تا ۶۵ سال باشد.

تستر باید بتواند بفهمد:

• ۱۸ معتبر است؟
• ۶۵ معتبر است؟
• ۱۷ چه؟
• ۶۶ چه؟

Checklist

• Minimum مشخص است.
• Maximum مشخص است.
• Inclusive یا Exclusive بودن محدوده مشخص است.
• شرایط Boundary قابل تشخیص است.

این اطلاعات بعداً برای تکنیک‌هایی مانند Boundary Value Analysis بسیار مفید هستند.

۱۸.۱۳. بررسی Dependencies

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

مثلاً:

سیستم برای پرداخت به Payment Gateway وابسته است.

یا:

سیستم برای ارسال SMS از یک سرویس خارجی استفاده می‌کند.

Checklist

• Dependencyهای مهم مشخص هستند.
• سیستم‌های خارجی شناسایی شده‌اند.
• رفتار سیستم در صورت Failure Dependency مشخص شده است.
• Interfaceهای مهم مستند شده‌اند.
• مسئولیت هر سیستم مشخص است.

۱۸.۱۴. بررسی Scope و Out of Scope

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

مثلاً پروژه قرار است فقط:

پرداخت آنلاین

را پیاده‌سازی کند.

اما شخصی Requirement جدیدی برای:

پرداخت نقدی هنگام تحویل

اضافه می‌کند.

این موضوع باید از نظر Scope بررسی شود.

Checklist

• In Scope مشخص است.
• Out of Scope مشخص است.
• Requirementهای خارج از محدوده شناسایی شده‌اند.
• Scope با اهداف پروژه سازگار است.

۱۸.۱۵. بررسی Priority

اگر پروژه ۲۰۰ Requirement داشته باشد، همه آن‌ها احتمالاً اهمیت یکسانی ندارند.

برای مثال:

Requirement	Priority
Login	Critical
Payment	Critical
Search	High
Profile Picture	Low

Priority می‌تواند در تصمیم‌گیری درباره Test Scope نیز مفید باشد.

Checklist

• Requirementهای مهم اولویت دارند.
• Priorityها منطقی هستند.
• Requirementهای Critical مشخص‌اند.
• Priority با Business Risk سازگار است.

۱۸.۱۶. بررسی تغییرات SRS

SRS باید قابلیت مدیریت تغییر داشته باشد.

Checklist

• Version مشخص است.
• Change Log وجود دارد.
• تغییرات مهم قابل پیگیری هستند.
• Approvalهای لازم ثبت شده‌اند.
• Requirementهای تغییرکرده مشخص هستند.
• Test Artefactهای مرتبط بعد از تغییر بررسی شده‌اند.

۱۸.۱۷. چک‌لیست نهایی برای تستر

اگر بخواهیم تمام موارد را به یک چک‌لیست سریع تبدیل کنیم، تستر می‌تواند قبل از شروع Test Design این سؤال‌ها را بپرسد:

درباره خود Requirement

• آیا Requirement واضح است؟
• آیا ابهام دارد؟
• آیا کامل است؟
• آیا با سایر Requirementها سازگار است؟
• آیا قابل تست است؟
• آیا ID دارد؟

درباره رفتار سیستم

• Input مشخص است؟
• Output مشخص است؟
• Expected Behavior مشخص است؟
• Exceptionها مشخص‌اند؟
• Boundaryها مشخص‌اند؟
• Business Ruleهای مرتبط مشخص‌اند؟

درباره Traceability

• Requirement به منبع خود متصل است؟
• Test Case مرتبط دارد؟
• Coverage مشخص است؟
• تغییرات آن قابل پیگیری است؟

درباره Non-Functional Requirements

• Performance بررسی شده؟
• Security بررسی شده؟
• Compatibility بررسی شده؟
• سایر Quality Attributeهای مهم بررسی شده‌اند؟

درباره تغییرات

• Version مشخص است؟
• آخرین تغییرات مشخص‌اند؟
• Impact Analysis انجام شده؟
• Test Artefactهای تحت تأثیر مشخص شده‌اند؟

۱۸.۱۸. یک نکته مهم: Checklist جای تحلیل را نمی‌گیرد

داشتن یک Checklist بسیار مفید است، اما نباید تصور کنیم اگر تمام Checkboxها تیک خوردند، SRS حتماً عالی است.

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

مثلاً:

سیستم باید ۹۹.۹٪ Availability داشته باشد.

Requirement:

• ID دارد. ✅
• قابل اندازه‌گیری است. ✅
• واضح است. ✅

اما سؤال مهم‌تر:

آیا این مقدار واقعاً با نیاز کسب‌وکار و معماری سیستم سازگار است؟

اینجاست که تحلیل واقعی Requirement اهمیت پیدا می‌کند.

پس Checklist یک ابزار کنترل کیفیت است، نه جایگزین تحلیل و تفکر مهندسی.

۱۸.۱۹. یک تستر چگونه SRS را در عمل Review کند؟

مرحله ۱: یک بار بدون نوشتن Test Case بخوان

هدف:

درک سیستم و Scope.

مرحله ۲: Requirementها را دسته‌بندی کن

مثلاً:

• Functional
• Non-Functional
• Business Rules
• Constraints

مرحله ۳: ابهام‌ها را علامت بزن

مثلاً:

«سریع» یعنی چقدر؟

مرحله ۴: سناریوهای مثبت و منفی را تصور کن

از خودت بپرس:

اگر همه چیز خوب پیش برود چه؟

و:

اگر خراب شود چه؟

مرحله ۵: Boundaryها را پیدا کن

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

مرحله ۶: Traceability را بررسی کن

ببین Requirement به چه Test Artefactهایی متصل است.

مرحله ۷: سؤال‌ها را قبل از Test Execution مطرح کن

این مرحله بسیار مهم است.

هدف این نیست که بعداً بگوییم:

«این Requirement مشکل داشت.»

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

یک مثال کوتاه

فرض کنید در SRS نوشته شده:

سیستم باید در کمتر از ۳ ثانیه پاسخ دهد.

یک تستر حرفه‌ای احتمالاً چند سؤال مطرح می‌کند:

• کدام درخواست؟
• تحت چه Loadای؟
• میانگین ۳ ثانیه است یا حداکثر؟
• ۳ ثانیه شامل چه بخشی از فرآیند است؟
• چه درصدی از درخواست‌ها باید این معیار را رعایت کنند؟
• در صورت Timeout چه اتفاقی می‌افتد؟

همین چند سؤال می‌تواند Requirement را از:

یک جمله مبهم

به:

یک Requirement قابل ارزیابی

جمع‌بندی

یک SRS خوب باید فقط طولانی و کامل به نظر نرسد؛ بلکه باید بتواند نیازمندی‌های سیستم را به شکل:

واضح، کامل، سازگار، قابل تست و قابل ردیابی

مستند کند.

از دید تستر، مهم‌ترین سؤال این نیست که:

«آیا SRS صفحه‌های زیادی دارد؟»

بلکه این است:

«آیا می‌توانم بر اساس این Requirementها رفتار مورد انتظار سیستم را بفهمم و آن را به شکل قابل اتکا ارزیابی کنم؟»

اگر پاسخ منفی باشد، احتمالاً SRS قبل از ورود به مرحله تست نیاز به Review و اصلاح دارد.

۱۹. ساختار استاندارد SRS؛ یک Template برای نوشتن سند نیازمندی نرم‌افزار

تا اینجا مفهوم SRS، انواع Requirement، تفاوت SRS در Agile و Waterfall و همچنین نحوه بررسی SRS از دید تستر را بررسی کردیم.

حالا وقت آن است که از بحث مفهومی فاصله بگیریم و ببینیم:

اگر بخواهیم واقعاً یک SRS بنویسیم، چه بخش‌هایی باید داشته باشد؟

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

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

۱۹.۱. صفحه عنوان و اطلاعات سند

در ابتدای SRS بهتر است اطلاعات پایه سند مشخص شود.

مورد	مقدار
نام پروژه	فروشگاه اینترنتی
نام سند	Software Requirements Specification
Version	1.0
وضعیت	Approved
تاریخ	2026/08/19
تهیه‌کننده	Requirements Team
تأییدکننده	Product Owner

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

۱۹.۲. Document History

در SRS بهتر است تغییرات مهم سند نیز ثبت شوند.

Version	Date	Change	Author
0.1	2026/08/01	Initial Draft	BA
0.2	2026/08/05	Added Payment Requirements	BA
1.0	2026/08/10	Approved Version	BA

این بخش زمانی اهمیت بیشتری پیدا می‌کند که Requirementها در طول پروژه تغییر کنند.

۱۹.۳. Introduction

در بخش Introduction توضیح می‌دهیم این سند درباره چیست.

معمولاً می‌توان موارد زیر را در آن قرار داد:

• Purpose
• Scope
• Intended Audience
• Definitions
• References

Purpose

مشخص می‌کند این SRS با چه هدفی تهیه شده است.

مثلاً:

هدف این سند، تعریف نیازمندی‌های عملکردی و غیرعملکردی سامانه فروشگاه اینترنتی است تا به‌عنوان مرجع مشترک برای تیم‌های Business، Development و Testing مورد استفاده قرار گیرد.

Intended Audience

مشخص می‌کند چه کسانی از SRS استفاده می‌کنند.

برای مثال:

• Product Owner
• Business Analyst
• Software Developer
• Software Tester
• QA Specialist
• Project Manager
• Solution Architect

۱۹.۴. Scope

Scope یکی از مهم‌ترین قسمت‌های SRS است.

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

سیستم چه چیزی را شامل می‌شود و چه چیزی را شامل نمی‌شود؟

In Scope

• ثبت‌نام
• ورود
• جستجوی محصول
• سبد خرید
• ثبت سفارش
• پرداخت آنلاین

Out of Scope

• مدیریت فیزیکی انبار
• حسابداری سازمان
• سیستم حمل‌ونقل

مشخص کردن Out of Scope می‌تواند از افزایش کنترل‌نشده Scope جلوگیری کند.

۱۹.۵. Product Overview

در این قسمت یک تصویر کلی از محصول ارائه می‌شود.

مثلاً:

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

این بخش نباید با Functional Requirements اشتباه گرفته شود.

اینجا هدف ارائه دید کلی است.

۱۹.۶. Definitions و اصطلاحات

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

Term	Definition
Customer	کاربر نهایی خرید
Admin	مدیر سامانه
Payment Gateway	سرویس پردازش پرداخت
Order	سفارش ثبت‌شده مشتری
Refund	بازگشت مبلغ پرداختی

این کار از سوءتفاهم میان اعضای تیم جلوگیری می‌کند.

۱۹.۷. References

اگر SRS به مستندات دیگری وابسته است، باید به آن‌ها اشاره شود.

• Business Requirements
• API Documentation
• Regulatory Documents
• UI Specification
• Architecture Document
• External Service Documentation

البته نوع و میزان References به پروژه بستگی دارد.

۱۹.۸. Overall Description

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

می‌توان مواردی مانند این‌ها را در آن قرار داد:

• Product Perspective
• User Classes
• Operating Environment
• Assumptions
• Dependencies
• Constraints

هدف این بخش پاسخ دادن به این سؤال است:

سیستم در چه محیطی و با چه شرایطی قرار است کار کند؟

۱۹.۹. User Classes

کاربران مختلف سیستم را مشخص می‌کنیم.

Customer

کاربری که محصولات را خریداری می‌کند.

Admin

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

Support Agent

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

در این بخش وارد طراحی User Story یا Use Case نمی‌شویم.

هدف فقط شناخت کلاس‌های کاربری و نقش آن‌ها است.

۱۹.۱۰. Functional Requirements

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

در اینجا مشخص می‌کنیم:

سیستم چه کارهایی باید انجام دهد؟

بهتر است Requirementها ID داشته باشند.

FR-AUTH-001

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

FR-AUTH-002

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

FR-PROD-001

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

FR-ORD-001

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

۱۹.۱۱. Non-Functional Requirements

در این بخش Quality Attributeها و محدودیت‌های کیفی سیستم تعریف می‌شوند.

Performance

سیستم باید ۹۵٪ درخواست‌های جستجو را در شرایط بار مشخص‌شده در کمتر از ۲ ثانیه پاسخ دهد.

Availability

سیستم باید در طول هر ماه حداقل ۹۹.۹٪ در دسترس باشد، به استثنای Maintenanceهای برنامه‌ریزی‌شده.

Security

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

Compatibility

سیستم باید در Browserهای پشتیبانی‌شده سازمان عملکرد مورد انتظار را ارائه دهد.

نکته مهم این است که NFRها نیز باید تا حد امکان قابل ارزیابی باشند.

۱۹.۱۲. Business Rules

قوانین کسب‌وکار را می‌توان در این بخش ثبت کرد.

BR-ORD-001

سفارش پس از تغییر وضعیت به Shipped قابل لغو نیست.

BR-DIS-001

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

Business Rule با Functional Requirement یکی نیست.

Functional Requirement بیشتر درباره رفتار سیستم صحبت می‌کند، در حالی که Business Rule می‌تواند یک قانون یا سیاست کسب‌وکار باشد که رفتار سیستم باید از آن پیروی کند.

۱۹.۱۳. External Interfaces

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

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

برای هر Interface می‌توان اطلاعات مورد نیاز را مشخص کرد.

مثلاً:

سیستم باید نتیجه تراکنش Payment Gateway را دریافت و وضعیت سفارش را بر اساس نتیجه آن به‌روزرسانی کند.

جزئیات فنی API، در صورت نیاز، می‌توانند در مستندات API جداگانه نگهداری شوند و SRS به آن‌ها Reference بدهد.

۱۹.۱۴. Data Requirements

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

• چه اطلاعاتی باید ذخیره شوند؟
• چه داده‌هایی اجباری هستند؟
• چه محدودیت‌هایی روی داده وجود دارد؟
• داده‌ها چه مدت نگهداری می‌شوند؟
• چه داده‌هایی حساس هستند؟

مثلاً:

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

این بخش بسته به پروژه ممکن است بسیار ساده یا بسیار گسترده باشد.

۱۹.۱۵. Constraints

Constraint یا محدودیت مشخص می‌کند چه چیزهایی دست تیم را بسته‌اند.

مثلاً:

• سیستم باید از Database موجود سازمان استفاده کند.
• سیستم باید روی زیرساخت فعلی شرکت Deploy شود.
• سیستم باید با Payment Gateway مشخص‌شده توسط سازمان یکپارچه شود.

Constraint با Requirement تفاوت دارد؛ Constraint معمولاً محدودیتی است که طراحی یا پیاده‌سازی سیستم باید تحت آن انجام شود.

۱۹.۱۶. Assumptions

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

مثلاً:

• فرض می‌شود سرویس Payment Gateway در محیط Production در دسترس باشد.
• فرض می‌شود کاربران به شماره تلفن معتبر دسترسی دارند.

ثبت Assumptionها مهم است؛ چون اگر یکی از آن‌ها تغییر کند، ممکن است Requirementها نیز تحت تأثیر قرار بگیرند.

۱۹.۱۷. Dependencies

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

Online Store
     ↓
Payment Gateway
     ↓
Bank Network

Online Store
     ↓
SMS Service

اگر یکی از این سرویس‌ها در دسترس نباشد، ممکن است رفتار سیستم تغییر کند.

بنابراین Dependencyها می‌توانند مستقیماً روی Testing نیز اثر بگذارند.

۱۹.۱۸. Error Handling و Exception Requirements

اگر شرایط خطا برای محصول مهم است، بهتر است رفتار مورد انتظار سیستم در آن شرایط نیز مشخص شود.

مثلاً:

• در صورت عدم دریافت پاسخ از Payment Gateway در بازه تعیین‌شده، سیستم نباید تراکنش را موفق تلقی کند.
• در صورت قطع ارتباط با سرویس ارسال SMS، ثبت سفارش نباید Fail شود و وضعیت Notification باید برای Retry ثبت شود.

این بخش به تستر کمک زیادی می‌کند تا فقط Happy Path را تست نکند.

۱۹.۱۹. Acceptance Information

در بعضی SRSها ممکن است اطلاعات مربوط به پذیرش Requirement نیز وجود داشته باشد.

مثلاً برای یک Requirement می‌توان معیارهای کلی پذیرش را مشخص کرد.

اما در اینجا یک نکته مهم وجود دارد:

SRS لزوماً نباید تمام جزئیات معیارهای پذیرش(Acceptance Criteria) را در خود جای دهد.

در برخی پروژه‌ها Acceptance Criteria در موارد زیر نگهداری می‌شود:

• User Story
• Acceptance Test
• اسناد تست پذیرش کاربر(UAT)
• Requirement Management Tool

اگر مقاله تخصصی Acceptance Criteria در سایت وجود داشته باشد، بهتر است این بخش در SRS فقط به آن مفهوم اشاره کند و توضیح کامل را به مقاله تخصصی واگذار کند.

۱۹.۲۰. Traceability

در SRSهای حرفه‌ای یا پروژه‌های دارای الزامات ردیابی، می‌توان ارتباط Requirementها را مشخص کرد.

Requirement	Source	Test Case
FR-AUTH-001	BR-LOGIN-001	TC-AUTH-001
FR-PAY-001	BR-PAY-001	TC-PAY-001
FR-ORD-003	BR-ORD-004	TC-ORD-003

Traceability باعث می‌شود بتوانیم مسیر Requirement را دنبال کنیم.

Business Need
      ↓
Requirement
      ↓
Test Case
      ↓
Test Result
      ↓
Defect

جزئیات Traceability Matrix را بهتر است در مقاله مستقل آن بررسی کنیم.

۱۹.۲۱. Requirement Priority

در پروژه‌های بزرگ، اولویت Requirementها نیز می‌تواند ثبت شود.

ID	Requirement	Priority
FR-PAY-001	پرداخت آنلاین	Critical
FR-ORD-001	ثبت سفارش	Critical
FR-PROD-001	جستجوی محصول	High
FR-PROF-001	تصویر پروفایل	Low

این اطلاعات می‌تواند در موارد زیر مفید باشد:

• Release Planning
• Risk Analysis
• Test Prioritization

۱۹.۲۲. Requirement Status

برای مدیریت Requirement می‌توان وضعیت آن را نیز مشخص کرد.

• Proposed
• Draft
• Reviewed
• Approved
• Implemented
• Verified
• Deprecated

این وضعیت‌ها به فرآیند سازمان بستگی دارند و نباید تصور کرد همه پروژه‌ها دقیقاً از همین Statusها استفاده می‌کنند.

۱۹.۲۳. Change Log

در پایان یا ابتدای SRS می‌توان Change Log داشت.

Version	Requirement	Change
1.1	FR-PAY-001	Added new payment method
1.2	FR-ORD-003	Changed cancellation rule

این اطلاعات برای Requirement Management و همچنین Regression Analysis بسیار مفید هستند.

۱۹.۲۴. ساختار پیشنهادی نهایی SRS

اگر بخواهیم تمام این بخش‌ها را در یک ساختار منظم قرار دهیم، می‌توانیم Template زیر را داشته باشیم:

1. Document Information
   1.1 Document Title
   1.2 Version
   1.3 Status
   1.4 Authors
   1.5 Approvers
   1.6 Revision History

2. Introduction
   2.1 Purpose
   2.2 Scope
   2.3 Intended Audience
   2.4 Definitions
   2.5 References

3. Product Overview
   3.1 Product Perspective
   3.2 Product Functions
   3.3 User Classes
   3.4 Operating Environment

4. Assumptions and Dependencies

5. Constraints

6. Functional Requirements

7. Non-Functional Requirements

8. Business Rules

9. External Interfaces

10. Data Requirements

11. Error Handling and Exceptions

12. Acceptance Information

13. Requirement Priority

14. Traceability

15. Requirement Status

16. Change Management

17. Appendices

این ساختار Template پیشنهادی است، نه یک ساختار اجباری.

در یک پروژه کوچک ممکن است بعضی از این بخش‌ها اصلاً لازم نباشند.

در یک پروژه Enterprise ممکن است هر بخش به چندین سند و Subsection تقسیم شود.

۱۹.۲۵. یک نکته مهم درباره Templateهای SRS

نباید با دیدن این Template تصور کنیم:

«هر SRS که این ۱۷ بخش را نداشته باشد، SRS بدی است.»

این برداشت درست نیست.

هدف Template این است که:

چیزی مهم را فراموش نکنیم.

نه اینکه همه پروژه‌ها را مجبور کنیم دقیقاً یک ساختار ثابت داشته باشند.

مثلاً یک پروژه ساده داخلی ممکن است فقط به این موارد نیاز داشته باشد:

Purpose
Scope
Functional Requirements
Non-Functional Requirements
Business Rules
External Interfaces

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

۱۹.۲۶. SRS خوب، SRS طولانی نیست

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

هرچه SRS طولانی‌تر باشد، حرفه‌ای‌تر است.

در حالی که ممکن است یک SRS ۲۰۰ صفحه‌ای:

• تکراری باشد.
• Requirementهای مبهم داشته باشد.
• تناقض داشته باشد.
• اطلاعات غیرضروری داشته باشد.

و یک SRS ۳۰ صفحه‌ای:

• واضح باشد.
• قابل تست باشد.
• Traceable باشد.
• Scope مشخصی داشته باشد.
• Requirementهای مهم را پوشش دهد.

بنابراین معیار اصلی:

کیفیت Requirementهاست، نه تعداد صفحات سند.

۱۹.۲۷. Template SRS و نقش تستر

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

تمرکز اصلی او معمولاً روی مواردی مانند:

• Functional Requirements
• Non-Functional Requirements
• Business Rules
• Constraints
• Exceptions
• External Interfaces
• Traceability
• Testability

خواهد بود.

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

مثلاً Scope می‌تواند مستقیماً روی Test Scope اثر بگذارد و Dependencies می‌توانند روی Test Environment و Integration Testing تأثیر بگذارند.

جمع‌بندی

یک SRS حرفه‌ای می‌تواند از بخش‌هایی مانند:

Purpose → Scope → Product Overview → Functional Requirements → Non-Functional Requirements → Business Rules → Interfaces → Constraints → Dependencies → Traceability

تشکیل شود.

اما ساختار دقیق باید متناسب با پروژه انتخاب شود.

نکته مهم این است که SRS باید بتواند یک مرجع قابل اعتماد برای درک نیازمندی‌های سیستم ایجاد کند و در صورت نیاز، Requirementها را به سایر Artefactهای پروژه متصل کند.

۲۰. استاندارد SRS چیست؟ بررسی IEEE 830 و ISO/IEC/IEEE 29148

وقتی درباره SRS (Software Requirements Specification) صحبت می‌کنیم، خیلی زود با نام IEEE 830 مواجه می‌شویم. بسیاری از مقاله‌ها و منابع آموزشی هنوز می‌گویند:

«استاندارد SRS، IEEE 830 است.»

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

استاندارد IEEE 830-1998 دیگر استاندارد جاری محسوب نمی‌شود و توسط ISO/IEC/IEEE 29148:2011 جایگزین شد. نسخه 2011 نیز بعداً با ISO/IEC/IEEE 29148:2018 بازنگری شد.

در حال حاضر، نسخه 2018 نسخه منتشرشده این استاندارد است؛ هرچند نسخه سوم آن نیز در سال 2026 در حال توسعه است.

۲۰.۱. IEEE 830 چیست؟

IEEE 830 عنوان استانداردی بود که برای ارائه راهنمای تهیه Software Requirements Specifications ایجاد شده بود.

نسخه معروف آن:

IEEE 830-1998 — IEEE Recommended Practice for Software Requirements Specifications

بود.

این استاندارد درباره محتوای SRS، ویژگی‌های یک SRS مناسب و نمونه‌هایی از ساختار SRS راهنمایی ارائه می‌کرد.

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

IEEE 830 SRS Template

را می‌بینیم.

اما باید توجه کنیم که IEEE 830-1998 یک استاندارد جایگزین‌شده (Superseded) است.

بنابراین اگر امروز بخواهیم یک مقاله تخصصی درباره SRS بنویسیم، بهتر است IEEE 830 را به‌عنوان مرجع تاریخی و بسیار تأثیرگذار معرفی کنیم، نه استاندارد جاری SRS.

۲۰.۲. چرا IEEE 830 اهمیت تاریخی دارد؟

با وجود اینکه IEEE 830 دیگر استاندارد جاری نیست، شناخت آن هنوز مفید است.

دلیلش این است که بسیاری از مفاهیمی که در آموزش SRS می‌بینیم، تحت تأثیر همین استاندارد و نسل‌های قبلی راهنماهای Requirements Specification شکل گرفته‌اند.

برای مثال، ساختارهایی شامل:

• Introduction
• Overall Description
• Functional Requirements
• Non-Functional Requirements
• External Interfaces
• Constraints

در آموزش‌های SRS بسیار رایج شده‌اند.

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

IEEE 830 SRS

مواجه شدید، لزوماً به این معنی نیست که منبع اشتباه است؛ ممکن است منبع بر اساس نسخه قدیمی استاندارد نوشته شده باشد.

اما برای استناد به استاندارد جاری، باید به نسخه جدیدتر مراجعه کرد.

۲۰.۳. ISO/IEC/IEEE 29148 چیست؟

استاندارد مهم‌تر و امروزی‌تر در حوزه Requirements Engineering:

ISO/IEC/IEEE 29148 — Systems and software engineering — Life cycle processes — Requirements engineering

است.

نسخه منتشرشده فعلی آن:

ISO/IEC/IEEE 29148:2018

است.

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

به همین دلیل، بهتر است آن را صرفاً با عنوان:

«استاندارد قالب SRS»

معرفی نکنیم.

این استاندارد در واقع نگاه وسیع‌تری به Requirements Engineering دارد.

۲۰.۴. ارتباط IEEE 830 و ISO/IEC/IEEE 29148

یکی از مهم‌ترین نکات تاریخی این است که:

ISO/IEC/IEEE 29148:2011، IEEE 830-1998 را جایگزین کرد.

سپس نسخه 2011 نیز با انتشار نسخه:

ISO/IEC/IEEE 29148:2018

بازنگری شد.

نسخه 2011 اکنون Withdrawn است و نسخه 2018 نسخه منتشرشده فعلی است.

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

IEEE 830-1998
       ↓
ISO/IEC/IEEE 29148:2011
       ↓
ISO/IEC/IEEE 29148:2018

و در حال حاضر نیز نسخه سوم 29148 در حال توسعه است.

۲۰.۵. پس برای SRS از کدام استاندارد استفاده کنیم؟

اگر امروز بخواهیم درباره SRS صحبت کنیم، بهتر است بگوییم:

ISO/IEC/IEEE 29148:2018 یکی از مهم‌ترین مراجع استانداردی برای Requirements Engineering و مشخصات نیازمندی‌های سیستم و نرم‌افزار است.

و نه اینکه:

«IEEE 830 استاندارد فعلی SRS است.»

این تفاوت برای یک مقاله تخصصی اهمیت دارد.

۲۰.۶. آیا ISO/IEC/IEEE 29148 یک Template ثابت برای SRS ارائه می‌کند؟

نه به این معنا که بگوییم:

«هر SRS باید دقیقاً همین ۱۰ یا ۱۵ Heading را داشته باشد.»

ISO/IEC/IEEE 29148 درباره فرآیندهای Requirements Engineering و اطلاعاتی که باید تولید و مدیریت شوند راهنمایی ارائه می‌کند و درباره محتوای Information Itemها نیز صحبت می‌کند.

بنابراین Templateهایی که در اینترنت می‌بینیم را نباید با خود استاندارد یکی بدانیم.

مثلاً اگر یک Template شامل:

1. Introduction
2. Overall Description
3. Functional Requirements
4. Non-Functional Requirements
5. External Interfaces

باشد، این به معنی آن نیست که:

«29148 دقیقاً همین پنج Heading را به‌عنوان تنها ساختار مجاز SRS تعیین کرده است.»

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

۲۰.۷. ویژگی‌های Requirement خوب

یکی از نکات مهم در Requirements Engineering این است که فقط داشتن Requirement کافی نیست؛ خود Requirement نیز باید کیفیت مناسبی داشته باشد.

مثلاً Requirement نباید:

• مبهم باشد.
• چند برداشت مختلف ایجاد کند.
• غیرقابل تست باشد.
• با Requirement دیگری تناقض داشته باشد.
• اطلاعات ضروری را حذف کرده باشد.

برای مثال:

❌

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

این Requirement معیار مشخصی برای ارزیابی ندارد.

در مقابل:

سیستم باید ۹۵ درصد درخواست‌های جستجو را در شرایط بار تعریف‌شده در کمتر از ۲ ثانیه پاسخ دهد.

Requirement دوم بسیار قابل ارزیابی‌تر است.

این موضوع برای تستر اهمیت زیادی دارد، زیرا Requirement باید بتواند مبنایی برای تعیین Expected Result قرار گیرد.

۲۰.۸. ISO/IEC/IEEE 29148 فقط برای Waterfall نیست

یک تصور اشتباه این است که استانداردهای Requirements Engineering فقط برای پروژه‌های Waterfall کاربرد دارند.

در حالی که ISO/IEC/IEEE 29148 فرآیندهای Requirements Engineering را در طول چرخه عمر سیستم و نرم‌افزار مورد توجه قرار می‌دهد و کاربرد آن را به پروژه‌های مختلف، صرف‌نظر از Scope، اندازه، پیچیدگی یا متدولوژی محدود نمی‌کند.

بنابراین استفاده از اصول Requirements Engineering می‌تواند در پروژه‌های:

• Waterfall
• Agile
• Hybrid

نیز مطرح باشد.

تفاوت بیشتر در نحوه مدیریت و مستندسازی Requirementها است.

۲۰.۹. رابطه استاندارد با Template مقاله ما

در بخش قبل یک Template پیشنهادی برای SRS ارائه کردیم.

باید این نکته را روشن کنیم که آن Template:

یک ساختار عملی و آموزشی پیشنهادی است، نه کپی مستقیم از یک استاندارد.

هدف آن این است که خواننده بتواند یک SRS قابل استفاده ایجاد کند.

برای یک پروژه واقعی، ممکن است سازمان بر اساس:

• استانداردهای داخلی
• الزامات صنعت
• قرارداد
• الزامات قانونی
• فرآیند Quality Management
• ابزار Requirements Management

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

۲۰.۱۰. تفاوت SRS Template با Standard

این دو مفهوم را نباید با یکدیگر اشتباه گرفت.

Standard

می‌گوید:

چه اصول، فرآیندها و اطلاعاتی باید در Requirements Engineering مورد توجه قرار گیرند؟

Template

می‌گوید:

این اطلاعات را در چه ساختاری می‌توانیم مستند کنیم؟

برای مثال:

Standard
   ↓
Requirements Engineering Principles
   ↓
Required / Relevant Information
   ↓
Organization-specific Template
   ↓
Actual SRS

بنابراین یک سازمان می‌تواند با توجه به استاندارد مورد استفاده خود، Template داخلی SRS طراحی کند.

۲۰.۱۱. IEEE 830 یا ISO/IEC/IEEE 29148؛ کدام را در رزومه و مصاحبه بدانیم؟

اگر در مصاحبه تست نرم‌افزار از شما پرسیده شود:

«استاندارد SRS چیست؟»

پاسخ حرفه‌ای‌تر این است:

«IEEE 830-1998 یکی از استانداردهای معروف و قدیمی برای Software Requirements Specification بود، اما جایگزین شده است. مرجع جدیدتر، ISO/IEC/IEEE 29148 است و نسخه منتشرشده فعلی آن 2018 است.»

این پاسخ از گفتن صرفِ:

«SRS بر اساس IEEE 830 است.»

دقیق‌تر است.

۲۰.۱۲. وضعیت فعلی ISO/IEC/IEEE 29148

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

طبق اطلاعات رسمی ISO، نسخه ISO/IEC/IEEE 29148:2018 منتشرشده است و در سال 2024 تأیید شده بود؛ اما در فوریه 2026 پروژه بازنگری آن آغاز شده و نسخه سوم در حال توسعه است. در ژوئیه 2026 نیز Draft International Standard آن ثبت شده است.

بنابراین در زمان نگارش این مقاله:

29148:2018 نسخه منتشرشده است، اما نسخه جدیدتر هنوز در مرحله توسعه است.

این نکته باعث می‌شود مقاله از نظر زمانی دقیق‌تر باشد.

۲۰.۱۳. آیا تستر باید متن کامل استاندارد را بخواند؟

برای بیشتر تسترهای نرم‌افزار، پاسخ الزاماً «بله» نیست.

اگر هدف شما فعالیت روزمره Testing است، مهم‌تر است مفاهیمی مانند:

• Requirement
• Requirement Quality
• Testability
• Traceability
• Requirement Review
• Change Management
• Acceptance Criteria
• Verification
• Validation

را به‌خوبی درک کنید.

استاندارد برای کسانی که در Requirements Engineering، Systems Engineering، Process Management یا پروژه‌های دارای الزامات رسمی فعالیت می‌کنند اهمیت بیشتری پیدا می‌کند.

اما آشنایی تستر با 29148 می‌تواند دید بسیار خوبی نسبت به جایگاه Requirement در چرخه عمر سیستم ایجاد کند.

۲۰.۱۴. یک نکته مهم برای SEO و ساختار محتوای سایت

در مقاله اصلی SRS بهتر است وارد جزئیات کامل استاندارد 29148 نشویم.

چون Search Intent عبارت‌هایی مانند:

• IEEE 830 چیست؟
• ISO/IEC/IEEE 29148 چیست؟
• تفاوت IEEE 830 و 29148 چیست؟

می‌توانند خودشان موضوع مقاله‌های تخصصی جداگانه باشند.

در مقاله مادر SRS بهتر است:

1. جایگاه استاندارد را توضیح دهیم.
2. تفاوت تاریخی IEEE 830 و 29148 را روشن کنیم.
3. مرجع به‌روز را معرفی کنیم.
4. خواننده را برای مطالعه بیشتر به مقاله تخصصی هدایت کنیم.

این کار هم از Keyword Cannibalization جلوگیری می‌کند و هم ساختار محتوایی سایت را منظم‌تر می‌کند.

جمع‌بندی

اگر بخواهیم موضوع استاندارد SRS را در چند جمله خلاصه کنیم:

IEEE 830-1998 استاندارد معروف و تاریخی برای Software Requirements Specifications بود، اما اکنون Superseded است. این استاندارد توسط ISO/IEC/IEEE 29148:2011 جایگزین شد.

نسخه 2011 نیز بعداً با:

ISO/IEC/IEEE 29148:2018

جایگزین شد. این استاندارد دامنه گسترده‌تری دارد و Requirements Engineering و Information Itemهای مرتبط با آن را در طول چرخه عمر پوشش می‌دهد.

در حال حاضر، 29148:2018 نسخه منتشرشده است و نسخه سوم آن در سال 2026 در حال توسعه است.

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

IEEE 830 یک مرجع تاریخی مهم برای SRS است؛ اما برای چارچوب استانداردی امروزی، ISO/IEC/IEEE 29148 مرجع مهم‌تری است.

و یک نکته مهم‌تر:

استاندارد با Template یکی نیست.

استاندارد چارچوب و الزامات Requirements Engineering را مشخص می‌کند؛ اما سازمان می‌تواند بر اساس آن و نیازهای پروژه، Template SRS مخصوص خود را طراحی کند.

۲۱. SRS برای تستر نرم‌افزار؛ خلاصه مسیر یادگیری 🧪

تا اینجا SRS را از جنبه‌های مختلف بررسی کردیم؛ از تعریف و ساختار آن گرفته تا انواع Requirement، ویژگی‌های یک Requirement خوب، استانداردها، ارتباط SRS با Testing و نحوه Review آن.

اما اگر هدف شما یادگیری تست نرم‌افزار است، شاید مهم‌ترین سؤال این باشد:

یک تستر دقیقاً چقدر باید درباره SRS و Requirements بداند؟

پاسخ این است که تستر قرار نیست جای Business Analyst یا Requirements Engineer را بگیرد؛ اما باید بتواند Requirement را بخواند، تحلیل کند، ابهام‌های آن را تشخیص دهد و بر اساس آن تست طراحی کند.

۲۱.۱. تستر باید از Requirement چه چیزی بفهمد؟

یک تستر حرفه‌ای هنگام مطالعه SRS باید بتواند به این سؤال‌ها پاسخ دهد:

• سیستم چه کاری باید انجام دهد؟
• چه کسی از این قابلیت استفاده می‌کند؟
• در چه شرایطی این رفتار باید اتفاق بیفتد؟
• نتیجه مورد انتظار چیست؟
• محدودیت‌های سیستم چیست؟
• چه شرایط خطایی وجود دارد؟
• چه Business Ruleهایی باید رعایت شوند؟
• چه Requirementهای غیرعملکردی وجود دارند؟
• چه Requirementهایی به یکدیگر وابسته‌اند؟
• چه چیزی باید تست شود؟

در واقع، تستر باید بتواند از:

Requirement

به:

Testable Requirement

و سپس به:

Test Condition و Test Case

برسد.

۲۱.۲. مسیر یادگیری SRS برای یک تستر

اگر بخواهیم این مسیر را مرحله‌به‌مرحله ببینیم، می‌توان آن را این‌گونه تصور کرد:

Business Need
      ↓
Requirement
      ↓
SRS
      ↓
Requirement Review
      ↓
Test Analysis
      ↓
Test Conditions
      ↓
Test Scenarios
      ↓
Test Cases
      ↓
Test Execution
      ↓
Defect
      ↓
Retest / Regression

تستر لازم نیست در تمام این مراحل مالک فرآیند باشد؛ اما باید ارتباط میان آن‌ها را درک کند.

۲۱.۳. مرحله اول: یادگیری مفهوم Requirement

اولین قدم این است که بدانیم Requirement دقیقاً چیست.

Requirement فقط یک جمله درباره قابلیت نرم‌افزار نیست.

Requirement می‌تواند بیان‌کننده:

• نیاز کسب‌وکار
• قابلیت سیستم
• رفتار مورد انتظار
• محدودیت
• ویژگی کیفی
• قانون کسب‌وکار

باشد.

بنابراین قبل از یادگیری Test Case باید بتوانیم نیازمندی را درست بخوانیم و تفسیر کنیم.

۲۱.۴. مرحله دوم: شناخت انواع Requirement

تستر باید حداقل با این دسته‌ها آشنا باشد:

Functional Requirement

مشخص می‌کند:

سیستم چه کاری باید انجام دهد؟

Non-Functional Requirement

مشخص می‌کند:

سیستم با چه ویژگی کیفی یا محدودیتی باید کار کند؟

Business Rule

مشخص می‌کند:

چه قانون کسب‌وکاری باید رعایت شود؟

Constraint

مشخص می‌کند:

سیستم تحت چه محدودیتی باید ساخته یا اجرا شود؟

این دسته‌بندی به تستر کمک می‌کند بفهمد با چه نوع تستی روبه‌رو است.

۲۱.۵. مرحله سوم: یادگیری Requirement Review

در این مرحله تستر دیگر فقط Requirement را نمی‌خواند؛ آن را بررسی می‌کند.

مثلاً:

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

تستر باید بپرسد:

سریع یعنی چند ثانیه؟

یا:

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

تستر باید بپرسد:

آیا سفارش ارسال‌شده هم قابل لغو است؟

این نوع سؤال‌ها بخشی از Static Testing و Requirement Review هستند.

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

۲۱.۶. مرحله چهارم: یادگیری Testability

یکی از مهارت‌های مهم تستر این است که تشخیص دهد Requirement:

قابل تست هست یا نه؟

برای مثال:

❌

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

تستر نمی‌تواند به‌سادگی Pass یا Fail تعیین کند.

اما:

حداقل ۹۰٪ کاربران آزمایشی باید بتوانند فرآیند ثبت سفارش را بدون کمک تکمیل کنند.

قابل ارزیابی‌تر است.

بنابراین تستر باید بتواند Requirementهایی را که Ambiguous، Incomplete یا Not Testable هستند شناسایی کند.

۲۱.۷. مرحله پنجم: استخراج Test Condition

بعد از درک Requirement، تستر باید مشخص کند:

چه چیزهایی باید تست شوند؟

مثلاً:

کاربر پس از پنج تلاش ناموفق Login، برای ۱۵ دقیقه محدود می‌شود.

Test Conditionهای احتمالی:

• تلاش ناموفق اول
• تلاش ناموفق پنجم
• تلاش ششم
• Login در زمان Lock
• Login پس از پایان Lock
• ورود موفق قبل از رسیدن به Limit

در این مرحله هنوز وارد جزئیات Test Case نشده‌ایم.

۲۱.۸. مرحله ششم: انتخاب تکنیک تست

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

مثلاً:

سن کاربر باید بین ۱۸ تا ۶۵ سال باشد.

اینجا Boundary Value Analysis می‌تواند مفید باشد.

یا:

نوع حساب می‌تواند یکی از سه مقدار Customer، Admin یا Support باشد.

اینجا Equivalence Partitioning یا تکنیک‌های مناسب دیگر می‌توانند مطرح شوند.

پس Requirement به تستر کمک می‌کند بفهمد:

کجا و چگونه باید تست طراحی شود؟

۲۱.۹. مرحله هفتم: طراحی Test Case

بعد از تحلیل Requirement و Test Condition، تستر می‌تواند Test Case طراحی کند.

Requirement:

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

Test Case:

بررسی Lock شدن حساب پس از پنج تلاش ناموفق.

در Test Case مشخص می‌شود:

• Preconditions
• Test Data
• Steps
• Expected Result
• Actual Result
• Status

در اینجا Test Case دیگر بر اساس حدس نوشته نشده؛ بلکه بر اساس Requirement طراحی شده است.

۲۱.۱۰. مرحله هشتم: Traceability

تستر باید بتواند رابطه بین Requirement و Test را دنبال کند.

FR-AUTH-001
      ↓
TC-AUTH-001
TC-AUTH-002
TC-AUTH-003

حالا می‌توانیم بگوییم:

Requirement مورد نظر Test Coverage دارد.

اگر Requirementی وجود داشته باشد که هیچ Test Case مرتبطی نداشته باشد، می‌تواند یک علامت هشدار باشد.

همچنین اگر Test Caseای داشته باشیم که مشخص نیست مربوط به کدام Requirement است، باید علت آن بررسی شود.

۲۱.۱۱. مرحله نهم: Defect Reporting

وقتی Test Case اجرا می‌شود، تستر باید بتواند نتیجه واقعی را با Requirement مقایسه کند.

Expected:

بعد از پرداخت موفق، وضعیت سفارش باید Paid شود.

Actual:

وضعیت سفارش همچنان Pending است.

حالا Defect می‌تواند به Requirement مربوطه متصل شود:

FR-PAY-002
     ↓
TC-PAY-005
     ↓
DEF-1024

این ارتباط باعث می‌شود گزارش Defect دقیق‌تر و قابل پیگیری‌تر باشد.

۲۱.۱۲. مرحله دهم: Retest و Regression

وقتی Defect مربوط به یک Requirement اصلاح شد، تستر باید ابتدا بررسی کند:

آیا همان Defect واقعاً برطرف شده است؟

این Retest است.

اما اگر تغییر انجام‌شده بتواند روی بخش‌های دیگر سیستم اثر بگذارد، باید Regression Testing نیز در نظر گرفته شود.

مثلاً:

Requirement Payment
       ↓
Payment Fix
       ↓
Retest
       ↓
Order
Invoice
Refund
Notification
       ↓
Regression Testing

در اینجا Requirement و Impact Analysis می‌توانند به تعیین دامنه تست مجدد کمک کنند.

۲۱.۱۳. تستر قرار نیست Business Analyst باشد

این نکته بسیار مهم است.

شناخت SRS به این معنی نیست که:

تستر باید تمام وظایف Business Analyst را انجام دهد.

وظیفه اصلی تستر همچنان Testing است.

اما برای Testing مؤثر، تستر باید بتواند Requirement را تحلیل کند.

بنابراین تفاوت این دو نقش را می‌توان این‌طور خلاصه کرد:

Business Analyst	Software Tester
نیاز کسب‌وکار را تحلیل می‌کند	Requirement را برای Testing تحلیل می‌کند
Requirement را تعریف و مستند می‌کند	Requirement را Review می‌کند
با Stakeholderها درباره نیاز صحبت می‌کند	ابهام‌ها و ریسک‌های قابل تست را مطرح می‌کند
رفتار مورد نیاز سیستم را مشخص می‌کند	رفتار مورد انتظار را مبنای تست قرار می‌دهد
مسئول اصلی Requirement نیست در همه سازمان‌ها یکسان	مسئول اصلی Test است

البته در پروژه‌های مختلف مرز این نقش‌ها می‌تواند متفاوت باشد.

۲۱.۱۴. چرا شناخت SRS برای رشد حرفه‌ای تستر مهم است؟

تستری که فقط بتواند:

Test Case اجرا کند و Pass/Fail ثبت کند

یک سطح از مهارت Testing را دارد.

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

Requirement را قبل از توسعه بررسی کند، ابهام آن را تشخیص دهد، ریسک تست را شناسایی کند و Requirement را به Test Coverage متصل کند،

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

به همین دلیل یادگیری Requirement Analysis می‌تواند مسیر رشد تستر را تقویت کند.

۲۱.۱۵. SRS را در کجای مسیر یادگیری تست نرم‌افزار قرار دهیم؟

اگر بخواهیم یک مسیر آموزشی منطقی برای تستر ترسیم کنیم:

مفاهیم پایه تست نرم‌افزار
            ↓
Software Development Lifecycle
            ↓
Requirements
            ↓
SRS / Requirement Analysis
            ↓
Test Levels
            ↓
Test Types
            ↓
Test Techniques
            ↓
Test Design
            ↓
Test Case
            ↓
Defect Management
            ↓
Test Execution
            ↓
Test Reporting

پس SRS خودش یک مهارت مستقل برای تبدیل شدن به تستر نیست؛ بلکه یکی از پایه‌هایی است که کمک می‌کند تستر بفهمد:

چه چیزی را باید تست کند و چرا؟

۲۱.۱۶. ارتباط SRS با Verification و Validation

در اینجا فقط باید یک ارتباط مهم را مشخص کنیم.

تستر هنگام Review Requirement می‌تواند بررسی کند که Requirement:

• واضح است؟
• کامل است؟
• سازگار است؟
• قابل تست است؟

این فعالیت‌ها با Verification ارتباط دارند.

از طرف دیگر، بررسی اینکه آیا محصول نهایی واقعاً نیاز و هدف موردنظر ذی‌نفعان را برآورده می‌کند، با Validation ارتباط دارد.

پس می‌توان ارتباط را به‌صورت ساده این‌گونه دید:

Requirement
     ↓
Verification
     ↓
Implementation
     ↓
Testing / Evaluation
     ↓
Validation

البته Verification و Validation دو مفهوم گسترده‌تر از این نمودار ساده هستند و در مقاله تخصصی مربوط به خودشان باید با جزئیات بررسی شوند.

۲۱.۱۷. مهم‌ترین مهارتی که تستر از SRS یاد می‌گیرد

اگر بخواهیم کل این بخش را در یک جمله خلاصه کنیم:

تستر باید یاد بگیرد Requirement را به زبان قابل تست تبدیل کند.

یعنی از:

«سیستم باید قابلیت پرداخت داشته باشد.»

به مجموعه‌ای از سؤال‌ها برسد:

• پرداخت موفق چه رفتاری دارد؟
• پرداخت ناموفق چه؟
• Timeout چه؟
• Duplicate Payment چه؟
• وضعیت سفارش چه می‌شود؟
• Refund چه زمانی انجام می‌شود؟
• چه محدودیت‌هایی وجود دارد؟
• چه Test Conditionهایی لازم است؟
• چه Test Caseهایی باید طراحی شوند؟

این همان نقطه‌ای است که Requirement Analysis و Software Testing به یکدیگر متصل می‌شوند.

جمع‌بندی بخش ۲۱

برای یک تستر، یادگیری SRS به معنی حفظ کردن ساختار یک سند نیست.

تستر باید بتواند:

Requirement را بخواند → ابهام را پیدا کند → Testability را بررسی کند → Test Condition استخراج کند → Test طراحی کند → Coverage را بررسی کند → نتیجه را با Expected Behavior مقایسه کند.

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

SRS
 ↓
Understand
 ↓
Review
 ↓
Analyze
 ↓
Design Tests
 ↓
Execute
 ↓
Report
 ↓
Retest
 ↓
Regression

و این دقیقاً همان دلیلی است که Requirement Analysis برای یک تستر حرفه‌ای اهمیت دارد؛ حتی اگر مالک اصلی Requirement شخص یا تیم دیگری در پروژه باشد.

منابع

• ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering
• IEEE 830-1998 — IEEE Recommended Practice for Software Requirements Specifications
• ISO/IEC/IEEE 29148:2011 — Requirements engineering
• IEC — ISO/IEC/IEEE 29148:2018
• ISTQB Glossary — Requirement
• ISTQB Glossary — Test Basis
• ISTQB Glossary — Test Requirement
• ISTQB Glossary — Requirements-Based Testing
• ISTQB — Official Certification and Exam Information

سوالات متداول درباره SRS برای تستر نرم‌افزار

آیا تستر نرم‌افزار باید SRS را بلد باشد؟

بله. تستر لازم نیست متخصص Requirements Engineering باشد، اما باید بتواند Requirementها را بخواند، تحلیل کند، ابهام‌ها و مشکلات Testability را تشخیص دهد و بر اساس آن‌ها Test Condition و Test Case طراحی کند.

آیا تستر باید خودش SRS را بنویسد؟

معمولاً مالک اصلی SRS نقش‌هایی مانند Business Analyst یا Requirements Engineer هستند، اما این موضوع به ساختار سازمان و پروژه بستگی دارد. تستر بیشتر باید بتواند Requirementها را Review و برای Testing تحلیل کند.

تفاوت Requirement Analysis و Test Case Design چیست؟

در Requirement Analysis، تستر نیازمندی را بررسی می‌کند و رفتار مورد انتظار، ابهام‌ها، شرایط و محدودیت‌های آن را شناسایی می‌کند. در Test Case Design، این اطلاعات به شرایط و سناریوهای قابل اجرا برای تست تبدیل می‌شوند.

آیا SRS مستقیماً Test Case تولید می‌کند؟

خیر. SRS یا سایر مستندات Requirement می‌توانند مبنای تست باشند، اما تستر ابتدا Requirementها را تحلیل می‌کند، Test Condition و Test Scenario را استخراج می‌کند و سپس Test Caseهای مناسب را طراحی می‌کند.

اگر یک Requirement مبهم باشد، تستر باید چه کاری انجام دهد؟

تستر نباید به‌صورت خودسرانه معنای Requirement را حدس بزند. باید ابهام را شناسایی و سؤال یا Issue مربوط به آن را با فرد یا تیم مسئول Requirement مطرح کند تا رفتار مورد انتظار مشخص شود.

آیا SRS فقط برای پروژه‌های Waterfall کاربرد دارد؟

خیر. مفاهیم Requirements Engineering در پروژه‌های مختلف از جمله Waterfall، Agile و Hybrid کاربرد دارند. تفاوت اصلی معمولاً در نحوه تعریف، مستندسازی، مدیریت و تغییر Requirementهاست.

آیا هر Requirement باید یک Test Case داشته باشد؟

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

چرا Traceability برای تستر مهم است؟

Traceability به تستر کمک می‌کند ارتباط میان Requirement، Test Case، Test Result و در صورت نیاز Defect را دنبال کند. این ارتباط برای بررسی Test Coverage و تحلیل اثر تغییر Requirementها نیز مفید است.

آیا تستر باید استاندارد ISO/IEC/IEEE 29148 را کامل مطالعه کند؟

برای بیشتر تسترها مطالعه کامل استاندارد ضروری نیست. درک مفاهیم Requirement، Requirement Review، Testability، Traceability و Requirements-Based Testing اهمیت عملی بیشتری دارد. مطالعه عمیق استاندارد برای افرادی که در Requirements Engineering یا پروژه‌های دارای الزامات رسمی فعالیت می‌کنند، مفیدتر است.

آیا IEEE 830 هنوز استاندارد جاری SRS است؟

خیر. IEEE 830-1998 یک استاندارد تاریخی و جایگزین‌شده است. IEEE اعلام کرده است که این استاندارد توسط ISO/IEC/IEEE 29148:2011 جایگزین شده و نسخه منتشرشده فعلی 29148، نسخه 2018 است.

مهم‌ترین چیزی که یک تستر باید از SRS یاد بگیرد چیست؟

مهم‌ترین مهارت این است که تستر بتواند Requirement را به یک مبنای قابل تست تبدیل کند؛ یعنی Requirement را درک کند، ابهام‌ها و ریسک‌ها را پیدا کند، Test Condition استخراج کند، Test طراحی کند و نتیجه تست را با رفتار مورد انتظار مقایسه کند.