А вы знаете какой тот самый заветный этап при управлении требованиями, который может потом определить успех или неудачу проекта? Да, мы говорим об утверждении требований! 😉

Для краткости давайте разберём это на примере:

👉 На семинаре обсуждалось одно из требований к системе обучения. Требование гласило: «Система должна обеспечить отключение неактивных терминалов системы обучения по истечении тайм-аута». Однако участники семинара обнаружили, что в требовании есть несколько неясностей...

▪ Разработчик предположил, что система должна автоматически отключать пользователей, если они неактивны в течение определённого периода времени. ▪ Сторонник продукта, выразил опасения, что это может раздражать пользователей, которые просто отвлеклись. ▪ Бизнес-аналитик, написавший спецификацию требований, отметила, что в требовании не указано, как именно система должна определять неактивность терминала.

Этот пример показывает, насколько важно тщательно прорабатывать требования и затем утверждать их точную и конкретную формулировку. Неясные или неполные требования могут привести к ошибкам, которые вам дорого обойдутся 😐