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

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

تعیین نیازمندی‌ها؛ آغاز یک پروژه

مهندسی نیازمندی‌ها اولین رکن از ارکان دوازده‌گانه مهندسی نرم‌افزار است. (2) یکی از تفاوت‌های بارز شغل برنامه‌نویسی کامپیوتر با شغل مهندسی نرم‌افزار در همین گام نخست است. در حالی که برنامه‌نویسی عمدتاً روی جنبه فنی تولید نرم‌افزار تأکید دارد، مهندسی نرم‌افزار در چند مرحله مختلف از فرآیند تولید برنامه به جنبه‌های ساختاری، مدیریتی، غیرفنی و انسانی یک پروژه نیز توجه دارد. در یک کلام، مهندسی نیازمندی‌های نرم‌افزار نوعی هنر است که از تلفیق مسائل دقیق فنی و نکات ظریف انسانی به انجام می‌رسد.
هر پروژه مهندسی نرم‌افزار، اگر قرار باشد به‌صورت اصولی و حرفه‌ای انجام شود، حتماً باید با مهندسی نیازمندی‌ها آغاز شود و منابع کافی (اعم از وقت، نیروی انسانی و هزینه) برای انجام درست آن تخصیص یابد، زیرا انجام درست این کار هم یک پایه حقوقی و مرضی‌الطرفین برای دو طرف قرار داد به وجود می‌آورد و هم از سوءتفاهم و مشکلات بعدی حین اجرای پروژه تا حدود زیادی جلوگیری می‌کند. حتی در پروژه‌هایی که قرار است مخاطب عام داشته باشند (مثلاً به تولید انبوه و در بازار بزرگ نرم‌افزار به فروش برسد) نیز این کار ضروری است چون کیفیت کار تضمین می‌شود، از هزینه‌های تولیدکننده نرم‌افزار در مراحل بعدی (به‌ویژه در مواجهه با ایرادهای نرم‌افزار) می‌کاهد و کمک زیادی به افزایش اعتبار محصول نزد کاربرانی می‌کند که هنوز مشتری این نرم‌افزار نشده‌اند. اهمیت این مرحله از مهندسی نرم‌افزار تا به آنجا است که برخی سرمایه‌گذاران و حامیان مالی یک پروژه نرم‌افزاری به‌عنوان بخشی از سند طرح کسب و کار (Business Plan) مستندات نیازمندی‌های نرم‌افزار را نیز خواستار می‌شوند.

چرا فرآیند نیازمندی‌های نرم‌افزار در بعضی شرکت‌ها جدی گرفته نمی‌شود؟

از نظر روان‌شناسی تیپ‌های شخصیتی در مدل MBTI، افراد را می‌توان به دو گروه Sensory و Intuitive تقسیم کرد. نحوه قضاوت کردن گروه اول بیشتر متکی به دریافت‌هایشان از حس‌های پنج‌گانه است. به همین دلیل آن‌ها آدم‌هایی واقعیت‌محور هستند، به این معنا که تا چیزی واقعی نباشد (با چشم قابل رؤیت یا با دست قابل لمس یا با گوش قابل شنیدن) باورش نمی‌کنند. مثلاً تا یک مشکل عملاً بروز نکند و سری به سنگ نخورد، باورش نمی‌کنند. در سطوح مدیران، این تیپ افراد فراوان هستند. قوه تخیلشان بیشتر جایی که بحث پول‌سازی و کسب سود در میان باشد به کار می‌افتد و در سایر امور (مثلاً جزئیات فنی مهندسی) قوه تخیل و بصیرتشان فعال نمی‌شود، چون برایشان جذاب نیست. (درباره اهمیت شم مهندسی یا قوه بصیرت در کارشناسی کامپیوتر به مقاله «آیا به حس ششم نیاز دارید؟»‌ در همین شماره مراجعه کنید.) گاهی اوقات به‌صورت تصادفی، مهندسانی که در یک شرکت کار می‌کنند هم از همین تیپ هستند (آدم‌های هم‌تیپ یکدیگر را جذب می‌کنند). در چنین شرکتی کمتر کسی پیدا می‌شود که به فکر کردن درباره چیزهایی که هنوز در عالم واقعیت محقق نشده‌اند بلکه تنها ایده هستند، علاقه داشته باشد. مستندسازی، نیازسنجی، اندازه‌گیری، پیش‌بینی مشکلاتی که در آینده (حین کار کردن نرم‌افزار) ممکن است رخ دهد، همه و همه برای آدم‌های واقعیت‌محور ملال‌آور و غیرجذاب است. در یک کلام، این‌گونه شرکت‌ها با وجود اینکه روی کاغذ شایسته‌اند، فاقد شم مهندسی هستند.

