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

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

چند نمونه از نیازمندی هایی که به این صورت نیستند را در زیر می بینید:

• نرم افزار باید سریع باشد
• وبسایت باید زیبا باشد
• نرم افزار باید خوش دست باشد
• نرم افزار باید کاربران را مدیریت نمایید

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

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

• روی کامپیوتر با حداقل چه مشخصاتی برنامه اجرا خواهد شد؟
• آیا برنامه به صورت شبکه ای اجرا خواهد شد؟
• بالا آمدن برنامه باید در حداقل چه زمانی انجام شود؟ محدودیتی در این زمینه وجود دارد؟
• بارگزاری داده ها در فرم های اطلاعاتی حداکثر در چه زمانی انجام شود؟ (با در نظر گرفتن امکانات سخت افزاری)
• عمل ذخیره سازی حداکثر در چه زمانی انجام شود؟ (با در نظر گرفتن امکانات سخت افزاری)

یافتن پاسخ مناسب برای این سوالات به برنامه نویس این امکان را می دهد که تصمیمات فنی مورد نظر را اتخاد نماید. در مورد بالا شاید تیم برنامه نویسی تصمیم بگیرد مقدار زیادی از داده ها را در زمان شروع اجرای برنامه cache کند. در صورتی که موضوع سرعت اجرای اول نرم افزار برای مشتری موضوع خیلی مهمی باشد و زمانی پایینی (به صورت دقیق) درخواست کرده باشد، تیم برنامه نویسی باید با دقت بیشتری این کار را انجام دهد. باید منظور دقیق از سریع بودن نرم افزار مشخص شود.

حتی شاید با توجه به نیازمندی ارائه شده و امکانات موجود، نیازمندی ها غیر منطقی به نظر برسند و مورد قبول قرار نگیرند.

فاجعه اصلی

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

معمولا تحویل گرفتن نیازمندی ها به صورت غیر قابل اندازه گیری و مشخص مشکلات زیر را بوجود خواهد آورد:

• تحویل بسیار مشکل کار و عدم رضایت همیشگی مشتری
• عدم امکان طراحی و پیاده سازی نرم افزار مناسب نرم افزار و تکرار دوباره کارهای انجام شده به دلیل طراحی بد
• بی انگیزگی تیم تولید به دلیل حاشیه ها و تنش های ایجاد شده در تحویل کارها
• عدم امکان تهیه و ارائه گزارش پیشرفت پروژه

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