Существуют ли инструменты (методы, техники), которые на ранних этапах проекта позволяют предсказать и оценить процент неучтенных требований?

У нас есть табличка с взаимосвязами (что без чего работать не будет) по которой можно выявить ключевые неучтенные требования.

У нас есть табличка с взаимосвязами (что без чего работать не будет) по которой можно выявить ключевые неучтенные требования.

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

Существуют ли инструменты (методы, техники), которые на ранних этапах проекта позволяют предсказать и оценить процент неучтенных требований?

Смотря с какой точностью. 

Смотря что считать "ранними этапами"

Если проект новый на 100% (компнда, клиент) - проще кинуть монетку.

Виталий, а на базе чего ты планируешь этот прогноз.

Просто, ты начинаешь скажем проект, и уже через неделю его начала хочешь знать каков ожидается % неучтенных требований? Как это можно сделать? Назови любую цифру в пределах от 0 до 100 - вдруг попадешь!

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

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

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

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

Другой вариант - это использование некоторых эмпирических данных (вопрос есть ли они?) с последующей коррекцией по ходу итераций

Если проект новый на 100% (компнда, клиент) - проще кинуть монетку.

Монетка это тоже инструмент, только им надо уметь пользоваться

Виталий, а на базе чего ты планируешь этот прогноз.

Просто, ты начинаешь скажем проект, и уже через неделю его начала хочешь знать каков ожидается % неучтенных требований? Как это можно сделать? Назови любую цифру в пределах от 0 до 100 - вдруг попадешь!

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

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

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

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

Другой вариант - это использование некоторых эмпирических данных (вопрос есть ли они?) с последующей коррекцией по ходу итераций

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

Самый простой механизм - это собирать данные по завершенным проектам и мерить отношение первоначальных требований к конечным.

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

Тогда ответ на твой вопрос очевиден - ткни пальцем в небо, результат тот же!

Существуют ли инструменты (методы, техники), которые на ранних этапах проекта позволяют предсказать и оценить процент неучтенных требований?

Для какой цели нужна такая оценка?

Для какой цели нужна такая оценка?

Для исследовательской, а далее для сокращения тех самых неучтенных требований

У нас в компании согласно статистике средний проект обычно оказывается недооцененным на 30%. Из них, полагаю, 20% - это из-за бестолковой организации и разных форс-мажорных обстоятельств. А 10% - это как раз то, о чем вы спрашивали.
При планировании работ следует иметь в виду, объем требований в поцессе реализации увеличится примерно на 10% от оценки, так как при разработке обязательно будут всплывать разные нюансы. Это при условии, что заказчик имеет достаточно систематизированное представлеие о реализуемой системе, а аналитик по максимуму использует аналогии и не является изобретателем велосипеда.
Если одно из этих условий нарушается - умножаем наш процент на 2. Если оба условия нарушены - умножаем на 4.

Надеюсь, что смогла вам немного помочь.

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

На мой взгляд, что действительно может помочь улучшить качество требований, улучшить процессы связанные с анализом и повысить профессиональные навыки, так это сбор некоторого набора метрик во время проекта и их тщательный анализ во время и после проекта.
У меня была идея собирать следующие метрики:
1. Кол-во требований в начале проекта с разбивкой по типам
2. Кол-во требований которые были добавлены во время проекта, опять же с разбивкой по типам
3. Кол-во требований которые были изменены во время проекта и почему(выделить некий ряд основных причин)
4. Кол-во требований которые были удалены/отменены во время проекта и почему. Если у требований есть оценки трудоемкости (с точки зрения имплементации разработчиками), то наверное это тоже может быть интересным для анализа – посмотреть не только количественно, но еще и объемно.
5. Кол-во дефектов от тестировщиков связанных с требованиями (если есть возможность то и линковать дефекты непосредственно к требованиям)
6. Так же можно попросить разработчиков и тестировщиков выставлять оценки требованиям по какой-нибудь простой шкале от 1 до 5 или от 1 до 3

Посмотреть какие конкретно требования были изменены наибольшее кол-во раз, проанализировать почему именно эти требования были изменены больше всего?

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

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

А вы собираете какие-нибудь метрики связанные с требованиями?

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

А вы собираете какие-нибудь метрики связанные с требованиями?

Пока не собираем, но планируем. Часть метрик можно вытащить из базовых версий требований, например в Sparx EA.
Также кроме количественных показателей интересно собирать качественные показатели, которые описать количественно без перевода в отн. единицы не получится. В дополнении к метрикам самих требований, можно собирать метрики в процессе согласования, оценивать стоимость согласования, время и другие показатели.