Меню
Чат для технических писателей в Telegram
Статьи
Свежевыжатые соки для технических писателей

Техническое задание (ТЗ)

Внимание! У нас сбои с почтовым сервером! Если не пришло письмо о регистрации или смене пароля напишите нам на info@techwriters.ru! 
@twriters obmen_soobsheniyami.pngчат для технических писателей в Telegram

 Зарегистрируйтесь
Поиск  Пользователи  Правила  Войти
Форум » Предложения по работе форума и сайта » Форум обсуждения Wiki для технических писателей
Страницы: 1
RSS
Техническое задание (ТЗ), Обсуждаем как правильно составлять требования и разрабатывать техническое задание (ТЗ)
 
#1
Мне нравится0
18.05.2007 14:33:51
Обсуждаем как правильно составлять требования и разрабатывать техническое задание (ТЗ)Как написать техническое задание ? С чего начать оформление? Есть ли стандартные образцы, формы или госты?
Есть ли шаблон(план) выполнения ТЗ. Может пример? Хочу сделать сайт и понадобилось техническое задание. Спасибо.


Обсуждение ЧТЗ (Частного технического задания) здесь
 
 
 
#2
Мне нравится0
18.05.2007 14:34:44
Цитата
Есть ли шаблон(план) выполнения ТЗ. Может пример? Хочу сделать сайт и понадобилось техническое задание. Спасибо.
 
 
 
#3
Мне нравится0
18.05.2007 20:33:45
Посмотрите:  ГОСТ 34.602-89  
Статус НД: Действует
Взамен: ГОСТ 24.201-85
Заглавие: Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
Объем: 12 стр.
Введен: 01.01.1990
Коды КГС: П87 Автоматизированные системы управления

Коды ОКС: 35.080 Программное обеспечение *Включая разработку программного обеспечения, документацию, интернет-приложения и использование

Область применения: Настоящий стандарт распространяется на автоматизированные системы для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа "Техническое задание на создание (развитие или модернизацию) системы".
Когда нет знания, есть мнение
 
 
 
#4
Мне нравится0
06.06.2007 15:43:57
Цитата
Заменен на ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы
Смотри также: ГОСТ 19.201-78 ЕСПД. Техническое задание  
УДК 65.011.56:681.3:002:006.354
Группа Т52




Г О С У Д А Р С Т В Е Н Н Ы Й   С Т А Н Д А Р Т   С О Ю З А   С С Р

--------------------------------------------------------------------------------
Система технической документации на АСУ
ГОСТ 24.201-79
   
ТРЕБОВАНИЕ К СОДЕРЖАНИЮ ДОКУМЕНТА «ТЕХНИЧЕСКОЕ ЗАДАНИЕ»  
   
System of technical documentation for computer control systems. Requirements to document «Technical Directions»    

--------------------------------------------------------------------------------

Постановлением Государственного комитета СССР по стандартам от 31 января 1979 г. № 383 срок введения установлен

с 01.07 1980 г.

Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления народным хозяйством (кроме общегосударственного), и устанавливает общие требования к содержанию документа «Техническое задание» (ТЗ) на создание АСУ, кроме АСУ технологическими процессами.

В зависимости от вида и назначения АСУ требования, устанавливаемые в настоящем стандарте, допускается конкретизировать в нормативно-технической документации.

1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. ТЗ является основным исходным документом для создания АСУ, на соответствие которому проверяется созданная АСУ.

1.2. ТЗ следует разрабатывать на основании результатов работ, проводимых на предпроектной стадии с учетом технико-экономического обоснования (ТЭО) и требований, изложенных в ГОСТ 15.001—73.

1.3. ТЗ на АСУ является частью задания на создание объекта управления, если АСУ создают одновременно и совместно с ним.

1.4. На части АСУ допускается разрабатывать отдельные технические задания.

2. СОСТАВ ТЕХНИЧЕСКОГО ЗАДАНИЯ
2.1. Техническое задание на создание АСУ должно содержать следующие разделы:

введение;
характеристика объекта управления;
назначение АСУ;
основные требования к АСУ;
технико-экономические показатели АСУ;
состав, содержание и организация работ по созданию АСУ;
порядок приемки АСУ.
2.2. Допускается расширять перечень разделов ТЗ, установленных настоящим стандартом, в зависимости от специфических особенностей создаваемых АСУ.

3. СОДЕРЖАНИЕ ТЕХНИЧЕСКОГО ЗАДАНИЯ
3.1. «Введение» должно содержать:

полное наименование и условное обозначение АСУ;
основание для создания АСУ (перечень документов);
наименование и условное обозначение темы или разработки;
сроки начала и окончания работы по созданию АСУ;
наименование организаций, участвующих в создании АСУ (исполнителей, соисполнителей), и их реквизиты;
сведения об источниках и порядке финансирования.
3.2. Раздел «Характеристика объекта управления» должен содержать:

описание состава объекта управления (производственную или иную структуру) в зависимости от его типа;
характеристики входных и выходных материальных потоков;
описание особенностей объекта управления, определяющих основные требования к создаваемой АСУ (регламент, режим работы и т. п.).
3.3. Раздел «Назначение АСУ» должен содержать:

назначение АСУ, основные цели ее создания, критерии эффективности функционирования объекта в условиях автоматизированного управления;
перечень выполняемых функций, необходимых для достижения целей;
описание общей структуры системы управления объектом с указанием места АСУ в ней;
взаимосвязи создаваемой АСУ с системами управления других уровней;
перспективы развития АСУ.
3.4. Раздел «Основные требования к АСУ» должен содержать следующие подразделы:

требования к системе и ее частям;
требования к качеству выполнения функции АСУ;
требования к видам обеспечения АСУ.
3.4.1. Подраздел «Требования к системе и ее частям» должен содержать:

основные показатели (параметры), которые должны быть достигнуты в условиях автоматизированного управления объектом;
структуру АСУ и входящих в нее частей;
требования к функционированию АСУ или ссылку на документы, регламентирующие:
режим работы,
способы обмена информацией со смежными системами с указанием режима обмена, объема, содержания, системы кодирования и, при необходимости, формы представления информации;
эргономические требования в части рациональной компоновки технических средств, удобств обслуживания, комфортности пунктов управления и, при необходимости, эстетического решения;
требования к сохранности информации при авариях в система энергоснабжения.
3.4.2. Подраздел «Требования к качеству выполнения функций АСУ» должен содержать перечень функций управления и решаемых задач или комплекса задач с указанием для каждой задачи основных входных и выходных показателей и потребителя информации.

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

3.4.3. Подраздел «Требования к видам обеспечения АСУ» должен содержать требования к программному, информационному, организационному, техническому и другим видам обеспечения в соответствии с требованиями, установленными стандартами на АСУ конкретных видов.

В подразделе допускается приводить требования по применению типовых решений, составу и структуре используемых технических средств, включая специальные технические средства, разрабатываемые для АСУ конкретного вида.

3.4.4. Состав требований к частям системы, разрабатываемым по отдельным техническим заданиям, определяют в зависимости от выделяемой части системы: подсистемы АСУ, ИВЦ, банка данных и т. п.

3.4.5. В разделе «Основные требования к АСУ» допускается приводить дополнительные требования, не указанные в пп. 3.4.1-3.4.4, а также ссылки на нормативно-техническую документацию, которой должна соответствовать техническая документация на АСУ.

3.5. Раздел «Технико-экономические показатели АСУ» должен содержать:

технико-экономические показатели, которые должны быть достигнуты в результате создания АСУ, с указанием максимально допускаемой суммы единовременных затрат на ее создание;
годовой экономический эффект и источники его возникновения (повышение производительности, улучшение качества и т. п.);
коэффициент экономической эффективности затрат.
К техническому заданию следует прилагать расчет экономической эффективности и, при необходимости, расчет научно-технического уровня создаваемой АСУ.

3.6. Раздел «Состав, содержание и организация работ по с озданию АСУ» должен содержать:

перечень стадий и этапов выполнения работ;
перечень работ по стадиям и этапам, сроки их выполнения и организации - исполнители работ;
форму завершения стадий и этапов создания АСУ.
Стадии, этапы и перечень выполняемых работ указывают в соответствии с нормативно-технической документацией на АСУ конкретного вида. Кроме того, в разделе необходимо приводить перечень мероприятий по подготовке объекта к внедрению АСУ с указанием сроков выполнения работ и исполнителей.

Сведения, приводимые в разделе, могут быть представлены в виде план-графиков.

В разделе может быть указана последовательность внедрения частей или задач АСУ.

3.7. Раздел «Порядок приемки АСУ» должен содержать указания о составе и объеме приемо-сдаточных испытаний, которые проводят при вводе системы в эксплуатацию или предъявлении системы Государственной (межведомственной, внутриведомственной) комиссии. Состав и объем испытаний определяют по нормативно-технической документации на АСУ конкретного вида.


--------------------------------------------------------------------------------

Переиздание. Июнь 1982 г.
 
 
 
#5
Мне нравится0
05.12.2007 10:01:19
Можно и тут попробовать глянуть...
Там же и шаблон ТЗ скачать можно, если это то, что вам нужно
 
 
 
