Помните миф о кратном удорожании исправления дефектов на поздних стадиях разработки, в 100 и 1000 раз? Но нас в первую очередь интересует разработка требований, что тут будет дефектом?

Можно отследить изменения требований, их источники и влияние на проект.

И тут есть исследование 2011 года 'Software Requirements Change Taxonomy: Evaluation by Case Study' — "Таксономия изменений требований: оценка на основе кейса".

Авторы указывают следующие источники изменений в требованиях:
* Рынок (включая сюда регуляторные требования);
* Организация-потребитель — изменения, связанные со сменой стратегического направления одного из потребителей / изменения договоров / политического климата;
* Концепция проекта — поменялась решаемая проблема, направление развития продукта, приоритеты, стейкхолдеры или процессы;
* Спецификация — уточнение спецификации для устранения неопределенности, двусмысленности, несогласованности, повышения понимания (это как раз можно отнести к дефектам требований);
* Техническое решение — изменения, отражающие технические ограничения, принципиально новый дизайн или элегантность решения.

К внутренним причинам можно отнести только спецификацию — остальное меняется из-за внешних факторов.

В статье рассмотрен один проект из британского госсектора, стоимостью более миллиона фунтов (45-50 млн. руб по курсу 2010 г.), выполненный по водопадному подходу (был конкурс и внешний подрядчик) и длившийся примерно полтора года — в общем, похоже на довольно типовой проект.

Всего в требования было внесено 282 изменения: 67 на этапе сбора, 97 — при проектировании и разработке, 9 на этапе системного тестирования и 109 на этапе приемки пользователями.
По источникам на разных этапах они распределились так:
— этап требований: 30 — организация; 22 — спецификация; 15 — концепция.
— этап разработки: 58 — спецификация; 33 — решение; 4 — организация; по 1 — концепция и рынок.
— этап системного тестирования: 5 — спецификация; 3 — решение; 1 — концепция.
— этап приемки пользователями: 102 — спецификация; 7 — концепция.

В сумме, для 187 изменений из 282 источником была сама спецификация — её уточняли, дополняли и детализировали. На втором и третьем месте с небольшим разрывом между собой, но с огромным отставанием от спецификации — решение (36) и организация (34).

Так как это внутренний проект для одной организации, рынок тут практически не стал источником изменений (и в дальнейшем его не анализировали).

Дальше интереснее — нам важно не количество изменений, а их влияние на перерасход бюджета проекта, причем бюджета в человеко-днях. Ведь в деньгах можно намерять много чего (часто при измерении в деньгах сбиваются со стоимости исправления на стоимость последствий), а потраченные дополнительные человеко-дни — более объективная характеристика.

Стоимость задержки по источникам изменений и этапам, по убыванию:

1. Изменения спецификации на этапе приемки пользователями: 737 дней(!)
2. Изменения организации на этапе требований: 638 дней
3. Изменения концепции на этапе требований: 266 дней
4. Спецификация на этапе разработки: 222
5. Спецификация на этапе требований: 194
6. Концепция(!) на этапе приемки пользователями: 163 (!)
+ по мелочи

Изменения распределились в форме ванны: 46% (1097 человеко-дней) на этапе работы с требованиями и 38% (900 человеко-дней) — на этапе приемки.

Делаем вывод: отложенный фидбэк — путь к запланированным переделкам.
Изменение требований на этапе сбора требований — нормальный рабочий процесс, а вот на приемке этого хотелось бы избежать.

Но самое интересное — удельный вес изменений в зависимости от источника. Да, косяков в спецификации больше всего. Но в основном они мелкие: медианное значение — 4 дня. А вот одно изменение концепции на этапе приемки "стоит" 20 дней! Ещё дороже — изменения организации на этапе требований.

В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для улучшения — можно сэкономить целых 31%! Не сотни раз, но тоже немало.