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