نیازمندی نرم‌افزار چیست؟ راهنمای جامع Software Requirements برای تسترها و QA

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

این انتظارات و نیازها در قالب نیازمندی‌های نرم‌افزار یا Software Requirements بیان و مدیریت می‌شوند.

نیازمندی‌ها فقط برای تیم تحلیل یا توسعه اهمیت ندارند. برای یک تستر نرم‌افزار یا متخصص QA نیز شناخت Requirements اهمیت زیادی دارد، زیرا بخش بزرگی از فعالیت‌هایی مانند طراحی Test Scenario، Test Case، بررسی رفتار سیستم، شناسایی Defect و Traceability به‌نوعی با نیازمندی‌ها ارتباط دارند.

به زبان ساده، نیازمندی مشخص می‌کند سیستم چه چیزی باید ارائه دهد و تحت چه شرایطی باید رفتار مورد انتظار را داشته باشد.

البته Requirements همیشه به یک شکل نوشته نمی‌شوند و ممکن است بسته به نوع پروژه، مدل توسعه و ساختار سازمان، در قالب‌هایی مانند Business Requirement، User Requirement، Software Requirement، User Story، Acceptance Criteria یا اسناد مختلف ثبت شوند.

نیازمندی نرم‌افزار چیست؟

نیازمندی نرم‌افزار (Software Requirement) بیان می‌کند که یک سیستم، محصول یا قابلیت باید چه نیاز یا انتظاری را برآورده کند.

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

• یک قابلیت یا رفتار مشخص سیستم باشد.
• یک محدودیت یا قانون کسب‌وکار باشد.
• یک ویژگی کیفی مانند Performance یا Security باشد.
• یک نیاز کاربر یا ذی‌نفع باشد.
• یا محدودیتی باشد که سیستم باید در طراحی و پیاده‌سازی رعایت کند.

برای مثال:

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

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

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

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

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

چرا نیازمندی‌های نرم‌افزار اهمیت دارند؟

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

یک Requirement مناسب می‌تواند به تیم کمک کند پاسخ پرسش‌هایی مانند موارد زیر را مشخص کند:

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

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

از دید QA نیز Requirements اهمیت ویژه‌ای دارند، زیرا می‌توانند مبنای موارد زیر باشند:

• طراحی Test Scenario
• طراحی Test Case
• بررسی Test Coverage
• شناسایی شرایط مختلف و Edge Caseها
• تشخیص رفتار مورد انتظار سیستم
• بررسی اینکه یک Defect کدام نیازمندی را نقض کرده است
• بررسی تأثیر تغییر یک Requirement بر تست‌ها

نیازمندی فقط قابلیت سیستم نیست

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

برای مثال، موارد زیر همگی می‌توانند بخشی از نیازمندی‌های یک محصول باشند:

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

به همین دلیل، برای درک درست Requirements باید آن‌ها را از چند زاویه مختلف بررسی کرد. دو زاویه مهم عبارت‌اند از:

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

یک نیازمندی از کجا شروع می‌شود؟

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

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

Business Need → Business Requirement → User / Stakeholder Requirement → System / Software Requirement

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

سطوح مختلف نیازمندی‌ها

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

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

Business Need یا نیاز کسب‌وکار

Business Need به یک مسئله، فرصت یا نیاز در سطح کسب‌وکار اشاره دارد.

برای مثال:

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

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

Business Requirement یا نیازمندی کسب‌وکار

Business Requirement مشخص می‌کند کسب‌وکار برای پاسخ به نیاز یا رسیدن به هدف خود چه چیزی لازم دارد.

برای مثال:

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

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

User یا Stakeholder Requirement

در این سطح، نیاز از دید کاربر یا یکی از ذی‌نفعان بیان می‌شود.

برای مثال:

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

در محیط‌های Agile، چنین نیازهایی ممکن است در قالب User Story بیان شوند.

System یا Software Requirement

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

برای مثال:

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

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

آیا این سطوح همیشه به همین ترتیب هستند؟

خیر. ساختار دقیق Requirements به نوع پروژه، مدل توسعه، سازمان و روش مستندسازی بستگی دارد.

ممکن است در یک پروژه ابتدا Business Requirement تعریف شود و سپس به Software Requirement تبدیل شود. در پروژه‌ای دیگر، تیم محصول مستقیماً User Story بنویسد و جزئیات مورد نیاز در Acceptance Criteria، طراحی، Business Rules یا مستندات دیگر تکمیل شوند.

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

انواع نیازمندی‌های نرم‌افزار

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

• Functional Requirements
• Non-Functional Requirements

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

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

Functional Requirements مشخص می‌کنند سیستم باید چه کاری انجام دهد.

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

برای مثال:

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

یک Functional Requirement معمولاً به این پرسش پاسخ می‌دهد:

سیستم باید چه کاری انجام دهد؟

نیازمندی های غیرعملکردی (Non-Functional Requirements) چیست؟

Non-Functional Requirements بیشتر به ویژگی‌ها و کیفیت عملکرد سیستم مربوط هستند.

برای مثال:

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

برای نمونه:

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

یا:

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

برای یک تستر، شناخت Non-Functional Requirements اهمیت زیادی دارد، زیرا بررسی آن‌ها معمولاً فقط با اجرای یک Test Case معمولی انجام نمی‌شود و ممکن است به روش‌ها، ابزارها و معیارهای اندازه‌گیری متفاوتی نیاز داشته باشد.

Business Rules و Constraints چه هستند؟

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

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

موجودی کالا نباید کمتر از صفر شود.

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

تفاوت سطح و نوع نیازمندی

برای جلوگیری از سردرگمی، می‌توان Requirements را از چند منظر بررسی کرد.

از نظر سطح:

• Business
• Stakeholder / User
• System / Software

از نظر ماهیت:

• Functional
• Non-Functional / Quality
• Business Rules
• Constraints

از نظر حوزه:

• Security
• Performance
• Data
• Interface
• Usability
• Accessibility
• Reliability
• Availability
• Scalability

مهم‌ترین نکته این است که این دسته‌بندی‌ها Mutually Exclusive نیستند. یک Requirement می‌تواند هم‌زمان از چند منظر قابل طبقه‌بندی باشد.

User Story و Acceptance Criteria چه جایگاهی دارند؟

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

داستان کاربر(User Story) چیست؟

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

یک قالب رایج برای نوشتن User Story به شکل زیر است:

As a [role], I want [goal], so that [benefit].

برای مثال:

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

User Story معمولاً به این پرسش‌ها کمک می‌کند:

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

User Story معمولاً تمام جزئیات مورد نیاز برای طراحی، توسعه و تست را به‌تنهایی مشخص نمی‌کند. جزئیات بیشتر ممکن است در Acceptance Criteria، گفتگوهای تیم، Business Rules یا سایر مستندات ثبت شوند.

معیارهای پذیرش (Acceptance Criteria) چیست؟

