Это скорее поможет в каком-то виде учесть риски, не более того. Да и то для учета этих рисков можно взять какую-то примерную цифру вроде 30% и от нее исходить, так как более точно и не надо для рисков.

Риск помимо процентной оценки должен быть идентифицирован и описан. Если просто сказать - у нас будет 30% рисков, то это точно ничего не даст, кроме дискуссий

Я имел ввиду, что знание о том, что у нас заведомо будет 30% неучтенных требований из практической значимости дает только возможность учесть риск "Риск: Порядка 30% требований не было учтено, что скорее всего приведет к изменению начального объема работ на Х человеко-дней.  Влияние: Х дней команды. Действие: Необходимо запланировать ревью требований тогда-то, необходимо заложить резерв в план проекта на анализ и имплементацию неучтенных требований в размере Х дней команды." Ну или что-то в этом роде. Тоесть это знание помогает для планирования, но не для улучшения :-)

Еще нашел интересные идеи про синтаксический анализ самих требований на предмет различных слов и выражений влияющих на качество, таких как "может", "много", "мало", "быстро" и т.д.

Я бы еще добавил к этому списку слова "все" и "любой". Количество последующих изменений прямо пропорционально количеству этих слов.

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

ИМХО, тоже очень хороший показатель.

Читали про "синдром неоткрытых руин" у Леффингуэлла? Вот это оно самое.