Как составить техническое задание для производства

Что такое ТЗ?

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

Характерной особенностью технических заданий выступает сильная зависимость – как содержимого, так и оформления документа – от специфики конечного продукта. Отдельного упоминания заслуживают ТЗ на различное программное обеспечение, включая веб-сайты, онлайн-сервисы, интернет-магазины и различные приложения. Их актуальность особенно велика, что легко и вполне логично объясняется важностью и стремительным развитием IT-индустрии.

Для чего требуется ТЗ?

Необходимость составления технического задания не вызывает сомнений. Наличие документа позволяет решить сразу несколько принципиально важных задач:

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

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

Кто должен составлять ТЗ?

Несмотря на кажущуюся простоту вынесенного в подзаголовок вопроса, ответ на него не так очевиден, каким видится на первый взгляд. Рассмотрим три возможных варианта.

Заказчик

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

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

Исполнитель

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

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

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

Совместно

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

Стоимость ТЗ

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

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

Как составить ТЗ?

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

Что потребуется?

Грамотно составленное ТЗ предусматривает наличие нескольких обязательных составных частей, включая:

1. Подробное описание целей реализации проекта.
2. Основные требования и ожидания от конечного продукта.
3. Ключевые этапы выполнения работ.
4. Календарный график или сроки исполнения.
5. Процедура контроля в процессе реализации проекта и итоговой приемки конечного продукта.
6. Приложения к ТЗ. Их перечень зависит от специфики проекта и обычно включает расчет стоимости, ссылки на нормативно-правовые документы и технические регламенты, другую справочную информацию, которая может оказаться полезной исполнителю.

Пошаговый план

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

Рекомендации по составлению

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

1. Однозначные формулировки. Содержание ТЗ не должно включать описаний или характеристик, допускающих неоднозначные трактовки. В тексте документа не допускается присутствие качественных прилагательных и крайне приветствуются конкретные цифры.
2. Определение используемых терминов. Заказчик и исполнитель должны разговаривать на одном языке. Поэтому ключевые понятия нуждаются в расшифровке.
3. Соблюдение установленных стандартов. Перечень нормативных документов, которые можно использовать при составлении технического задания, приводится ниже. Здесь же необходимо отметить, что ссылки на ГОСТы или ISO всегда полезны, так как сводят к минимуму возможные разночтения.
4. Предоставление исполнителю максимально возможной информации о заказчике. Такие сведения помогают сориентироваться в том, что является важным для заказчика, его целевой аудитории и других важных параметрах.
5. Перечисление конкурентов. Достаточно часто существенную помощь в реализации проекта оказывает изучение и анализ аналогов, уже представленных на рынке или запланированных к запуску конкурирующими компаниями. Такой подход к решению задачи заслуживает внимания, так как позволяет минимизировать сопутствующие расходы и не заниматься «изобретением велосипеда», а сосредоточиться на улучшении уже имеющихся разработок.
6. Внесение корректировок при необходимости. Если речь идет о сотрудничестве двух коммерческих структур, целесообразно наладить постоянное общение. В том числе –с целью уточнения ТЗ, если это потребуется. Хотя намного правильнее заранее прописать все возможные нюансы и сценарии развития событий, так как любые корректировки технического задания можно и нужно считать форс-мажором.

Скачать шаблон и пример ТЗ на оказание услуг – источник s-vfu.ru.

О стандартах

Порядок разработки технических заданий регламентируется множеством стандартов – как международных, так и отечественных. Причем в отношении разных проектов и продуктов действуют различные нормы. Наиболее часто упоминается международный стандарт ISO/IEC/IEEE 29148-2018. Он устанавливает требования к ТЗ на разработку информационных систем и программного обеспечения.

Если говорить об отечественных стандартах, необходимо обязательно отметить два из них. Первый – это ГОСТ 34.602-89, который устанавливает основные технические и другие требования к ТЗ на автоматизированные системы. Второй – это ГОСТ 19.201-78, определяющий порядок разработки ТЗ в рамках единой системы программной документации.

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

Существуют и другие стандарты, в большинстве своем международные – IEEE STD 830-1998, RUP, BABOK, SWEBOK и т.д. Их использования в отечественных условиях сильно ограничено из-за отсутствия учета местной специфики и широкого распространения.

Порядок документирования требований

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

Далее формируется коммерческое и техническое предложение. Такой документ обычно составляется при реализации масштабных проектов. Он содержит детальное описание финансовых показателей и технических требований к результатам.

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

В каком случае ТЗ не нужно?

Техническое задание требуется далеко не всегда. Например, если уже разработана детальная проектная документация, или проведены детальные предпроектные исследования/инженерные изыскания. Также не имеет особого смысла составлять ТЗ для небольших проектов, требования и характеристики которых можно перечислить непосредственно в договоре.

Шаблоны для скачивания и примеры

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

FAQ

Что такое ТЗ?

Под техническим заданием понимается перечень требований к разрабатываемому продукту или реализуемому проекту. Он включает технические характеристики, сроки выполнения, нередко – стоимость производимых работ и другие подобные параметры.

Для чего необходимо техническое задание?

Составление ТЗ позволяет четко сформулировать поставленные перед исполнителем задачи и исключить возможность возникновения спорных ситуаций в процессе их решения.

Что следует включить в ТЗ?

Содержание ТЗ определяется с учетом специфики конкретного продукта и может включать обширный набор сведений – от перечня требуемых характеристик до описания процедуры контроля качества.

Кто занимается составлением ТЗ?

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

Какие типичные ошибки допускаются при разработке технического задания?

Самыми частыми ошибками при составлении ТЗ выступают: неоднозначные формулировки, отсутствие четких требований, недостаток информации о заказчике, продукте и конкурентах.

Подведем итоги

1. Техническое задание – это перечень требований к конечному продукту или результатам реализации проекта.
2. Разработка ТЗ – важный подготовительный этап, от успешного выполнения которого зависит эффективность дальнейшего сотрудничества между заказчиком и исполнителем, а также качество полученного на выходе продукта.
3. Составлением ТЗ занимается заказчик, исполнитель или одновременно оба. Последний вариант нередко оказывается самым плодотворным при условии взаимного доверия между сторонами.
4. Стоимость технического задания определяется индивидуально и зависит от специфики конечного продукта, его сложности и предъявляемых заказчиком требований.

В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается “как получится”. Как сказал Генри Шоу “Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи”.

О чем эта статья?

Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?».  Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему.  В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 50 страниц и решил разбить ее на 2 части:  

• В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.

• Вторая часть «Разработка Технического задания. Как формулировать требования?» будет полностью посвящена выявлению и формулировке требований к информационной системе.

Для начала надо разобраться, какой в действительности вопрос  интересует тех, кто спрашивает «Как разработать техническое задание?»  Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания.   О каких вариантах я говорю:

• Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной  IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;

• Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную  IT-службу. Решили поступить так:  разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;

• Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.

• IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:

  • Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;

  • Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);

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

  • Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.

  • Возможны и другие, реже встречающиеся варианты;

Думаю, сейчас у читателя должны возникнуть вопросы:

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

• Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?

• Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?

• Как понять, хорошо составлено Техническое задание или нет?

• За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли.  Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах.  Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

 Как ни странно, проблемы у всех одинаковые! У всех бывают как успешные документы (и проекты), так и совсем бестолковые  (исключение, пожалуй, составляют Технические задания, разработанные еще во времена, когда не было персональных компьютеров, но там были совсем другие условия).  Почему так получается? Именно потому, что цели у проектов бывают разные, как и пользователи этих документов. И, конечно, компетенции непосредственных специалистов не на последнем месте.  В этих двух статьях я попытаюсь  поделиться своим личным  опытом, накопленном  за многие годы. Конечно, получится в сжатом виде, т.к. вопрос достоин целой книги (кстати, идея, а может написать?)…  

Что такое техническое задание?

Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись.  Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели.  Возможно, кто-то сейчас подумал, что правда где-то по серединеJ. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

Заметим, что  в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации – далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;

• ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;

• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

Куда более удачное определение представлено в википедии (правда про ТЗ в целом, а не только для программного обеспечения ): «Техническое задание – это исходный документ на проектирование технического объекта. Техническое задание устанавливает основное назначение разрабатываемого объекта, его технические и тактико-технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.)»

Отличное определение, полностью раскрывающее суть. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание. И это нормально, ведь есть ГОСТ, например, на изготовление хлеба, и это вовсе не значит, что любой человек может выпечь хлеб по ГОСТу. Кроме ГОСТа требуется знание методик и практик, как в любом деле. Именно этот факт лежит в корне проблемы, которая лежит посерединеJ.  А многие специалисты почему-то при необходимости разработать Техническое задание, обращаются только к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится! Но ведь не может такого быть, что в столь распространенном занятии, как разработка и внедрение автоматизированных систем  не проводилось исследований, не изучались практики, не писалось книг об этих самых практиках! И это так. Конечно, есть много отличных (!) трудов, посвященных тематике формулирования требований и в конце статьи я приведу такие примеры. Многое в своей практике я использовал именно оттуда, а когда работал над этой статьей, то тоже нашел много интересных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не нужно, но есть потребность систематизировать эти знания. Кстати, любопытный факт, ни одного отечественного автора в этих трудах нет. Вся литература в переводе с западных авторов, но зато каких! Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Иначе, споры о том, «Как разработать техническое задание» будут продолжаться бесконечно. Однако, я увлекся лирикой…

И так, как следует из определения, основное назначение Технического задания – сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе.

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:

• Требования в функциональности;

