نيازمنديها (requirements) در حوزه نرمافزار هميشه پيچيدگي خاصي داشتهاند و شناخت، درك و مدلسازي آنها اغلب نيازمند مهارتهاي تجربي است. پيچيدگي نيازمنديها برخواسته از دو حوزه متفاوت است: حوزه كاربران و حوزه توسعه نرمافزار. در حوزه كاربران نگاه متفاوت كاربران به خواستهها و نيازها، ميزان جزئيات ارائهشده توسط كاربران، دانش قبلي كاربران در حوزه نرمافزار و برخي پارامترهاي ديگر (كه شناختشان اغلب دشوار است) سبب پيچيدگي فضاي كاربران ميشود. به همين دليل اغلب متدهاي توسعه نرمافزار سعي ميكنند كه كاربران را با استفاده از روشهايي كه در حوزه دوم ارائه ميدهند، پيچيدگي حوزه اول را مهار نمايند. نمودار موارد كاربري، نمودار جريان داده، نمودار زمينه سيستم و نمودار فعاليت از جمله روشهايي هستند كه براي مهار پيچيدگي حوزه كاربران براي نيازمنديها ارائه ميشوند و سعي به كاناليزه نمودن دادههاي مربوط به نيازمنديها نموده تا نرمافزار شروع به شكلگيري نمايد. اما اين همه ماجرا نيست! واقعيت اين است كه پيچيدگي حوزه نرمافزار در نيازمنديها خيلي بيشتر از پيچيدگي در حوزه كاربران است كه ما سعي به مهار و هدايت آن داريم. انواع روشهاي دستهبندي نيازمنديها، روشهاي مدلسازيها و خصوصيات ابزارها در كنار پيچيدگي تعاريفي كه در ذهن براي مفاهيمي چون فعاليت، وظيفه، مورد كاربري، رفتار داريم، سبب ميشود تا شناخت نيازمنديها اغلب مهارتي شود تا ساختاريافته. حال انتقال اين پيچيدگي به حوزه كاربران سبب ميشود تا او دنياي ما رو بي قانون! تلقي نمايد.
در سادهترين دستهبندي نيازمنديها، آنها به سه دسته نيازمندي كاركردي (Functional)، كيفي (Quality) و اجبار (Constraint) تقسيم ميشوند (هر چند دستهبنديهاي ديگري نيز از نيازمنديها وجود دارد). نيازمندي كاركردي اغلب براي همه آشنا و قابل درك است و شايد هر دانشجوي نرمافزاري كه درس مهندسي نرمافزار را گذارنده (شايد هم نگذارنده) بتواند در اين زمينه اظهارنظر كند، اما به نظر من موضوع به اين سادگي نيست. بهعنوان مثال به نيازمندي زير توجه كنيد:
«سيستم بايد در حداكثر زمان 5 ثانيه جستجو را انجام دهد»
طبيعي است كه اين نيازمندي كيفي (كارايي) به نظر برسد، چرا كه كيفيت كاركرد «جستجو» را تعيين ميكند، اما در نظر بگيريد كه سيستم، ماژول جستجوي كتابخانه باشد كه در اينصورت زمان در تعيين اغلب رفتارهاي سيستم و طبعاً كاركرد سيستم نقشي اساسي دارد. حال شما از مسئول كتابخانه ميپرسيد كه وقتي بيشتر از 5 ثانيه جستجو طول ميكشد، سيستم بايد چه كاري انجام دهد؟ (يك بار امتحان كنيد، صحنه جالبيست!) با اين كار پيچيدگي فضاي توسعه نرمافزار به فضاي كاربري هل داده ميشود تا كاربر نقشي يك متخصص! را ايفا نمايد.
براي كاهش چنين پيچيدگيهايي در نيازمنديهاي نرمافزار موارد زير ميتواند كمك نمايد:
- جهت كمتر درگير نمودن كاربران در جزئيات فني، نيازي نيست تا كاربر تمامي جزئيات را بهصورت دقيق مطرح نمايد، بلكه با اندكي از جزئيات شروع كنيد و سعي كنيد با نمونهسازي ساده (واقعي) او را وارد جزئيات كنيد.
- فرمولها، روشها و مدلهاي خود را به فضاي ذهن كاربر منتقل نكنيد، بلكه شما وارد فضاي كاربر شويد و قواعد محيطي او را فراگيريد.
- روش كاري خود را به صورتي كاربرپسند (فاقد پيچيدگي) به كاربر توضيح دهيد تا بداند چگونه كار ميكنيد.
- از يك مدل دستهبندي نيازمنديهاي همچون ISO 25000 استفاده كنيد (كتاب تضمين كيفيت نرمافزار ميتواند به شما كمك كند) تا بتوانيد با سوالات مختلف، نيازمنديهاي مختلف را كشف كنيد، اما لزومي ندارد تا دستهبندي را رعايت كنيد و در قيد و بند آن باشيد.
- نيازمنديها را در ابتدا بهصورت User story يا داستان بنويسيد و سپس در آنها را تبديل به نيازمنديهاي سيستمي نماييد.
- ممكن است كاربر برخي اوقات حس خود را از نرمافزار يا كاري كه قرار است با نرمافزار انجام دهد، بيان كند، آنها به شما خط ميدهند كه بتوانيد در مورد نيازمندي كيفي يا اجبارها اظهارنظر كنيد.
Leave A Comment