امکان‌سنجی و نیازسنجی در مهندسی نرم‌افزار

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

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

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

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

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

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

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

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

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

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

در سناریوی اول؛
کارفرما یک موجود بیرونی است؛ یک سازمان، استارتاپ یا کسب‌وکار که با یک ایده یا درخواست سراغ تیم نرم‌افزاری می‌آید. معمولاً کارفرما با یک تصویر ذهنی نسبتاً مشخص وارد می‌شود: «یک سیستم شبیه فلان»، «یک اپ مثل بهمان» یا «چیزی که این مشکل را حل کند». در این حالت، اگر تیم تحلیل بدون نیازسنجی عمیق وارد نوشتن SRS شود، احتمال زیادی وجود دارد که سند نهایی صرفاً بازنویسی خواسته‌های اولیه‌ی کارفرما باشد، نه بازتاب نیاز واقعی او.

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

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

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

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

این همه از اسناد SRS صحبت کردیم باهم. معماران و تحلیل گران عزیز میدانند؛ ما یکسری اسناد دیگری داریم تحت عناوین BRS و FRS که به نوعی در فرایند امکان سنجی و نیازسنجی تولید میشوند. در این مقاله بیشتر در مورد این اسناد و مقایسه اونها صحبت کردم.

امیدوارم مفید بوده باشه ...