مقدمه

به نظر من يكي از مشكلات دانشجويان و تازه واردهاي توليد نرم افزار، نبود ديد كلي نسبت به بخشهاي مختلف مهندسي نرم افزار است. قبلاً اشاره‌اي به SWEBOK كردم، حال برپاية آن به معرفي حوزه‌هاي دانش مهندسي نرم افزار مي‌پردازم. بي شك خوانندگان مي‌توانند با رجوع به سند SWEBOK با منابع تشريح كننده هر حوزه آشنا شوند.

در كل ۱۲ حوزه وجود دارد كه در ابتدا به اولين حوزه در چرخة توليد نرم افزار مي‌پردازم.

نيازمنديهاي نرم افزار (Software Requirements)

بررسيهاي مختلفي در مورد عوامل شكست پروژه‌هاي نرم افزار صورت پذيرفته است. عدم توجه به نيازمنديهاي پروژه و استخراج ناقص آنها يكي از عوامل اصلي شكست پروژه‌هاي نرم افزار شناخته شده است.

نيازمنديهاي نرم افزار مبحث مهم و گسترده‌اي است كه سعي ميكنم در چند پاراگراف كليات آن را بيان كنم.

تعريف چند اصطلاح

تعاريف مختلفي براي نيازمندي نرم افزار ارائه شده است، بنا به تعريف IEEE:

نيازمندي خصوصيت يا ملاكي است كه در راستاي حل مشكل در دنياي حقيقي، بيان مي‌شود.

بر اين پايه:

نيازمندي نرم افزاري، خصوصيت يا ملاكي است كه با هدف حل مشكل در دنياي حقيقي، پايه پياده سازي نرم افزار مي‌شود. كه IEEE به آن “نيازمندي محصول” (Product Requirement) مي‌گويد.

و در مقابل

“نيازمندي فرآيند” (Process Requiremnt) به نيازمنديهاي خوده توسعه نرم افزار مي‌پردازد مانند: “نرم افزار بايد با زبان #C‌ نوشته شود”.

تمركز از اينجا به بعد بر “نيازمندي محصول” است و به مفاهيم مرتبط با آن اشاره مي‌كنم.

اجزا و عوامل تأثيرگذار بر”نيازمنديهاي نرم افزاري”

شكلي كه در ادامه آمده است به نحو جالبي اجزا و عوامل تأثيرگذار بر “نيازمنديهاي نرم افزار” را نمايش مي‌دهد [Kar03]:

نیازمندیها

نيازمنديها به دو دسته كلي تقسيم مي‌شوند:

1. نيازمنديهاي عملياتي (Functional) يا رفتاري (Behavioral): به زبان ساده اين نوع نيازمندي ارتباط مستقيم با فعاليتهاي تجاري كاربر دارد و توسعه دهنده بايد آنها را پياده سازي كند تا كاربر بتواند از نرم افزار استفاده نمايد. به عنوان مثال “نرم افزار بايد امكان ايجاد طرف حساب جديد را داشته باشد” يك نيازمندي عملياتي است. بصورت سنتي نيازمنديهاي عملياتي بصورت ليستي از امكانات (مانند مثالي كه زده شد) بيان مي‌شدند ولي امروزه روشهاي مؤثرتري مانند Usecase يا استفاده از UML در حال گسترش است.
2. نيازمنديهاي غير عملياتي (Nonfunctional): اين نوع نيازمندي به عنوان محدوديت براي سرويس يا عملكردي كه سيستم ارائه مي‌دهند، در نظر گرفته مي‌شوند. آنها شامل محدوديتهاي زماني، محدوديت براي فرآيند يا استاندارهاي توسعه مي‌باشند. آنها معمولاً به كليت سيستم اعمال مي‌شوند و مربوط به سرويس يا امكان خاصي نيستند [Som06]. به موارد ذكر شده مي‌توانيد نيازمنديهاي كيفي نرم افزار مانند Usability يا كاربري، Reliability يا قابليت اطمينان، Performance‌ يا كارايي، Supportability را نيز اضافه كنيد. در آينده با بررسي مدل +FURPS بيشتر به اين مقوله مي‌پردازم.

