مدلسازي نيازمندي‌هاي كيفي

شناخت نیازمندی‌ها همیشه اولین دغدغه توسعه نرم‌افزار بوده است (البته نه در ایران). نیازمندی‌های کیفی از نظر اجرایی بخش اغلب مبهمی از نیازمندی‌هاست و معمولاً نمی‌توان آن را در ابزارهای کاربردی مدلسازی متداول ردگیری (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) تقسیم می‌شوند. سناریوهای عمومی برای خصوصیت کیفی تعیین می‌شوند و در واقع محدوده بخش‌های هر خصوصیت کیفی را تعیین می‌کنند اما سناریوهای کیفی اختصاصی به‌صورت دقیق مشخص می کنند که چه اتفاقی می‌افتد و برای هر خصوصیت کیفی مطابق با نیازمندی‌ها تعیین می‌شود. با این روش پس از نوشتن نیازمندی‌های کیفی می‌بایست آنها را تبدیل به سناریوهای کیفی اختصاصی نمود و در واقع سناریوهای کیفی هستند که برای طراحی مورد استفاده قرار می‌گیرند. بنابراین ره‌گیری نیازمندی‌های کیفی به مجموعه سناریوهایی کیفی است که سبب برآورده شدن آنها می‌شوند. همچنین سناریوها اجازه می‌دهند که جزئیات بیشتری از نیازمندی‌های کیفی شناخته و یا تشریح شوند.