تحلیل نیازمندی با سند نیازمندی چه فرقی دارد؟
تحلیل «کار» است و سند «نتیجه» آن کار. در تحلیل، مسئله، نقش‌ها، فرایندها، قواعد و اولویت‌ها روشن می‌شوند. بعد همان‌ها در یک سند مکتوب می‌شوند تا تیم ساخت بداند چه چیزی را بسازد و چطور تست کند. در تحلیل، نیازمندی عملکردی و غیر عملکردی را جدا بنویسید: اولی کار سیستم است و دومی کیفیت آن.
جزئیات ساختار سند را در سند نیازمندی‌های نرم‌افزار (SRS) نوشته‌ایم. اگر می‌خواهید ببینید مستند همکاری با تکنوراه چه شکلی دارد، صفحهٔ مستند نیازمندی پروژه (PRD) را ببینید. این مقاله روی «چطور به آن سند می‌رسیم» تمرکز دارد، نه روی فهرست بخش‌های سند.
در کتاب‌ها و دانشگاه به این کار «مهندسی نیازمندی» هم می‌گویند. ما اینجا همان کار را از زاویهٔ کارفرما و جلسهٔ عملی توضیح می‌دهیم.
چرا قبل از قیمت گرفتن و کدنویسی؟
برآورد بدون تحلیل، برآورد یک فهرست امکانات است، نه یک فرایند. یک کلمه در ذهن دو نفر می‌تواند دو کار کاملاً متفاوت باشد. آن‌وقت قیمت و زمان روی فرض‌های متفاوت ساخته می‌شود و بعد از شروع کار اختلاف پیش می‌آید.
مثال فرضی: دو نفر از یک تیم فروش می‌گویند «ثبت سفارش». منظور یکی یک فرم ساده در پنل است. منظور دیگری سفارش از پیام‌رسان، تأیید موجودی و ارسال خودکار فاکتور است. بدون تحلیل، هر دو فکر می‌کنند حرف یکسانی زده‌اند.
در صفحه‌های خدمت تکنوراه، از جمله توسعه نرم‌افزار سفارشی، زمان دقیق پروژه پس از فاز صفر و نوشتن مستند نیازمندی مشخص می‌شود، نه قبل از آن. تحلیل همان مرحله‌ای است که این فرض‌ها را یکی میکند.
مراحل تحلیل نیازمندی‌های نرم‌افزار در یک نگاه
جدول زیر شش مرحلهٔ تحلیل را با سهم شما در هر مرحله نشان می‌دهد.
| مرحله | چه کاری انجام می‌شود | چه کسی | خروجی | سهم کارفرما |
|---|---|---|---|---|
| ۱. شناخت مسئله و هدف | مسئلهٔ کسبوکار را از راهکار جدا می‌کنیم؛ هدف و شاخص موفقیت را می‌نویسیم | کارفرما + تحلیلگر | جملهٔ هدف و نتیجهٔ مورد انتظار | هدف را با زبان کسبوکار بگویید؛ راهکار پیشنهادی را فعلاً کنار بگذارید |
| ۲. شناسایی ذی‌نفعان و نقش‌ها | کسانی که از سیستم اثر می‌گیرند یا روی آن تصمیم می‌گیرند (ذی‌نفعان) فهرست می‌شوند | کارفرما + تحلیلگر | فهرست نقش‌ها و تصمیمگیر نهایی | نام نقش‌ها و یک تصمیمگیر را مشخص کنید |
| ۳. جمع‌آوری نیاز | مصاحبه، مشاهدهٔ کار واقعی، بررسی فایل‌ها و سیستم‌های فعلی، کارگاه | تحلیلگر با حضور کاربران | یادداشت نیازها، فرایند فعلی، دردها | وقت جلسه بگذارید؛ دسترسی به فایل‌ها و سیستم فعلی بدهید |
| ۴. تحلیل و دسته‌بندی | فرایندها، قواعد، استثناها، اتصال به سیستم‌های دیگر و نوع هر نیاز مرتب می‌شوند | تحلیلگر / تیم فنی | فرایندهای اصلی با شروع و پایان؛ قواعد و استثناها | جواب‌های مبهم را روشن کنید؛ استثناهای واقعی را بگویید |
| ۵. اولویت‌بندی و محدودهٔ نسخهٔ اول | نیازها با «باید / بهتر است / فعلاً نه» مرتب می‌شوند؛ فهرست خارج از محدوده نوشته می‌شود | کارفرما + تحلیلگر | محدودهٔ نسخهٔ اول و فهرست خارج از محدوده | اولویت واقعی کسبوکار را اعلام کنید |
| ۶. اعتبارسنجی و تأیید | بازبینی مشترک، نمونهٔ اولیه در صورت نیاز، و معیار پذیرش (شرط‌هایی که نشان می‌دهد کار درست انجام شده) برای نیازهای مهم | همه + تصمیمگیر | سند تأییدشده برای ساخت | سند را بخوانید و مکتوب تأیید کنید |
مهم‌ترین ستون «سهم کارفرما» است. بدون حضور شما، تحلیلگر مجبور می‌شود فرض کند.
چه کسانی باید در تحلیل باشند؟
کارفرما و تصمیمگیر نهایی (یک نفر)
بدون تصمیمگیر نهایی، جلسه بی‌نتیجه می‌ماند. یک نفر باید اولویت را قطعی کند و سند را تأیید کند. این نقش در «ماتریس تصمیم‌گیری پروژه» صفحهٔ مستند نیازمندی پروژه (PRD) آمده است.
کاربران واقعی، نه فقط مدیر
اگر فقط مدیر در جلسه باشد، درد اپراتور یا مشتری نهایی دیده نمیشود. دست‌کم یک نفر از کسانی که هر روز با فرایند کار می‌کنند باید حرف بزند.
تحلیلگر یا تیم فنی
نقش تحلیلگر تبدیل نیاز کسبوکار به جمله‌ای است که بشود ساخت و تست کرد: شروع، شرط‌ها، نتیجه و معیار درست‌بودن کار.
نیازها را از کجا پیدا کنیم؟ ۵ روش جمع‌آوری نیازمندی
هر روش برای یک موقعیت به کار می‌آید:
- مصاحبه: وقتی مسئله در ذهن افراد است ولی مکتوب نیست. مثال فرضی: از منشی کلینیک بپرسید «امروز نوبت‌ها از کجا می‌آیند و کجا گم می‌شوند؟»
- مشاهدهٔ کار واقعی: وقتی افراد به کاری «عادت» کرده‌اند و در مصاحبه جزئیاتش را جا می‌اندازند. مثال فرضی: یک ساعت کنار پذیرش بنشینید و ببینید لغو نوبت واقعاً چطور ثبت می‌شود.
- بررسی سیستم‌ها و فایل‌های فعلی: وقتی کار امروز روی اکسل، فرم کاغذی، گروه پیام‌رسان یا نرم‌افزار قدیمی می‌چرخد. مثال فرضی: ستون‌های فایل نوبت هفتگی همان فیلدهای نسخهٔ اول‌اند.
- کارگاه گروهی: وقتی چند واحد باید روی یک فرایند توافق کنند. مثال فرضی: پذیرش، پزشک و حسابداری با هم مسیر «ثبت تا پرداخت» را روی تخته می‌کشند.
- نمونهٔ اولیه یا وایرفریم (طرح سادهٔ صفحه‌ها، بدون رنگ و جزئیات): وقتی بحث روی یک صفحه گیر کرده و حرف کافی نیست. مثال فرضی: یک صفحهٔ سادهٔ انتخاب ساعت را به کاربر نشان می‌دهید تا ببینید کجا گیج می‌شود.
برای نسخهٔ اول معمولاً مصاحبه به‌علاوهٔ بررسی فایل‌های فعلی کافی است.
بانک سؤال جلسهٔ اول تحلیل نیازمندی
چکلیست آمادگی قبل از جلسه در صفحهٔ مستند نیازمندی پروژه (PRD) آمده است. بانک زیر سؤال‌های خود جلسه است. جواب هر سؤال را زیر همان سؤال یادداشت کنید.
گروه ۱: هدف و مسئله
- با این نرم‌افزار دقیقاً چه مشکلی باید حل شود؟
- اگر هیچ کاری نکنید، شش ماه دیگر چه اتفاقی برای کسبوکار می‌افتد؟
- از کجا می‌فهمید نسخهٔ اول موفق بوده؟ (یک شاخص ساده، نه ده تا)
گروه ۲: کاربران و نقش‌ها
- چه کسانی هر روز با این سیستم کار می‌کنند؟ (نقش، نه اسم افراد)
- چه کسی فقط گزارش می‌بیند و چه کسی داده وارد میکند؟
- مشتری نهایی مستقیم با سیستم کار میکند یا از طریق کارکنان شما؟
- تصمیمگیر نهایی این پروژه کیست و تغییر محدوده را چه کسی تأیید میکند؟
گروه ۳: فرایند فعلی
- امروز این کار از کجا شروع می‌شود و به کجا ختم می‌شود؟
- سفارش، درخواست یا نوبت امروز از دست چند نفر رد می‌شود؟
- کجاها کار دستی، اکسل یا پیام‌رسان جای سیستم را گرفته است؟
- پرتکرارترین خطا یا گم‌شدن اطلاعات کجاست؟
گروه ۴: قواعد و استثناها
- چه قاعده‌ای اگر رعایت نشود، کار خراب می‌شود؟ (مثلاً لغو، سقف اعتبار، سطح دسترسی)
- وقتی آن قاعده برقرار نیست چه می‌کنید؟ (استثناهای واقعی، نه ایده‌آل)
- چه چیزهایی را عمداً دستی نگه می‌دارید و نباید خودکار شود؟
گروه ۵: سیستم‌ها و داده‌ها
- امروز داده کجاست؟ (اکسل، نرم‌افزار حسابداری، CRM یعنی نرم‌افزار مدیریت ارتباط با مشتری، پیام‌رسان)
- به چه سیستم‌های بیرونی باید وصل شوید؟ (پیامک، درگاه پرداخت، تقویم، بیمه و …)
- کدام گزارش‌ها حتماً باید در نسخهٔ اول باشند؟
- انتقال داده از سیستم قبلی لازم است یا از صفر شروع می‌کنید؟
اگر وقت کم است، اول گروه‌های ۱، ۳ و ۴ را پر کنید.
نیازهایتان را برای یک محدودهٔ روشن نوشته‌اید؟ برآورد اولیهٔ هزینه و زمان را از فرم تکنوراه بگیرید.
از نیاز خام تا نیازمندی روشن: یک مثال قدم‌به‌قدم (مثال فرضی)
سناریوی زیر یک مثال فرضی برای یک کلینیک است. همین سامانهٔ نوبت‌دهی در مقالهٔ سند نیازمندی‌های نرم‌افزار به شکل سند نوشته شده است. اینجا می‌بینید چطور به آن رسیدیم.
نیاز خام کارفرما: «می‌خواهم مشتری‌ها آنلاین نوبت بگیرند.»
مرحله ۱: مسئله، نه راهکار
مسئله: تماس‌های پذیرش زیاد است و گاهی یک نوبت دو بار رزرو می‌شود. هدف: بیمار ساعت آزاد را ببیند و نوبت قطعی بگیرد.
مرحله ۲: نقش‌ها
بیمار، منشی پذیرش، پزشک. تصمیمگیر: مدیر کلینیک.
مرحله ۳: جمع‌آوری
با منشی حرف می‌زنیم و فایل اکسل هفتگی را می‌بینیم. معلوم می‌شود لغو تلفنی گاهی ثبت نمیشود.
مرحله ۴: فرایند، قاعده، استثنا
طبق قالب صفحهٔ مستند نیازمندی پروژه، هر فرایند با ۴ پاسخ تعریف می‌شود:
- عنوان: رزرو نوبت آنلاین
- رویداد شروع: بیمار خدمت و پزشک را انتخاب میکند.
- مراحل و شرط‌ها: دیدن ساعت‌های آزاد ← انتخاب ← وارد کردن مشخصات ← تأیید؛ شرط: ساعت هنوز آزاد باشد.
- نتیجهٔ نهایی: نوبت قطعی ثبت می‌شود و پیام تأیید برای بیمار و پذیرش می‌رود.
قاعده: لغو تا چند ساعت قبل از نوبت برای بیمار آزاد است؛ بعد از آن فقط پذیرش می‌تواند لغو کند. استثنا: اگر پزشک غایب شود، پذیرش همهٔ نوبت‌های آن بازه را آزاد میکند و به بیماران خبر می‌دهد.
نیازمندی‌های عملکردی همان رفتار سیستم‌اند (مثل رزرو نوبت). نیازمندی‌های غیرعملکردی کیفیت آن رفتارند (مثل سرعت یا امنیت). مثال و تفکیک کامل در سند نیازمندی‌های نرم‌افزار (SRS) آمده است.
مرحله ۵: اولویت نسخهٔ اول
باید: رزرو، لغو در مهلت، دیدن نوبت‌ها برای پذیرش. بهتر است: یادآوری پیامکی. فعلاً نه: پرداخت آنلاین و پروندهٔ پزشکی کامل. اگر کسب‌وکارتان پزشکی است، امکاناتی را که ما برای این حوزه پیشنهاد می‌کنیم در صفحهٔ راهکار پزشکی ببینید.
مرحله ۶: معیار پذیرش
یک معیار پذیرش ساده: «بیمار بتواند بدون تماس تلفنی یک نوبت آزاد بگیرد و همان نوبت در پنل پذیرش دیده شود. اگر ساعت هم‌زمان گرفته شده باشد، سیستم پیام خطا بدهد و ساعت دیگری پیشنهاد کند.» اگر می‌خواهید همین نیاز را به شکل داستان کاربری بنویسید، مقالهٔ User Story چیست را ببینید. نوشتن شرط‌های تحویل هم در مقالهٔ معیار پذیرش آمده است.
نیاز واقعی یا نیاز کاذب؟ اولویت‌بندی و تعیین محدوده
سه سؤال برای هر امکان
قبل از اینکه چیزی وارد نسخهٔ اول شود، بپرسید:
- این امکان کدام مشکل را حل میکند؟
- چه کسی هر روز از آن استفاده میکند؟
- اگر نسخهٔ اول آن را نداشته باشد، کار اصلی می‌خوابد یا فقط سخت‌تر می‌شود؟
اگر جواب سؤال سوم «کار می‌خوابد» نبود، آن امکان احتمالاً «بهتر است» یا «فعلاً نه» است، نه «باید».
روش ساده «باید، بهتر است، فعلاً نه»
همین سه برچسب برای بیشتر پروژه‌های کوچک و متوسط کافی است. در مدیریت محصول به روش مشابهش MoSCoW می‌گویند؛ لازم نیست برچسب‌های انگلیسی‌اش را حفظ کنید. مهم این است که «باید»های نسخهٔ اول واقعاً کم بمانند.
فهرست «خارج از محدوده» را بنویسید
آنچه عمداً در نسخهٔ اول نیست را مکتوب کنید. این فهرست جلوی بزرگ شدن تدریجی محدوده را می‌گیرد؛ همان چیزی که به آن Scope Creep می‌گویند. راه‌های جلوگیری‌اش را در جلوگیری از Scope Creep نوشته‌ایم.
تحلیل کی تمام شده است؟ (چکلیست)
تحلیل تمام شده است اگر به این هشت مورد بتوانید «بله» بگویید:
- همهٔ نقشهای اصلی فهرست شده‌اند.
- هر فرایند اصلی شروع و پایان دارد.
- برای هر قاعدهٔ مهم، دست‌کم یک استثنا بررسی شده است.
- فهرست «خارج از محدوده» نوشته شده است.
- اولویت هر نیاز نسخهٔ اول روشن است (باید / بهتر است / فعلاً نه).
- سیستم‌ها و داده‌های بیرونی مشخص‌اند.
- هر نیاز مهم دست‌کم یک معیار پذیرش دارد.
- تصمیمگیر نهایی سند را مکتوب تأیید کرده است.
خروجی این کار معمولاً در قالب SRS یا مستند نیازمندی پروژه نوشته می‌شود. برای شکل سند به سند نیازمندی‌های نرم‌افزار (SRS) و برای قالب آماده به نمونه ساختار PRD سر بزنید. مقالهٔ SRS یک چکلیست جدا هم برای بررسی خود سند قبل از قرارداد دارد.
۶ اشتباه رایج کارفرما در تحلیل نیازمندی
- شروع از راهکار به‌جای مسئله: «مثل دیوار می‌خواهم» نقطهٔ شروع نیست؛ بگویید چه مشکلی را حل می‌کنید.
- فقط مدیر در جلسه: درد کاربر واقعی شنیده نمیشود.
- نادیده گرفتن استثناها: فقط مسیر بی‌دردسر ساخته می‌شود و روز اول کار واقعی می‌شکند.
- ننوشتن خارج از محدوده: هر جلسه یک امکان جدید «ضروری» می‌شود.
- چند تصمیمگیر بدون سلسله‌مراتب: اولویت‌ها هر هفته عوض می‌شوند.
- تأیید نکردن مکتوب: بعداً اختلاف بر سر «مگر نگفتیم» شروع می‌شود.
خودمان تحلیل کنیم یا به تیم فنی بسپاریم؟
کارفرما صاحب دانش کسبوکار است؛ تیم فنی آن را به نیازمندی قابل ساخت و تست تبدیل میکند. اگر فرایندها ساده‌اند، پیش‌نویس اول را خودتان با بانک سؤال همین مقاله بنویسید. اگر چند واحد و استثناهای زیاد دارید، سپردن تحلیل به تیم فنی معمولاً کم‌هزینه‌تر از اصلاح بعد از کدنویسی است.
در تکنوراه این مرحله «فاز صفر: تشخیص و هم‌راستاسازی» است و طبق صفحهٔ توسعه نرم‌افزار سفارشی ۱ تا ۳ هفته طول می‌کشد. اگر می‌خواهید از چند شرکت با یک متن واحد پیشنهاد بگیرید، نمونه RFP پروژه نرم‌افزاری را ببینید. برای شروع همکاری روی مستند، صفحهٔ مستند نیازمندی پروژه (PRD) مسیر را نشان می‌دهد.
جمع‌بندی و قدم بعدی
اگر فقط سه کار انجام دهید، کیفیت تحلیل‌تان بالا می‌رود:
- فهرست ذی‌نفعان و یک تصمیمگیر نهایی را بنویسید.
- بانک سؤال را برای یک فرایند اصلی پر کنید (شروع، مراحل، قاعده، استثنا).
- جلسهٔ تحلیل بگذارید و خروجی را با چکلیست هشت‌موردی بالا ببندید.
نیازهایتان را مرتب کرده‌اید؟ برای همین محدوده، برآورد اولیهٔ هزینه و زمان را از فرم تکنوراه بگیرید.
تحلیل نیازمندی را با هم انجام دهیم؟ تکنوراه مستند نیازمندی پروژه را همراه شما می‌نویسد.
سوالات متداول
تحلیل نیازمندی‌های نرم‌افزار چه فرقی با سند نیازمندی (SRS) دارد؟
تحلیل کار است و سند نتیجهٔ آن کار. تحلیل یعنی فهمیدن مسئله، نقش‌ها، فرایندها و اولویت‌ها. سند نیازمندی‌های نرم‌افزار (SRS) همان چیزهایی را که در تحلیل روشن شده مکتوب میکند تا مبنای ساخت و تست باشد. جزئیات ساختار سند در مقالهٔ سند نیازمندی‌های نرم‌افزار آمده است.
تحلیل نیازمندی چقدر طول می‌کشد؟
به دامنهٔ پروژه و تعداد فرایندها بستگی دارد. در تکنوراه، فاز صفر «تشخیص و هم‌راستاسازی» طبق صفحهٔ توسعه نرم‌افزار سفارشی ۱ تا ۳ هفته است. زمان دقیق کل پروژه هم پس از همین فاز مشخص می‌شود.
کارفرما در تحلیل نیازمندی چه نقشی دارد؟
هدف کسبوکار، فرایندهای فعلی، قواعد و استثناها، اولویت نسخهٔ اول و تأیید نهایی با شماست. تیم فنی اینها را به نیازمندی قابل ساخت و تست تبدیل میکند. بدون دانش کسبوکار شما تحلیل کامل نمیشود.
برای جلسه تحلیل نیازمندی چه چیزی آماده کنم؟
هدف و شاخص موفقیت، نقشهای کاربران، امکانات ضروری و اختیاری، محدودیت بودجه و زمان، سرویسهای بیرونی و نام تصمیمگیر را بنویسید. چکلیست آمادگی قبل از جلسه در صفحهٔ مستند نیازمندی پروژه (PRD) آمده است. بانک سؤال همین مقاله هم کمک میکند جوابها را مرتب کنید.
آیا برای یک MVP هم تحلیل نیازمندی لازم است؟
بله، ولی کوتاهتر. MVP یعنی نسخهٔ اول و کوچک محصول. در آن روی یک جریان اصلی تمرکز کنید، فهرست «خارج از محدوده» را بنویسید و همان را با تصمیمگیر تأیید کنید تا نسخهٔ اول از مسیر اصلی منحرف نشود.