Валідація і верифікація вимог: як не плутати і чітко розуміти різницю

💡 Усі статті, обговорення, новини для аналітиків — в одному місці. Приєднуйтесь до Analysts спільноти!

Сьогодні хочу поговорити про верифікацію і валідацію вимог. Я вже майже 10 років у бізнес-аналізі, і все ще, коли мене хтось питає про верифікацію і валідацію вимог, я зависаю на секунду.

Коли я тільки вчилась бізнес-аналізу, я постійно плутала ці два процеси. Це щось із того роду, коли знайомишся з людиною, вона називає своє ім’я, і за секунду ти його забуваєш. Ну хоч вбий — не могла нормально запам’ятати. Ніби читала BABOK — Requirements Analysis and Design Definition, є етап requirements verification і є також етап requirements validation.

Я часто плуталась на співбесідах і тестах. Так от, одного разу я вирішила таки покласти цьому край — розібратись і раз і назавжди запам’ятати. Можливо, у вас теж така сама проблема, або, може, ви в процесі навчання — так от, ловіть пояснення, яке мені запам’яталося.

Якщо коротко і по суті:

А якщо детальніше:

Верифікація вимог

Коли ми пишемо вимоги, перед тим як передати їх розробникам, ми маємо перевірити їх на якість: чи правильно вони сформульовані, структуровані і деталізовані.

Наприклад, коли перевіряємо конкретну вимогу, то дивимось на такі критерії:

• Атомарність → вимога є самодостатньою
• Однозначність → має лише одне можливе тлумачення
• Повнота → містить усі необхідні деталі для розробки
• Узгодженість → не суперечить іншим вимогам
• Тестованість → можна довести, чи вимогу виконано

Сам процес верифікації вимог класно описаний у книжках Карла Вігерса (Software Requirements або Software Requirements Essentials) — кому цікаво, рекомендую.

Як я знаю, що мої вимоги якісні?

Навіть якщо я перечитала 100 разів свої вимоги, я могла щось пропустити або просто не сприймати.

Ось ці три активності допомагають мені робити якісні вимоги.

Мій улюблений підхід — чеклісти: робиш один раз свій чекліст і використовуєш на всіх проектах.

Валідація вимог

Коли ми створюємо вимоги, ми також маємо бути впевнені, що вони вирішують реальну проблему і приносять цінність.

Тобто ми маємо бути впевнені, що будуємо потрібний функціонал, продукт і так далі.

Зазвичай, щоб це зробити, я дуже тісно працюю зі стейкхолдерами, роблю прототипи, розрахунки і так далі — залежно від типу проекту.

Тобто ідеальна вимога марна, якщо вона не вирішує проблему. Так само правильна ідея марна, якщо вона описана з помилками.

Тому використовуємо валідацію для напрямку, а верифікацію для якості.