معیارهای پذیرش(Acceptance Criteria) شرایطی را مشخص می‌کند که باید برقرار باشند تا یک قابلیت، User Story یا نیازمندی قابل قبول در نظر گرفته شود.

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

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

Acceptance Criteria می‌تواند شامل موارد زیر باشد:

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

Acceptance Criteria برای QA اهمیت زیادی دارد، زیرا مشخص می‌کند چه شرایطی باید بررسی شوند تا قابلیت مورد نظر قابل قبول تلقی شود.

سؤال اصلی Acceptance Criteria این است: چه شرایطی باید برقرار باشد تا این قابلیت قابل قبول باشد؟

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

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

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

• BRD
• SRS
• FRD
• User Story
• Acceptance Criteria

این مفاهیم الزاماً همیشه جایگزین یکدیگر نیستند و ممکن است در یک پروژه چند مورد از آن‌ها هم‌زمان استفاده شوند.

BRD چیست؟

BRD یا Business Requirements Document معمولاً برای ثبت نیازها، اهداف و انتظارات کسب‌وکار استفاده می‌شود.

برای مثال:

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

BRD بیشتر بر نیاز و هدف کسب‌وکار تمرکز دارد و می‌تواند موضوعاتی مانند موارد زیر را پوشش دهد:

• اهداف کسب‌وکار
• مشکلات و نیازهای موجود
• محدوده پروژه
• ذی‌نفعان
• نیازهای اصلی کسب‌وکار
• نتایج مورد انتظار

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

SRS چیست؟

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

برای مثال:

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

یا:

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

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

• Functional Requirements
• Non-Functional Requirements
• External Interfaces
• Data Requirements
• Security Requirements
• Constraints
• Business Rules

پرسش اصلی SRS: نرم‌افزار چه نیازمندی‌هایی باید داشته باشد؟

FRD چیست؟

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

برای مثال:

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

یا:

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

در برخی سازمان‌ها ممکن است FRD به‌صورت یک سند مستقل وجود داشته باشد و در برخی دیگر، Functional Requirements بخشی از SRS یا سایر مستندات نیازمندی باشند.

مقایسه BRD، SRS، FRD، User Story و Acceptance Criteria

مفهوم	تمرکز اصلی	پرسش کلیدی	سطح یا کاربرد
BRD	نیاز و هدف کسب‌وکار	چرا؟	Business
SRS	نیازمندی‌های نرم‌افزار	نرم‌افزار چه نیازمندی‌هایی دارد؟	Software
FRD	رفتارها و قابلیت‌های Functional	سیستم چه کاری باید انجام دهد؟	Functional
User Story	نیاز کاربر	کاربر چه می‌خواهد و چرا؟	User / Product
Acceptance Criteria	شرایط پذیرش	چه شرایطی باید برقرار باشد تا قابل قبول باشد؟	Acceptance

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

آیا این مفاهیم همیشه پشت سر هم قرار می‌گیرند؟

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

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

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

مهندسی نیازمندی‌های نرم‌افزار چیست؟

مهندسی نیازمندی‌ها (Requirements Engineering) مجموعه‌ای از فعالیت‌ها و روش‌هایی است که برای شناسایی، استخراج، تحلیل، مستندسازی، اعتبارسنجی و مدیریت نیازمندی‌های یک سیستم انجام می‌شود.

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

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

Elicitation → Analysis → Specification → Validation → Management

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

به همین دلیل، Requirements Engineering را بهتر است مجموعه‌ای از فعالیت‌های به‌هم‌پیوسته بدانیم که در طول چرخه عمر محصول یا پروژه ادامه پیدا می‌کنند.

چرخه Requirements Engineering

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

Requirements Elicitation

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

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

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

• Interview
• Workshop
• Observation
• Questionnaire
• Document Analysis
• Brainstorming
• Prototyping
• تحلیل سیستم یا فرآیند موجود

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

Requirements Analysis

بعد از شناسایی نیازها، باید آن‌ها بررسی و تحلیل شوند.

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

• مبهم هستند.
• ناقص هستند.
• با یکدیگر تناقض دارند.
• از نظر فنی محدودیت دارند.
• نیاز به اولویت‌بندی دارند.
• باید به چند Requirement کوچک‌تر تقسیم شوند.

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

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

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

Requirements Specification

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

این مرحله می‌تواند شامل ثبت Requirements در قالب‌هایی مانند موارد زیر باشد:

• BRD
• SRS
• FRD
• User Story
• Acceptance Criteria
• Backlog Item
• یا سایر قالب‌های مورد استفاده در سازمان

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

Requirements Validation

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

در Validation ممکن است پرسش‌هایی مانند موارد زیر مطرح شوند:

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

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

Requirements Management

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

Requirements Management به فعالیت‌هایی مربوط می‌شود که برای مدیریت این تغییرات و حفظ وضعیت Requirements انجام می‌شوند.

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

• Versioning
• Change Management
• Prioritization
• Traceability
• بررسی تأثیر تغییرات
• مدیریت وضعیت Requirements

یک نیازمندی خوب چه ویژگی‌هایی دارد؟

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

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

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

واضح و بدون ابهام باشد

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

❌ مثال نامناسب:

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

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

✅ مثال بهتر:

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

در مثال دوم، معیار مشخص‌تری برای بررسی Requirement وجود دارد.

کامل باشد

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

برای مثال:

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

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

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

این اطلاعات ممکن است مستقیماً در همان Requirement یا در Acceptance Criteria، Business Rules یا مستندات مرتبط ثبت شوند.

سازگار باشد

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

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

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

اما در یک Business Rule دیگر مشخص شده باشد:

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

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

قابل بررسی و قابل تست باشد

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

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

به همین دلیل، تا حد امکان باید شرایط، معیارها یا رفتار مورد انتظار به شکلی بیان شوند که بتوان درباره تحقق آن‌ها قضاوت کرد.

ضروری و مرتبط باشد

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

وجود Requirements غیرضروری می‌تواند باعث افزایش پیچیدگی، هزینه توسعه و حجم Testing شود.

قابل ردیابی باشد

در پروژه‌هایی که تعداد Requirements زیاد است، اهمیت دارد بتوان مشخص کرد هر Requirement از کجا آمده، چه بخش‌هایی از سیستم را تحت تأثیر قرار داده و توسط چه تست‌هایی پوشش داده شده است.

Traceability به تیم کمک می‌کند ارتباط بین Requirements، طراحی، توسعه، Test Case و در صورت نیاز Defectها را بهتر مدیریت کند.

Requirements Review چیست؟

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

Requirements Review فرآیندی است که در آن نیازمندی‌ها توسط افراد مرتبط بررسی می‌شوند تا مشکلات احتمالی قبل از ورود به مراحل بعدی شناسایی شوند.

در یک Review ممکن است پرسش‌هایی مانند موارد زیر مطرح شوند:

• آیا Requirement واضح است؟
• آیا ابهام یا اصطلاحات قابل تفسیر در آن وجود دارد؟
• آیا اطلاعات لازم برای درک رفتار مورد انتظار ارائه شده است؟
• آیا Requirement با سایر نیازمندی‌ها تناقض دارد؟
• آیا محدودیت‌ها و Business Ruleهای مرتبط مشخص شده‌اند؟
• آیا می‌توان Requirement را بررسی یا تست کرد؟
• آیا شرایط استثنایی و حالت‌های مختلف در نظر گرفته شده‌اند؟

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

چه کسانی در Requirements Review شرکت می‌کنند؟

افراد حاضر در Review به ساختار تیم و نوع پروژه بستگی دارند، اما ممکن است شامل افراد زیر باشند:

• Business Analyst
• Product Owner یا Product Manager
• Developer یا Technical Lead
• QA یا Software Tester
• نماینده کسب‌وکار یا سایر Stakeholderها

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

QA در Requirements Review چه نقشی دارد؟

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

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

• رفتار مورد انتظار دقیقاً چیست؟
• ورودی‌های معتبر و نامعتبر کدام‌اند؟
• در صورت بروز خطا چه اتفاقی باید بیفتد؟
• چه شرایطی باعث تغییر وضعیت سیستم می‌شوند؟
• چه Business Ruleهایی باید رعایت شوند؟
• چه حالت‌های مرزی یا استثنایی وجود دارند؟
• بر اساس چه معیارهایی می‌توان گفت قابلیت مورد نظر درست کار می‌کند؟

این نوع پرسش‌ها می‌توانند قبل از شروع توسعه، ابهام‌ها و نقص‌هایی را آشکار کنند که در غیر این صورت ممکن بود بعداً در مرحله Testing یا حتی پس از Release شناسایی شوند.

Requirements Validation چیست؟

Requirements Validation به بررسی این موضوع مربوط می‌شود که آیا نیازمندی‌های تعریف‌شده واقعاً نیازها و انتظارات مورد نظر را پوشش می‌دهند یا خیر.

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

در فرآیند Validation ممکن است مواردی مانند زیر بررسی شوند:

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

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

Verification و Validation در بررسی نیازمندی‌ها

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

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

• Verification: آیا Requirement به‌درستی و مطابق معیارهای مورد انتظار تعریف شده است؟
• Validation: آیا Requirement واقعاً نیاز درست و مورد انتظار را بیان می‌کند؟

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

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

ارتباط نیازمندی‌ها با Testing

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

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

Requirement → Test Condition → Test Scenario → Test Case → Test Execution → Result

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

از Requirement چگونه Test Condition استخراج می‌شود؟

فرض کنید Requirement زیر وجود دارد:

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

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

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

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

نکته مهم این است که یک Requirement الزاماً معادل یک Test Case نیست. یک Requirement ممکن است به چندین Test Condition و تعداد زیادی Test Case منجر شود.

Acceptance Criteria چه ارتباطی با Testing دارد؟

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

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

برای مثال، اگر یکی از معیارهای پذیرش این باشد:

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

QA می‌تواند بر اساس آن شرایطی مانند موارد زیر را بررسی کند:

• لغو سفارش قبل از ارسال
• تلاش برای لغو سفارش پس از ارسال
• بررسی تغییر وضعیت سفارش پس از لغو موفق
• بررسی پیام یا رفتار سیستم در صورت عدم امکان لغو

به همین دلیل، Acceptance Criteria معمولاً ارتباط نزدیکی با Acceptance Testing و بررسی شرایط پذیرش یک قابلیت دارد.

ارتباط Requirements و Defect

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

Requirements، Acceptance Criteria، Business Rules و سایر اطلاعات مرتبط می‌توانند به مشخص شدن رفتار مورد انتظار کمک کنند.

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

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

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

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

Traceability بین Requirements و Testing

در پروژه‌هایی که تعداد Requirements و Test Caseها زیاد است، مهم است بتوان ارتباط میان آن‌ها را تا حد نیاز حفظ کرد.

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

• هر Test Case کدام Requirement را پوشش می‌دهد.
• برای هر Requirement چه تست‌هایی طراحی شده‌اند.
• کدام Requirements هنوز پوشش تست مناسبی ندارند.
• یک تغییر در Requirement چه تست‌هایی را ممکن است تحت تأثیر قرار دهد.
• یک Defect با کدام Requirement یا قابلیت مرتبط است.

برای مثال، اگر یک Requirement با شناسه FR-AUTH-001 مربوط به ورود کاربر باشد، Test Caseهای مرتبط می‌توانند با آن ارتباط داده شوند.

این ارتباط بسته به ابزار و فرآیند تیم ممکن است در یک ابزار مدیریت نیازمندی، ابزار مدیریت تست، سیستم مدیریت پروژه یا حتی یک ماتریس Traceability نگهداری شود.

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

مدیریت تغییرات در نیازمندی‌ها

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

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

برای مثال، تغییر یک Requirement ممکن است بر موارد زیر اثر بگذارد:

• Business Ruleها
• Acceptance Criteria
• طراحی سیستم
• کدهای موجود
• APIها و Interfaceها
• Test Scenarioها
• Test Caseها
• Test Data
• مستندات
• زمان و هزینه پروژه

Change Impact Analysis چیست؟

Change Impact Analysis به بررسی تأثیر یک تغییر بر بخش‌های مختلف سیستم و پروژه گفته می‌شود.

فرض کنید Requirement مربوط به ورود کاربران تغییر کند و علاوه بر Email و Password، ورود با یک روش جدید نیز اضافه شود.

در این شرایط، فقط یک Test Case جدید ایجاد نمی‌شود. ممکن است لازم باشد موارد زیر نیز بررسی شوند:

• صفحه Login
• Validationهای مربوط به ورود
• API احراز هویت
• مدیریت Session
• سطوح دسترسی
• پیام‌های خطا
• Test Caseهای موجود
• Regression Testهای مرتبط

اینجاست که داشتن ارتباط مناسب بین Requirements، اجزای سیستم و تست‌ها می‌تواند به تحلیل تأثیر تغییر کمک کند.

برای QA، تحلیل تغییر فقط به این سؤال محدود نمی‌شود که «چه Test Case جدیدی باید نوشته شود؟». پرسش مهم‌تر این است:

این تغییر چه بخش‌هایی از رفتار فعلی سیستم را ممکن است تحت تأثیر قرار دهد؟

QA چگونه با تغییر نیازمندی‌ها برخورد می‌کند؟

وقتی یک Requirement تغییر می‌کند، QA باید ابتدا تغییر را به‌درستی درک کند و سپس تأثیر آن را بر تست‌های موجود بررسی کند.

برخی از پرسش‌هایی که می‌توان در زمان تغییر یک Requirement مطرح کرد عبارت‌اند از:

• دقیقاً چه چیزی تغییر کرده است؟
• دلیل این تغییر چیست؟
• کدام رفتار قبلی دیگر معتبر نیست؟
• چه Acceptance Criteriaهایی تغییر کرده‌اند؟
• چه Test Caseهایی تحت تأثیر قرار می‌گیرند؟
• آیا Test Data جدیدی نیاز است؟
• چه بخش‌هایی نیاز به Regression Testing دارند؟
• آیا این تغییر با سایر Requirements تناقض ایجاد می‌کند؟

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

اگر Requirement مبهم باشد، QA چه کاری باید انجام دهد؟

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

برای مثال:

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

این Requirement پرسش‌های زیادی ایجاد می‌کند. «سریع» یعنی چه؟ چه اطلاعاتی؟ برای چه تعداد کاربر؟ تحت چه شرایطی؟ معیار قابل قبول چیست؟

QA نباید به‌صورت خودکار یک تفسیر را انتخاب و بر اساس آن تست طراحی کند. بهتر است ابهام شناسایی و با افراد مناسب مطرح شود.

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

• رفتار مورد انتظار دقیقاً چیست؟
• معیار موفقیت یا پذیرش چیست؟
• آیا مثال مشخصی وجود دارد؟
• چه شرایطی خارج از محدوده هستند؟
• در شرایط خطا چه رفتاری انتظار می‌رود؟
• آیا Business Rule مرتبطی وجود دارد؟

هدف این پرسش‌ها ایجاد پیچیدگی غیرضروری نیست؛ هدف، رسیدن به درک مشترک قبل از طراحی، توسعه و Testing است.

اگر Requirement ناقص باشد چه باید کرد؟

یک Requirement ممکن است مبهم نباشد، اما همچنان ناقص باشد.

برای مثال:

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

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

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

در چنین شرایطی، QA می‌تواند موارد ناقص را به‌عنوان سؤال، Risk یا Issue مطرح کند تا قبل از شروع یا ادامه Testing، رفتار مورد انتظار مشخص شود.

آیا QA باید خودش Requirement را کامل کند؟

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

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

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

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

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

برخی مشکلات در پروژه‌ها بارها تکرار می‌شوند و می‌توانند کیفیت Requirements و در نتیجه کیفیت محصول را تحت تأثیر قرار دهند.

شروع توسعه قبل از مشخص شدن رفتار مورد انتظار

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

فرض کردن جزئیات توسط اعضای تیم

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

نادیده گرفتن حالت‌های استثنایی

تمرکز فقط بر Happy Path باعث می‌شود بسیاری از شرایط خطا، ورودی‌های نامعتبر و Edge Caseها مورد توجه قرار نگیرند.

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

یک تغییر کوچک ممکن است روی بخش‌های مختلف سیستم و تست‌های موجود اثر داشته باشد. نادیده گرفتن این تأثیر می‌تواند باعث ایجاد Regression یا ناقص شدن Test Coverage شود.

نداشتن معیار مشخص برای پذیرش

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

تمرکز فقط بر Functional Requirements

گاهی تمام توجه تیم روی قابلیت‌های قابل مشاهده سیستم قرار می‌گیرد و نیازمندی‌هایی مانند Performance، Security، Reliability یا Compatibility دیرتر مورد توجه قرار می‌گیرند.

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

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

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

QA با بررسی Requirements می‌تواند دید بهتری نسبت به موارد زیر پیدا کند:

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

برای مثال، اگر در Requirements مشخص شود که یک قابلیت با یک سرویس خارجی ارتباط دارد، QA می‌تواند از همان مراحل اولیه نیاز به بررسی Integration، مدیریت خطا، Timeout یا رفتار سیستم در صورت در دسترس نبودن سرویس را در نظر بگیرد.

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

نقش Requirements در Risk-Based Testing

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

بررسی Requirements می‌تواند به QA کمک کند تا چنین بخش‌هایی را زودتر شناسایی کند.

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

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

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

در Risk-Based Testing، اطلاعاتی مانند اهمیت قابلیت، پیچیدگی، احتمال بروز مشکل و تأثیر آن می‌توانند در تصمیم‌گیری درباره میزان و نوع Testing مؤثر باشند.

بنابراین، شناخت Requirements فقط برای استخراج Test Case نیست؛ بلکه می‌تواند در تصمیم‌گیری درباره اولویت Testing نیز نقش داشته باشد.

Requirements و Test Coverage

یکی از پرسش‌های مهم در Testing این است که آیا Requirements مورد نظر به‌اندازه کافی بررسی شده‌اند یا خیر.

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

برای مثال، اگر یک قابلیت شامل چند Requirement باشد، ممکن است برای هر Requirement چند Test Condition و چندین Test Case طراحی شود.

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

Requirements → Test Conditions → Test Cases → Test Results

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

• کدام Requirements دارای تست هستند.
• کدام Requirements هنوز پوشش تست ندارند.
• کدام Test Caseها به یک Requirement مرتبط هستند.
• چه Requirementsی پس از تغییر نیاز به بررسی مجدد دارند.

البته داشتن ارتباط بین Requirement و Test Case به‌تنهایی به معنای کامل بودن Testing نیست. ممکن است یک Requirement دارای چند Test Case باشد، اما همچنان برخی شرایط مهم، حالت‌های مرزی یا ریسک‌های مرتبط پوشش داده نشده باشند.

به همین دلیل، Test Coverage باید با توجه به نیازمندی‌ها، ریسک‌ها، شرایط مختلف و اهداف Testing بررسی شود.

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

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

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

آیا Requirement واضح است؟

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

آیا رفتار مورد انتظار مشخص است؟

• سیستم دقیقاً چه کاری باید انجام دهد؟
• چه ورودی‌هایی دریافت می‌کند؟
• خروجی یا نتیجه مورد انتظار چیست؟
• در صورت موفقیت چه اتفاقی می‌افتد؟
• در صورت خطا چه رفتاری انتظار می‌رود؟

آیا شرایط مختلف مشخص شده‌اند؟

• Happy Path چیست؟
• چه ورودی‌های نامعتبری ممکن است وجود داشته باشند؟
• چه Edge Caseهایی قابل تصور هستند؟
• چه محدودیت‌هایی وجود دارد؟
• آیا حالت‌های استثنایی مشخص شده‌اند؟

آیا Business Rule مرتبط وجود دارد؟

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

آیا Acceptance Criteria مشخص است؟

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

آیا نیازمندی قابل تست است؟

• آیا می‌توان بر اساس Requirement Test Condition تعریف کرد؟
• آیا معیار Pass یا Fail مشخص است؟
• آیا اطلاعات لازم برای بررسی رفتار سیستم وجود دارد؟

آیا وابستگی وجود دارد؟

• این Requirement به کدام قابلیت‌ها وابسته است؟
• آیا به API یا سرویس خارجی وابستگی دارد؟
• آیا اجرای آن به داده یا تنظیمات خاصی نیاز دارد؟

مثال عملی: بررسی یک Requirement از دید QA