• Требования к безопасности и правам доступа;

• Требования к квалификации персонала;

• …. И т.д. Вы можете  прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).

Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования.  Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома.  Красота!).  Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат  нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания.

Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:

1. Требование должно быть понятным;

2. Требование должно быть конкретным;

3. Требование должно быть тестируемым;

Причем последнее свойство невозможно без двух предыдущих, т.е. является этакой «лакмусовой бумажкой». Если результат выполнения требования невозможно протестировать, значит, оно либо не понятное, либо не конкретное. Подумайте об этом. Именно во владении этими тремя свойствами требований и заключается мастерство и профессионализм. На само деле все очень просто. Когда разберешься.

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

• на каком языке (в смысле сложности понимания) должно быть написано техническое задание? 

• Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?

• А что такое техническое  проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?

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

Так вот:

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

Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуютсятехническим специалистам. Заказчику в это вникать вовсе не обязательно (ему и термины такие могут быть непонятны). Технический проект делает Архитектор системы (вот совмещение этой роли с программистом вполне нормально).  А точнее группа специалистов во главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием.

Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований.  Что, знакомая ситуация?  И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.

Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. Она плавает между  ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так потому, что культура разработки стала слабой. Частично  это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени – это факт). Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.

Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.

Управленческий учет: с нуля до настройки в 1С, Excel и Google-таблицах

Уметь настраивать и вести управленку — значит быть полезным для руководителей. Научитесь понимать, откуда приходят и куда уходят деньги компании на курсе повышения квалификации от «Клерка».

А нужно ли вообще техническое задание? А Технический проект?

Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей  так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого». Золотые ведь слова, ко всему подходят. Так  что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ.  Должен ли с ним знакомиться  Заказчик? Если хочет, почему нет, но настаивать  и утверждать данный документ нет никакой необходимости, он будет только сдерживать и  мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы  и программистами.

Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

Формулирование требований к информационной системе. Структура Технического задания

Сразу определимся: мы будет говорить именно о формулировании требований к информационной системе, т.е. предполагая, что работа по выработке бизнес-требований, формализации бизнес-процессов и вся предшествующая консалтинговая работа уже выполнена. Конечно, некоторые уточнения могут выполняться и на этом этапе, но именно уточнения. Сам проект автоматизации не решает проблем бизнеса – помните об этом. Это аксиома. Почему-то некоторые руководители пытаются ее опровергнуть,  считая, что если купят программу, то наступит порядок в хаотичном бизнесе. Но ведь аксиома на то и аксиома, что доказательств не требует.

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий.  По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

Несмотря на то, что формулировка требований является основной частью Технического задания, а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично!  Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю?  Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.

И так, ГОСТ рекомендует следующие разделы:

1. общие сведения;

2. назначение и цели создания (развития) системы;

3. характеристика объектов автоматизации;

4. требования к системе;

5. состав и содержание работ по созданию системы;

6. порядок контроля и приемки системы;

7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8. требования к документированию;

9. источники разработки.

Итого, 9 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.

Раздел 1. общие сведения.

Раздел 2. назначение и цели создания (развития) системы.

Раздел 3. Характеристика объектов автоматизации.

Раздел 4. Требования к системе

Раздел 5. Состав и содержание работ по созданию системы

Раздел 6. Порядок контроля и приемки системы

Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Раздел 8. Требования к документированию

Раздел 9. Источники разработки

И так, мы рассмотрели все разделы, которые могут быть включены в Техническое задание. «Могут», а не «Обязаны» именно потому, что любой документ должен разрабатываться для достижения результата. Поэтому, если для Вас очевидно, что какой-то отдельный раздел к результату не приблизит, значит он Вам не нужен и не надо тратить на него время.

Но вот без главного: функциональных требований ни одно грамотно  Техническое задание не обходится.  Хочу  заметить, что в практике такие Технические задания встречаются, и еще как! Есть деятели, которые сумеют развести воды по всем разделам, опишут общие требования общими словами, и документ получается весьма увесистый, и слов в нем умных много, и даже Заказчику может понравится (т.е. он его утвердит). Но вот работать по нему может не получиться, т.е. практической пользы от него мало. В большинстве случаев такие документы рождаются, когда надо получить много денег  именно под Техническое задание, а сделать его надо быстро и не погружаясь в детали. А особенно, если известно, что дальше дело не пойдет, или его будут делать совсем другие люди. В общем, просто для освоения бюджета, особенно государственного.

Во второй статье  будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.

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

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

Надеюсь, идея понятна. Если будут конкретные вопросы, пишите, попробую помочь.

Чтобы в Техническом задании было больше конкретики, существует немало рекомендаций. Даже есть перечень слов, которые употреблять в Техническом задании не рекомендуется. Интересно об этом пишет К.Вигерс, в своей книге «Разработка требований к программному обеспечению». Приведу самые интересные и простые, на мой взгляд, рекомендации:

• Не следует использовать слов, имеющих множество синонимов. Если это необходимо, то лучше дать четкое определение термину в разделе «Термины и определения» к Техническому заданию.

• Следует стараться не использовать длинных предложений;

• Если какое-то требование Вам кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований;

• Используйте больше схем, графиков, таблиц, рисунков – так информацию воспринимается гораздо легче;

• Следует избегать таких слов: «эффективный», «адекватный», «простой», «понятный», «быстрый», «гибкий», «улучшенный», «оптимальный», «прозрачный», «устойчивый», «достаточный», «дружественный», «легкий» и др.  Перечень можно продолжать, но, мне кажется идея понятна (попробуйте его продолжить самостоятельно).

Все, что написано выше, это информация важная, но не самая. Как Вы помните, в начале статьи я это назвал термином «камуфляж», т.к. самое главное, что составит как минимум 90% времени и сложности работы над документом – это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. Одно из таких ключевых отличий – это наличия этапа построения прототипа будущей системы, или как его еще называют «модели информационной системы».

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

Чтобы в результате закупки получить именно то, что необходимо, заказчики составляют техническое задание (ТЗ). Однако порой перед ними стоит нелегкая задача: подробно составить описание объекта закупки, при этом не нарушив антимонопольного законодательства.

Сложности составления ТЗ

Составление технического задания — это процесс трудоемкий и непростой. В результате прочтения ТЗ поставщик должен точно понимать, какой товар нужен заказчику. Поэтому техзадание должно содержать максимальный набор характеристик объекта закупки. В то же время слишком скрупулезный подход может привести к тому, что объект будет подогнан под товар конкретного производителя. Особенно если сам заказчик прекрасно осознает, какая марка оборудования ему нужна или с кем из поставщиков ему было бы выгоднее работать. И тогда участники закупки обратят внимание на то, что заказчик создает преимущественные условия для какого-то поставщика и ограничивает конкуренцию. В результате ФАС может усмотреть в действиях заказчика нарушение Федерального законодательства.

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

Распространенные нарушения при составлении ТЗ

Использование неточных формулировок

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

В случае использования диапазонных значений следует четко установить их границы. Если некоторые фразы используются в определенном смысле или допускают разное толкование, их трактовку нужно расписать в документации. Например, «порядка 100» может означать у заказчика не более 100, а «около 100» — не менее 100.

Наименование технических терминов и единицы их измерения необходимо излагать в соответствии с техническими регламентами. Иначе придется давать обоснование, почему в документации заказчик применяет какие-то нестандартные термины. Например, мало кто поймет, что речь идет о миллиметрах, если написано «10 м», а не «10 мм». Однако случаи столь странного применения заказчиками единиц измерения на практике были.

Нарушения, связанные с ГОСТами

Очень часто происходит путаница с разного рода характеристиками, которые заказчики берут из ГОСТов. Зачастую оттуда переписывается все подряд. В результате в техническом задании присутствуют взаимоисключающие характеристики. Понятно, что объекта, соответствующего им, в природе быть не может. Проявляя такую некомпетентность, заказчик нарушает часть 2 статьи 33 закона 44-ФЗ.

Нередко заказчики просто перечисляют в ТЗ номера ГОСТов, при этом не указывая, к каким объектам они относятся. ФАС считает, что это мешает поставщику составить заявку правильно, ведь подобное описание не позволяет идентифицировать товар.

Отсутствие упоминания об эквиваленте

При составлении технического задания зачастую заказчики указывают марку товара, который им необходимо приобрести. При этом забывают добавлять «или эквивалент», чем явно ограничивают конкуренцию и нарушают законодательство. Специалисты советуют описывать объект закупки в ТЗ максимально безлико, то есть не упоминать ни марки, ни производителя, ни даже страны происхождения товара.

Советы специалистов

Грамотно составленное ТЗ отсекает заведомо неподходящее товары, избавляет от необходимости отвечать на множество запросов о разъяснении и, вообще, лишает заказчика массы проблем. И главное тут — внимательно изучить требования к объектам закупки, оценить свои потребности и строго следовать правилам закона 44-ФЗ Маститые специалисты дают своим коллегам некоторые советы, о которых расскажем далее.

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

Никогда не копируйте описание объекта закупки с интернет-сайтов — оно может быть неточным. В результате либо вы закупите вовсе не то, что собирались, либо этому описанию не будет соответствовать ни один товар. Еще один вполне возможный исход — под описание попадет конкретная марка/модель, и вас обвинят в нарушении антимонопольного законодательства.

Максимально точно описывайте требования к характеристикам объекта закупки. Используйте фраза, которые исключают двусмысленное толкование. Иначе придется давать очень много пояснений.

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

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

О чем еще не следует забывать:

• объекты закупки указывайте в соответствии с классификатором ОКПД2;
• изучите нормативные документы и стандарты, в которых содержатся требования к объекту закупки (ГОСТ, СНиП, ТУ);
• при наличии сметной документации следите за тем, чтобы в ТЗ содержались соответствующие ей объекты закупки;
• обязательно укажите в требованиях, что товар должен быть новым, иначе рискуете приобрести бывший в употреблении, отремонтированный, отреставрированный товар;
• если закупаете выполнение строительных работ, капремонта, реконструкции, не забудьте приложить смету и проектную документацию.

Некоторые вопросы по составлению техзадания

Имеем ли мы право в ТЗ на закупку запчастей указать, что они должны быть оригинальными?

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

Нужно ли в техническом задании указывать идентификационный код закупки?

Нет, это не обязательно. Но этот код должен быть указан в плане и плане-графике закупок, извещении о закупке, приглашении на закупку, которая проводится закрытым способом, в закупочной документации, в контракте и иных документах, если это предусмотрено законом 44-ФЗ.

Требуется приобрести прибор для научных исследований. Имеем три прибора одного производителя и необходимо, чтобы новый имел с ними полную совместимость. Техника дорогостоящая и требует тонкой настройки, поэтому покупка эквивалента крайне нежелательна. Можем ли мы указать конкретного производителя без добавления «или эквивалент»?

Вам следует оценить, подходит ли ваш случай под исключение, указанное в пункте 1 части 1 статьи 33 закона 44-ФЗ: «за исключением случаев несовместимости товаров, на которых размещаются другие товарные знаки, и необходимости обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком». Если это полностью соответствует вашей ситуации, то можно указать производителя без добавления фразы «или эквивалент».

Составляем ТЗ на капремонт помещения. Допустимо ли приложить шаблон композиции из гипсокартона для потолка, указать конкретный колер для краски и коллекцию плитки, не указывая «или эквивалент»?

Такие характеристики, как цвет краски и форма потолка, в полной мере зависят от предпочтений заказчика и не ограничивают круг поставщиков. Конкретный цвет стен или форму композиции из гипсокартона по вашему макету может обеспечить любой исполнитель контракта. Поэтому указанные характеристики можно смело описывать в ТЗ. А вот при указании конкретной коллекции плитки придется добавить «или эквивалент», иначе будет прямое нарушение статьи 33 закона 44-ФЗ.

МЕЖГОСУДАРСТВЕННЫЙ СОВЕТ ПО СТАНДАРТИЗАЦИИ, МЕТРОЛОГИИ И СЕРТИФИКАЦИИ

(МГС)

INTERSTATE COUNCIL FOR STANDARDIZATION, METROLOGY AND CERTIFICATION

(ISC)

МЕЖГОСУДАРСТВЕННЫЙ

СТАНДАРТ

Система разработки и постановки продукции на производство

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Требования к содержанию и оформлению

Издание официальное

Предисловие

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0-2015 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2015 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены».

Сведения о стандарте

1    РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ)

2    ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3    ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 25 октября 2016 г. № 92-П)

За принятие проголосовали:

Краткое наименование страны по MK (ИСО 3166) 004—97 Код страны по МК (ИСО 3166) 004—97 Сокращенное наименование национального органа по стандартизации Армения AM Минэкономики Республики Армения Киргизия KG Кыргызстандарт Россия RU Росстандарт Таджикистан TJ Таджикстандарт

4    Приказом Федерального агентства по техническому регулированию и метрологии от 14 марта 2017 г. № 135-ст межгосударственный стандарт ГОСТ 15.016-2016 введен в действие в качестве национального стандарта Российской Федерации с 1 сентября 2017 г.

5    ВВЕДЕН ВПЕРВЫЕ

Информация об изменениях к настоящему стандарту публикуется в ежегодном информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования— на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2017

В Российской Федерации настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

–    к периодичности и продолжительности контроля (при необходимости) технического состояния, технического обслуживания во время хранения (переконсервация, тренировка);

–    к срокам хранения изделия в различных условиях и видах технического состояния;

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

6.1.4.9    В подразделе «Транспортирование» устанавливают требования, определяющие приспособленность изделия к перевозке, и указывают:

–    класс опасности по ГОСТ 19433 (при необходимости);

–    виды транспорта, которыми может осуществляться перевозка;

–    необходимое количество транспортных средств для перевозки изделия, возможное количество перевозимых изделий одной единицей транспорта (при необходимости);

–    показатели транспортирования изделия каждым видом транспорта (дальность, скорость, продолжительность перевозок, количество погрузок, перегрузок, выгрузок и др.) и массогабаритные характеристики изделия;

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

–    последовательность, объем работ, продолжительность подготовки изделия к перевозке, людские ресурсы и средства, привлекаемые для подготовки изделия к перевозке, меры безопасности при проведении погрузочно-разгрузочных работ;

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

–    последовательность, объем работ, людские ресурсы, средства и продолжительность приведения изделия в рабочее состояние после перевозки;

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

Конкретные типы транспортных средств, контейнеров, оборудования и приспособлений, необходимых для обеспечения перевозки изделий, уточненные показатели транспортирования и другие параметры данного подраздела определяют на этапе ЭП (ТП) и устанавливают на стадии разработки РКД в «Руководстве по эксплуатации», разрабатываемом в соответствии с ГОСТ2.601, согласованным сорга-нами надзора (контроля) за безопасностью перевозок и соответствующими заказчиками (по видам транспортного обеспечения).

6.1.4.10    В подразделе «Требования безопасности» устанавливают требования, характеризующие конструктивно-технические особенности создаваемого изделия, обеспечивающие безопасность персонала, местного населения, сопрягаемых и других близко расположенных объектов, а также ОС на всех стадиях жизненного цикла изделия:

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

–    взрывобезопасности и пожаростойкости изделия, его СЧ, их покрытий и материалов, в том числе применяемых при эксплуатации и ремонте изделия;

–    к входящим в состав изделия средствам защиты персонала;

–    к средствам блокировки и сигнализации;

–    защиты изделия от самосрабатывания и повреждений при воздействии статического электричества и перегрузок (в заданных условиях);

–    критерии опасного состояния изделия;

–    безопасного удаления персонала при эксплуатации изделия (указывают при необходимости).

В подразделе устанавливают требования по экологической безопасности и утилизации, уничтожению и (или) захоронению изделия, отходов от него и удалению опасных отходов, указывая:

–    источники загрязнения ОС в составе изделия при его функционировании (хранении);

ГОСТ 15.016-2016

–    состав и количественные значения загрязняющих воздействий, вредных физических факторов [радиусы зоны с концентрацией веществ (уровнем вредных воздействий) не выше предельно допустимых и (или) мощность выброса, интенсивность воздействия];

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

–    требования к входящим в состав изделия защитным устройствам (оборудованию), снижающим экологический риск;

–    правила эксплуатации (применения) изделия (с защитными устройствами и без них), обеспечивающие его экологическую безопасность и включенные в разрабатываемую ЭД;

–    требования к составу и характеристикам технических средств (систем, оборудования, приборов) контроля экологичности изделия, методам и периодичности контроля загрязняющих воздействий (уровня вредных физических факторов) изделия при его функционировании (хранении), аварийных ситуациях;

–    требования по возможно максимальному полному вторичному использованию изделия, веществ и материалов по окончании срока годности (ресурса) и хранения;

–    требования к производству и утилизации изделий без использования или побочного выделения токсичных веществ;

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

–    требования по ликвидации отходов и изделий.

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

6.1.4.11    В подразделе «Требования стандартизации, унификации и каталогизации» устанавливают требования, направленные на достижение целей стандартизации и каталогизации.

Подраздел должен состоять из двух частей, устанавливающих:

–    требования стандартизации и унификации;

–    требования каталогизации.

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

6.1.4.11.2    В подразделе «Требования каталогизации» излагают требования согласно национальному законодательству государств — участников МГС в этой области.

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

В подразделе при необходимости устанавливают требования технологической независимости изделий, создаваемых с применением ЭРИ и ЭВТ иностранного производства, которая должна обеспечиваться:

–    в изделиях, подлежащих единичному производству, — путем закупки необходимого количества ЭРИ и ЭВТ иностранного производства для проведения исследований и испытаний, комплектации в процессе разработки и изготовления опытного образца изделия, обеспечения ремонтных предприятий, создания страховых запасов на период применения изделия;

–    в изделиях, подлежащих серийному производству, — путем последующей замены ЭРИ и ЭВТ иностранного производства в установленные сроки на отечественные аналоги.

Требования технологичности задают в соответствии с ГОСТ 14.201.

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

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

9

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

В разделе указывают:

–    предельное значение стоимости выполнения ОКРвцелом¹и, по усмотрению заказчика, предельные значения стоимости отдельных этапов ОКР;

–    предельное значение стоимости строительства объектов, средств измерений, контроля, регистрации и других средств и оборудования, необходимого для проведения испытаний опытных образцов изделий;

–    предельное значение стоимости строительства новых (реконструкции существующих) объектов производственного назначения для организации серийного производства изделий;

–    ориентировочную стоимость жизненного цикла изделия в серийном производстве;

–    предельную трудоемкость изготовления изделия при серийном производстве;

–    предельное значение нормативной трудоемкости технического обслуживания изделия в процессе эксплуатации;

–    предельные значения стоимости капитального строительства объектов заказчика или стоимости переоборудования, реконструкции существующих объектов, обеспечивающих эксплуатацию (функционирование) изделий (включается по усмотрению заказчика);

