فراسان

به اشتراک بگذارید برای یادگیری، یاد بگیرید برای به اشتراگ گذاری

مستندات نیازمندی ها و نقش آن در موفقیت یک پروژه نرم افزاری

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

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

متغیر بودن نیازهای کاربران و پیچیدگی شناسایی برخی نیازهای آنان، نوشتن مستندات نیازمندی ها را بسیار مشکل می کند. در اکثر پروژه های نرم افزاری شناسایی نیازهای کاربران و سیستم بسیار سخت و گاه غیر ممکن است. وقتی خود مشتری ها و کاربران نهایی از نیازهای خودشان آگاهی ندارند، نباید به مهندسین نرم افزار خرده گرفت که چرا نمی توانند فرمول یا استانداردی برای شناسایی بی نقص نیازهای یک سیستم نرم افزاری پیدا کنند!!

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

نیازمندی ها در سیستم های نرم افزاری به دو دسته نیازهای عملکری (Functional) و نیازهای غیر عملکردی (Non-Funcitonal) تقسیم می شوند. نیازهای عملکردی همان نیازهایی هستند که سیستم نرم افزاری برای برآورده کردن آن ها بوجود می آید. نیازهای غیر عملکردی آن هایی هستند که برای تضمین کیفیت نرم افزار بوجود می آیند. به نیازهای غیر عملکردی، نیازمندی های کیفیت نیز گفته می شود. مثالی از نیازمندی های غیر عملکردی می تواند ظاهر زیبای رابط کاربری، سرعت بالا، امنیت و استفاده آسان باشد.

هر چند با پیاده سازی نیازهای عملکردی می توان گفت بخش مهمی از نرم افزار پیاده سازی می شود اما در برخی مواقع این عمل بدون پیاده سازی نیازهای غیرعملکردی بی فایده است. به لفظ ساده تر، نیازهای غیر عملکردی پیش پا افتاده که نیستند هیچ، خیلی هم مهم و برای کارکرد درست سیستم نرم افزاری حیاتی هستند. به طور مثال استفاده آسان کاربران از نرم افزار و داشتن یک رابط کاربری User Friendly برای یک نرم افزار یک خواسته غیر عملکردی است که تاثیر مستقیم بر کاربران نهایی یک نرم افزار دارند. اگر این نیازهای غیر عملکردی در یک نرم افزار پیاده سازی نشوند، خیلی زود کاربران از آن زده شده و سراغ نرم افزارهای رقیب خواهند رفت.

چطور مستندات نیازمندی های یک نرم افزار را تهیه کنیم؟

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

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

مشکلات پیش روی جمع آوری نیازمندی های یک پروژه نرم افزاری

  • مشتری دقیقاً نمی داند چه می خواهد یا به چه چیزهایی برای رسیدن به هدفش نیاز دارد
  • مشتری یا کاربران نمی توانند نیازمندی های نرم افزار خود را مشخص کنند
  • ارتباط مداوم با مشتری و کاربران معمولاً پروسه زمان بری است
  • مشتری ایده ای از نحوه کارکرد سیستم های نرم افزاری ندارد
  • مشتری از تکنولوژی های توسعه نرم افزار خبر ندارد
  • مشتری همه نیازهایش را یکجا و به یکباره ذکر نمی کند و معمولاً پس از تولید نرم افزار یکسری نیازهای جدید پیدا می کند!

و مشکلاتی که شما می توانید در قسمت نظرت با ما به اشتراک بگذارید!

farasun.wordpress.com

امیدوارم دوستان با تجربه تر اشکالات این نوشته را به من گوشزد کنند و تجربه های خودشان را با ما به اشتراک بگذارند. هدف نهایی این نوشته ها به اشتراک گذاری تجربه ها و در نهایت یادگیری است.

7 پاسخ به مستندات نیازمندی ها و نقش آن در موفقیت یک پروژه نرم افزاری

  1. من مارس 11, 2010 در 5:38 ب.ظ.

    درد دل ما رو تازه کردی. موردیم از دست این مشتری های زبون نفهم که هر روز رنگ عوض می کنن.
    بهترین کار اینه که از مشتری بخوایم مستند vision ایجاد کنه. البته هر کسی زیر بار این قضیه نمیره و آخرش همه چیز میفته رو دوش Developer بدبخت.

  2. رضا.ب مارس 13, 2010 در 10:23 ب.ظ.

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

    • ایمان مارس 14, 2010 در 10:03 ق.ظ.

      @ رضا.ب : مستندت نیازمندی ها برای همین باید تهیه بشه که جلوی اشتباهات این چنینی رو بگیره. یعنی این مستندات اگر به درستی نوشته بشه مشکل این که مشتری بعدش بفهمه این سولوشن به درد این پروژه نمیخوره هیچ وقت پیش نمیاد. گفتم که نهایتاً نیاز به یک سری تغییرات کوچیک پیدا میکنه یا نیاز به ویژگی های جدید داره که اینم اگر پروژه رو استاندارد بنویسیم تغییر دادن و گسترش دادنش باید خیلی راحت باشه.

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

  3. کاوه مارس 13, 2010 در 11:12 ب.ظ.

    ممنون آقا ایمان. مقاله بسیار مفیدی بود.

  4. مجید مارس 29, 2010 در 4:50 ب.ظ.

    سلام دوست عزيز:
    اگه موافق باشيد با هم تبادل لينک کنيم
    نام : هرچي بخواي دارم برات
    لينک : http://www.deledivane.blogfa.com
    بعد از اطلاع شما ، لينک شما در کمتر از 2 ساعت در سايت ما قرار مي گيرد و به شما خبر داده مي شود.
    لطفا لينکتان را همراه نام انتخابي خود براي ما بفرستيد.

  5. توفان ژوئیه 9, 2010 در 7:41 ق.ظ.

    با سلام
    نکته ای راجع به مقاله تان به ذهنم رسید که گفتم اینجا بیان نمایم
    یکی از مهمترین و تاثیر گذارترین پارامترها در تهیه نرم افزار توجه به کار و محصولات دیگران یا همان best practice ها است. مطالعه و بررسی محصولات مشابه دیگری که در زمینه کاری ما وجود دارند راه میانبری در بدست آوردن نیازمندی ها نرم افزارمان خواهد بود.

  6. بازتاب: کیفیت در نرم افزار واقعاً به چه معناست!؟ « فراسان

پاسخی بگذارید

در پایین مشخصات خود را پر کنید یا برای ورود روی شمایل‌ها کلیک نمایید:

نشان‌واره‌ی وردپرس.کام

شما در حال بیان دیدگاه با حساب کاربری WordPress.com خود هستید. بیرون رفتن / تغییر دادن )

تصویر توییتر

شما در حال بیان دیدگاه با حساب کاربری Twitter خود هستید. بیرون رفتن / تغییر دادن )

عکس فیسبوک

شما در حال بیان دیدگاه با حساب کاربری Facebook خود هستید. بیرون رفتن / تغییر دادن )

درحال اتصال به %s

دنبال‌کردن

هر نوشته‌ی تازه‌ای را در نامه‌دان خود دریافت نمایید.

به 36 مشترک دیگر بپیوندید