#6
Мне нравится0
05.12.2007 15:02:30
Всем, огромное
спасибо!
Быть или не быть?
 
 
 
#7
Мне нравится0
24.11.2009 12:31:31
Добрый день, в ТЗ на АСУ требуется "указать ссылку на отраслевой стандарт при определении отказа, сбоя, повреждения системы, а также её структурных компонентов". Почему-то ГОСТ 24.701-86 не подошёл... Подскажите, пожалуйста, на какой ГОСТ сослаться?
Заранее большое спасибо.
Светлана.
 
 
 
#8
Мне нравится0
24.11.2009 22:26:55
Цитата
Цитата
... в ТЗ на АСУ требуется "указать ссылку на отраслевой стандарт при определении отказа, сбоя, повреждения системы, а также её структурных компонентов". Почему-то ГОСТ 24.701-86 не подошёл... Подскажите, пожалуйста, на какой ГОСТ сослаться?

ГОСТ 27.002-89
Надежность в технике. Основные понятия. Термины и определения

P. S.  ГОСТы серии 24 отменены (недействительны).
Спасибо!
 
 
 
#9
Мне нравится0
24.11.2009 19:07:06
Видимо, ГОСТ 24.701 не подошел потому, что требуется указать ссылку на ОТРАСЛЕВОЙ стандарт...
ГОСТ - это государственный стандарт, а не отраслевой
 
 
 
#10
Мне нравится0
24.11.2009 20:03:16
Цитата
... в ТЗ на АСУ требуется "указать ссылку на отраслевой стандарт при определении отказа, сбоя, повреждения системы, а также её структурных компонентов". Почему-то ГОСТ 24.701-86 не подошёл... Подскажите, пожалуйста, на какой ГОСТ сослаться?

ГОСТ 27.002-89
Надежность в технике. Основные понятия. Термины и определения

P. S.  ГОСТы серии 24 отменены (недействительны).
 
 
 
#11
Мне нравится0
25.11.2009 17:13:51
Цитата


P. S.  ГОСТы серии 24 отменены (недействительны).

Неправда Ваша. Отменены не все.
Про ГОСТ 24.701 можете убедиться на официальном сайте: http://www.gost.ru/wps/portal/pages.CatalogOfStandarts
 
 
 
#12
Мне нравится0
26.11.2009 13:44:04
Цитата

Неправда Ваша.
Это скорее, не побоюсь сказать, обман.
Когда-то давным-давно я читал статью по проблемам стандартизации, в которой  анализировались недостатки ГОСТов серии 24 (типа дублирование и/или противоречие с другими родственными сериями),  в которой было сказано об отмене этих ГОСТов и заменой их ГОСТами серии 34 "Информационные технологии".
Лично я ГОСТами серии 24 не пользуюсь (только серии 2, 19, 34), но фраза об их скорой отмене  в памяти отпечаталась.
Но, как это бывает со всеми оракулами,  предсказание не сбылось.
Реальность оказалась не столь трагичной для этих ГОСТов.
Часть из них все-таки была заменена ГОСТами серии 34, а часть - нет (либо передумали, либо помешала перестройка). "Жив курилка!"
Так что сейчас некоторые ГОСТы серии 24  действительно продолжают действовать на радость их апологетов.
 
 
 
#13
Мне нравится0
07.10.2014 15:18:34
ТЗ в виде сайта, да ещё и красочного, делать не приходилось, потому что заказчикам не приходило в голову требовать. Когда-то делала юзабилити-аудиты интерфейсов, тоже никто не предъявлял каких-то особых требований к формам отчетов, всем хватало документа в ворде или pdf, конвертированного из ворда. С заказчиком обсуждались содержание и доступность изложения, форма - только в начале работы, с непосредственным начальством, на уровне "сделайте титульный лист по нашим корпоративным стандартам".

Разбить текст ТЗ на смысловые блоки, соответствующие вебстраницам, смогу без проблем. Сверстать каждую в HTML, наверно, тоже (но это ведь уже работа верстальщика)? Смогу внятно нарисовать прототипы карандашом на бумаге или в Visio (в Axura - это к проектировщику интерфейсов). Собрать из этого готовый сайт и разместить на хостинге - это к веб-программисту. Чтобы сайт был ещё и красочный - к веб-дизайнеру.
 
 
 
#14
Мне нравится0
07.10.2014 15:37:10
Цитата
techwriter пишет:
Цитата
ADVANCED пишет:
Вы зациклились на Ворде.
ТЗ необязательно писать в ворде, оно не обязательно должно быть распечатано на принтере. Оно не обязательно должно быть по ГОСТ и тд.
При упоминании ТЗ, почему-то ассоциация о печатном документе. Оно может быть в HTML и им пользуются разработчики как им удобно. Один на планшете, другой на компе, третьему достаточно прочитать.