–    предельную среднегодовую стоимость эксплуатации изделия и содержания его в процессе длительного хранения.

В разделе (по усмотрению заказчика) устанавливают годовой объем выпуска изделий в серийном производстве (ориентировочно), предполагаемую длительность стадии эксплуатации и требования проведения головным исполнителем (исполнителем) ОКР технико-экономического обоснования целесообразности создания изделия и сравнения его с аналогами, разрабатываемыми и (или) находящимися в эксплуатации. В числе показателей технико-экономического обоснования устанавливают:

–    стоимость и продолжительность подготовки и освоения серийного производства;

–    ориентировочную стоимость жизненного цикла изделия, в том числе стоимость выполнения ОКР и серийного производства (при необходимости — ориентировочную стоимость подтверждения соответствия);

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

–    экономическую целесообразность разработки и постановки на производство данного изделия;

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

–    техническую и технико-экономическую реализуемость заявок заказчика на поставку изделий (по технологии, трудоемкости изготовления изделия, дефицитному сырью и материалам, по возможности поставок КИМП, по размеру необходимых капитальных вложений).

6.1.6 В разделе «Требования к видам обеспечения» устанавливают требования и нормы по видам обеспечения изделия для достижения заданной эффективности в процессе его применения и эксплуатации. Раздел должен состоять из подразделов:

–    требования к нормативно-техническому обеспечению;

–    требования к метрологическому обеспечению;

–    требования к диагностическому обеспечению;

–    требования к математическому, программному и информационно-лингвистическому обеспечению.

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

ГОСТ 15.016-2016

6.1.6.1    В подразделе «Требования к нормативно-техническому обеспечению» устанавливают:

–    требования к срокам и содержанию работ по нормативно-техническому обеспечению;

–    требования формирования электронного каталога создаваемого изделия;

–    порядок и правила обеспечения участников ОКР нормативными документами по стандартизации и каталожной информацией.

Примечание — Работы² по нормативно-техническому обеспечению (в части работ по стандартизации и унификации СЧ, КИМП и материалов создаваемого изделия) включают:

–    анализ существующего фонда НД по стандартизации с целью оценки его возможностей по нормативному обеспечению стадий жизненного цикла создаваемого изделия;

–    экспертизу вновь разрабатываемых программ, планов и нормативных документов по стандартизации СЧ, КИМП и материалов создаваемого изделия (при необходимости);

экспертизу ТЗ на СЧ ОКР³ (ОКР по созданию СЧ, КИМП, материалов, а также используемых при разработке, эксплуатации и применении изделия оборудования, средств технологического оснащения, средств обеспечения испытаний, контроля и пр.), проводимую с целью определения целесообразности создания новых изделий и включения их в каталог продукции согласно национальному законодательству государств —участников МГС в этой области.

В данном подразделе приводят перечень НД по стандартизации, которым должна соответствовать РКД, ТД, ЭД и другая ОНТД, разрабатываемые в процессе ОКР. При необходимости перечень стандартов (при большом его объеме) может оформляться в виде приложения кТЗ.

6.1.6.2    В подразделе «Требования к метрологическому обеспечению» устанавливают:

–    количественные значения показателей метрологического обеспечения изделия (СЧ изделия): технических (показатели точности измерений и достоверности измерительного контроля, продолжительность и периодичность измерений параметров, массогабаритные показатели средств измерений и измерительного контроля по ГОСТ 16504 и др.) и технико-экономических (трудоемкость, стоимость и др.);

–    требования к методам (методикам) измерений и измерительного контроля параметров и характеристик изделия [обеспечение требуемой точности и (или) достоверности, надежности, быстродействия, простоты аппаратурной реализации, аттестации методик выполнения измерений, степени автоматизации и унификации и др.];

–    требования к измерительной системе (системе измерительного контроля) для комплектации изделия (назначение и решаемые задачи, вид используемых средств измерений и измерительного контроля, допустимые значения показателей метрологического обеспечения, степень автоматизации измерительного контроля, способы взаимодействия и информационного обмена и др.);

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

–    требования к метрологической, электрической, информационной, конструктивной и эксплуатационной совместимости системы (средств) измерения и измерительного контроля с изделием;

–    требования к методам и средствам поверки и ремонта средств измерений (возможность выполнения поверки и ремонта метрологическими службами заказчика, согласованность периодичности их проверки с периодичностью технического обслуживания изделия);

–    требования к метрологическому обеспечению испытаний опытного образца изделия;

–    требования к организации метрологической экспертизы на этапах ОКР по созданию изделия;

–    требования к программе метрологического обеспечения разработки изделия (задачи метрологического обеспечения на этапах жизненного цикла, сроки их выполнения, виды отчетности, состав исполнителей), метрологическому сопровождению ОКР.

6.1.6.3    В подразделе «Требования к диагностическому обеспечению» устанавливают:

–    количественные значения показателей технического диагностирования [контроля технического состояния: показателей достоверности (условные вероятности необнаруженного и ложного отказов (неисправностей)⁴ изделия, условные вероятности необнаруженного и ложного отказов (неисправностей) в СЧ изделия с точностью, до которой определяется место отказа (неисправности), условная вероятность ошибочного прогнозирования безопасной эксплуатации] и технико-экономических показателей [удельные затраты на техническое диагностирование (контроль технического состояния), средние тру-

доемкость и продолжительность технического диагностирования (контроля технического состояния)], а также характеристик технического диагностирования [глубина поиска отказа, полнота технического диагностирования (контроля технического состояния) и др.];

–    требования приспособленности ктехническомудиагностированию (контролепригодности) изделия [количественные значения показателей приспособленности к техническому диагностированию (контролепригодности)], требования к введению в конструкцию изделия встроенных средств технического диагностирования (контроля технического состояния), требования к количеству, расположению и доступности устройств сопряжения с внешними средствами технического диагностирования (контроля технического состояния и др.);

–    требования к номенклатуре диагностических (контролируемых) параметров и их характеристик (номинальные, допустимые значения, точки ввода, контрольные точки и др.);

–    требования к средствам технического диагностирования (контроля

технического состояния);

–    требования к методам и правилам технического диагностирования (контроля технического состояния).

6.1.6.4 В подразделе «Т ребования к математическому, программному и информационно-лингвистическому обеспечению» устанавливают:

–    требования к математическому обеспечению (состав и структура общего и специального математического обеспечения, требования к разработке и обоснованию технологий взаимодействия компонентов общего и специального программного обеспечения, требования к разработке и обоснованию алгоритмов и расчетных методик, к надежности, точности и времени решения задач, ресурсу памяти, чувствительности и пределам изменения входных данных, модульности и гибкости математического обеспечения; нормативы адаптации к составу и состоянию вычислительных средств, возможность использования ранее разработанных элементов математического обеспечения);

–    требования к программному обеспечению (требования к общему программному обеспечению, программированию функциональных задач, средствам программирования, метрологической аттестации программного обеспечения и использованию перспективныхтехнологий программирования, порядку отладки, испытаний и сдачи программ в эксплуатацию, к использованию стандартных программ) должны задаваться с учетом требований стандартов ЕСПД;

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

В подразделе также устанавливают требования по обеспечению безопасности информации в части:

–    требований к программным средствам обеспечения безопасности обрабатываемой, хранимой и передаваемой по каналам связи информации, в том числе безопасности информации баз данных каталогизации;

–    разработки (применения существующих) программных средств и способов защиты информации, обрабатываемой и хранимой в ЭВТ изделия или передаваемой по каналам связи, от несанкционированного доступа;

–    требований к сертификации разрабатываемых программных средств и способов защиты информации.

6.1.7    В разделе «Требования ксырью, материалам и КИПМ» устанавливают:

–    требования к КИМП, групповым, ремонтным комплектам ЗИП и другим покупным изделиям, жидкостям, смазкам, краскам и материалам (продуктам, веществам);

–    требования к использованию при создании (модернизации), изготовлении и эксплуатации изделий материалов и КИМП;

–    ограничение номенклатуры (видов, марок, типоразмеров) применяемого сырья, материалов (в том числе эксплуатационных), КИМП и других покупных изделий;

–    возможность применения и (или) ограничения в применении дефицитных и драгоценных материалов (металлов) и сплавов, порядок их учета;

–    требования к физико-химическим, механическим и другим свойствам отдельных видов сырья и материалов, определяющих качество изделия.

6.1.8    В разделе «Требования к консервации, упаковке и маркировке» устанавливают:

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

ГОСТ 15.016-2016

вации универсального оборудования или необходимость разработки и изготовления специального оборудования, методы и средства консервации);

–    требования к упаковке (в том числе вид упаковки, применяемые упаковочные средства), способ упаковки, возможные варианты упаковки в зависимости от сроков и условий хранения и перевозки;

–    количество изделий, упаковываемых в одну потребительскую и (или) транспортную упаковку;

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

6.1.9    В разделе «Требования кучебно-тренировочным средствам» устанавливают:

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

–    требования к комплексным и специализированным тренажерам по конструктивному исполнению, степени имитации реальной обстановки эксплуатации, принципу действия, габариту, массе и др.;

–    требования к моделям, макетам, стендам, учебно-техническим плакатам (расцветка, размеры, альбомы или настенные плакаты и т. п.);

–    этапы, порядок и сроки разработки, изготовления, представления учебно-тренировочных средств на приемочные испытания и поставки их потребителю.

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

6.1.10    В разделе «Специальные требования» устанавливают:

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

–    требования к специальному ремонтно-технологическому оборудованию, предназначенному для комплектования ремонтных органов в целях обеспечения ремонта и поддержания изделия в работоспособном состоянии в процессе эксплуатации;

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

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

–    вид экспортного исполнения изделия (при необходимости);

–    требования к патентной чистоте и патентоспособности изделия и его СЧ.

6.1.11    В разделе «Требования к документации» устанавливают требования кдокументам разрабатываемого изделия (комплекса, системы) согласно стандартам ЕСКД, включая:

–    требования к конструкторской документации согласно ГОСТ 2.001, ГОСТ 2.102 и ГОСТ 2.103;

–    требования к конструкторским документам, которые разрабатываются и применяются в электронном виде, согласно стандартам ЕСКД;

–    требования к технологической документации согласно ГОСТ 3.1001 и ГОСТ 3.1102;

–    требования к программной документации согласно ГОСТ 19.201.

6.1.12    В разделе «Этапы выполнения ОКР» указывают наименования обязательных этапов, а при необходимости — самостоятельных отчетных подэтапов и конкретный перечень работ, выполняемых на каждом этапе (подэтапе).

В перечень работ, выполняемых на этапах (подэтапах) ОКР, должны быть включены следующие работы:

–    проведение поэтапных патентных исследований (проверка выполнения заданных требований патентной чистоты и патентоспособности изделия и его СЧ);

–    анализ фонда НД и мероприятий по нормативно-техническому обеспечению создания изделия в соответствии с требованиями, изложенными в 6.1.6.1;

–    экспертиза проектной и РКД по реализации заданных требований уровня стандартизации и унификации, эргономике и др. с указанием места ее проведения, комплектности документов, предъявляемых на экспертизу, а также организаций (предприятий), выполняющих экспертизу;

–    оценка соответствия изделия заданным требованиям по надежности [точность оценки и методы ее проведения (расчетный, расчетно-экспериментальный или экспериментальный) задаются заказчиком];

–    оценка соответствия заданным требованиям кэргономике, обитаемости и технической эстетике;

–    оценка соответствия заданным требованиям к радиоэлектронным средствам, живучести и стойкости к внешним воздействующим факторам;

–    проверка выполнения заданных требований транспортирования изделия различными видами транспортных средств;

–    проведение (уточнение) технико-экономического обоснования целесообразности продолжения разработки изделия и сравнительной оценки его с аналогичными изделиями, в том числе разрабатываемыми;

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

–    отработка постановки задач и обоснование решений по математическому, программному и информационно-лингвистическому обеспечению в соответствии с заданными требованиями;

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

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

6.1.13 В разделе «Порядок выполнения и приемки этапов ОКР» указывают:

–    правила и порядок выполнения и приемки этапов ОКР, а также порядок выполнения и приемки самостоятельных отчетных подэтапов ОКР;

–    перечень документов и исходных данных для выполнения ОКР;

–    необходимость разработки, изготовления и испытания макетов (моделей) изделия на этапах ЭП иТП, их перечень и количество, необходимость разработки на них РКД и другой технической документации, согласования программ и методик испытаний с заказчиком;

–    количество опытных образцов изделий, необходимое для проведения всех категорий и видов испытаний;

–    место (организацию, предприятие) проведения испытаний опытных образцов изделий и учебно-тренировочных средств (включают по решению заказчика);

–    номенклатуру или вид средств эксплуатационного обеспечения испытаний, ЗИП, состав и комплектность документации, предъявляемых на испытания;

–    порядок разработки, согласования и утверждения плана совместных работ по выполнению ОКР (единого сквозного плана, сетевого плана-графика, плана-графика или другого планирующего документа);

–    порядок разработки, согласования и утверждения программы обеспечения стойкости, программы метрологического обеспечения, программы обеспечения надежности, программы эргономического обеспечения;

–    порядок разработки, согласования и утверждения «Инструкции по перевозке образца»;

–    порядок разработки, согласования и утверждения плана мероприятий по каталогизации;

–    порядок разработки, согласования и утверждения программы (программ) работ по стандартизации, разрабатываемой (разрабатываемых) в соответствии с порядком, изложенным в 6.1.6.1 (при необходимости);

–    основных соисполнителей [уточняют в соответствии с совместным решением заказчика и головного исполнителя (исполнителя) ОКР];

–    требования к гарантийным обязательствам поставщика и подтверждению в процессе ОКР выполнения заданных требований результатами испытаний, расчетов и другими отчетными документами);

–    состав, количество комплектов и перечень рассылки ОНТД, представляемой по окончании этапов ОКР и ОКР в целом;

–    порядок разработки отчета о патентных исследованиях, а также патентного формуляра на изделие в соответствии с ГОСТ 15.012;

–    требования к разработке РКД в соответствии с требованиями стандартов ЕСКД;

–    необходимость разработки и требования к разработке ремонтной документации;

–    требования к разработке ЭД в соответствии с ГОСТ 2.601;

–    требования проведения технико-экономической оценки результатов выполненной ОКР;

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

ГОСТ 15.016-2016

6.1.14 В приложения кТЗ на ОКР могут быть включены отчет о патентных исследованиях*, перечень стандартов, используемых при создании изделия, справочные материалы, ограничения по использованию специальных материалов, КИМП и других покупных изделий, а также материалы, необходимые для разработки изделия (чертежи, схемы, расчеты).

6.2 Требования к оформлению ТЗ на ОКР

6.2.1    ТЗ на ОКР должно быть оформлено в соответствии с общими требованиями к текстовым документам по ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301, без рамки, основной надписи и дополнительных граф к ней.

Схемы, чертежи и таблицы допускается выполнять на листах форматов А4, АЗ, А2. Номера листов (страниц) следует проставлять в правом верхнем углу листа (над текстом).

6.2.2    Титульный лист ТЗ на ОКР оформляют в соответствии с требованиями ГОСТ2.105 по форме, приведенной в приложении А (форма 1).

Регистрационный номер проставляет головной исполнитель (исполнитель) ОКР.

6.2.3    На последнем листе ТЗ на ОКР после основного текста документа помещают подписи разработчиков ТЗ на ОКР и согласующие подписи других организаций (предприятий), предусмотренных в 6.3. Форма последнего листа ТЗ на ОКР приведена в приложении А (форма 2).

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

6.2.4    По решению заказчика ТЗ на ОКР допускается составлять в двух и более частях исходя из удобства пользования, области применения и других причин. Наиболее важные сведения и характеристики изделия можно группировать в одну из частей ТЗ или оформлять в виде отдельного приложения кТЗ.

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

Во вторую и последующие части может быть включено содержание любого раздела (разделов) ТЗ на ОКР полностью или частично. Во вводной части второй и последующих частей ТЗ на ОКР указывают назначение каждой части и регламентируемые в ней требования.

6.2.5    Титульный лист второй и последующих частей ТЗ на ОКР оформляют по форме 3 приложения А.

Подписи разработчиков частей ТЗ на ОКР и согласующие подписи, предусмотренные в 6.3, располагают на последнем листе соответствующей части ТЗ в соответствии с формой 2 приложения А.

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

6.2.7    После утверждения ТЗ на ОКР ответственное лицо заказчика заверяет титульные листы второй и последующих частей ТЗ на ОКР под рубрикой «Утверждено заказчиком. Верно» в соответствии с формой 3 приложения А.

6.3    Порядок согласования и утверждения ТЗ на ОКР

6.3.1    Согласование ТЗ на ОКР с заинтересованными организациями (предприятиями), как правило, осуществляет разработчик. Утверждает ТЗ заказчик, а в случае инициативной разработки — разработчик.

6.3.2    ТЗ на ОКР должно быть согласовано:

–    с головным исполнителем (исполнителем) ОКР (этапа ОКР);

–    с исполнителем СЧ ОКР — по решению заказчика;

–    с другими организациями (предприятиями) — по решению заказчика.

6.4    Порядок внесения изменений в утвержденное ТЗ на ОКР

6.4.1 Изменения в утвержденное ТЗ на ОКР, необходимость внесения которых выявлена в процессе выполнения ОКР, оформляют выпуском дополнения. Дополнение кТЗ на ОКР разрабатывают, согласовывают и утверждают в том же порядке и на том же уровне, что и основной документ.

* Отчет о патентных исследованиях, включаемый в приложения кТЗ на ОКР, может быть подготовлен НИО заказчика при разработке ТЗ, головным исполнителем (исполнителем) в процессе выполнения НИР, технических предложений, предшествующих данной ОКР (с дополнениями НИО заказчика, если они необходимы), или другой организацией (предприятием) по поручению (заданию) заказчика.

15

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

6.4.2    Дополнение к ТЗ на ОКР должно состоять из вводной части, в которой указывают причину выпуска дополнения и изменяемых разделов, указанных в 6.1.1.

В изменяемых разделах дополнения под соответствующими рубриками («имеется», «должно быть») приводят номера и содержание изменяемых и новых пунктов ТЗ на ОКР или номера и содержание отменяемых пунктов.

Допускается в дополнении приводить все пункты ТЗ с сохранением их нумерации.

6.4.3    Титульный лист дополнения кТЗ на ОКР оформляют по правилам, установленным в 6.2.2. При этом под наименованием документа указывают:

«Дополнение_».

номер дополнения

Если ТЗ на ОКР состоит из нескольких частей, то на титульном листе указывают также номер части, в которой оформляют дополнение:

«Дополнение_к    части_».

номер дополнения    номер части

6.4.4    После выпуска дополнения на титульном листе ТЗ на ОКР под наименованием документа делают отметку:

«Действует с дополнением_».

номер дополнения