فرض کنید Requirement زیر در اختیار تیم قرار گرفته است:

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

در نگاه اول، Requirement ساده به نظر می‌رسد؛ اما از دید QA پرسش‌های مختلفی ایجاد می‌شود.

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

این پرسش‌ها لزوماً به این معنا نیستند که همه پاسخ‌ها باید در یک Requirement نوشته شوند. بخشی از پاسخ ممکن است در Acceptance Criteria، Business Ruleها، طراحی محصول یا تصمیم‌های فنی مشخص شود.

نکته مهم این است که QA بتواند موارد نامشخص را شناسایی کند و قبل از تبدیل Requirement به Test Case، درباره رفتار مورد انتظار به درک کافی برسد.

Requirements برای یک تستر نرم‌افزار؛ چه چیزهایی را باید یاد بگیرید؟

برای فعالیت مؤثر در Testing، لازم نیست یک تستر نقش Business Analyst یا Product Manager را بر عهده بگیرد؛ اما باید بتواند نیازمندی‌ها را بخواند، تحلیل کند و تأثیر آن‌ها را بر Testing درک کند.

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

• آشنایی با مفهوم Requirement و انواع نیازمندی‌ها
• درک تفاوت Functional و Non-Functional Requirements
• آشنایی با User Story و Acceptance Criteria
• شناخت مفاهیمی مانند BRD، SRS و سایر مستندات نیازمندی
• یادگیری نحوه بررسی ابهام، نقص و تناقض در Requirements
• آشنایی با Requirements Review
• درک ارتباط Requirement با Test Condition و Test Case
• آشنایی با Traceability و Change Impact Analysis
• توانایی مطرح کردن سؤال‌های مناسب درباره رفتار مورد انتظار سیستم

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

Checklist بررسی Requirement

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

• ☐ آیا Requirement واضح است؟
• ☐ آیا ابهام قابل توجهی ندارد؟
• ☐ آیا اطلاعات لازم برای درک رفتار مورد انتظار کامل است؟
• ☐ آیا با سایر Requirements تناقض ندارد؟
• ☐ آیا با محدودیت‌ها و شرایط پروژه قابل اجراست؟
• ☐ آیا قابل تست یا قابل بررسی است؟
• ☐ آیا تا حد امکان Atomic است و چند نیاز مستقل را بدون دلیل در یک Requirement ترکیب نکرده است؟
• ☐ آیا در صورت نیاز شناسه مشخصی دارد؟
• ☐ آیا ارتباط و Traceability آن با سایر موارد قابل مدیریت است؟
• ☐ آیا Priority آن مشخص شده است؟
• ☐ آیا منبع یا منشأ Requirement در صورت نیاز مشخص است؟
• ☐ آیا Acceptance Criteria یا معیار پذیرش مورد نیاز برای آن مشخص شده است؟

همه این موارد لزوماً برای هر پروژه و هر Requirement ضروری نیستند. میزان جزئیات و مستندسازی باید با عواملی مانند اندازه پروژه، پیچیدگی سیستم، میزان ریسک و نیازهای تیم متناسب باشد.

یک نکته مهم: Requirement خوب لزوماً Requirement طولانی نیست

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

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

برای مثال، ممکن است یک User Story کوتاه باشد، اما جزئیات لازم در موارد زیر ثبت شده باشند:

• Acceptance Criteria
• Business Rules
• نمونه‌ها و Exampleها
• Mockup یا Prototype
• مستندات فنی
• تصمیم‌های ثبت‌شده تیم

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

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

اولویت‌بندی نیازمندی‌ها

همه Requirements از نظر اهمیت یکسان نیستند. ممکن است برخی نیازمندی‌ها برای ارائه نسخه اولیه محصول ضروری باشند، در حالی که برخی دیگر ارزشمند هستند اما می‌توان اجرای آن‌ها را به زمان دیگری موکول کرد.

اولویت‌بندی نیازمندی‌ها به تیم کمک می‌کند تصمیم بگیرد کدام نیازها باید زودتر مورد توجه قرار گیرند و منابع پروژه چگونه تخصیص پیدا کنند.

برای تعیین اولویت یک Requirement ممکن است عوامل مختلفی در نظر گرفته شوند:

• ارزش کسب‌وکار
• نیاز کاربران
• ریسک
• وابستگی به سایر قابلیت‌ها
• هزینه و پیچیدگی پیاده‌سازی
• الزامات قانونی یا قراردادی
• زمان‌بندی و اهداف Release

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

• Must have: نیازمندی‌هایی که برای هدف یا نسخه مورد نظر ضروری هستند.
• Should have: نیازمندی‌های مهمی که در صورت امکان باید انجام شوند.
• Could have: مواردی که ارزشمند هستند اما اولویت پایین‌تری دارند.
• Won’t have for now: مواردی که در محدوده فعلی انجام نمی‌شوند.

اولویت‌بندی فقط یک فعالیت مربوط به Product یا Business نیست. برای QA نیز اهمیت دارد، زیرا می‌تواند در شناخت بخش‌های مهم‌تر سیستم، تحلیل ریسک و برنامه‌ریزی Testing مؤثر باشد.

Requirements را کجا مستند می‌کنیم؟

بسته به نوع پروژه، روش توسعه و فرآیند سازمان، Requirements می‌توانند در Artifactها و مستندات مختلفی ثبت شوند.

BRD

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

SRS

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

FRD

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

User Story

در محیط‌های Agile، User Story یکی از روش‌های رایج برای بیان نیاز از دید کاربر است.

Acceptance Criteria

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

Product Backlog

در محیط‌های Agile، آیتم‌های محصول می‌توانند در Product Backlog نگهداری و مدیریت شوند.

مستندسازی بیش از حد هم می‌تواند مشکل‌ساز باشد

همان‌طور که مستندسازی ناکافی می‌تواند باعث ابهام و سوءبرداشت شود، مستندسازی بیش از حد (Over-Documentation) نیز ممکن است مشکلاتی ایجاد کند.

اگر برای یک Requirement ساده چندین صفحه توضیح نوشته شود، ممکن است:

• نگهداری مستندات دشوارتر شود.
• اعمال و مدیریت تغییرات زمان بیشتری نیاز داشته باشد.
• اطلاعات مهم در میان جزئیات غیرضروری گم شوند.
• زمان و انرژی زیادی صرف Documentation شود.

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

میزان Documentation در Agile چقدر باید باشد؟

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

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

• Description
• Acceptance Criteria
• Priority

اما یک Feature پیچیده ممکن است به اطلاعات و مستندات بیشتری نیاز داشته باشد، مانند:

• Diagram
• Business Rules
• API Contract
• Data Model
• Security Requirements
• Non-Functional Requirements

بنابراین میزان Documentation باید متناسب با Complexity، Risk و نیازهای پروژه تعیین شود.

Requirement و Design را با یکدیگر مخلوط نکنیم