راه‌اندازی سیستم آموزش آنلاین

ذکر یک مثال می‌تواند روشن کند فرآیند مهندسی نیازمندی‌ها دقیقاً درباره چه چیزی است. فرض کنید قرار است یک سایت و سیستم آنلاین آموزشی راه‌اندازی شود. این‌گونه سیستم‌ها معمولاً زیر عنوان e-Learning طبقه‌بندی می‌شوند. مخاطب این سیستم ممکن است یک دانشگاه یا یک مؤسسه آموزشی خاص باشد. همچنین ممکن است این پروژه در قالب محصولی برای تولید و عرضه انبوه به همه کاربران دنیا (یا دست‌کم یک زبان خاص مثلاً فارسی) تعریف شده باشد.
قبل از شروع کارهای فنی این پروژه کارهای مهمی باید صورت گیرد تا مشخص شود این سیستم چه قابلیت‌هایی باید داشته باشد، از نظر فنی دارای کدام مشخصات است و کاربران نهایی آن چه انتظاری دارند. بی‌توجهی به این موضوع ممکن است به تولید سیستمی منجر شود که با وجود قابلیت‌های متعدد، نیاز مشتری را پاسخ نمی‌دهد (مثلاً با بروکراسی آن مؤسسه آموزشی هم‌خوانی ندارد) و نه‌تنها مشکلی را حل نمی‌کند بلکه به مشکلات نیز می‌افزاید. همچنین، ممکن است سیستم تولید شده نیازهای مشتری را به‌خوبی هدف قرار دهد، اما از نظر فنی مشخصات مناسب نداشته باشد (مثلاً کار کردن هم‌زمان بیش از پنج اپراتور روی سیستم باعث کند شدن آن شود) و اسباب سرخوردگی و کلافگی کاربران را فراهم کند. در ادامه مقاله از همین مثال برای توضیح سایر مفاهیم کلیدی در مهندسی نیازمندی‌ها استفاده خواهیم کرد.
سند نیازمندی‌های نرم‌افزار
نمودار مارپیچی شکل 1 نمایی از چرخه کامل فرآیند مهندسی نیازمندی‌ها را نشان می‌دهد. این چرخه مجموعه‌ای از عملیات است که به‌صورت جمع‌آوری اطلاعات، انجام مصاحبه با دست‌اندرکاران، مستندسازی و بررسی‌های فنی مهندسی انجام می‌شود. درنهایت محصول کار یک سند است که با عنوان «سند نیازمندی‌های نرم‌افزار» (3) تولید می‌شود و در اختیار مشتری (کارفرما) و تیم تولید نرم‌افزار (که خود ممکن است در تهیه این سند مشارکت کرده باشند) قرار می‌گیرد. این سند مرجع تصمیم‌گیری و اقدام برای هر دو طرف است و نشان می‌دهد قرار است چه سیستمی با چه مشخصاتی ساخته شود و محدودیت‌ها و قابلیت‌های فنی آن چه خواهد بود. 

شکل 1 - چرخه فرآیند شناسایی نیازمندی‌های نرم‌افزار (منبع: کتاب مهندسی نرم‌افزار تالیف یان سامرویل، ناشر ادیسون وسلی، چاپ نهم)