6.4.5    При внесении изменений в утвержденное ТЗ на ОКР сроки выполнения работ по этапам подлежат пересмотру только в том случае, если приходится переделывать уже выполненную часть работ или изменять объем работ.

7 ТЗ на составную часть ОКР

7.1    Требования к построению, содержанию, изложению и оформлению ТЗ на составную

часть ОКР

7.1.1    Построение и изложение ТЗ на СЧ ОКР должны соответствовать требованиям, установленным в 6.1. Содержание разделов и подразделов ТЗ определяет головной исполнитель ОКР.

7.1.2    Требования ТЗ на СЧ ОКР должны обеспечивать выполнение требований ТЗ на ОКР, в которую она входит, и учитывать специфические условия применения СЧ в изделии в целом.

Сроки выполнения этапов СЧ ОКР и СЧ ОКР в целом (если они не указаны в ТЗ на ОКР) необходимо устанавливать применительно к срокам выполнения ОКР.

7.1.3    ТЗ на СЧ ОКР должно быть оформлено в соответствии с требованиями, изложенными в 6.2.1—6.2.3, за исключением расположения утверждающих и согласующих подписей.

Форма титульного листа ТЗ на СЧ ОКР приведена в приложении А (форма 4).

На последнем листе ТЗ на СЧ ОКР после основного текста помещают подписи разработчиков ТЗ и согласующие подписи других организаций (предприятий), предусмотренных в 7.2 (аналогично форме 2 приложения А).

7.2 Порядок согласования и утверждения ТЗ на составную часть ОКР

7.2.1    ТЗ на СЧ ОКР согласовывает с другими организациями (предприятиями) и утверждает головной исполнитель ОКР.

7.2.2    ТЗ на СЧ ОКР должно быть согласовано:

–    с заказчиком либо, по его решению, с НИО заказчика;

–    с исполнителем СЧ ОКР;

–    с другими организациями (предприятиями) по решению заказчика или по решению головного исполнителя ОКР, согласованному с заказчиком.

Исполнитель СЧ ОКР по согласованию с головным исполнителем ОКР привлекает при согласовании ТЗ на СЧ ОКР предприятие (организацию), допущенную для проведения экспертизы в соответствии с требованиями, изложенными в 6.1.6.1.

7.2.3    Уровень должностных лиц заказчика, согласующих ТЗ наСЧ ОКР (заказчик, НИО заказчика), устанавливает заказчикпри согласовании головным исполнителем ОКР с заказчиком «Перечня СЧ ОКР, на которые должны быть выданы ТЗ их исполнителям». В отдельных случаях необходимость согласования ТЗ на СЧ ОКР с заказчиком указывается непосредственно в ТЗ на ОКР.

ТЗ на разработку учебно-тренировочных средств должны согласовываться с заказчиком.

ГОСТ 15.016-2016

ТЗ на СЧ ОКР представляют на согласование заказчику после его согласования со всеми заинтересованными предприятиями (организациями).

7.2.4    ТЗ на СЧ ОКР должно быть подписано должностными лицами организаций (предприятий), указанных в 7.2.1, под рубрикой «Согласовано»:

на титульном листе — в соответствии с приложением А (форма 4);

на последнем листе — после подписей разработчиков ТЗ на СЧ ОКР — должностными лицами других согласующих организаций (предприятий) и служб.

Согласование ТЗ на СЧ ОКР может быть оформлено отдельным документом (письмом, протоколом). В этом случае в ТЗ под рубрикой «Согласовано» делают ссылку на этот документ.

7.2.5    Срок рассмотрения и согласования проекта ТЗ на СЧ ОКР не должен превышать 15 рабочих дней с момента его получения.

7.2.6    Разногласия, возникшие между головным исполнителем ОКР и согласующими организациями (предприятиями) при согласовании ТЗ на СЧ ОКР, разрешают совместным решением не позднее 10 рабочих дней после его получения.

7.2.7    Утвержденное ТЗ на СЧ ОКР должно быть выдано головным исполнителем ОКР исполнителю СЧ ОКР не позднее, чем за месяц до начала выполнения по СЧ ОКР.

7.3 Порядок внесения изменений в утвержденное ТЗ на составную часть ОКР

7.3.1    Изменения в утвержденное ТЗ на СЧ ОКР, необходимость внесения которых выявлена в процессе выполнения ОКР, оформляют выпуском дополнения. Дополнение кТЗ на СЧ ОКР разрабатывают, согласовывают и утверждают в том же порядке и на том же уровне, что и основной документ.

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

7.3.2    Правила оформления дополнения к утвержденному ТЗ на СЧ ОКР аналогичны изложенным

в 6.4.

7.3.3    Учет и обращение ТЗ на СЧ ОКР производят в порядке, установленном головным исполнителем ОКР по согласованию с заказчиком.

8 ТЗ на ОКР по разработке КИМП

8.1    Требования к построению, содержанию, изложению и оформлению ТЗ на ОКР

по разработке КИМП

8.1.1    Построение и содержание ТЗ на ОКР по разработке КИМП должно соответствовать требованиям, установленным в 6.1, с учетом специфики и особенностей создаваемого изделия, необходимых уточнений наименования отдельных разделов и подразделов, предусмотренных в настоящем разделе.

Допускается в зависимости от особенностей КИМП исключать отдельные разделы и подразделы, а также уточнять их содержание.

8.1.2    В разделе «Наименование, шифр ОКР и основание для выполнения ОКР» указывают наименование, шифр ОКР и полное наименование документа, на основании которого должна выполняться ОКР, дату утверждения.

8.1.3    В разделе «Цель выполнения ОКР и наименование изделия» указывают цель выполнения ОКР, функциональное назначение и наименование разрабатываемого изделия, его перспективность, краткую характеристику области применения и ожидаемый технический уровень разрабатываемого изделия.

В разделе при необходимости указывают, какие выпускаемые изделия могут быть заменены вновь разрабатываемым изделием.

8.1.4    Раздел «Технические требования к изделию»

8.1.4.1    Подраздел «Состав изделия» предусматривают при необходимости.

8.1.4.2    В подразделе «Требования назначения» устанавливают параметры изделия и их нормы, режимы измерений, а также предельные значения допускаемых режимов эксплуатации.

8.1.4.3    Подраздел «Требования электромагнитной совместимости» предусматривают при необходимости.

8.1.4.4    В подразделе «Требования живучести и стойкости к внешним воздействиям» устанавливают требования к механическим, климатическим и специальным воздействиям.

Характеристики внешних воздействующих факторов задают в соответствии с требованиями ГОСТ 21964 и стандартов на КИМП конкретных групп (видов).

При необходимости характеристики внешних воздействующих факторов конкретизируют с учетом особенностей эксплуатации и применения разрабатываемого изделия.

17

ГОСТ 15.016-2016

Содержание

1    Область применения……………………………………………1

2    Нормативные ссылки…………………………………………..1

3    Термины и определения…………………………………………2

4    Сокращения………………………………………………..3

5    Общие положения…………………………………………….3

6    Требования к построению, содержанию и изложению ТЗ……………………….4

6.1    ТЗ на ОКР……………………………………………….4

6.2    Требования к оформлению ТЗ на ОКР………………………………15

6.3    Порядок согласования и утверждения ТЗ на ОКР………………………..15

6.4    Порядок внесения изменений в утвержденное ТЗ на ОКР……………………15

7 ТЗ на составную часть ОКР……………………………………….16

7.1    Требования к построению, содержанию, изложению и оформлению ТЗ на составную часть

ОКР…………………………………………………16

7.2    Порядок согласования и утверждения ТЗ на составную часть ОКР………………16

7.3 Порядок внесения изменений в утвержденное ТЗ на составную часть ОКР………….17

8    ТЗ на ОКР по разработке КИМП…………………………………….17

8.1    Требования к построению, содержанию, изложению и оформлению ТЗ на ОКР по разработке

КИМП………………………………………………..17

8.2    Порядок согласования и утверждения ТЗ на ОКР по разработке КИМП……………18

8.3 Порядок внесения изменений в утвержденное ТЗ на ОКР по разработке КИМП………19

9    ТЗ на НИР, ТПр, ЭП, ТП и другие виды работ……………………………..19

Приложение А (рекомендуемое) Типовые формы титульных листов (последнего листа) ТЗ на ОКР

и на составную часть ОКР………………………………..20

8.1.4.5    В подразделе «Требования надежности» устанавливают показатели надежности, номенклатуру и их конкретные значения, которые должны соответствовать требованиям стандартов на КИМП конкретных групп (видов).

8.1.4.6    Подразделы «Требования эргономики, обитаемости и технической эстетике» и «Требования к эксплуатации, хранению, удобству технического обслуживания и ремонта» предусматривают при необходимости.

8.1.4.7    В подразделе «Транспортирование» указывают вид транспортных средств, необходимость и способы крепления при перевозке, климатические условия при перевозке, специальные требования к изделию при перевозке (защита от ударов при погрузке и выгрузке и т. п.).

8.1.4.8    Подраздел «Требования безопасности» предусматривают при необходимости.

8.1.4.9    В подразделе «Требования стандартизации, унификации и каталогизации» устанавливают количественные и качественные показатели по стандартизации и унификации изделия, порядок и правила выполнения работ по каталогизации изделия.

8.1.4.10    В подразделе «Требования технологичности» устанавливают показатели производственной технологичности.

8.1.4.11    В подразделе «Конструктивные требования» устанавливают требования к габаритным, установочным и присоединительным размерам изделия, способам его крепления, конструктивному оформлению, массе, климатическому исполнению и т. п.