مستندسازی Requirement نباید بدون دلیل وارد جزئیات مربوط به راه‌حل یا نحوه پیاده‌سازی شود.

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

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

این Requirement مشخص می‌کند سیستم چه قابلیتی باید داشته باشد.

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

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

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

یا:

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

چنین مواردی می‌توانند به‌عنوان Constraint ثبت شوند و بر طراحی و پیاده‌سازی سیستم تأثیر بگذارند.

Checklist مستندسازی Requirements

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

• ☐ آیا Requirement شناسه مشخصی دارد؟
• ☐ آیا Description آن واضح است؟
• ☐ آیا نوع Requirement مشخص است؟
• ☐ آیا Source یا منشأ Requirement مشخص است؟
• ☐ آیا Priority آن مشخص است؟
• ☐ آیا Status آن مشخص است؟
• ☐ آیا در صورت نیاز Acceptance Criteria تعریف شده است؟
• ☐ آیا Business Ruleهای مرتبط مشخص شده‌اند؟
• ☐ آیا Dependencyهای مهم مشخص هستند؟
• ☐ آیا Requirement با سایر موارد مرتبط سازگار است؟
• ☐ آیا Version یا Change History در صورت نیاز قابل پیگیری است؟
• ☐ آیا Requirement قابل تست یا قابل بررسی است؟
• ☐ آیا اطلاعات اضافی و غیرضروری از مستند حذف شده‌اند؟

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

Requirements Documentation یعنی تبدیل نیازهای شناسایی‌شده به اطلاعاتی ساختاریافته، قابل فهم و قابل استفاده برای اعضای مختلف تیم.

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

• BRD
• SRS
• FRD
• User Story
• Acceptance Criteria
• Product Backlog

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

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

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

یکی از مهم‌ترین ارتباط‌های Requirements Engineering با حوزه QA و Software Testing، استفاده از Requirement به‌عنوان یکی از مبانی طراحی و اجرای تست است.

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

Requirement
↓
Acceptance Criteria
↓
Test Scenario
↓
Test Case
↓
Test Execution
↓
Defect

کیفیت Requirement می‌تواند مستقیماً بر کیفیت Test Caseها، Test Coverage و حتی تشخیص Defectها تأثیر بگذارد.

به همین دلیل، حضور QA در مراحل اولیه بررسی و تحلیل Requirements می‌تواند به شناسایی زودتر ابهام‌ها و مشکلات احتمالی کمک کند.

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

Requirement نقطه شروع طراحی تست نیست، اما یکی از مهم‌ترین Test Basisها است

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

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

• Requirements
• Specifications
• User Stories
• Acceptance Criteria
• Business Rules
• Design Documents
• Contracts
• قوانین و مقررات

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

بنابراین، Requirement یکی از منابع مهم Test Basis است، اما تنها منبع آن نیست. :contentReference[oaicite:1]{index=1} :contentReference[oaicite:2]{index=2}

یک مثال ساده از تبدیل Requirement به Test Scenario

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

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

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

Positive Scenario

Email و Password معتبر هستند.

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

Negative Scenario

Password واردشده اشتباه است.

Expected Result: ورود نباید انجام شود و سیستم باید پیام خطای مناسب نمایش دهد.

Validation Scenario

Email با Format نامعتبر وارد شود.

Expected Result: سیستم باید از ارسال اطلاعات نامعتبر جلوگیری کند.

بنابراین، یک Requirement نسبتاً ساده می‌تواند مبنای چندین Test Scenario باشد. :contentReference[oaicite:3]{index=3}

نوع Requirement چه تأثیری بر Testing دارد؟

نوع Requirement می‌تواند بر نوع Testing و Test Strategy تأثیر بگذارد.

نوع Requirement	نمونه Testing Artifact یا فعالیت تست
Functional Requirement	Test Scenario / Test Case
Acceptance Criteria	Acceptance Test
Performance Requirement	Performance Test
Security Requirement	Security Test
Usability Requirement	Usability Evaluation
Accessibility Requirement	Accessibility Test

بنابراین، همه Requirements لزوماً به یک نوع Test Case تبدیل نمی‌شوند و ماهیت Requirement می‌تواند نوع بررسی مورد نیاز را مشخص کند. :contentReference[oaicite:4]{index=4}

Requirements-Based Testing

در Requirements-Based Testing، Testها با تکیه بر Requirements و معیارهای تعریف‌شده برای آن‌ها طراحی می‌شوند.

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

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

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

• TC-01: موجودی = ۱۰ → ثبت سفارش باید موفق باشد.
• TC-02: موجودی = ۱ → ثبت سفارش باید موفق باشد.
• TC-03: موجودی = ۰ → ثبت سفارش نباید انجام شود.
• TC-04: موجودی = مقدار نامعتبر → رفتار سیستم باید مطابق Requirement یا Validation Rule باشد.

در این حالت Testها مستقیماً با Requirement ارتباط دارند، اما برای طراحی کامل تست ممکن است Business Rules، Risk و سایر منابع Test Basis نیز مورد توجه قرار گیرند. :contentReference[oaicite:5]{index=5}

Acceptance Criteria و Testing

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

برای مثال:

User Story

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

Acceptance Criteria

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

QA می‌تواند بر اساس این Criteria یک یا چند Test Scenario و Test Case طراحی کند. به همین دلیل Acceptance Criteria ارتباط نزدیکی با Acceptance Testing دارد. :contentReference[oaicite:6]{index=6}

اگر Requirement ناقص باشد چه اتفاقی می‌افتد؟

فرض کنیم Requirement فقط این باشد:

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

از دید QA، این Requirement پرسش‌های مختلفی ایجاد می‌کند:

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

اگر رفتار مورد انتظار در Requirement یا سایر منابع معتبر مشخص نشده باشد، تعیین Expected Behavior بر اساس فرضیات شخصی می‌تواند باعث اختلاف میان Tester، Developer و Business شود. :contentReference[oaicite:7]{index=7}

Requirement و Expected Result

یکی از مهم‌ترین بخش‌های Test Case، Expected Result است؛ اما Expected Result باید بر اساس یک Test Basis معتبر تعیین شود.

برای مثال، اگر Requirement فقط بگوید:

کاربر باید بتواند Password را تغییر دهد.

ممکن است هنوز مشخص نباشد پس از تغییر Password چه اتفاقی برای Sessionهای فعال می‌افتد یا آیا کاربر باید Logout شود.

اگر این رفتار در Requirements یا سایر منابع معتبر مشخص نشده باشد، ثبت Defect صرفاً بر اساس انتظار شخصی Tester می‌تواند نادرست باشد.

Requirement ضعیف → Expected Result نامطمئن → Test نامطمئن

Requirements و Defect

Requirement یا سایر منابع معتبر Test Basis می‌توانند مبنایی برای تشخیص Defect باشند.

فرض کنیم Requirement مشخص کرده است:

سیستم باید بعد از سه تلاش ناموفق Login، حساب را برای ۱۰ دقیقه Lock کند.

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

در این حالت می‌توان ارتباط زیر را در نظر گرفت:

Requirement
↓
Expected Behavior
↓
Actual Behavior
↓
Mismatch
↓
Defect

بنابراین، Defect زمانی معنا پیدا می‌کند که رفتار واقعی سیستم با یک Test Basis معتبر، Requirement یا معیار پذیرفته‌شده مقایسه شود. :contentReference[oaicite:8]{index=8}

اما هر اختلافی الزاماً Bug نیست

این نکته بسیار مهم است. هر رفتاری که از نظر QA غیرمنتظره به نظر می‌رسد، الزاماً یک Defect یا Bug نیست.

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

برای مثال، ممکن است QA انتظار داشته باشد پس از تغییر Password، تمام Sessionهای فعال کاربر پایان پیدا کنند. اما اگر چنین رفتاری در Requirement، Acceptance Criteria، Business Rule، Design یا سایر منابع معتبر مشخص نشده باشد، این انتظار شخصی به‌تنهایی برای ثبت Defect کافی نیست.

در چنین شرایطی ابتدا باید مشخص شود:

• آیا رفتار مورد انتظار در Requirement یا مستندات مرتبط مشخص شده است؟
• آیا Acceptance Criteria یا Business Rule مرتبطی وجود دارد؟
• آیا تصمیم یا توافق ثبت‌شده‌ای درباره این رفتار وجود دارد؟
• آیا موضوع در واقع یک ابهام یا نقص در Requirement است؟

اگر رفتار مورد انتظار مشخص نباشد، ممکن است مسئله اصلی نه یک Bug در سیستم، بلکه ابهام یا ناقص بودن نیازمندی باشد.

رفتار غیرمنتظره همیشه به معنای Bug نیست؛ ابتدا باید مشخص شود انتظار ما بر چه Test Basis معتبری استوار است.

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

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

بسیاری از این مشکلات در مراحل اولیه کوچک به نظر می‌رسند، اما در ادامه می‌توانند باعث سوءبرداشت، توسعه اشتباه، افزایش Rework و پیچیده‌تر شدن Testing شوند.

نوشتن Requirement مبهم

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

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

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

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

ناقص بودن Requirement

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

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

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

در چنین شرایطی، توسعه‌دهنده، QA و سایر اعضای تیم ممکن است هرکدام فرض متفاوتی داشته باشند.

ترکیب چند Requirement مستقل در یک مورد

گاهی چند نیاز مستقل در یک Requirement نوشته می‌شوند. این موضوع می‌تواند مدیریت، اولویت‌بندی، تغییر و Traceability را دشوارتر کند.

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

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

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

نوشتن راه‌حل به جای بیان نیاز

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

برای مثال:

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

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

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

نادیده گرفتن Non-Functional Requirements

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

در نتیجه، ممکن است تا مراحل پایانی پروژه پرسش‌هایی درباره موارد زیر مطرح شوند:

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

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

نبود معیار مشخص برای پذیرش

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

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

مدیریت نکردن تغییرات

Requirements در طول پروژه ممکن است تغییر کنند، اما اگر این تغییرات به‌درستی ثبت و بررسی نشوند، احتمال ایجاد ناسازگاری میان Requirement، Design، Implementation و Test افزایش پیدا می‌کند.

هر تغییر مهم باید تا حد امکان از نظر تأثیر بر سایر بخش‌های سیستم و Artifactهای مرتبط بررسی شود.

فرض کردن به جای پرسیدن

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

این موضوع می‌تواند باعث شود یک قابلیت دقیقاً مطابق انتظار یک نفر پیاده‌سازی شود، اما با انتظار Product، Business یا سایر اعضای تیم تفاوت داشته باشد.

یک سؤال مناسب در مراحل اولیه معمولاً هزینه کمتری نسبت به اصلاح یک فرض اشتباه پس از توسعه دارد.

چگونه از این اشتباهات جلوگیری کنیم؟

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

Elicit → Analyze → Document → Review → Prioritize → Validate → Trace → Change Management

1. Elicit: نیاز را کشف کنید.
2. Analyze: نیاز را تحلیل کنید.
3. Document: آن را به شکلی مناسب مستند کنید.
4. Review: Requirement را از نظر ابهام، نقص و تناقض بررسی کنید.
5. Prioritize: اولویت Requirement را مشخص کنید.
6. Validate: درباره درست بودن و مناسب بودن Requirement با Stakeholderهای مرتبط به توافق برسید.
7. Trace: ارتباط Requirement را با Artifactهای مرتبط حفظ کنید.
8. Change Management: تغییرات Requirement را کنترل و مدیریت کنید.

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

Checklist نهایی Requirements

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

• ☐ Requirement واضح است.
• ☐ ابهام جدی ندارد.
• ☐ اطلاعات لازم برای درک رفتار مورد انتظار کامل است.
• ☐ با Requirements دیگر سازگار است.
• ☐ قابل اجراست.
• ☐ قابل بررسی، Verification یا Testing است.
• ☐ تا حد امکان Atomic است.
• ☐ Priority آن مشخص است.
• ☐ Source یا منشأ آن مشخص است.
• ☐ در صورت نیاز شناسه مشخصی دارد.
• ☐ Business Ruleهای مرتبط مشخص شده‌اند.
• ☐ در صورت نیاز Acceptance Criteria دارد.
• ☐ Negative Scenarioهای مهم در نظر گرفته شده‌اند.
• ☐ Dependencyهای مهم مشخص شده‌اند.
• ☐ در صورت تغییر، Impact آن بررسی شده است.

جمع‌بندی

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

تیم دقیقاً نمی‌دانسته چه چیزی باید ساخته شود.

Requirementهای مبهم، ناقص، غیرقابل تست یا متناقض می‌توانند باعث مشکلات مختلفی شوند:

• Rework
• اختلاف بین اعضای تیم
• افزایش هزینه
• تأخیر در پروژه
• ایجاد Defect
• و در برخی موارد، شکست پروژه

به همین دلیل، Requirements Engineering فقط درباره نوشتن Requirements نیست؛ بلکه درباره ایجاد درک مشترک از چیزی است که قرار است ساخته شود.

منابع

• 
  
  ISO/IEC/IEEE 29148:2018 — Systems and Software Engineering: Requirements Engineering
  
  
• 
  
  ISO Online Browsing Platform — ISO/IEC/IEEE 29148:2018
  
  
• 
  
  The Scrum Guide — The Definitive Guide to Scrum
  
  
• 
  
  Atlassian — Requirements Management
  
  
• 
  
  Atlassian — User Stories
  
  
• 
  
  Atlassian — Acceptance Criteria
  
  

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

نیازمندی نرم‌افزار (Software Requirement) چیست؟

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

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

تفاوت Requirement و Feature چیست؟

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

Feature معمولاً یک قابلیت یا ویژگی قابل ارائه به کاربر است که برای ایجاد ارزش مشخصی در محصول طراحی می‌شود.

برای مثال:

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

Feature: قابلیت جستجوی محصول با فیلترهای مختلف.

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

تفاوت Functional و Non-Functional Requirement چیست؟

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

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

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

درخواست Reset Password باید در کمتر از ۲ ثانیه پاسخ داده شود.

BRD چیست؟

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

BRD بیشتر روی این سؤال تمرکز دارد:

چرا این محصول یا سیستم لازم است و کسب‌وکار چه چیزی می‌خواهد؟

SRS چیست؟

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

SRS معمولاً جزئیات بیشتری درباره رفتار مورد انتظار سیستم نسبت به Business Requirements ارائه می‌کند.

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

SRS می‌تواند مرجع مهمی برای Development و Testing باشد.

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

به شکل ساده، BRD بیشتر بر نیاز و هدف کسب‌وکار و سؤال Why تمرکز دارد، در حالی که SRS نیازمندی‌های نرم‌افزار و سؤال What را با جزئیات بیشتری مشخص می‌کند.

برای مثال:

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

SRS: سیستم باید امکان افزودن محصول به Cart، ثبت آدرس و ایجاد Order را فراهم کند.

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

FRD چیست؟

FRD (Functional Requirements Document) سندی است که Functional Requirements سیستم را با جزئیات بیشتری مستند می‌کند.

FRD در همه سازمان‌ها یک سند مستقل یا استاندارد اجباری نیست و ممکن است برخی سازمان‌ها Functional Requirements را در SRS یا سایر Artifactها مدیریت کنند.

User Story چیست؟

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

یک قالب رایج آن به شکل زیر است:

As a [user], I want [goal], so that [benefit].

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

User Story در محیط‌های Agile کاربرد زیادی دارد.

Acceptance Criteria چیست؟

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

سفارش قبل از ارسال قابل لغو باشد.

سفارش ارسال‌شده قابل لغو نباشد.

Acceptance Criteria ارتباط نزدیکی با Acceptance Testing و QA دارد.

آیا Requirement باید همیشه به شکل یک سند نوشته شود؟

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

• SRS
• User Story
• Acceptance Criteria
• Product Backlog
• Business Rule
• Diagram
• Specification

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

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

یک Requirement خوب، متناسب با زمینه پروژه، باید تا حد امکان:

• واضح باشد.
• ابهام نداشته باشد.
• کامل باشد.
• قابل بررسی باشد.
• قابل تست یا Verification باشد.
• با Requirements دیگر سازگار باشد.
• قابل پیگیری باشد.
• در صورت نیاز اولویت داشته باشد.

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

آیا Requirements در طول پروژه تغییر می‌کنند؟

بله. تغییر در Requirements اتفاق رایجی است و می‌تواند به دلایل مختلفی رخ دهد:

• تغییر نیاز کسب‌وکار
• Feedback کاربران
• تغییر قوانین
• تغییر بازار
• کشف Requirement اشتباه یا ناقص
• تغییر اولویت محصول
• تغییرات فنی

موضوع مهم این است که تغییرات کنترل و مدیریت شوند، نه اینکه الزاماً از آن‌ها جلوگیری شود.

Requirements Traceability چیست؟

Requirements Traceability یعنی بتوان ارتباط یک Requirement را با Artifactهای مرتبط در طول چرخه توسعه دنبال کرد.

Requirement → User Story → Acceptance Criteria → Test Case → Defect

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

RTM چیست؟

RTM (Requirements Traceability Matrix) جدولی است که ارتباط Requirements با موارد مرتبط، به‌خصوص Test Caseها، را نشان می‌دهد.

Requirement	Test Case
REQ-001	TC-001
REQ-002	TC-002, TC-003
REQ-003	TC-004

RTM یکی از روش‌های پیاده‌سازی Traceability است، اما Traceability محدود به RTM نیست.

آیا هر Requirement باید Test Case داشته باشد؟

اگر Requirement قابل تست باشد، معمولاً باید بتوان Verification یا Testing مناسب برای آن تعریف کرد.

اما رابطه همیشه به شکل یک Requirement = یک Test Case نیست.

ممکن است یک Requirement چند Test Case داشته باشد یا چند Requirement توسط مجموعه‌ای از Testها بررسی شوند.

نوع Requirement نیز مشخص می‌کند چه نوع Verification یا Testing برای آن مناسب است.

QA چه نقشی در Requirements دارد؟

QA فقط پس از تولید نرم‌افزار وارد فرآیند نمی‌شود و می‌تواند در فعالیت‌های مختلف مرتبط با Requirements مشارکت کند:

• Requirements Review
• شناسایی Ambiguity
• بررسی Testability
• شناسایی Missing Requirements
• بررسی Acceptance Criteria
• تحلیل Risk
• بررسی Negative Scenarioها
• تحلیل تأثیر تغییرات

در نتیجه QA می‌تواند قبل از نوشته شدن Code نیز به جلوگیری از برخی مشکلات کمک کند.

آیا Agile به SRS نیاز دارد؟

پاسخ مطلقی وجود ندارد. Agile الزام نمی‌کند که تمام Requirements حتماً در یک SRS بزرگ و ثابت قرار بگیرند.

در عین حال، Agile به معنی حذف Documentation نیست.

Requirements ممکن است در قالب‌هایی مانند User Story، Acceptance Criteria، Product Backlog و سایر مستندات مورد نیاز مدیریت شوند.

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

تفاوت Requirement، User Story و Acceptance Criteria چیست؟

به شکل ساده:

Requirement: سیستم چه نیازی را باید برآورده کند؟

User Story: این نیاز را از دیدگاه چه کاربری و برای چه هدفی بیان می‌کنیم؟

Acceptance Criteria: از کجا بفهمیم این نیاز به شکل مورد انتظار پیاده‌سازی شده است؟

برای مثال:

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

User Story: به عنوان مشتری، می‌خواهم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، بتوانم خرید را متوقف کنم.

Acceptance Criteria: سفارش قبل از ارسال قابل لغو باشد.

بهترین ابزار برای مدیریت Requirements چیست؟

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

• اندازه پروژه
• تعداد Requirements
• تعداد اعضای تیم
• نیاز به Traceability
• روش توسعه
• سطح کنترل و Compliance

برای یک پروژه کوچک ممکن است یک ابزار ساده مدیریت مستندات کافی باشد، در حالی که پروژه‌های بزرگ‌تر ممکن است به یک Requirements Management Platform اختصاصی نیاز داشته باشند.

آیا Requirements فقط برای پروژه‌های بزرگ هستند؟

خیر. حتی در یک پروژه کوچک نیز مشخص کردن اینکه چه چیزی باید ساخته شود و چگونه می‌توان تشخیص داد درست ساخته شده است اهمیت دارد.

تفاوت بیشتر در میزان Formality و Documentation است.