به عنوان مثال در پروژه فرضی سیستم آموزشی آنلاین، ممکن است یکی از قابلیت‌های فنی مورد نظر امکان اندازه‌گیری زمان حضور آنلاین دانشجو در انجمن‌ آنلاین یک درس به‌خصوص باشد. این قابلیت باید هم به‌لحاظ کاربردی (دیدگاه کارفرما) و هم از نظر فنی (روش و مختصات فنی انجام این کار) در سند تصریح شود تا حین تولید یا بعد از خاتمه تولید نرم‌افزار مرجع دو طرف برای حل اختلاف نظر باشد.
یکی از مهم‌ترین کارهایی که این سند انجام می‌دهد، مشخص کردن «محدودیت‌های سیستم» و قابلیت‌هایی است که نخواهد داشت. این مشابه عنوان «شرکت با مسئولیت محدود» است که چهارچوبی را مشخص می‌کند که فعالیت شرکت در آن معنا دارد. ممکن است در حین اجرای پروژه کارفرما نظرش را درباره نیازمندی‌هایش تغییر دهد یا اصلاح کند و یا ممکن است تیم تولید با مشکلات فنی مواجه شود که قبلاً پیش‌بینی نشده بود. در این صورت این موارد اصلاحی باید مجدد مورد مذاکره دو طرف قرار گیرد و به سند نیازمندی‌ها ضمیمه شود.

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

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

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

به‌لحاظ نظری، بعضی صاحب‌نظران مایلند فرآیندهای مهندسی نیازمندی‌ها را به دو گروه نیازمندی‌های عملیاتی (Functional) و غیرعملیاتی (Non-Functional) تقسیم کنند. گروه اول مشخصات فنی هستند که سیستم و کارکرد کامپیوتری آن دارد. مثلاً نوع زبان برنامه‌نویسی یا سیستم عاملی که برای تولید این نرم‌افزار در نظر گرفته شده است. در پروژه فرضی ما، سیستم آنلاین آموزشی، ممکن است نرم‌افزار تحت وب توسط زبان PHP یا C# نوشته و برای کار روی سیستم عامل ویندوز یا لینوکس تولید شود. همچنین آن دسته از نیازمندی‌های مشتری که روی کارکرد و قابلیت‌های سیستم تأثیر می‌گذارند، در این دسته قرار می‌گیرند. به عنوان نمونه، شاید مشتری فرضی ما مایل باشد مکانیسم امنی برای آپلود و دانلود تکالیف درسی دانشجویان فراهم شود. اما این غیر از نیازمندی‌های غیرعملیاتی است. گروه دوم نیازمندی‌ها آنهایی هستند که شرایط مشتری یا شرایط بیرون از پروژه به آن تحمیل می‌کند. مثلاً ممکن است مشتری بگوید کاربران این سیستم به‌دلیل مقررات آن سازمان نمی‌توانند یا نباید از مرورگر IE استفاده کنند. اما یک طبقه‌بندی مرسوم‌تر تقسیم کردن نیازمندی‌ها به دو گروه نیازمندی‌های سیستم و نیازمندی‌های مشتری است. نیازمندی‌های مشتری آن دسته از مشخصات و ویژگی‌های نرم‌افزار است که منشأ آن‌ها درخواست‌ها و نیازهای مدیران و کاربران در سمت مشتری است. مثلاً ممکن است یک دانشگاه هم‌اکنون یک سیستم کامپیوتری برای ثبت‌نام و انتخاب واحد دانشجویان داشته باشد و بخواهید این سیستم با نرم‌افزاری که قرار است برای آموزش آنلاین دانشجویان تولید می‌شود یکپارچه شود، به گونه‌ای که انتخاب واحد از طریق هرکدام از این دو مسیر به ثبت و نمایش انتخاب واحد در دیگری منجر شود. بدیهی است کارفرما مایل نیست حضور سیستم آنلاین به دوباره‌کاری منجر شود. اما نیازمندی‌های مشتری لزوماً تعیین‌کننده مشخصات فنی سیستم نیست. ممکن است در پروژه فرضی ما، برای مؤسسه آموزشی مهم نباشد که این نرم‌افزار با چه زبان برنامه‌نویسی و برای کدام سیستم‌ عامل (یا وب سرور) تولید می‌شود. این دسته از نیازمندی‌ها چه به توصیه پیمانکار و چه از طریق مشورت بین دو طرف، در گروه نیازمندی‌های سیستم قرار می‌گیرند.

