ارائه الگویی جهت ارزیابی متریک های سند تشریح الزامات نرم افزار SRS

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

فصل اول

مقدمه

۱-۱ تعریف مسئله

۱-۲ سؤال‌های تحقیق

۱-۳ سابقه تحقیق

۱-۴ ضرورت انجام تحقیق

۱-۵ فرضیه‌ها

۱-۶    هدف‌ها

۱-۸ جنبه جدید بودن و نوآوری طرح

۱-۹ روش انجام تحقیق

۱-۱۰ مراحل انجام تحقیق

۱-۱۱ ساختار پایان‌نامه

فصل دوم

ادبیات و پیشینه تحقیق

۲-۱  تاریخچه مهندسی نیازمندیها

۲-۲ تعریف نیازمندی

۲-۳ طبقهبندی نیازمندیها

۲-۴  ذینفعان

۲-۵  مهندسی نیازمندیها

۲-۶  دلایل اهمیت مهندسی نیازمندیها

۲-۷ خلاصه فصل

فصل سوم

بررسی کارهای انجام شده

۳-۱ مراحل مهندسی نیازمندیها

۳-۲ استخراج نیازمندیها

۳-۳  تحلیل و مذاکرات نیازمندیها

۳-۴  مستندسازی نیازمندیها

۳-۵  تایید اعتبار نیازمندیها

۳-۶ مدیریت نیازمندیها

۳-۷ چگونگی انجام مهندسی نیازمندیها

فصل چهارم

الگوی پیشنهادی

۴- ۱ مقدمه

۴- ۲ اندازهگیری

۴-۳    استاندارد بین المللی فرایندهای چرخه حیات نرم افزار ISO/IEC

۴-۴ اهداف الگوی پیشنهادی

۴-۵ الگوی پیشنهادی

۶-۴ استاندارد  12207 ISO/IEC  به عنوان پایه الگو

۴-۷  ویژگیهای الگو

فصل پنجم

ارزیابی

۵-۱ مقدمه

۵-۲   آشنایی کلی با پروژه درخواستی شهرداری در شرکت سامانه ارتباطات الماس پارس

۵- ۳ متریکهای مدیریت

۵- ۴ متریکهای ریسک

۵- ۵ وزندهی به زیر متریکهای تعریفشده

۵- ۶ روند ارزیابی، تحلیل و نمایش نتایج

فصل ششم

بحث و نتیجه گیری

۶-۱ مقدمه

۶-۲ دستاورد  پایاننامه

۶-۳ پیشنهادات آتی

 مقدمه

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

۱-۱ تعریف مسئله 

مفهوم نیازمندی یکی از اصول و مقدمات بحث مهندسی نیازمندی ها است [Zuse, 1991]. یک «نیازمندی» به این صورت تعریف می شود: «شرط یا قابلیتی که باید به منظور حل مسئله یا رسیدن به یک هدف تامین شود. یا یک شرط یا قابلیت که باید توسط سیستم یا مولفه سیستم به منظور برآورده ساختن یک قرارداد، استاندارد، توصیف یا دیگر مستندات رسمی اعمال شده تامین شود».

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

اهمیت زیاد نیازمندی‏ها از این گفته بروکس [Brooks & Fred P, 1986] کاملاً مشهود است: «سخت‏ترین بخش از سیستم نرم‏افزاری تصمیم‏گیری دقیق در مورد چیزی است که باید ساخته شود. هیچ بخش دیگری از کار به دشواری ایجاد نیازمندی‏های با جزئیات تکنیکی که شامل تمام واسط‏ها با افراد، ماشین و سایر سیستم‏های نرم‏افزاری باشد نیست. هیچ بخشی از کار اگر درست انجام نشود به اندازه این بخش سیستم حاصل را فلج نمی‏کند. تصحیح بعدی هیچ بخش از کار، دشوارتر از این مرحله نیست.» به عبارتی استخراج، تحلیل و خوب نوشتن نیازمندی‏ها دشوارترین بخش از مهندسی نرم‏افزار است.

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

می توان نیازمندی ها را به دو گروه، نیازمندی های کارکردی و نیازمندی های غیرکارکردی تقسیم بندی کرد. بر این اساس، نیازمندی های کارکردی، کارکردی که سیستم نرم-افزاری قادر به انجام آن است را معلوم می کند. از طرف دیگر نیازمندی های غیرکارکردی، کارکرد نیستند، بلکه کیفیت یا رفتار مورد انتظار کاربر است. چنین نیازمندی-هایی سیستم را در حد عملیاتی قابل قبولی، محدود می-کنند. برای مثال، یک نیازمندی غیرکارکردی می تواند به این صورت تعریف شود که، فرآیند احراز هویت باید در چهار ثانیه یا کمتر انجام شود. نیازمندی های غیرکارکردی با بسیاری از نیازمندی های کارکردی در ارتباط هستند. به هر حال بیان نیازمندی های غیرکارکردی بصورت کمّی بسیار چالش برانگیزتر و مهم تر از بیان نیازمندی های کارکردی است.

ولی عموماً توافق نظر بر روی طبقه بندی نیازمندی ها در سه سطح می باشد: «نیازمندی های محصول»، «نیازمندی های کاربر» و «نیازمندی های کسب و کار». همانگونه که در (شکل۱) مشاهده می شود. این مدل درک بهتری از نیازمندی-ها را ارائه می دهد.