تعیین نیاز ها ، مستند مهندسی نیاز ها

نیازها
پس از تعیین چارت عملیاتی می بایست نیازهای عملیاتی و نیازهای كیفی را مشخص كنیم.
انواع نیازها :
معمولاً نیازها را بر اساس شرح وظایف افراد مشخص می كنیم. در واقع، نیازها در قالب (سیستم باید را انجام دهد ) مشخص می شوند . نیازها ، عملیاتی یا غیرعملیا تی هستند . به نیازهای X عمل غیرعملیاتی، نیازهای كیفی گفته می شود. بعد از این كه چارت عملیاتی را تعیین كردیم ، با درنظر گرفتن شرح وظایف، امكانات سیستم كامپیوتری و نیازهای جدید مبادرت به تعیین نیازهای عملیاتی و كیفی می نماییم. هر نیاز را با كدی مشخص می كنیم. برای مثال تمام نیازهای واحد قرض الحسنه، كد واحد قرض الحسنه همراه با شماره و نوع نیاز می گیرد. 

شكل زیر ، نیازهای عملیاتی واحد قرض الحسنه را نشان می دهد.

قابلیت ها، سرویس هایی هستند كه سیستم در اختیار كاربران قرار می دهد . برای هر نیاز ، كدی مشخص شده است. نوع نیاز عملیاتی می تواند یكی از موارد زیر باشد:
 E ) 1). ضروری
 O ) 2). اختیاری
 H ) 3). پنهان
 

برای هر واحد عملیاتی به طور جداگانه نیازهای كیفی را نیز مشخص می كنیم . نیازهای كیفی بسیار مهم هستند و در حالت كلی شامل موارد زیر می باشند:
-1 تحمل خطا: اشكالات غیرمترقبه ی سخت افزاری و نرم افزاری را باید پیش بینی كرد. برای مثال در سیستم كارت ساعت، ممكن است دستگاه كار نكند، در این صورت نگهبان باید قادر به وارد كردن اطلاعات از طریق صفحه كلید باشد. سیستم باید در صورت خرابی شبكه پیام های ارسالی را نگهداری كند.
2 _ زمان پاسخگویی: این زمان، به خصوص در سیستم های بلادرنگ بسیار مهم می باشد. سیستم های بلادرنگ، عملیات كنترل پردازش را انجام می دهند. برای نمونه، سیستم باید با دریافت سیگنال خطر حداكثر در ظرف 5 دقیقه كلیه ی درب ها را قفل نماید.
3 _ سهولت استفاده: در واقع تاكید بر این دارد كه كاربر بدون هیچ شناخت قبلی از سیستم بتواند به سادگی آن را مورد استفاده قرار دهد. برای نمونه، سیستم باید دارای راهنمای برخط 1 باشد. سیستم باید
از طریق ماوس امكان استفاده از راهنما را داشته باشد.
4 _ نوع رابط: سیستم باید اطلاعات را به صورت گرافیكی نمایش دهد یا این كه از طریق ترمینال هایی قابل دسترسی باشد. سیستم باید فرم های استاندارد شركت را استفاده نماید.
5 _ محیط اجرایی: سیستم باید تحت ویندوز یا تحت شبكه ی لینوكس عمل نماید. تومان شود. 

 6 _ هزینه: هزینه ی تولید برنامه ها باید حداكثر X ریال شود.

7 _ امنیت: سیستم باید كلمه ی عبور افراد را كنترل یا داده ها را رمزگذاری نماید.

دیدگاه شی گرا چه پیشنهادی برای تعیین نیازها می نماید؟
تعیین نیازها در دیدگاه شی گرا:
برای اینكه سیستم را شناسایی كنیم، ابتدا سرحدات آنرا مشخص می نماییم. یعنی، تعیین می كنیم كه چه افراد، نرم افزار ها یا سازمان هایی از سیستم استفاده می كنند. اینها را در اصطلاح بازیگر 2 می نامند .
یك كاربر یك نوع اكتور است اما كاربر فقط از نتایج كار استفاده می كند. اكتورها هم استفاده كننده هستند و هم كمك می كنند كه عملیات سیستم انجام شود. بنابراین اكتورها را می توان در دو دسته
قرار داد:
Online - 1
Actor - 2

دسته ی اول اكتورهای داخلی و دسته ی دوم اكتورهای خارج از سیستم هستند.

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