کارتهایی با آیکون‌های مختلفی که سمبول نقش‌های مختلف کاربران ذینفع یک پروژه (مشتری) و ارتباطات میان آنهاست. هنگام شناسایی و استنباط نیازمندی ها ممکن است از این کارت‌ها برای مدل‌سازی پروژه استفاده شود.

گفت‌وگوهای مبهم و تکه پاره کردن تعارفات

اصول مهندسی نیازمندی‌ها

با مراجعه به نمودار مارپیچی شکل 1 معلوم است گام‌های اصلی در این چرخه کدامند. این کار ابتدا با ابلاغ سیاست‌ها، خط‌مشی و نیازمندی‌های کلی کسب و کار مشتری آغاز می‌شود. سپس پیمانکار مطالعه‌ای روی امکان‌پذیر بودن پیاده‌سازی سیستم با مشخصات اصلی مورد نظر کارفرما انجام می‌دهد تا معلوم شود آیا با بودجه و امکانات موجود امکان اجرای موفق پروژه در مدت زمان مورد نظر مشتری وجود دارد یا نه.
گام بعدی استنباط نیازمندی‌ها است. (4) گاهی این مرحله کشف و درک نیازمندی‌ها نیز نامیده می‌شود. این مرحله بسیار حساس است، زیرا پیمانکار باید منظور و هدف مشتری را به‌خوبی استنباط کند. در غیر این صورت ممکن است در پایان، نتیجه کار با تصور مشتری بسیار متفاوت باشد و خسارات سنگینی به هر دو طرف وارد شود. برای کشف صحیح نیازمندی‌های مشتری روش‌های مختلفی وجود دارد. اما اجرای درست این روش‌ها از خود آن‌ها مهم‌ترند. مثلاً یک روش متداول برگزاری جلسات بین دست‌اندرکاران هر دو طرف است. یک روش دیگر انجام مصاحبه با تک تک کاربران احتمالی و اصلی سیستم آتی است. مثلاً اگر قرار است آقا یا خانم به‌خصوصی در پروژه فرضی دانشگاه آنلاین مدیر اجرایی این سیستم باشد باید تولیدکننده نرم‌افزار مطمئن شود که او دقیقاً به چه نکاتی توجه دارد، نیازش چیست و چه مشکلاتی را می‌خواهد از طریق این سیستم حل کند. این جلسات معمولاً با حضور عالی‌ترین مدیران در سمت کارفرما آغاز می‌شود و به‌تدریج جلسات بعدی با سطوح پایین‌تر اجرایی در سازمان ادامه می‌یابد.

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

پس از استنباط، نوبت به تجزیه و تحلیل نیازمندی‌ها می‌رسد و کار مستندسازی شروع می‌شود و هر نیازمندی به‌صورت گزاره مستقلی نوشته می‌شود تا به تأیید مشتری برسد. گاهی لازم است یک Prototype ساخته شود (5) تا مشتری بتواند درک بهتری از تقاضای خود و نتیجه نهایی کار داشته باشد. به هر حال، این چرخه باید درباره تمام تقاضاها و نیازمندی‌های فنی و غیرفنی آنقدر تکرار ‌شود تا هیچ ابهامی باقی نماند. علی‌الاصول، مدیریت جلسات و مصاحبه‌ها باید به‌عهده مهندسان باتجربه‌ای باشد که قبلاً درس نرم‌افزار خوانده‌اند و تجربه عملی مستندسازی نیازمندی‌های نرم‌افزار را دارند، زیرا ابهام در شیوه تقسیم وظایف در سمت پیمانکار و نابلدی در مهندسی نیازمندی‌ها مشکل‌ساز خواهد بود.

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

پی‌نوشت:

(1) Requirements Engineering
(2) برای آشنایی با ارکان مهندسی نرم‌افزار، به مقاله‌ای در همین زمینه در شماره 200 ماهنامه شبکه مراجعه کنید.
(3) System Requirements Document
(4) Requirements Elicitation (Discovery)
(5) یعنی نمونه‌ای از محصول نهایی در ابعادی بسیار کوچک