Книги тоже не обязательно должны быть на бумаге. Есть e-book со своими форматами. И в них тоже можно писать и ТЗ и другую документацию и ГОСТ можно забыть.
Предложи свой вариант ТЗ так, чтобы при этом печатного и электронного документа не существовало в природе. При этом ТЗ содержало все обоснования решений, ограничения и условия.
Заказчик на встрече с аналитиком ставит требование "чтобы адрес можно было выбрать из списка". Аналитик отправляет программисту СМС "надо сделать справочник КЛАДР, подробности в письме". Пишет письмо в электричке пока не забыл, или прикладывает аудиозапись с диктофона. Когда аналитик приезжает на свое рабочее место со встречи, прикладывает переписку из почты в JIRA. Программист в это время уже заканчивает справочник и передает на тестирование. Тестировщик читает весь ход мыслей от появления идеи, до завершения разработки и тестирует, писатель документирует. Доработка сдается заказчику патчем или в следующем обновлении.
Вообще так редко бывает, если честно, но бывает. Пример из опыта работы с госзаказчиком. Срок разработки сокращен до минимума, все все выполнили, заказчик доволен. Никто не растягивает договоры, печати, ТЗ по ГОСТ и т.п.  
 
 
 
#15
Мне нравится0
07.10.2014 15:44:07
Цитата
Гость пишет:
Цитата
ADVANCED пишет:
ТЗ ... не обязательно должно быть распечатано на принтере.


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

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

Результат работ может сопровождаться актом выполненных работ, который подписывают обе стороны. Налоговые органы могут проверить договор и акт о выполнении работ, по которому перечислены деньги, с которых подлежит уплате налог. ВСЁ!
Изменено: ADVANCED - 21.10.2014 11:06:18
 
 
 
#16
Мне нравится0
07.10.2014 15:52:13
Цитата
techwriter пишет:
Цитата
ADVANCED пишет:
При упоминании ТЗ, почему-то ассоциация о печатном документе. Оно может быть в HTML и им пользуются разработчики как им удобно. Один на планшете, другой на компе, третьему достаточно прочитать.
Конкретно у тебя такая ассоциация, а не у всех. "Печатный документ" - это документ, который может быть распечатан, и не более того.
Распечатан может быть скриншот с экрана мобильного, на котором открыт tooltip, являющийся частью справки. Распечатать можно что угодно, хоть статуэтку на 3D-принтере.

Печатный документ - документ, выполненный непосредственно для печати на принтере. В основном это файлы в формате PDF.
В нашей стране в последнее время стали забывать о безопасности и подлогах документов и для печати и для обмена файлами вполне годятся файлы doc, которые "проще на месте поправить если что" Когда-то недавно документы прошнуровывались с указанием количества листов, печатями и т.п. и к их хранению также предьявлялись требования. И часть таких требований прописана в ГОСТах.

Если техпис открыл MS Word и пишет текст, оформляя заголовки по ЕСПД, это не означает что документация подготовлена по требованиям ГОСТ.  
 
 
 
#17
Мне нравится0
20.10.2014 16:22:49
Цитата
ADVANCED пишет:
ТЗ не юридический документ. В гражданском праве нет такого основания (вида документа) возникновения обязательств.

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

То, что договор является юридическим документом,  не означает, что ТЗ им не является.

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

При возникновении судебного спора, связанного с выполнением работ по ТЗ, суд почти наверняка будет рассматривать ТЗ как один из документов (письменных доказательств), имеющих существенное значение для разрешения спора.

Hope this helps.
Изменено: Виктор Фигурнов - 21.10.2014 11:06:19
 
 
 
#18
Мне нравится0
21.11.2017 11:52:04
Доброго времени суток!

Скажите пожалуйста, есть ли смысл интересоваться примерами ТЗ на тему разработки руководства пользователя для какого-либо софта?
Или искать подобную информацию здесь или где бы то ни было ещё нет смысла?
 
 
 
#19
Мне нравится0
20.09.2019 09:34:04
Марина М.
коллеги, в ТЗ по ГОСТУ раздел "Источники разработки" описан только для ТЗ на создание Системы. А для модернизированной системы в этом разделе надо накопительно с момента создание АС или только в части модернизации? Есть ли конкретные основания для заполнения этого раздела ТЗ на модернизацию АС ?

Из нашего Телеграмм для технических писателей (@twriters)
 
 
 
Страницы: 1
Читают тему

©2005- 2022 «TechWriters.ru: Все для технического писателя и разработки технической документации»

г.Москва, Большая Спасская 10/1
Рейтинг@Mail.ru