پس، برای شناخت به روش تجزیه و تركیب، ابتدا چارت سازمانی و با ارجاع به پست های سازمانی كه در چارت سازمانی درج شده، شرح وظا یف برای هر پست سازمانی بدست می آید . بر مبنای شرح وظایف، چارت عملیاتی را مشخص می نماییم. سپس برای هر واحد عملیاتی نیازهای كیفی و نیازهای عملیاتی را مشخص می كنیم. اما چه روشی برای شناخت باید داشته باشیم؟
تعیین نیاز در مقوله ی مهندسی نیازها مطرح است. انواع روش ها برای استخراج نیازها به صورت زیر می باشند:
1. مبتنی بر هدف
2. مبتنی بر وظیفه
3. مبتنی بر سرویس
4. مبتنی بر فرآیند
شناخت مبتنی بر هدف رابطه ای است منطقی بین آنچه كه وجود دارد و آنچه كه در آتیه به دست خواهد آمد. در جهت رفع مشكلات، اهداف و برنامه ریزی های راهبردك - بلند مدت و كوتاه مدت - در سازمان ها مطرح می باشد . لذا می توان تعدادی از نیازها را بر مبنای اهداف مشخص نمود . بر اساس فرآیندهای كاری نیز می توان بخش دیگر از نیازها را مشخص كرد. در واقع با شناخت عملیات كه در روش های ساخت یافته رایج بود، سیستم ها را بر اساس عملكرد سیستم ها تجزیه و مورد شناسایی قرار می دادند. همچنین بر اساس عملیاتی كه باید در سیستم كامپیوتری انجام شود نیازها را مشخص می كردند. به این روش در اصطلاح تجزیه ی عملیات می گویند.
شناخت مبتنی بر تجزیه و تركیب و نمودار عملیاتی، روش تجزیه ی سیستم ها بر اساس عملیات می باشد. در واقع، اگر برای مثال عملیات واحد آموزش را در قالب نمودار عملیاتی تجزیه كنیم و به آنجا رسیدیم كه عمل حذف و اخذ به صورت دستی انجام شود، حالا می توانیم بگوییم كه سیستم باید عمل حذف و اخذ را انجام دهد. پس باید ببینیم كه چگونه سیستم كامپیوتری می تواند پاسخگوی مشكلات بوده و عملیات را مكانیزه كند. سپس باید یادداشت كنیم كه نیاز است كه سیستم این عملیات را انجام دهد. شرح وظایف افراد نیز به كمك می كند تا نیازهای دیگر را مشخص كنیم. برای نمونه به شرح وظیفه ی مدیر گروه نگاه كنید. تائید شرایط فارغ التحصیل بودن یكی از وظایف مدیر گروهاست.

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

اكتورهای كاری سرویس گیرنده یا سرویس دهنده هستند. موردهای استفاده از سیستم جاری و اكتورها به صورت زیر مشخص می شود:

برای هر واحد عملیاتی اكتورها را مشخص می كنیم و مشخص می كنیم كه چه سرویس هایی ارائه می كنند.

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

نرم افزار و مهندسی نرم افزار software Engineering

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

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

نکات مورد توجه در مورد نرم افزار:

• نرم افزار هم شامل محصول است و هم وسیله ای برای تولید یک محصول.

• نرم افزار، مهندسی (طراحی و ساخته) می شود نه تولید.

• نرم افزار رو به زوال میرود اما کهنه نمی شود.

در حال حاضر اکثر نرم افزارها بصورت خصوصی ساخته شده اند.

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

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

مهندسی نرم افزار software Engineering :

مهندسی نرم افزار شامل : یک فرآیند، تکنیکهای مدیریت ، روشهای فنی و استفاده از ابزار است.

فازهای عمومی مهندسی نرم افزار :

فاز تعریف - تمرکز دارد بر چه چیز (مهندس اطلاعات، برنامه ریزی پروژه نرم افزار، تحلیل نیازمندیها)

فاز توسعه – تمرکز دارد بر چگونه (طراحی نرم افزار، تولید کد، تست نرم افزار)

فاز پشتیبانی – تمرکز دارد بر تغییرات (نگهداری تصحیحی ، نگهداری وفق دهی، نگهداری تکمیلی و نگهداری پیش گیری)

مدلهای فرآیند نرم افزاری :

مدل آبشاری : روش قدیمی اما مناسب برای جایی که نیازمندیها از ابتدا کاملا مشخص است.

مدل نمونه سازی : مناسب برای مواقعی که مشتری نیازهای درستی را مطرح می کند اما کمتر با جزییات سروکار دارد و توسعه دهنده باید با سختیهای آن همانند توسعه یک نمونه زمخت به یک محصول کامل ، مدارا کند.

مدل توسعه و کاربرد سریع RAD : از اجزا و قطعات آماده بیشترین استفاده را انجام میدهد و سیکل توسعه بسیار کوتاهی دارد.

مدل افزایشی: نرم افزار را بصورت قسمتهای کوچک اما قابل استفاده ارائه می کند و هر قسمت روی قسمتهای قبلی سوار شده است.

مدل حلزونی: خصوصیت تکراری بودن روش نمونه سازی را با جنبه های سیستماتیک و کنترل شده روش آبشاری ترکیب می کند.

مدل توسعه همزمان: شبیه مدل حلزونی است اما اغلب در توسعه برنامه های کارگذار – مشتری استفاده می شود.

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

مدل روشهای فرمال: نمادهایی کاملا ریاضی وار برای مشخص کردن، طراحی و ارزیابی سیستم های رایانهی.

تکنیک های نسل چهارم4GT : ابزاری نرم افزاری که کد منبع رابرای یک نرم افزار از روی یک تعریف خصوصیات سطح بالا تولید می کند.