Тема трактуется таким образом:
Анализ [требований | архитектурный | системный] [управляемый|поддерживаемый] [тестами|тестированием]

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

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

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

Готов услышать вопросы, замечания и пожелания, будет ли тема интересна, хотели бы вы послушать такое? Жду предложений

Видимо, тема не вызывала восторга, снимаю?

Эдуард, а это  как то связано с моим прошлогодним докладом "Написание тестов как вид тестирования требований"? Является продолжением / сильно отличается / никак не связано?

PS. Прошлогодний доклад, на мой взгляд, получился. Тема народ зацепила.

Эдуард, а это  как то связано с моим прошлогодним докладом "Написание тестов как вид тестирования требований"? Является продолжением / сильно отличается / никак не связано?

PS. Прошлогодний доклад, на мой взгляд, получился. Тема народ зацепила.

Сергей, твой доклад был интересным. Ты вообще харизматичная личность

Но мой доклад не связан с этим, хотя я сейчас вижу ту методологическую основу. которой пока не видел.

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

Возможно ли, используя технику тестирования, в ходе анализа и формирования постановок учесть это?

Это действитеьно коррелирует с твоим лозунгом - выдвинув требование дай ответ - как ты будешь это проверять!
Хотя мы помним, что в самом свойстве идеального требование заложена характеристика проверяемости...