شناخت نيازمنديها هميشه اولين دغدغه توسعه نرمافزار بوده است (البته نه در ايران). نيازمنديهاي كيفي از نظر اجرايي بخش اغلب مبهمي از نيازمنديهاست و معمولاً نميتوان آن را در ابزارهاي كاربردي مدلسازي متداول ردگيري (Trace) نمود. عمدهترين علتي كه سبب چنين موضوعي ميشود آن است كه ابزارهاي متداول مدلسازي كاركرد (Functionality) را مدل مينمايند و از اولين مدل كه معمولاً مدل موارد كاربري (use-case) ميباشد، كاركردهاي سيستم در نظر گرفته ميشوند، اما تنها برخي از نيازمنديها و خصوصيات كيفي در كاركردها ظاهر ميشوند و به همين دليل رهگيري آنها دشوار است. اين موضوع سبب شده است كه اغلب نيازمنديهاي كيفي بهصورت محسوسي ناديده گرفته شوند و تنها در صورتيكه تيم توان اجراي اجراي آنها را دارا باشد، مورد توجه قرار گيرند. به مثالهايي از خصوصيات كيفي توجه كنيد:
- نرمافزار باید توانایی برقراری، مدیریت، ارسال و دریافت امن اطلاعات با تجهیزات تعريفشده را دارا باشد.
- نرمافزار باید پردازش دستورات گزارشگیری را در کمتر از 90 ثانیه کامل نماید.
- نرمافزار بايد مستقل از سيستم عامل و قابليت استفاده در سيستم عاملهاي Desktop و Mobile را دارا باشد.
- نرمافزار بايد هر نوع از دست دادن داده را در كمتر از 500 ميلي ثانيه ترميم نمايد.
- نرمافزار بايد قابليت بازيابي مولفههاي خود را در كمتر 100 ميلي ثانيه دارا باشد.
- نرمافزار بايد بهگونهاي طراحي شود كه خطاي كاربري حذف يا به كمترين حد خود برسد.
(برگرفته از http://www.discovertodeliver.com)
چقدر امن، چقدر سرعت، چقدر مستقل از سيستم عامل، چه ميزان از دست دادن داده، چند مولفه براي بازيابي، چقدر خطاي كاربري؟؟
سوالاتي كه هر چقدر به جزئيات آنها وارد شويد، مسئله گيجكنندهتر خواهد شد و كاربران واقعاً از پاسخدهي به آن عاجز هستند (اينجا را بخوانيد). از طرفي برخي نيازمنديهاي كيفي حاوي بيشتر از يك نيازمندي هستند و در واقع ميبايست در بخشهاي مختلف سيستم اعمال شوند و نه يك بخش خاص. براي اينكه نيازمنديهاي كيفي به حالت تقريباً شفاف و بهگونهاي قابل تست تبديل شوند، نكات يا روشهايي بيان شده است. بهعنوان مثال استفاده از مدلهاي كيفي براي خصوصيات كيفي همانند سري ISO 25000 يا McCall يا Bohem كه ميتواند در شناخت نيازمنديهاي كيفي مورد استفاده قرار گيرد. اين روشها اغلب داراي مسئله تعريف هستند بدين معني كه تعاريفي كه از هر خصوصيات كيفي ارائه ميشوند كه سبب غرق شدن شما در فلسفه تعاريف شده و عملاً در قرار دادن نيازمنديها در دسته بهخصوص گمراه ميشويد.
يكي از روشهايي كه فارغ از تعاريف عمل مينمايد، روش سناريوهاي خصوصيت كيفي (quality attribute scenarios) است. اين روش به نوعي معادل مدل موارد كاربري براي مدلسازي كاركردهاست و براي مدلسازي نيازمنديهاي كيفي است. در اين روش مجموعهاي از سناريوها براي هر خصوصيت كيفي تعريف ميشود كه هر سناريو داراي شش بخش است.
- محرك (Stimulus): رويداد ورودي كه باعث تحريك سيستم يا نرمافزار ميباشد. ميتواند يك «درخواست تغيير» يا «حمله» يا «خطاي بحراني» باشد
- منبع محرك (Stimulus source): حتماً محرك از جايي صادر شده است كه بايد مشخص شود.
- پاسخ (Response): چگونه سيستم بايد به اين محرك پاسخ دهد (عمدتاً شما بايد با همكاري كاربر به آن پاسخ دهيد و توپ را سمت كاربران نياندازنيد)
- معيار پاسخ (Response measure): نحوة ارزيابي كيفيت پاسخ ميبايست به درستي مشخص و شفاف شود.
- محيط (Environment): محطيي كه محرك در آن اتفاق ميافند و در واقع نشان ميدهد كه وضعيت در زمان اتفاق محرك چگونه است.
- فرآورده (Artifact): بخشي از سيستم كه درگير تحريك ميشود. اغلب كل سيستم نرمافزاري است اما ميتواند بخش خاصي از آن نيز باشد.
سناريوهاي كيفي به دو دسته عمومي (General) و اختصاصي (Concrete) تقسيم ميشوند. سناريوهاي عمومي براي خصوصيت كيفي تعيين ميشوند و در واقع محدوده بخشهاي هر خصوصيت كيفي را تعيين ميكنند اما سناريوهاي كيفي اختصاصي بهصورت دقيق مشخص مي كنند كه چه اتفاقي ميافتد و براي هر خصوصيت كيفي مطابق با نيازمنديها تعيين ميشود. با اين روش پس از نوشتن نيازمنديهاي كيفي ميبايست آنها را تبديل به سناريوهاي كيفي اختصاصي نمود و در واقع سناريوهاي كيفي هستند كه براي طراحي مورد استفاده قرار ميگيرند. بنابراين رهگيري نيازمنديهاي كيفي به مجموعه سناريوهايي كيفي است كه سبب برآورده شدن آنها ميشوند. همچنين سناريوها اجازه ميدهند كه جزئيات بيشتري از نيازمنديهاي كيفي شناخته و يا تشريح شوند.
براي مطالعه بيشتر در زمينه ميتوانيد به فصل چهار كتاب معماري نرمافزار (اينجا) و اينجا مراجعه كنيد.
Leave A Comment