8.1.5    В разделе «Технико-экономические требования» устанавливают лимитную стоимость ОКР, ориентировочную годовую потребность изделий (поданным заказчика) после окончания ОКР и ихориен-тировочную цену.

8.1.6    Раздел «Требования к видам обеспечения» предусматривают при необходимости.

8.1.7    Раздел «Требования к сырью, материалам и КИМП» предусматривают при необходимости.

8.1.8    В разделе «Требования к консервации, упаковке и маркировке» устанавливают требования к консервации, упаковке изделия, вариантам упаковки в зависимости от условий хранения и транспортирования, а также требования к маркировке, наносимой на изделие (место нанесения, требования к содержанию и качеству маркировки).

8.1.9    Разделы «Требования к учебно-тренировочным средствам» и «Специальные требования» предусматривают при необходимости.

8.1.10    В разделе «Этапы выполнения ОКР» указывают перечень работ, выполняемых на этапах ОКР, установленных с учетом изложенных в 6.1.12, в том числе:

–    наименование обязательных этапов ОКР и при необходимости конкретный объем работ по этапам ОКР;

–    сроки выполнения этапов (если они не установлены в договорных документах).

8.1.11    В разделе «Порядок выполнения и приемки ОКР» с учетом порядка, изложенного в 6.1.13, указывают:

–    порядок приемки ОКР;

–    состав документации, предъявляемой к приемке;

–    исполнителей ОКР — головного исполнителя и соисполнителей ОКР (при их наличии), в том числе предприятие, на котором изготавливают опытные образцы изделия и предприятие, на котором проводят испытания;

предполагаемые предприятия — изготовители серийных изделий (при необходимости).

8.1.12    В приложениях к ТЗ приводят карту технического уровня, отчет о патентных исследованиях, перечень НД, использованных при выполнении ОКР по разработке КИМП, а также (при необходимости) таблицы, графики, схемы, расчеты, перечень справочно-информационных и других технических материалов и документов, необходимых для выполнения ОКР.

8.1.13    ТЗ на ОКР должно быть оформлено в соответствии с общими требованиями к текстовым документам, установленным в ГОСТ 2.105, на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней. Номера листов (страниц) проставляют в правом верхнем углу листа (над текстом).

Форма титульного листа ТЗ на ОКР приведена в приложении А (форма 5). На последнем листе (странице) ТЗ после основного текста помещают подпись исполнителя ОКР.

8.2 Порядок согласования и утверждения ТЗ на ОКР по разработке КИМП

8.2.1    ТЗ на ОКР по разработке КИМП утверждает заказчик ОКР.

8.2.2    ТЗ на ОКР должно быть согласовано:

–    с головным исполнителем (исполнителем) ОКР;

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Система разработки и постановки продукции на производство

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Требования к содержанию и оформлению

System of products development and launching into manufacture. Technical assignment. Requirements to contents and form of presentation

Дата введения —2017—09—01

1    Область применения

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

2    Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:

ГОСТ 2.001-2013 Единая система конструкторской документации. Общие положения ГОСТ 2.102-2013 Единая система конструкторской документации. Виды и комплектность конструкторских документов

ГОСТ 2.103-2013 Единая система конструкторской документации. Стадии разработки ГОСТ 2.105-95 Единая система конструкторской документации. Общие требования к текстовым документам

ГОСТ 2.116-84 Карта технического уровня и качества продукции

ГОСТ 2.118-2013 Единая система конструкторской документации. Техническое предложение ГОСТ 2.119-2013 Единая система конструкторской документации. Эскизный проект ГОСТ 2.120-2013 Единая система конструкторской документации. Технический проект ГОСТ 2.301-68 Единая система конструкторской документации. Форматы ГОСТ2.601—2013 Единая система конструкторской документации. Эксплуатационные документы ГОСТ 3.1001-2011 Единая система технологической документации. Общие положения ГОСТ 3.1102-2011 Единая система технологической документации. Стадии разработки и виды документов. Общие положения

ГОСТ 14.201-83 Обеспечение технологичности конструкции изделий. Общие требования ГОСТ 15.012-84 Система разработки и постановки продукции на производство. Патентный формуляр

ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

ГОСТ 27.003-90 Надежность в технике. Состав и общие правила задания требований по надежности

ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

ГОСТ 16504-81 Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения

Издание официальное

ГОСТ 19433-88 Грузы опасные. Классификация и маркировка

ГОСТ 21964-76 Внешние воздействующие факторы. Номенклатура и характеристики

ГОСТ 28934-91 Совместимость технических средств электромагнитная. Содержание раздела технического задания в части электромагнитной совместимости

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если ссылочный стандарт заменен (изменен), то при пользовании настоящим стандартом следует руководствоваться заменяющим (измененным) стандартом. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1    техническое задание (ТЗ): Исходный технический документ для проведения работы, устанавливающий требования к создаваемому изделию (его СЧ или КИМП) и технической документации на него, а также требования кобъему, срокам проведения работы и форме представления результатов.

3.2    заказчик: Предприятие (организация, объединение или другой субъект хозяйственной деятельности), по заявке или договору с которым производится разработка (модернизация), производство и (или) поставка продукции, в том числе научно-технической.

3.3    разработчик: Предприятие (организация, объединение, юридическое или физическое лицо), осуществляющее разработку продукции в установленном порядке.

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

3.5    радиоэлектронные средства: Технические средства, предназначенные для передачи и (или) приема радиоволн, состоящие из одного или нескольких передающих и (или) приемных устройств либо комбинации таких устройств и включающие в себя вспомогательное оборудование.

3.6

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

[ГОСТ 27.002-89, пояснение к термину «Надежность»]_

3.7    эскизный проект (ЭП): Вид проектной конструкторской документации на изделие, содержащей принципиальные конструкторские решения, дающие общее представление о конструкции и принципе работы изделия, а также данные, определяющие его соответствие назначению.

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

3.9

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

[ГОСТ 2.103-2013, пункт 4.10]_

3.10 рабочая конструкторская документация (РКД): Совокупность конструкторских документов, предназначенных для изготовления, контроля, приемки, поставки, эксплуатации и ремонта изделия.

ГОСТ 15.016-2016

3.11 головной исполнитель: Предприятие (организация, объединение), выполняющее работу по созданию изделия (комплекса, системы), координирующее деятельность исполнителей составных частей этой работы и отвечающее за выполнение работы в целом.

4 Сокращения

В настоящем стандарте применены следующие сокращения:

ЕСКД — единая система конструкторской документации;

ЕСПД — единая система программной документации;

ЗИП — запасной инструмент и принадлежности;

КД — конструкторские документы (документация);

КИМП — комплектующие изделия межотраслевого применения;

МГС — Межгосударственный совет по стандартизации, метрологии и сертификации;

НД — нормативные документы;

НИО — научно-исследовательская организация;

НИР — научно-исследовательская работа;

ОКР — опытно-конструкторская работа;

ОНТД — отчетная научно-техническая документация;

ОС — окружающая среда;

РКД — рабочая конструкторская документация;

СИ — средства измерений;

СЧ — составная часть;

ТД — техническая документация;

ТЗ — техническое задание;

ТП — технический проект;

ТПр — техническое предложение;

ЭД — эксплуатационная документация;

ЭВТ — электронно-вычислительная техника;

ЭП — эскизный проект;

ЭРИ — электрорадиоизделия.

5 Общие положения

5.1    ТЗ является неотъемлемой частью контракта (договора), заключаемого между заказчиком работы (далее — заказчик), головным исполнителем, исполнителями СЧ работы, исполнителями работ по разработке КИМП.

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

5.2    Утверждает ТЗ заказчик. Разработку и согласование ТЗ осуществляет заказчик или разработчик, исходя из статуса заказчика, источника финансирования и условий рынка сбыта.

Разработку, согласование и утверждение ТЗ в случае инициативной разработки осуществляет разработчик в установленном у него порядке.

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

5.3    Согласованное и утвержденное ТЗ является обязательным документом для организаций заказчика, головного исполнителя (исполнителя) работы (СЧ работы, работ по разработке КИМП).

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

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

5.5    При необходимости может проводиться метрологическая экспертиза ТЗ.

3

5.6 ТЗ обозначается как приложение к контракту (договору). Его учет (регистрация), хранение, изменение и передача осуществляются в качестве составной части контракта.

6 Требования к построению, содержанию и изложению ТЗ

6.1    ТЗнаОКР

6.1.1    В ТЗ на ОКР рекомендуется предусматривать учет интересов всех возможных потребителей.

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

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

В ТЗ на ОКР рекомендуется предусматривать следующие положения:

–    оценку технического уровня и качества продукции на основе одноименной карты по ГОСТ 2.116;

–    прогноз развития требований на данную продукцию на предполагаемый период ее выпуска;

–    рекомендуемые этапы модернизации (модифицирования) продукции с учетом прогноза развития требований;

–    соответствие требованиям стран предполагаемого экспорта с учетом прогноза развития этих требований;

–    безопасность и доступность эффективного использования продукции инвалидами и гражданами пожилого возраста (для соответствующей продукции, предусмотренной законодательством государств — участников МГС);

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

ТЗ на ОКР может состоять из разделов, располагаемых в следующем порядке:

–    наименование, шифр ОКР, основание, исполнитель и сроки выполнения ОКР;

–    цель выполнения ОКР, наименование и обозначение изделия;

–    технические требования к изделию;

–    технико-экономические требования;

–    требования к видам обеспечения;

