Ок, проект запущен, все бизнес-требования реализованы или не все. Но прибыль получают с продажи продукта, а не архитектуры. Архитектура может соответствовать или не соответствовать бизнес-требованиям (функциональные, нефункциональные).

Первое - отвечает на вопрос "Всё ли мы учли при проектировании, что выявили в постановке?", а второе "Закрывает ли наша реализация реальные потребности?"

Бизнес анализ может сформулировать потребности. Архитектор может сказать каким образом эти потребности удовлетворить.
Для того, чтобы действительно удовлетворить потребности, нужно правильно организовать проектирование. Тогда, при достаточной полноте постановки у вас реализация будет соответствовать назначению.

Вы знаете разницу между "Проверкой" и "Приёмкой" ?

Конечно. Проверяем варианты реализации, принимаем конечный продукт.

Это если по жизненному циклу (в смысле по этапам). А если в процессе проектирования, то проверяем на соответствие требованиям, принимаем в соответствии с мерой удовлетворённости потребностей.

Не помню, тут ли писали - что если ваш заказчик перестал менять требования перед релизом, то, скорее всего, он умер)))

Было. Но тут сразу вспомнить, что есть понятие "рамки проекта". Если заказчик за изменения требований готов платить бабло - ноу проблем)

Рамки, это про другое, тут содержание и ресурсы. Если он готов платить в том числе и сдвигом сроков, тогда только ноу проблем. Иногда готов и деньгами, но не временем. И тут его нужно остановить. Или наоборот готов в долгострой, но сокращая деньги, тоже не вариант. Тут и до суда легко доехать, а преценденты что сейчас уже не нужно, и это расхрды уже не заказчика, есть, и это риски это управленца уже.

Зато при достижении оптимума, болезнь одного разработчика грозит срывом всего проекта. Оптимизация на границе, зачастую зло то еще. Запас нужен всегда. А задачи как известно делаются за то время, которое на них выделили, тут грань очень тонка, так что бы и время не "перевыделить" но и запас оставить. И лучше чуть чуть перевыделить, но договориться с исполнителями.

1. Зависит от ваших собственных оценок качества управления. В смысле должна же быть у вас статистика на тему "В скольких случаях конкретный управленец попадает в самим им составленный план". Исходя из реальности и прогноза можно построить "сколько вешать в %".

2. Упущеная выгода, на мой взгляд - это термин для "адвокатских разборок". В реальном управлении записывать её в "убытки" - это ошибочно. Если вы чего-то не сделали - значит не могли сделать.
Сам концепт был придуман для по-сути перекладывания ответственности за убытки с одних людей на других. Причём в случае управления - рассматривать упущенную выгоду, это как сказать "Я некомпетентный управленец, поэтому найду себе оправдание, что мне помешали, заставили, гады, упустить выгоду" )