Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: ilita от 09 Декабря 2010, 17:48:19
-
В теме "Функционал, не описанный в требованиях" упоминается "внутренне" ТЗ:
Наживочная функциональность должна быть ... отражена во внутренних ТЗ, которые заказчику не передаются.
Поделитесь опытом: часто ли для реальных проектов (в предположении, что "внешнее" ТЗ существует) пишутся такие "внутренние" документы? Каковы их главные отличия от "внешних"? В каких ситуациях "внутренние" ТЗ наиболее полезны?
-
По практике применения внутренние ТЗ пишутся на отдельные модули системы, которые выделяются в отдельные внутренние проекты или планируется применять в нескольких проектах.
Во внутренних ТЗ обычно отражают детали, которые не нужны заказчику проекта, но требуют фиксации и понимания всей командой в процессе разработки, внедрения и поддержки. И это наверно является главным фактором, вызывающим необходимость такого ТЗ.
Если кратко, то как-то так
-
По-моему тема на форуме уже поднималась.
Да, часто.
Отличия в степени детализации: внешние документы описывают бизнес-требования, внутренние архитектуру.
-
... или планируется применять в нескольких проектах.
Во внутренних ТЗ обычно отражают детали, которые не нужны заказчику проекта ...
Это, имхо, 2 разных подхода
1 - наличие нескольких заказчиков на общий продукт, который имеет единое ядро - "внутреннее" ТЗ и функциональность, заточенную под конкретного заказчика
2 - детализация - это не "внутреннее" ТЗ, это всего лишь те детали, которые не понятны и не интересны заказчику, но необходимы для создания работоспособного решения. Это детализация требования верхнего уровня (ТЗ) до уровня конкретных спцификаций и архитекурных решений
Отличия в степени детализации: внешние документы описывают бизнес-требования, внутренние архитектуру.
это скорее детализация ТЗ, а не "внутреннее" ТЗ
все имхо
-
Спасибо за ответы, общая картина понятна. Мне импонирует ответ LDV
детализация - это не "внутреннее" ТЗ
Интересно было бы продолжить список ситуаций в которых необходимо именно "внутреннее" ТЗ (а не более детальный\архитектурный документ) т.е. аналогичных этой:
наличие нескольких заказчиков на общий продукт, который имеет единое ядро - "внутреннее" ТЗ
Я могу придумать только вырожденный случай: если "внешнего" (передающегося заказчику) ТЗ по каким-то причинам нет, документация, по которой будет вестись разработка, автоматически становится "внутренней".
-
наличие нескольких заказчиков на общий продукт, который имеет единое ядро - реальная ситуация начала этого века с некогда известным продуктом БОСС-Корпорация. Под каждого заказчика делались свои "допилки", которые должны были работать на едином ядре. Сам я вживую никаких их ТЗ не видел, но, очевидно, были они на каждый проект по заказчику и в каком-то виде "внутреннее ТЗ" на ядро.