Любопытно, что сейчас всплыла эта тема, так как я как раз работаю в похожем направлении - создаю шаблон идеального ТЗ.

Прихожу к выводу, что идеальное ТЗ должно:
1) использовать термины понятные и Заказчику, и Разработчику (сорри, за тривиальность). И таких терминов должно быть ОЧЕНЬ мало. При этом я НЕ имею в виду термины из предметной области! Я говорю о терминах, в которые Заказчик "оборачивает" требования. Пример такого термина - "web-страница"
2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру.
3) идеальное ТЗ будет разное для разных типов приложений. Примеры типов приложений: desktop приложение, web-приложение,  встроенное приложение и т.д.

Думаю, что расскажу про это на ЛАФ-2011.

Денис, действительно интересно, как обстоят у тебя дела в этом проекте.

"Идеальное" ТЗ, идеальная жизнь Скукотааа......

"Идеальное" ТЗ, идеальная жизнь Скукотааа......

Почему скукота?
Не бойтесь стремиться к совершенству, вы его все равно никогда не достигнете. (ц)
С. Дали.

2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру.

Что значит ОДНОЗНАЧНОЕ? Это уже не ТЗ получается, а технический проект.

Что значит ОДНОЗНАЧНОЕ? Это уже не ТЗ получается, а технический проект.

Если представление будет не однозначное - то новые требования через какое-то время разрушат архитектуру.
Техническим проектом это не будет, так как терминов технических там не будет (пункт 1 в моем post)

2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру.

Денис, давайте сначала договоримся о терминах.
Что Вы подразумеваете под ТЗ?

Чувствую меня сейчас задавят ГОСТовскими определениями...

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

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

Да по ГОСТУ именно для этого в том числе предназначено ТЗ.
Но ТЗ по ГОСТУ не определяет детально архитектуру и конкретику проектирования - это более высокоуровневый документ.

"2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру."

Требования Заказчика и "архитектура" это разные уровни абстракции. И однозначного соответствия между терминами не будет, поскольку разработчик вынужден оперировать "терминами" той среды (платформы) которая используется для разработки.
Например Заказчик использует термин Классификатор (суть НСИ).
Разработчик в 1С будет использовать "термин" - Справочник.
Разработчик в другой системе вообще может оперировать термином - таблица БД и т.п.

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

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

На самом деле в разных командах и проектах по разному используют термин ТЗ.
Во многих мох проектах использовалось и используется абсолютно не гостовское понимание. У нас под "ТЗ" подразумевается низкоуровневый документ описывающий постановку задачи, требования к структурам данных, алгоритмам их обработки и т.п. именно в терминах конкретной среды или платформы разработки - то есть по сути это постановка задачи разработчику.
Дерево документации в наши проектах такое:
RFA (Заявка на доработку или решение задачи или проблемы)
  Концепция (не обязательно)
      Бизнес-дизайн, функциональные требования (это собственно основной документ оговаривающий все значимые с точки зрения требований заказчика моменты, зачастую с примерами экранных форм разъясняющий логику работы пользователей с разрабатываемой фунциональностью)
         Техническое задание, постановка задачи

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

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

несколько некорректно сформулировано

В этом-то и суть! При переходе от одного уровня абстракции к другому делаются некие интеллектуальные усилия и информация Заказчика изменяется так, чтобы Разработчик понял о чем идет речь.

Возможно Вы имели в виду что-то другое (правильное), но данная формулировка у Вас некорректна. Информация Заказчика не изменяется, иначе произойдет ее искажение. На самом деле при правильном подходе она дополняется - это называется проектирование.

При этом происходит некая трансформация требований. Эти трансформации влияют на архитектуру.

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

и на архитектуру создаваемой системы влияют не некие трансформации, а вполне конкретно "требования определяют архитектуру".

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

Правильная формулировка "архитектура будет удовлетворять требованиям", но не тем которые "трансформировались", а тем которые были задействованы (т.е. использовались) при определении/разработке архитектуры.

И если вдруг позже придет требование, которое не удастся трансформировать, то ... сами понимаете, что будет

наверное, оно останется нетрансформированным? :о)))

и вообще, что значит "позже придет требование"? какую-то лажу с управлением и приоритизацией требований пропагандируете.

Почему скукота?
Не бойтесь стремиться к совершенству, вы его все равно никогда не достигнете. (ц)
С. Дали.

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

Любопытно, что сейчас всплыла эта тема, так как я как раз работаю в похожем направлении - создаю шаблон идеального ТЗ.

Хотелось бы взглянуть на шаблон.

Из этого обсуждения у меня возник следующий вопрос.
Нужно ли отказываться от оформления ТЗ по ГОСТу, если есть такая возможность? То есть считать ли ГОСТ устаревшим, до момента принятия следующего стандарта? У меня в этом нету опыта.

Хотелось бы взглянуть на шаблон.

Из этого обсуждения у меня возник следующий вопрос.
Нужно ли отказываться от оформления ТЗ по ГОСТу, если есть такая возможность? То есть считать ли ГОСТ устаревшим, до момента принятия следующего стандарта? У меня в этом нету опыта.

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

Идеи "идеального ТЗ" понятны, и я с ними согласен (более того, 1 и 2 - это часть принципов DDD, который сейчас mainstream, по-моему). Единственное, на тему 2 - представление НЕ является однозначным, всегда есть техническая вариативность, да и не-техническая - тоже есть - иначе сложность ТЗ будет равна сложности системы. 3 - это, в общем,  следствие. А вот "шаблон идеального ТЗ" - это уже интереснее. Потому что он имеет смысл, если применим для любых предметных областей и/или для любых классов задач. Или подразумевается шаблон все-таки ограниченной применимости? В общем, с интересом послушаю доклад на эту тему.

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