بنام خدا

با سلام

در ادامه مطلب قسمت دوم با يكسري مثالها در خصوص كاهش ريسك پروژه هاي نرم افزاري از طريق دقت در استخراج نيازمنديها صحبت شده است.

تشخيص ، تعريف ، تجزيه ، درستي و قابليت ارزيابي نيازمنديها يكي از بزرگترين مسائل پيش روي مهندسين نرم افزار مي باشد.در اكثر مستندات نيازمنديها ، نيازمنديهاي موجود مبهم و متناقض مي باشد در بعضي موارد نيازمنديها به صورت يكتا تعريف نشده و نهايتا منجر به اين مي گردد كه قابل پيگيري نبوده و تست آنها به سختي صورت پذيرد.در بسياري از حالات نيازمنديها بسيار سطحي و يا بسيار جزيي و در سطح تحليل سيستم بيان گرديده است(نه در سطح نيازمنديهاي نرم افزار)

اگر با استفاده از روشهايي بتوانيم بر اين مشكلات فائق آييم مي توانيم ريسك توسعه سيستمهاي نرم افزاري را (ريسك عدم پوشش نيازمنديها) تا حد زيادي كاهش دهيم.

در اين مثالها سعي شده است روش برخورد با مسائلي كه افراد مرتبط در تعيين نيازمنديها با آن دست و پنجه نرم مي كنند عنوان  گردد.

صورت كلي مثال : طبق برنامه ريزي مقرر گرديد تا نسبت به توسعه مجدد نرم افزارهاي قبلي اقدام گردد در اين راستا با توجه به محدوده سيستم ، چند تيم بصورت همزمان وظيفه مهندسي مجدد سيستمهاي موجود و تعريف نيازمنديها را عهده دار شدند و مشاوري جهت راهنمايي به تيمها در راستاي استخراج صحيح نيازمنديها بكار گرفته شده است.

 

مثالهاي مرتبط :

مثالهاي ذيل مرتبط با تعدادي از سيستمهاي موجود است كه قرار است در پروسه توسعه مجدد بازنويسي گردند. اينها تنها نشان دهنده فاز شناخت نيازمنديها بوده و ساير مراحل چرخه توسعه نرم افزار را شامل نمي شود در اين مثالها ابتدا نيازمندي استخراج شده توسط تيمها آورده شده ، سپس با توجه به موارد بحراني فوق ارزيابي هاي لازم صورت گرفته و نهايتا نيازمندي بازنويسي گرديده است.

 

مثال 7 :

نيازمندي اوليه : 3.2.7.1 سيستم نبايد مانع  وارد نمودن سال از جانب كاربران كه قصد ورود اطلاعات پرداخت را دارند گردد اما مي بايد امكاني را فراهم نمايد كه آنها از درستي سال وارد شده مطمئن گردند.

ايرادات : اين يك نيازمندي منفي مي باشد نيازمنديهاي منفي نمي بايد تعريف شوند(عدم نيازمندي) زيرا آنها قابل پياده سازي نيستند. در نيازمنديها مي بايست تمامي شرايطي كه بايد وجود داشته باشد بيان گردد. اگر شرايطي لازم نيست پياده سازي نيز نمي شوند. علاوه بر آن دوبار از بايد(يكبار مثبت ، يكبار منفي) در يك نيازمندي استفاده شده است.

نيازمندي بازنويسي شده : 3.2.7.1 سيستم مي بايست :

  1. اجازه ورود سال پرداخت را به كاربر بدهد.
  2. ‎ٌامكاني جهت اطمينان كاربر از صحت سال پرداخت وارد شده فراهم نمايد.

 

 

مثال 8 :

نيازمندي اوليه : 3.2.7.3 بعد از اين كه سيستم يك فايل سالم را دريافت نمود، سيستم مي بايست:

  • اگاه ساختن كاربر از پذيرش با عدم پذيرش فايل
  • فايل پذيرفته شده مي بايست شامل نام و كد پستي فرد ارسال كننده باشد.
  • درخواست پذيرفته نشده مي بايست شامل يك (كد علت عدم پذيرش) باشد.

 

ايرادات : آيتم دوم و سوم در صورتي كه مستقل از آيتم اول خوانده شوند هيچ معنايي ندارند :

  • سيستم مي بايست فايل پذيرفته شده مي بايست ....
  • سيستم مي بايست درخواست پذيرفته نشده مي بايست ....

از طرف ديگر استفاده از Bullets در تعريف نيازمنديها نبايد استفاده شود زير امكان رديابي وجود ندارد بنابراين از شماره گذاري و يا حروف استفاده نماييد. در كل اين نيازمندي مبهم بوده و قابل پياده سازي و تست نمي باشد.

نيازمندي بازنويسي شده : 3.2.7.3 هنگامي كه سيستم يك فايل سالم را دريافت مي نمايد مي بايست :

  1. عدم پذيرش فايل در صورتي كه شامل مشخصات ذيل از شخص تاييد كننده نمي باشد:
    1. نام
    2. كد پستي
  2. آگاه سازي شخص درباره پذيرش و يا عدم پذيرش با كد علت عدم پذيرش.مرجع كد علت ها جدول شماره 5.4.8 مي باشد.

 

مثال 9 :

نيازمندي اوليه :

 3.2.8.2 فرايند ثبت نام در انواع روشهاي ثبت نام بين 1 تا 10 روز بطول انجامد.

3.2.8.3 فرايند ثبت نام در موارد ذيل نبايد بيش از 3 روز بطول بينجامد.:

  1. ثبت نام با استفاده از كارت اعتباري
  2. ثبت نام بصورت درخواست كتبي

ايرادات : اين دو نيازمندي در تناقض با هم مي باشد.

نيازمندي بازنويسي شده : 3.2.8.2 فرايند ثبت نام مي بايست :

  1. براي روشهاي ثبت نام ذيل بين 1 تا 3 روز بطول بينجامد:
    1. ثبت نام با استفاده از كارت اعتباري
    2. ثبت نام بصورت درخواست كتبي
  2. براي ساير روشهاي ثبت نام بين 1 تا 10 روز بطول بينجامد.

 

مثال 10 :

نيازمندي اوليه : 3.2.8.6 هنگامي كه نرم افزار محاسباتي را انجام مي دهد مي بايست نتايج صحيح توليد نمايد.

 ايرادات : واقعا ؟ اين يك نيازمندي نيست. اين نوع از نيازها نبايد تعريف گردد.

نيازمندي بازنويسي شده : حذف نيازمندي

 

نتيجه گيري :

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

مرجع :

1.        Military Standard Specification Practices. MIL-STD-490A. U.S. Department of Defense, 4 June 1985.

منابع مفيد جهت مطالعه بيشتر :

1.       IEEE Std. 830-1998. IEEE Recommended Practices for Software Requirements Specifications. IEEE Computer Society. 20 Oct. 1998.

2.       Cook, David A., and Les Dupaix. "The Requirements for Good Requirements." Software Technology Conference Proceedings. Mar. 2001.

 

خوب دوستان اينم از قسمت آخر اين مطلب – در مطالب بعدي با ما باشيد.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت