به نظر می رسد سردرگمی زیادی در مورد شرایط راستی آزمایی و اعتبارسنجی وجود دارد. بسیاری از مردم و حتی تحلیلگران کسب و کار و متخصصان QA (تضمین کیفیت) به گونه ای در مورد V&V (راستی آزمایی و اعتبار سنجی) صحبت می کنند و حتی آن را اجرا می کنند که انگار یکی هستند در حالیکه این فعالیت ها یکسان نمی باشند. در این مطلب، قصد داریم تفاوت بین راستی آزمایی (Verification ) و اعتبار سنجی (Validation) را بررسی نماییم.
اعتبار سنجی (Validation) فرآیند تایید کامل بودن و صحت الزامات است. اعتبار سنجی همچنین تضمین می کند که الزامات:
۱) به اهداف تجاری اعلام شده دست پیدا می کنند
۲) نیازهای ذینفعان پاسخ داده می شود
۳) واضح هستند و توسط توسعه دهندگان قابل درک می باشند.
اعتبار سنجی برای شناسایی الزامات از دست رفته و اطمینان از اینکه الزامات دارای ویژگی های کیفی خاصی هستند، ضروری است. اعتبارسنجی به هر یک از نیازهای فردی می پردازد تا بدین وسیله اطمینان حاصل شود که الزامات دارای ویژگی های زیر می باشند:
- صحیح – به طور دقیق نیازهای مشتری یا نیازهای جانبی را بیان می کند
- واضح – فقط می تواند یک معنی داشته باشد
- امکان پذیر – می تواند در فضای محدودیت های شناخته شده پیاده سازی شود
- قابل تغییر – در صورت لزوم به راحتی می تواند با تاریخچه تغییر کند
- ضروری – چیزی که مشتریان واقعاً به آن نیاز دارند را مستند می کند
- اولویت بندی شده – از نظر اهمیت گنجاندن در محصول رتبه بندی شده است
- قابل ردیابی – می تواند به الزامات سیستمی و به طرح ها، کدها و آزمایش ها مرتبط باشد
- قابل تأیید – اجرای صحیح را می توان با آزمایش، بازرسی، تجزیه و تحلیل یا نمایش تعیین کرد
راستی‌آزمایی (Verification) فرآیندی است که طی آن تأیید می شود که محصول طراحی‌شده و ساخته شده به‌طور کامل نیازمندی‌های ذینفعان را برآورده می‌کند. راستی‌آزمایی شامل انجام بازرسی‌ها، آزمایش‌ها و تحلیل‌های مختلف در طول چرخه عمر محصول است تا اطمینان حاصل شود که طراحی، تکرارها و محصول نهایی به طور کامل نیازمندی‌ها را برآورده می نمایند.
برای جلوگیری از دوباره کاری ها، الزامات باید قبل از طراحی، تایید و تصویب شوند. اگر الزامات مورد تایید قرار نگیرند، آنگاه اعتبار سنجی الزامات و راستی آزمایی محصول به ناچار در طول فعالیت های طراحی و توسعه محصول با هم انجام می شود. از آنجایی که راستی آزمایی بر اساس الزامات هدایت می‌شود، احتمال زیادی وجود دارد که الزامات گمشده، از دست رفته یا نامعتبر کشف نشوند. الزامات از دست رفته و الزامات نامعتبر باعث دوباره کاری و خارج از حد شدن هزینه ها می شوند. توجه داشته باشید که آخرین مشخصه کیفی ذکر شده در بالا “قابل تایید” بودن است. ارزیابی راستی آزمایی در حین اینکه الزامات خود را توسعه می دهید و تأیید اینکه الزامات قابل تأیید هستند، به طور قابل‌توجهی کیفیت الزام را بهبود می‌بخشد.
این مطلب را هم بخوانید: اهمیت مدارک تحلیل کسب و کار IIBA
تأیید اینکه الزامات شما از راستی آزمایی پشتیبانی می کنند، مبنایی برای تخمین هزینه‌های راستایی آزمایی و زمان‌بندی فراهم می‌کند و هزینه‌های راستایی آزمایی را کاهش می‌دهد. الزام غیر قابل تأیید یک الزام بد یا غیر ضروری است. اگر نمی توانید یک الزام را تأیید کنید، نخواهید توانست آن را طراحی کرده یا بسازید. به عنوان مثال، شرط “محصول باید قابل اعتماد باشد” را در نظر بگیرید. چه چیزی قرار است قابل اعتماد باشد؟ اگر نمی توانید تعریف کنید که چه چیزی قابل اعتماد است، طراحان چگونه بدانند که قابل اعتماد چیست؟ اگر نتوانید یک نیاز را راستی آزمایی کنید، ممکن است نتوانید مشتری خود را متقاعد کنید که محصول شما قابل اعتماد است.
مدیریت ریسک یکی از مسئولیت های کلیدی مدیر پروژه است. اطمینان از اینکه کار توسعه با استفاده از الزامات قابل تأیید شروع می شود، کلید کاهش ریسک است. بررسی دقیق هر الزام برای اطمینان از قابل تأیید بودن آن و حذف یا درخواست بازنویسی الزاماتی که قابل تأیید نیستند، یک فعالیت مهم در فرآیند توسعه نیازمندی ها است. Enfocus Solutions Requirement Suite ابزارها و پشتیبانی اساسی را برای اطمینان از مستندسازی مؤثر، اعتبار سنجی و راستی آزمایی الزامات فراهم می کند.
