Форум Сообщества Аналитиков

×


Шаблон идеального ТЗ(Прочитано 30557 раз)
Шаблон идеального ТЗ : 13 Мая 2011, 10:51:15
Любопытно, что сейчас всплыла эта тема, так как я как раз работаю в похожем направлении - создаю шаблон идеального ТЗ.

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

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

Денис, действительно интересно, как обстоят у тебя дела в этом проекте.
« Последнее редактирование: 14 Мая 2011, 23:34:57 от bas »



Тренинг «Идеальное ТЗ» Ответ #1 : 13 Мая 2011, 13:14:00
"Идеальное" ТЗ, идеальная жизнь :) Скукотааа......



Тренинг «Идеальное ТЗ» Ответ #2 : 13 Мая 2011, 14:05:22
"Идеальное" ТЗ, идеальная жизнь :) Скукотааа......
Почему скукота?
Не бойтесь стремиться к совершенству, вы его все равно никогда не достигнете. (ц)
С. Дали.



Тренинг «Идеальное ТЗ» Ответ #3 : 13 Мая 2011, 14:51:58
2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру.

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Тренинг «Идеальное ТЗ» Ответ #4 : 13 Мая 2011, 15:16:33
Что значит ОДНОЗНАЧНОЕ? Это уже не ТЗ получается, а технический проект.

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



Тренинг «Идеальное ТЗ» Ответ #5 : 13 Мая 2011, 15:22:37
Цитата: Денис Иванов
2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру.
Денис, давайте сначала договоримся о терминах.
Что Вы подразумеваете под ТЗ?




Тренинг «Идеальное ТЗ» Ответ #6 : 13 Мая 2011, 16:56:13
Чувствую меня сейчас задавят ГОСТовскими определениями...

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



Тренинг «Идеальное ТЗ» Ответ #7 : 13 Мая 2011, 17:40:44
ТЗ наверное не самый лучший термин (просто данный пост посвящен ТЗ). Я имею в виду спецификацию (описание) того, что пользователь ожидает от программы.
Да по ГОСТУ именно для этого в том числе предназначено ТЗ.
Но ТЗ по ГОСТУ не определяет детально архитектуру и конкретику проектирования - это более высокоуровневый документ.

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

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

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

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

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



Тренинг «Идеальное ТЗ» Ответ #8 : 13 Мая 2011, 18:23:43
Требования Заказчика и "архитектура" это разные уровни абстракции. И однозначного соответствия между терминами не будет, поскольку разработчик вынужден оперировать "терминами" той среды (платформы) которая используется для разработки.

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



Тренинг «Идеальное ТЗ» Ответ #9 : 13 Мая 2011, 19:08:06
несколько некорректно сформулировано

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

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

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

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

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

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

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

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


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

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

« Последнее редактирование: 13 Мая 2011, 19:10:22 от Водолей »
Лью воду...



Тренинг «Идеальное ТЗ» Ответ #10 : 13 Мая 2011, 20:47:42
Почему скукота?
Не бойтесь стремиться к совершенству, вы его все равно никогда не достигнете. (ц)
С. Дали.
Богоподобие это болезнь тех, у кого с папой какие-то проблемы не решены.
Мне в этом отношении сказочно повезло :)



Re: Шаблон идеального ТЗ Ответ #11 : 15 Мая 2011, 01:25:18
Любопытно, что сейчас всплыла эта тема, так как я как раз работаю в похожем направлении - создаю шаблон идеального ТЗ.
Хотелось бы взглянуть на шаблон.

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



Re: Шаблон идеального ТЗ Ответ #12 : 15 Мая 2011, 16:34:41
Хотелось бы взглянуть на шаблон.

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

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Шаблон идеального ТЗ Ответ #13 : 16 Мая 2011, 22:59:13
Идеи "идеального ТЗ" понятны, и я с ними согласен (более того, 1 и 2 - это часть принципов DDD, который сейчас mainstream, по-моему). Единственное, на тему 2 - представление НЕ является однозначным, всегда есть техническая вариативность, да и не-техническая - тоже есть - иначе сложность ТЗ будет равна сложности системы. 3 - это, в общем,  следствие. А вот "шаблон идеального ТЗ" - это уже интереснее. Потому что он имеет смысл, если применим для любых предметных областей и/или для любых классов задач. Или подразумевается шаблон все-таки ограниченной применимости? В общем, с интересом послушаю доклад на эту тему.
Максим Цепков, CustIS



Re: Шаблон идеального ТЗ Ответ #14 : 12 Марта 2013, 17:23:50
Так есть ли у кого то шаблон тз, хорошо зарекомендовавший себя не один раз? посоветуйте или ссылку скиньте




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19