موارد ديگري كه ذكر توضيح كوتاهي در مورد آنها خالي از لطف نيست:

• نيازمندي تجاري (Business Requirement): بالاترين سطح نيازمندي است كه بدون توجه به سيستم نرم افزاري كه قرار به توليد است به سازمان و كسب و كار مربوط به آن مي‌پردازد.
• نيازمنديهاي كاربر (User Requirement) و بقيه زير مجموعه Functional: از اين به بعد وارد چرخه توليد نرم افزار شده‌ايم و با توجه به سيستمي كه قرار به تهيه است، نيازمنديها جمع آوري و منعكس مي‌شوند.
• Use case Document: يكي از منعطف ترين و قدرتمندترين ابزاري كه بشر براي جمع آوري و تكميل نيازمنديهاي عملياتي شناخته است. در آينده بصورت مبسوط به آن مي‌پردازم.
• Business Rules يا قوانين تجاري: معمولاً به قوانين خارج از سازمان اشاره دارد مانند قوانين مالياتي يا استاندارهاي اجباري. اين قوانين برروي توسعه سيستم شما تأثير دارند.
• خصوصيات و پارامترهاي كيفي (Quality Attributes): در نيازمنديهاي غير عملياتي به آنها اشاره كردم Usability يا كاربري، Reliability يا قابليت اطمينان، Performance‌ يا كارايي، Supportability. آنها به “ility-” هم معروف هستند، چون بيشتر آنها با همين ۵ حرف پايان مي‌يابند.

تا اينجا به نظر من پرداختن به مفاهيم كافي است، اگر سئوالي در ذهن شما هست كه هنوز پاسخ داده نشده، با من در ميان بگذاريد.

فعاليتها در حوزة “نيازمنديهاي نرم افزاري”

چهار فعاليت عمده در حوزة “نيامنديهاي نرم افزار” وجود دارد كه ذكر آنها لازم به نظر مي‌رسد:

1. استخراج (Elicitation): فعاليتي است كه در آن فرد مسئول با ذي نفعان پروژه ارتباط برقرار مي‌كند و نياز و انتظار آنان از نرم افزار كه قرار است توليد شود را كشف مي‌نمايد. اين فعاليت از طريق مصاحبه، مشاهده و ساير تكنيكهاي ممكنه صورت مي‌پذيرد.
2. تجزيه و تحليل (Analysis): در اين مرحله با تجزيه و تحليل خروجي مرحله قبل تضادهاي احتمالي بين نيازمنديهاي استخراج شده از بين مي‌رود، مرز نيازمنديهايي كه بايد پياده سازي شود پرنگ شده و نيازمنديها دسته بندي مي‌شوند.
3. تهيه مشخصات (Specification): اين فعاليت به زبان ساده به مستندسازي و مكتوب كردن نيازمنديها اشاره دارد با اين توضيح كه بصورت نظامند قابل بازبيني، ارزيابي و تصديق باشند.
4. تصديق (Validation): در اين فعاليت نيازمنديهاي مستند شده با هدف تصديق صحت آنها بررسي مي‌شوند. اين صحت شامل تطابق با استاندارهاي شركت، قابل فهم بودن، سازگاري و كامل بودن آنان مي‌باشد.

عدم توجه به هر كدام از موارد بالا سلامت پروژه را با خطر مواجه مي‌كند.

سخن پاياني

اميدوارم با همين مقدمه كوتاه ديد بازتري نسبت به “نيازمنديهاي نرم افزار” پيدا كرده باشيد. سعي مي‌كنم در آينده نكات عملي بيشتري در مورد اين حوزة مهم از مهندسي نرم افزار بيان كنم.