فرقش با PRD در یک جمله این است: مستند نیازمندی پروژه (PRD) بیشتر میگوید «چه محصولی و چرا»، و SRS میگوید «سیستم دقیقاً چه رفتاری داشته باشد».
در ادامه از نگاه کارفرما توضیح داده‌ایم SRS چه بخش‌هایی دارد، چه کسی آن را می‌نویسد و قبل از امضای قرارداد چطور بررسی‌اش کنید.
SRS دقیقاً چیست و چه مشکلی را حل می‌کند؟
وقتی کارفرما میگوید «یک سامانه نوبت‌دهی می‌خواهیم»، هر پیمانکار تصویر متفاوتی در ذهن می‌سازد. یکی فقط فرم رزرو را می‌بیند. دیگری پرداخت آنلاین، پیامک یادآوری و پنل پزشک را هم حساب می‌کند.
SRS این تصویرها را یکی می‌کند. همه آنچه سیستم باید انجام دهد روی کاغذ می‌آید، با جزئیاتی که بشود ساخت و تست کرد. هر چیزی هم که در نسخه فعلی نیست، صریحاً «خارج از محدوده» نوشته می‌شود.
چرا بدون SRS، برآورد هزینه و زمان قابل اعتماد نیست
هزینه و زمان ساخت نرم‌افزار از روی کارهایی که باید انجام شود حساب می‌شود. اگر کارها مشخص نباشد، برآورد یک حدس است.
نتیجه معمولاً یکی از این دو است: یا پیمانکار برای پوشش ریسک عدد بالاتری می‌دهد، یا عدد پایین می‌دهد و وسط کار «امکانات اضافه» قیمت جدا پیدا می‌کنند. SRS هر دو را کم می‌کند، چون دو طرف درباره یک فهرست مشخص قیمت می‌دهند و قیمت می‌گیرند. وقتی نیازمندیها روشن شد، می‌توانید با برآورد هزینه پروژه یک بازه تقریبی هم ببینید.
تفاوت SRS با PRD و BRD
سه سند در پروژه‌های نرم‌افزاری زیاد شنیده می‌شوند. BRD (Business Requirements Document) سند نیازمندیهای کسبوکار است. PRD (Product Requirements Document) سند نیازمندی محصول است. SRS سند نیازمندیهای نرم‌افزار است.
| معیار | BRD | PRD | SRS |
|---|---|---|---|
| سؤالی که جواب می‌دهد | کسبوکار چه هدفی دارد و چرا این پروژه لازم است؟ | چه محصولی، برای چه کسی و با چه امکاناتی؟ | سیستم دقیقاً چه رفتاری دارد و با چه کیفیتی؟ |
| مخاطب اصلی | مدیران و سرمایه‌گذاران | مدیر محصول، طراح، تیم فنی | برنامه‌نویس، تستر، کارفرما در قرارداد |
| سطح جزئیات | کلی | متوسط | دقیق و قابل تست |
| چه کسی می‌نویسد | کارفرما یا تحلیلگر کسبوکار | مدیر محصول | تحلیلگر سیستم با همکاری کارفرما |
آیا پروژه شما به هر سه سند جدا نیاز دارد؟
برای بیشتر پروژه‌های کوچک و متوسط، نه. یک مستند یکپارچه که هدف کسبوکار، امکانات محصول و نیازمندیهای دقیق سیستم را با هم داشته باشد کافی است. ما در تکنوراه همین مستند یکپارچه را تدوین می‌کنیم و توضیح کاملش را در صفحه مستند نیازمندی پروژه (PRD) آورده‌ایم.
سه سند جدا بیشتر در سازمان‌های بزرگ لازم می‌شود، جایی که تیم‌های مختلف هر کدام بخشی را تأیید می‌کنند.
چه کسی SRS را می‌نویسد؟
SRS کار یک نفر نیست. کارفرما و تحلیلگر هر کدام بخشی را می‌دانند که دیگری نمی‌داند.
نقش کارفرما: هدف، فرایندها، قواعد کسبوکار
فقط شما میدانید کسب‌وکارتان چطور کار می‌کند. سهم شما در SRS این‌هاست:
- هدف پروژه و مشکلی که باید حل شود
- فرایندهای فعلی، مثلاً سفارش امروز از کجا می‌آید و چه مسیری طی می‌کند
- قواعد کسبوکار، مثل شرایط تخفیف، لغو نوبت یا بازگشت وجه
- سیستم‌هایی که الان دارید و باید به نرم‌افزار وصل شوند
- اولویت‌ها، یعنی چه چیزی باید در نسخه اول باشد و چه چیزی می‌تواند صبر کند
نقش تحلیلگر یا پیمانکار: تبدیل نیاز به نیازمندی قابل تست
تحلیلگر نیاز شما را به جمله‌هایی تبدیل می‌کند که بشود ساخت و تست کرد. مثلاً «سیستم سریع باشد» را به یک معیار قابل اندازه‌گیری تبدیل می‌کند و حالت‌های استثنا را می‌پرسد، مثل اینکه اگر پرداخت نیمه‌کاره ماند چه شود.
اگر نرم‌افزار سفارشی می‌خواهید، تحلیل نیازمندی معمولاً اولین مرحله توسعه نرم‌افزار سفارشی است.
ساختار سند نیازمندیهای نرم‌افزار
ساختار رایج SRS بر پایه IEEE 830 است؛ استانداردی که مؤسسه مهندسان برق و الکترونیک (IEEE) برای نوشتن SRS منتشر کرده است. لازم نیست همه بندهایش را عیناً رعایت کنید، ولی این بخش‌ها باید در سند باشند.
مقدمه، هدف و محدوده
هدف نرم‌افزار، مخاطبانش و مرز پروژه. مهم‌ترین بند این بخش فهرست «خارج از محدوده» است.
کاربران و نقش‌ها
چه کسانی از سیستم استفاده می‌کنند و هر کدام چه دسترسی‌ای دارند. مثلاً مشتری، اپراتور، مدیر شعبه و مدیر کل.
نیازمندیهای عملکردی
کارهایی که سیستم انجام می‌دهد: ثبت‌نام، جستجو، ثبت سفارش، پرداخت، گزارش‌گیری.
نیازمندیهای غیرعملکردی
کیفیت انجام آن کارها: سرعت، امنیت، در دسترس بودن، سازگاری با دستگاه‌ها.
رابط‌ها و اتصال به سیستم‌های دیگر
اتصال به درگاه پرداخت، پنل پیامکی، نرم‌افزار حسابداری یا CRM (نرم‌افزار مدیریت ارتباط با مشتری). برای هر اتصال بنویسید چه داده‌ای، در چه زمانی و به کدام جهت جابه‌جا می‌شود.
قواعد کسبوکار، محدودیتها و فرض‌ها
قواعدی که سیستم باید رعایت کند، محدودیت‌هایی مثل بودجه، زمان یا الزامات قانونی، و فرض‌هایی که پروژه بر پایه آنها برآورد شده است.
معیارهای پذیرش
شرط‌هایی که مشخص می‌کنند یک امکان «تمام‌شده» حساب می‌شود. این بخش مبنای تحویل و تسویه است. جزئیاتش را در مقاله معیار پذیرش نوشتهایم.
نیازمندیهای عملکردی و غیرعملکردی با مثال
مثال‌های زیر از یک سامانه نوبت‌دهی آنلاین برای یک کلینیک است. همه عددهای این بخش مثال فرضی‌اند، نه آمار یا توصیه عمومی.
| نوع | مثال |
|---|---|
| عملکردی | بیمار با شماره موبایل و کد یک‌بارمصرف (OTP) وارد می‌شود. |
| عملکردی | بیمار پزشک، روز و ساعت خالی را انتخاب می‌کند و نوبت را با پرداخت آنلاین قطعی می‌کند. |
| عملکردی | یک روز قبل از نوبت، پیامک یادآوری برای بیمار ارسال می‌شود. |
| عملکردی | منشی می‌تواند نوبت را جابه‌جا یا لغو کند و دلیل آن ثبت می‌شود. |
| غیرعملکردی | صفحه انتخاب نوبت در اینترنت موبایل معمولی زیر ۳ ثانیه باز شود (مثال فرضی). |
| غیرعملکردی | سیستم هم‌زمان ۲۰۰ کاربر را بدون خطا پشتیبانی کند (مثال فرضی). |
| غیرعملکردی | اطلاعات پزشکی بیماران فقط برای پزشک معالج و مدیر قابل مشاهده باشد. |
| غیرعملکردی | سامانه روی نسخه‌های رایج مرورگرهای موبایل و دسکتاپ درست نمایش داده شود. |
عدد واقعی این معیارها را باید با توجه به کسبوکار خودتان و با کمک تیم فنی تعیین کنید.
نمونه کوتاه سند SRS برای یک سامانه نوبت‌دهی
این اسکلت نیم‌صفحه‌ای برای همان سامانه نوبت‌دهی است. هدفش نشان دادن شکل سند است، نه یک قالب کامل.
| بخش | محتوای نمونه |
|---|---|
| هدف | کاهش تماس‌های تلفنی برای رزرو و حذف نوبت‌های فراموش‌شده |
| محدوده | رزرو آنلاین، پرداخت، یادآوری پیامکی، پنل منشی و پزشک |
| خارج از محدوده | پرونده الکترونیک سلامت، اپ موبایل در نسخه اول |
| نقش‌ها | بیمار، منشی، پزشک، مدیر |
| اتصالها | درگاه پرداخت، پنل پیامکی |
| قاعده کسبوکار | لغو تا ۲۴ ساعت قبل با بازگشت کامل وجه (مثال فرضی) |
| معیار پذیرش نمونه | بیمار بعد از پرداخت موفق، پیامک تأیید با تاریخ و ساعت نوبت دریافت می‌کند. |
برای دیدن یک مستند کامل‌تر، نمونه ساختار PRD را ببینید.
یک نیازمندی خوب چه ویژگی‌هایی دارد؟
یک نیازمندی خوب این پنج ویژگی را دارد:
- روشن: فقط یک برداشت از آن می‌شود.
- کامل: حالت‌های عادی و استثنا را میگوید.
- قابل تست: می‌شود بررسی کرد که انجام شده یا نه.
- قابل ردیابی: شماره دارد و می‌شود آن را به طراحی، تست و قرارداد وصل کرد.
- بدون تناقض: با نیازمندی دیگری در سند تعارض ندارد.
| نیازمندی بد | نیازمندی خوب |
|---|---|
| سیستم باید کاربرپسند باشد. | بیمار بتواند در کمتر از ۴ مرحله نوبت بگیرد (مثال فرضی). |
| پرداخت باید امن باشد. | پرداخت فقط از طریق درگاه بانکی انجام شود و اطلاعات کارت در سیستم ذخیره نشود. |
| گزارش فروش داشته باشد. | مدیر بتواند گزارش نوبت‌ها و مبلغ دریافتی را به تفکیک پزشک و بازه تاریخ ببیند و خروجی اکسل بگیرد. |
خیلی از تیم‌ها نیازمندیهای عملکردی را به شکل User Story می‌نویسند. توضیحش در User Story چیست آمده است.
SRS در قرارداد و کنترل محدوده پروژه
SRS فقط سند فنی نیست. اگر پیوست قرارداد شود، مهم‌ترین ابزار شما برای کنترل زمان و هزینه است.
SRS، معیار پذیرش و جلوگیری از Scope Creep
Scope Creep یعنی بزرگ شدن تدریجی و برنامه‌ریزی‌نشده محدوده پروژه. هر درخواست کوچک «این را هم اضافه کنید» در ظاهر بی‌خطر است، ولی جمعشان زمان و هزینه را بالا می‌برد.
وقتی SRS و معیارهای پذیرش پیوست قرارداد باشند، هر درخواست جدید با سند مقایسه می‌شود. اگر در سند نبود، درخواست تغییر حساب می‌شود و اثرش روی زمان و هزینه جدا برآورد می‌شود. روش کامل را در جلوگیری از Scope Creep توضیح داده‌ایم.
SRS و RFP؛ از درخواست پیشنهاد تا قرارداد
RFP (Request for Proposal) سندی است که کارفرما برای دریافت پیشنهاد قیمت و زمان به چند پیمانکار می‌فرستد. هرچه نیازمندیهای داخل RFP دقیق‌تر باشد، پیشنهادها قابل مقایسه‌ترند. برای یک قالب آماده و چک‌لیست ارسال، نمونه RFP پروژه نرم‌افزاری را ببینید.
مسیر معمول این است: یک نسخه اولیه از نیازمندیها در RFP می‌آید، پیمانکار منتخب در جلسات تحلیل آن را به SRS کامل تبدیل می‌کند، و SRS نهایی پیوست قرارداد می‌شود.
نمونه واقعی: پروپوزالی که از سند نیازمندی ساخته شده است
اگر برایتان سؤال است که بعد از سند نیازمندیها چه چیزی تحویل می‌گیرید، پروپوزال واقعی پروژه «بذر» را از دکمه دانلود پایین همین صفحه بگیرید. «بذر» یک وب‌اپلیکیشن رشد فردی است و کارفرمایش اجازه داده این سند کامل منتشر شود. این پروپوزال این بخش‌ها را دارد:
- محدوده پروژه: جدول امکانات به تفکیک بخش‌ها، از ثبت‌نام و اشتراک و پرداخت تا پنل مدیریت، همراه با بندی که میگوید تغییر امکانات یعنی محاسبه دوباره هزینه و زمان.
- فرض‌های پروژه: آنچه کارفرما فراهم می‌کند، مثل هویت بصری و محتوا.
- معماری و فرایند طراحی: معماری فنی و فرایند طراحی گام‌به‌گام، با نقطه تأیید کارفرما در هر مرحله.
- زمان‌بندی: زمان‌بندی فازبندی‌شده، با یک تاریخ برای تحویل نسخه اولیه و یک تاریخ برای تحویل نهایی.
- قیمت‌گذاری: مبنای قیمت، مقایسه نسخه کامل با نسخه اولیه (MVP) و شرایط پرداخت مرحله‌ای.
با کنار هم گذاشتن این سند و چک‌لیست بعدی، می‌بینید هر نیازمندی چطور به یک ردیف در جدول امکانات، یک فاز در زمان‌بندی و یک قلم در قیمت تبدیل می‌شود. وقتی پیشنهاد شرکت‌های مختلف را مقایسه می‌کنید، هم می‌فهمید یک پروپوزال جدی باید کدام بخش‌ها را داشته باشد و هم میدانید چه چیزی را دقیق از پیمانکار بپرسید.
چک‌لیست بررسی SRS قبل از امضای قرارداد
قبل از امضا، به هر سؤال بله یا خیر بدهید:
- هدف پروژه و مشکلی که حل می‌کند در یک پاراگراف روشن آمده است؟
- فهرست «خارج از محدوده» وجود دارد؟
- همه نقش‌های کاربری و دسترسی هر کدام نوشته شده است؟
- هر نیازمندی عملکردی شماره دارد و قابل تست است؟
- نیازمندیهای غیرعملکردی، مثل سرعت و امنیت، با معیار قابل اندازه‌گیری آمده‌اند؟
- همه اتصالها به سیستم‌های دیگر و داده‌های هر کدام مشخص است؟
- قواعد کسبوکار شما، مثل لغو، تخفیف و بازگشت وجه، درست نوشته شده است؟
- هر امکان معیار پذیرش دارد؟
- روش ثبت و قیمت‌گذاری درخواست تغییر مشخص است؟
- SRS نهایی پیوست قرارداد می‌شود؟
اگر به بیش از دو سؤال جواب خیر دادید، سند هنوز برای قرارداد آماده نیست.
قدم بعدی
تکنوراه پیش از شروع توسعه، مستند نیازمندی پروژه شما را همراه با محدوده، معیارهای پذیرش و فازبندی تدوین می‌کند. برای هماهنگی جلسه تحلیل، یک جلسه مشاوره رایگان ۱۵ دقیقه‌ای بگیرید.
وقتی نیازمندیها مشخص شد، هزینه تقریبی پروژه را با محاسبه‌گر آنلاین ببینید.
سوالات متداول
SRS را به چه زبانی و در چه قالبی بنویسیم؟
به زبانی که کارفرما و تیم فنی هر دو راحت بخوانند؛ برای پروژه‌های داخلی معمولاً فارسی، با اصطلاحات فنی به انگلیسی. قالب مهم نیست. Word یا Google Docs کافی است، به شرطی که نسخه‌ها شماره‌گذاری شوند و همه به آخرین نسخه دسترسی داشته باشند.
آیا برای یک MVP هم SRS لازم است؟
بله، ولی کوتاهتر. برای MVP کافی است امکانات اصلی، نقش کاربران، اتصالها و معیار پذیرش هر امکان نوشته شود. هرچه در نسخه اول نیست، صریحاً «خارج از محدوده» بیاید. درباره خود MVP در مقاله MVP چیست در آکادمی تکنوراه نوشتهایم.
بعد از شروع پروژه SRS قابل تغییر است؟
بله. هر تغییر باید بهصورت درخواست تغییر ثبت شود، اثرش روی زمان و هزینه برآورد شود و بعد از تأیید دو طرف، نسخه جدید سند منتشر شود.
SRS را خودمان بنویسیم یا از پیمانکار بخواهیم؟
شما هدف، فرایندها و قواعد کسبوکار را میدانید و باید آنها را بگویید. تبدیل اینها به نیازمندیهای دقیق و قابل تست کار تحلیلگر است. بهترین حالت، نوشتن مشترک در چند جلسه تحلیل است.
SRS با User Story چه فرقی دارد؟
User Story یک نیاز را در یک جمله از زبان کاربر میگوید. SRS سند کاملی است که همه نیازمندیها، کیفیتها، اتصالها و محدودیتها را یکجا دارد. User Storyها میتوانند بخشی از نیازمندیهای عملکردی SRS باشند. بیشتر را در مقاله User Story چیست در آکادمی تکنوراه بخوانید.