Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Денис Иванов от 13 Мая 2011, 10:51:15
-
Любопытно, что сейчас всплыла эта тема, так как я как раз работаю в похожем направлении - создаю шаблон идеального ТЗ.
Прихожу к выводу, что идеальное ТЗ должно:
1) использовать термины понятные и Заказчику, и Разработчику (сорри, за тривиальность). И таких терминов должно быть ОЧЕНЬ мало. При этом я НЕ имею в виду термины из предметной области! Я говорю о терминах, в которые Заказчик "оборачивает" требования. Пример такого термина - "web-страница"
2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру.
3) идеальное ТЗ будет разное для разных типов приложений. Примеры типов приложений: desktop приложение, web-приложение, встроенное приложение и т.д.
Думаю, что расскажу про это на ЛАФ-2011.
Денис, действительно интересно, как обстоят у тебя дела в этом проекте.
-
"Идеальное" ТЗ, идеальная жизнь :) Скукотааа......
-
"Идеальное" ТЗ, идеальная жизнь :) Скукотааа......
Почему скукота?
Не бойтесь стремиться к совершенству, вы его все равно никогда не достигнете. (ц)
С. Дали.
-
2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру.
Что значит ОДНОЗНАЧНОЕ? Это уже не ТЗ получается, а технический проект.
-
Что значит ОДНОЗНАЧНОЕ? Это уже не ТЗ получается, а технический проект.
Если представление будет не однозначное - то новые требования через какое-то время разрушат архитектуру.
Техническим проектом это не будет, так как терминов технических там не будет (пункт 1 в моем post)
-
2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру.
Денис, давайте сначала договоримся о терминах.
Что Вы подразумеваете под ТЗ?
-
Чувствую меня сейчас задавят ГОСТовскими определениями...
ТЗ наверное не самый лучший термин (просто данный пост посвящен ТЗ). Я имею в виду спецификацию (описание) того, что пользователь ожидает от программы.
-
ТЗ наверное не самый лучший термин (просто данный пост посвящен ТЗ). Я имею в виду спецификацию (описание) того, что пользователь ожидает от программы.
Да по ГОСТУ именно для этого в том числе предназначено ТЗ.
Но ТЗ по ГОСТУ не определяет детально архитектуру и конкретику проектирования - это более высокоуровневый документ.
"2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру."
Требования Заказчика и "архитектура" это разные уровни абстракции. И однозначного соответствия между терминами не будет, поскольку разработчик вынужден оперировать "терминами" той среды (платформы) которая используется для разработки.
Например Заказчик использует термин Классификатор (суть НСИ).
Разработчик в 1С будет использовать "термин" - Справочник.
Разработчик в другой системе вообще может оперировать термином - таблица БД и т.п.
Далее одна и та же сущность предметной области, может быть в архитектуре отражена целым набором взаимосвязанных сущностей, в этом случае также нет однозначного соответствия между терминами.
Если новые требования противоречат предыдущим требованиям то вполне возможно что не то что архитектуру придется пересматривать, а вообще инструмент разработки менять, потому что выбранный инструмент не может с заданными ограничениями выполнять эти новые требования.
На самом деле в разных командах и проектах по разному используют термин ТЗ.
Во многих мох проектах использовалось и используется абсолютно не гостовское понимание. У нас под "ТЗ" подразумевается низкоуровневый документ описывающий постановку задачи, требования к структурам данных, алгоритмам их обработки и т.п. именно в терминах конкретной среды или платформы разработки - то есть по сути это постановка задачи разработчику.
Дерево документации в наши проектах такое:
RFA (Заявка на доработку или решение задачи или проблемы)
Концепция (не обязательно)
Бизнес-дизайн, функциональные требования (это собственно основной документ оговаривающий все значимые с точки зрения требований заказчика моменты, зачастую с примерами экранных форм разъясняющий логику работы пользователей с разрабатываемой фунциональностью)
Техническое задание, постановка задачи
-
Требования Заказчика и "архитектура" это разные уровни абстракции. И однозначного соответствия между терминами не будет, поскольку разработчик вынужден оперировать "терминами" той среды (платформы) которая используется для разработки.
В этом-то и суть! При переходе от одного уровня абстракции к другому делаются некие интеллектуальные усилия и информация Заказчика изменяется так, чтобы Разработчик понял о чем идет речь. При этом происходит некая трансформация требований. Эти трансформации влияют на архитектуру. Более того, архитектура в дальнейшем будет способна выдержать только те требования, которые можно будет трансформировать подобным образом.
И если вдруг позже придет требование, которое не удастся трансформировать, то ... сами понимаете, что будет
-
несколько некорректно сформулировано
В этом-то и суть! При переходе от одного уровня абстракции к другому делаются некие интеллектуальные усилия и информация Заказчика изменяется так, чтобы Разработчик понял о чем идет речь.
Возможно Вы имели в виду что-то другое (правильное), но данная формулировка у Вас некорректна. Информация Заказчика не изменяется, иначе произойдет ее искажение. На самом деле при правильном подходе она дополняется - это называется проектирование.
При этом происходит некая трансформация требований. Эти трансформации влияют на архитектуру.
по той же причине (во избежание искажений) не должно происходить трансформации требований. Они детализируются в соответствии с принятым подходом, используемыми средствами разработки и тому подобными вещами...
и на архитектуру создаваемой системы влияют не некие трансформации, а вполне конкретно "требования определяют архитектуру".
Более того, архитектура в дальнейшем будет способна выдержать только те требования, которые можно будет трансформировать подобным образом.
Правильная формулировка "архитектура будет удовлетворять требованиям", но не тем которые "трансформировались", а тем которые были задействованы (т.е. использовались) при определении/разработке архитектуры.
И если вдруг позже придет требование, которое не удастся трансформировать, то ... сами понимаете, что будет
наверное, оно останется нетрансформированным? :о)))
и вообще, что значит "позже придет требование"? какую-то лажу с управлением и приоритизацией требований пропагандируете.
-
Почему скукота?
Не бойтесь стремиться к совершенству, вы его все равно никогда не достигнете. (ц)
С. Дали.
Богоподобие это болезнь тех, у кого с папой какие-то проблемы не решены.
Мне в этом отношении сказочно повезло :)
-
Любопытно, что сейчас всплыла эта тема, так как я как раз работаю в похожем направлении - создаю шаблон идеального ТЗ.
Хотелось бы взглянуть на шаблон.
Из этого обсуждения у меня возник следующий вопрос.
Нужно ли отказываться от оформления ТЗ по ГОСТу, если есть такая возможность? То есть считать ли ГОСТ устаревшим, до момента принятия следующего стандарта? У меня в этом нету опыта.
-
Хотелось бы взглянуть на шаблон.
Из этого обсуждения у меня возник следующий вопрос.
Нужно ли отказываться от оформления ТЗ по ГОСТу, если есть такая возможность? То есть считать ли ГОСТ устаревшим, до момента принятия следующего стандарта? У меня в этом нету опыта.
По-моему, ГОСТ применительно к программным разработкам имеет смысл использовать только в том случае, если этого явно требует заказчик (обычно это государственные или окологосударственные структуры). ГОСТ создавался в эпоху, когда бумажная документация ещё рассматривалась как эффективное средство передачи информации. С тех пор ситуация изменилась полностью.
-
Идеи "идеального ТЗ" понятны, и я с ними согласен (более того, 1 и 2 - это часть принципов DDD, который сейчас mainstream, по-моему). Единственное, на тему 2 - представление НЕ является однозначным, всегда есть техническая вариативность, да и не-техническая - тоже есть - иначе сложность ТЗ будет равна сложности системы. 3 - это, в общем, следствие. А вот "шаблон идеального ТЗ" - это уже интереснее. Потому что он имеет смысл, если применим для любых предметных областей и/или для любых классов задач. Или подразумевается шаблон все-таки ограниченной применимости? В общем, с интересом послушаю доклад на эту тему.
-
Так есть ли у кого то шаблон тз, хорошо зарекомендовавший себя не один раз? посоветуйте или ссылку скиньте
-
Так есть ли у кого то шаблон тз, хорошо зарекомендовавший себя не один раз? посоветуйте или ссылку скиньте
У меня на разные случае заготовлены разные шаблоны. Приведу структуру одного из шаблонов на развитие существующей системы.
АННОТАЦИЯ
ИСТОРИЯ ДОКУМЕНТА
ГЛОССАРИЙ
1 Общие сведения
1.1 Наименование системы и её условное обозначение
1.2 Наименование организаций – заказчика и исполнителя работ
1.3 Плановые сроки начала и окончания работ
2 Назначение и цели развития системы
2.1 Назначение системы
2.2 Цели развития системы
3 Варианты использования системы
4 Требования к системе
4.2 Требования к функции <>
4.3 Требования к функции <>
4.4 Требования к пользовательскому интерфейсу
4.5 Требования к независимости
4.6 Требования к стандартизации
4.7 Требования к надежности
4.8 Требования к защите информации от несанкционированного доступа
4.9 Требования к документированию
4.10 Дополнительные требования
ПРИЛОЖЕНИЕ А
ПРИЛОЖЕНИЕ Б
УТВЕРЖДАЮЩИЕ ПОДПИСИ
-
Еще дай
-
Еще дай
http://www.rugost.com/index.php?option=com_content&view=article&id=96:gost-34602-89&catid=22&Itemid=53
-
У меня на разные случае заготовлены разные шаблоны. Приведу структуру одного из шаблонов на развитие существующей системы.
Могли бы Вы рассказать поподробнее.
1. Какую классификацию случаев Вы разработали?
2. Все ли Ваши шаблоны созданы на основе ГОСТ34?
Лично я бы выделил следующие случае в ИТ:
- Разработка новой ИС
- Модернизация существующей ИС (существенные доработки по требованию бизнеса)
- Доработка существующей ИС (незначительные доработки по требования пользователей)
-
Могли бы Вы рассказать поподробнее.
1. Какую классификацию случаев Вы разработали?
2. Все ли Ваши шаблоны созданы на основе ГОСТ34?
1. Это коммерческая тайна
2. Почти ни одного, т.к. основной заказчик не требует соблюдать ГОСТ 34
-
А шаблон приведенный Вами выше разве разработан не на основе ГОСТ?
-
А шаблон приведенный Вами выше разве разработан не на основе ГОСТ?
Сравните приведенную структуру со структурой ТЗ по ГОС Т34 и сами сделайте выводы.
-
А именно так я и сделал и на мой взгляд за основы был взят ГОСТ 34. Разработан "на основе" означает, что большая часть пунктов соотвествует ГОСТ 34, а остальное дописано самостоятельно. Ну это ИМХО на основе моих знаний и опыта, если это не так, подскажите, что вы взяли за основу для разработки этой структуры?