В теме "Функционал, не описанный в требованиях" упоминается "внутренне" ТЗ:

Наживочная функциональность должна быть ... отражена во внутренних ТЗ, которые заказчику не передаются.

Поделитесь опытом: часто ли для реальных проектов (в предположении, что "внешнее" ТЗ существует) пишутся такие "внутренние" документы? Каковы их главные отличия от "внешних"? В каких ситуациях "внутренние" ТЗ наиболее полезны?

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

По-моему тема на форуме уже поднималась.
Да, часто.

Отличия в степени детализации: внешние документы описывают бизнес-требования, внутренние архитектуру.

... или планируется применять в нескольких проектах.
Во внутренних ТЗ обычно отражают детали, которые не нужны заказчику проекта ...

Это, имхо, 2 разных подхода
1 - наличие нескольких заказчиков на общий продукт, который имеет единое ядро - "внутреннее" ТЗ и функциональность, заточенную под конкретного заказчика
2  - детализация - это не "внутреннее" ТЗ, это всего лишь те детали, которые не понятны и не интересны заказчику, но необходимы для создания работоспособного решения. Это детализация требования верхнего уровня (ТЗ) до уровня конкретных спцификаций и архитекурных решений

Отличия в степени детализации: внешние документы описывают бизнес-требования, внутренние архитектуру.

это скорее детализация ТЗ, а не "внутреннее" ТЗ

все имхо

Спасибо за ответы, общая картина понятна. Мне импонирует ответ LDV

детализация - это не "внутреннее" ТЗ

Интересно было бы продолжить список ситуаций в которых необходимо именно "внутреннее" ТЗ (а не более детальный\архитектурный документ) т.е. аналогичных этой:

наличие нескольких заказчиков на общий продукт, который имеет единое ядро - "внутреннее" ТЗ

Я могу придумать только вырожденный случай: если "внешнего" (передающегося заказчику) ТЗ по каким-то причинам нет, документация, по которой будет вестись разработка, автоматически становится "внутренней".

наличие нескольких заказчиков на общий продукт, который имеет единое ядро - реальная ситуация начала этого века с некогда известным продуктом БОСС-Корпорация. Под каждого заказчика делались свои "допилки", которые должны были работать на едином ядре. Сам я вживую никаких их ТЗ не видел, но, очевидно, были они на каждый проект по заказчику и в каком-то виде "внутреннее ТЗ" на ядро.