–    требования к сырью, материалам и КИМП;

–    требования к консервации, упаковке и маркировке;

–    требования кучебно-тренировочным средствам (при необходимости);

–    специальные требования;

–    требования кдокументации;

–    этапы выполнения ОКР;

–    порядок выполнения и приемки этапов ОКР.

ТЗ на ОКР может быть дополнено приложениями.

В зависимости от особенностей разрабатываемого (модернизируемого) изделия, условий его применения и эксплуатации допускается вводить в ТЗ на ОКР другие разделы или исключать разделы, в которых нет необходимости.

Конкретное количество, содержание разделов и подразделов ТЗ на ОКР определяет заказчик на основе требований настоящего стандарта с учетом специфики и особенностей создаваемого изделия, условий его применения и эксплуатации.

При необходимости уточнения отдельных требований ТЗ в процессе выполнения ОКР должен быть указан этап ОКР, на котором эти требования уточняют.

6.1.2    В разделе «Наименование, шифр ОКР, основание, исполнитель и сроки выполнения ОКР» указывают наименование, шифр ОКР и полное наименование документа (документов), на основании которого (которых) должна выполняться ОКР, номер и дату его (их) утверждения, исполнителя и сроки выполнения ОКР.

ОКР и СЧ ОКР присваивают одинаковые шифры, которые сохраняют до окончания ОКР или ее прекращения. Для СЧ ОКР при необходимости устанавливают дополнительные (добавочные) шифры.

6.1.3    В разделе «Цель выполнения ОКР, наименование и обозначение изделия» указывают цель выполнения ОКР (устанавливают подлежащие достижению обобщенные результаты выполнения ОКР), полное наименование, обозначение (если имеется), назначение и область применения создаваемого (модернизируемого) изделия, а при необходимости и место создаваемого изделия в системе.

4

ГОСТ 15.016-2016

В том случае, если разрабатывается многоцелевое изделие, указывают его основное назначение и решаемые задачи, а также предполагаемые варианты применения изделия.

При необходимости в разделе приводят информацию о том, что данное изделие создается:

–    в качестве базового с модификациями (комплектациями);

–    взамен ранее созданных изделий (отражая преимущества разрабатываемых изделий перед аналогом) или указывают на отсутствие аналога.

В разделе также могут быть указаны (при их наличии) научно-технические достижения и изобретения, на основе которых ведется разработка изделия и обеспечивается функционирование его основных СЧ.

6.1.4 В разделе «Технические требования к изделию» указывают требования, характеристики, нормы, показатели и другие параметры, определяющие назначение, эксплуатационные характеристики, условия эксплуатации и применения изделия. Раздел может состоять из следующих подразделов:

–    состав изделия;

–    требования назначения;

–    требования электромагнитной совместимости (для радиоэлектронных средств);

–    требования живучести и стойкости к внешним воздействиям;

–    требования надежности;

–    требования эргономики, обитаемости и технической эстетики;

–    требования к эксплуатации, хранению, удобству технического обслуживания и ремонта;

–    транспортирование;

–    требования безопасности;

–    требования стандартизации, унификации и каталогизации;

–    требования технологичности;

–    конструктивные требования.

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

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

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

6.1.4.1    В подразделе «Состав изделия» перечисляют основные СЧ изделия или приводят требования к составу изделия, а также указывают (при необходимости) назначение СЧ.

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

Допускается окончательно определять состав изделия при выполнении этапа разработки эскизного (технического) проекта.

6.1.4.2    В подразделе «Требования назначения» устанавливают:

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

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

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

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

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

5

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

6.1.4.3    В подразделе «Конструктивные требования» устанавливают совокупность требований к конструкции создаваемого изделия, соблюдение которых обеспечивает соответствие изделия его целевому назначению и заданному уровню качества в процессе создания, производства и эксплуатации, и указывают:

–    основные конструктивные требования к изделию и его СЧ (габаритные, установочные и присоединительные размеры; способ крепления; запасы регулировки управления);

–    требования конструктивной приспособленности изделия к консервации;

–    вид исполнения (контейнерное, блочное, моноблочное и др.);

–    требования к конструктивному оформлению изделия, к разработке его в качестве базового и приспособленности конструкции изделия к дальнейшей модернизации;

–    требования комплексной миниатюризации радиоэлектронной аппаратуры изделия;

–    требования к порядку заимствования ранее разработанных СЧ изделия и использования СЧ и КИМП, включенных в каталог продукции согласно национальному законодательству государств — участников МГС в этой области;

–    массу изделия (при необходимости) и ограничения по массе отдельных или изымаемых СЧ изделия;

–    требования приспособленности конструкции изделия к контролю технических характеристик в процессе производства и эксплуатации.

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

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

Содержание требований подраздела по электромагнитной совместимости устанавливают с учетом требований ГОСТ 28934.

6.1.4.5    В подразделе «Требования живучести и стойкости к внешним воздействиям» устанавливают требования, обеспечивающие способность изделия выполнять свои функции в условиях влияния ОС, сопрягаемых и других объектов, а также при возможных повреждениях и в аварийных ситуациях. Номенклатуру, характеристики внешних воздействующих факторов и содержание требований по стойкости устанавливают с учетом требований ГОСТ 21964. В подразделе в зависимости от вида и назначения изделия устанавливают требования в части:

–    восстановления и поддержания работоспособности изделия после эксплуатационного повреждения;

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

–    стойкости к воздействию механических нагрузок (вибрационных, ударных, скручивающих, ветровых и др.);

–    износостойкости (в том числе к абразивному действию песка и пыли, к воздействию снега, обледенения и др.);

–    устойчивости к влиянию внешних физических полей (магнитного, электрического);

–    устойчивости к моющим средствам, топливу, маслам, биологическим факторам;

–    схемного, конструктивного, производственно-технологического и эксплуатационного обеспечения живучести.

6.1.4.6    В подразделе «Требования надежности» в соответствии с порядком и правилами, регламентированными ГОСТ 27.003, устанавливают:

–    номенклатуру и значения показателей надежности;

–    критерии отказов [или конкретное выражение (значение) «выходного эффекта» для изделий, требования надежности к которым установлены с использованием показателя «коэффициент сохранения эффективности»] и предельных состояний, применительно к которым устанавливают показатели надежности;

6

ГОСТ 15.016-2016

–    количественные значения показателей назначенного ресурса, срока службы, срока хранения (включают при необходимости);

–    требования к конструктивным, производственным и эксплуатационным способам обеспечения надежности в заданных условиях и режимах эксплуатации;

–    требования надежности математического и других видов обеспечения, в том числе метрологической надежности СИ (включают при необходимости);

–    общие требования к методам оценки (контроля) соответствия изделия заданным требованиям надежности на различных этапах жизненного цикла;

–    количество изделий, выделяемыхдля испытаний на надежность, и указание отом, с какими испытаниями можно совмещать испытания на надежность;

–    необходимость разработки методик ускоренных испытаний на надежность и требования к ним.

6.1.4.7    В подразделе «Требования эргономики, обитаемости и технической эстетики»* устанавливают:

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

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

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

6.1.4.8    В подразделе «Требования к эксплуатации, хранению, удобству технического обслуживания и ремонта» устанавливают требования:

–    к рабочим и предельным условиям эксплуатации, во время и после которых изделие не должно разрушаться, сохраняя свои параметры в пределах установленных норм с заданным уровнем отклонения величин;

–    кэксплуатационным режимам;

–    к продолжительности непрерывной или циклической работы;

–    к эксплуатации изделия в аварийных ситуациях;

–    к системе средств эксплуатационного (объективного) контроля;

–    к численности, составу и квалификации обслуживающего персонала;

–    к информационно-справочной системе по эксплуатации, техническому обслуживанию и ремонту изделия;

–    к видам (календарное, по ресурсу, по техническому состоянию), периодичности и объему технического обслуживания, контролю технического состояния и ремонта;

–    кудобству ремонта изделия в условиях ремонтных предприятий (органов) и в эксплуатационных условиях;

–    кудобству сборки и разборки изделия при техническом обслуживании и ремонте;

–    к доступности к отдельным СЧ изделия для технического обслуживания и ремонта без демонтажа других СЧ;

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

–    к составу инструментов, СИ и приспособлений для проведения технического обслуживания и ремонта, сборки и разборки изделия;

–    кобеспечению и степени автоматизации дистанционного контроля технического состояния изделия (при необходимости);

–    к видам и составу комплектов ЗИП, а также к нормам расхода запасных частей;

–    к условиям хранения на открытых площадках, под навесами, в хранилищах, в составе законсервированного объекта;

Для отдельных изделий требования обитаемости могут быть заданы самостоятельным подразделом.

7

1

При необходимости из общих затрат могут быть выделены и приведены в ТЗ затраты на отдельные составляющие ОКР (затраты на нормативно-техническое обеспечение, обеспечение испытаний опытных образцов изделий, проведение метрологической экспертизы), которые обосновываются стороной [заказчиком или головным исполнителем (исполнителем) ОКР], предлагающей выделение затрат.

2

Часть из указанных работ может выполняться в рамках НИР или ТПр, предшествующих данной ОКР.

3

Для выдачи заключения о целесообразности создания новых изделий исполнитель СЧ ОКР (по согласованию с головным исполнителем ОКР) привлекает организацию (предприятие), за которой закреплена соответствующая номенклатура, и (или) центр каталогизации заказчика.

4

Требования к указанным показателям также задают в подразделе «Требования к метрологическому обеспечению» применительно к измерительному контролю технического состояния изделия.

11