Что включают в себя технические требования

Что включают в себя технические требования

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

6 ПЕРЕИЗДАНИЕ. Декабрь 2018 г.

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

Настоящий стандарт распространяется на изделия машиностроения и приборостроения всех отраслей промышленности, изготавливаемые и применяемые по конструкторской документации, выполняемой в соответствии с требованиями Единой системы конструкторской документации.

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

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

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

ГОСТ 2.051-2013 Единая система конструкторской документации. Электронные документы. Общие положения

ГОСТ 2.058-2016 Единая система конструкторской документации. Правила выполнения реквизитной части электронных конструкторских документов

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

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

ГОСТ 2.104-2006 Единая система конструкторской документации. Основные надписи

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

ГОСТ 2.106-96 Единая система конструкторской документации. Текстовые документы

ГОСТ 2.113-75 Единая система конструкторской документации. Групповые и базовые конструкторские документы

ГОСТ 2.201-80 Единая система конструкторской документации. Обозначение изделий и конструкторских документов

ГОСТ 2.301-68 Единая система конструкторской документации. Форматы

ГОСТ 2.501-2013 Единая система конструкторской документации. Правила учета и хранения

ГОСТ 2.503-2013 Единая система конструкторской документации. Правила внесения изменений

ГОСТ 2.511-2011 Единая система конструкторской документации. Правила передачи электронных конструкторских документов. Общие положения

ГОСТ 2.512-2011 Единая система конструкторской документации. Правила выполнения пакета данных для передачи электронных конструкторских документов. Общие положения

ГОСТ 15.000-82 Система разработки и постановки продукции на производство. Общие положения*

* В Российской Федерации действует ГОСТ Р 15.000-2016.

ОК 012-93 Общероссийский классификатор изделий и конструкторских документов (Классификатор ЕСКД) (ОКЕСКД)

3 Термины, определения и сокращения

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

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

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

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

2 Число изделий может измеряться в штуках (экземплярах).

3 К изделиям допускается относить завершенные и незавершенные предметы производства, в том числе заготовки.

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

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

3.2 Сокращения

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

4 Основные положения

4.1 ТУ в соответствии с ГОСТ 2.102 являются КД, содержащим требования (совокупность всех показателей, норм, правил и положений) к изделию, его изготовлению, контролю, приемке и поставке, которые нецелесообразно указывать в других КД.

ТУ разрабатываются по решению разработчика, заказчика, если это не отражено в ТЗ на ОКР.

ТУ разрабатываются в составе комплекта КД и являются неотъемлемой частью комплекта КД на изделие.

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

4.3 ТУ следует разрабатывать:

— на одно конкретное изделие;

— на несколько однотипных изделий (групповое ТУ) в соответствии с требованиями ГОСТ 2.113.

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

Источник

Как составить техническое задание и получить то, что нужно

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

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

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

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

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

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

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

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

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

Устоявшейся практики нет — как договоритесь с подрядчиком.

Заказчик делает сам

Например, гендиректор студии архитектурной фотографии «АрхФото» Анатолий Шостак называет идеальным заказом ситуацию, когда заказчик сразу присылает подробное ТЗ и просит оценить работы.

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

Анатолий Шостак
Гендиректор «АрхФото»

Совместная работа

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

Техзадание полностью делает исполнитель

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

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

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

Сколько стоит заказать ТЗ

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

Основатель компании по разработке информационных систем Work Solutions Максим Мул при заказе ТЗ рекомендует ориентироваться на 10-20 % от общей стоимости разработки продукта.

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

Максим Мул
Основатель Work Solutions

Если речь про IT-задачи, например, интеграцию между информационными системами, внедрение CRM, разработку дополнительного функционала ПО или приложения по API, то не стоит рассчитывать на ТЗ стоимостью меньше 50 000 руб., считает гендиректор компании «Информатика и Сервис» Владимир Севрук.

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

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

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

У нас есть более сложная форма ТЗ — мы называем ее «сценарий». Для сценария мы проводим предварительные съемки, прописываем и согласовываем все ракурсы с заказчиком, прорабатываем целевую аудиторию и рассчитываем тайминг каждого кадра с учетом движения солнца. И все это ещё до начала чистовой работы.

Анатолий Шостак
Гендиректор «АрхФото»

За составление такого подробного сценария в «АрхФото» берут деньги. В зависимости от сложности проекта и требований заказчика сценарий иногда стоит дороже самой съемки. Зато благодаря ТЗ заказчик еще до начала работ понимает, что получит в итоге, говорит Анатолий Шостак.

Как написать техническое задание

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

Пишите однозначно

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

Хороший подрядчик будет конкретизировать и уточнять неоднозначные строчки в ТЗ, но это потребует дополнительного времени на переделку. Поэтому лучше стараться минимизировать недопонимание. И постараться определить для себя конкретные требования к продукту еще до разговора с исполнителем.

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

Алексей Орлов
Руководитель проектов компании «Рексофт»

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

Дайте подрядчику общую информацию

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

Гендиректор INOSTUDIO Максим Болотов рекомендует как минимум озвучить подрядчику идею проекта, который вы заказываете, уточнить, в чем его конкурентные преимущества и уникальность.

Расскажите подрядчику, какие задачи будет решать IT-решение. Это может быть увеличение прибыли, повышение узнаваемости бренда, лояльности пользователей. Уточните, кто будет пользователями продукта, их социальные и поведенческие характеристики, например, пол, возраст, интересы, семейное положение, потребности — это нужно, чтобы корректно и эффективно сформулировать функциональные требования к продукту.

Максим Болотов
Гендиректор INOSTUDIO

Помогите разобраться в терминах и нюансах

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

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

Покажите конкурентов

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

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

Максим Болотов
Гендиректор INOSTUDIO

Уточните важные технические требования

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

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

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

Распишите сценарии использования продукта

Если вы делаете что-то стандартное, то так сильно погружаться в особенности продукта не стоит, это лишь запутает и добавит ТЗ многословности. Но в случае чего-то необычного попробуйте в техзадании отвечать не на вопрос «Что?», а на вопрос «Как будет делать пользователь?».

Если речь про IT-продукты, можно прописывать сценарии по такому шаблону:

Опишите требования к проверке проекта

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

Например, для интернет-магазина это может быть:

Чем подробнее и длиннее чек-лист, тем лучше.

Двигайтесь от общего к частному

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

Шаблоны и примеры ТЗ

Универсального шаблона технического задания нет — требования будут отличаться в зависимости от отрасли и типа проекта.

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

Если планируете заказать IT-продукт, можно использовать за основу госстандарты. Например:

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

Когда ТЗ не нужно

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

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

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

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

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

Кратко — универсальные советы по составлению ТЗ

Составляя ТЗ самостоятельно или с подрядчиком, придерживайтесь следующих правил:

Не пропустите новые публикации

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

Источник

Термин: Технические требования

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

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

Обозначим далее минимально необходимые ТТ на систему (изделие):

При составлении ТТ Вам может помочь раздел Терминология на этом сайте.

Источник

Что включают в себя технические требования

Единая система конструкторской документации

Unified system for design documentation. Specifications

____________________________________________________________________
Текст Сравнения ГОСТ 2.114-95 с ГОСТ 2.114-2016 см. по ссылке.
— Примечание изготовителя базы данных.
____________________________________________________________________

Дата введения 1996-07-01

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

ВНЕСЕН Госстандартом Российской Федерации

2 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол N 7 от 26 апреля 1995 г.)

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

Наименование национального органа по стандартизации

Госстандарт Республики Беларусь

Госстандарт Республики Казахстан

3 Постановлением Комитета Российской Федерации по стандартизации, метрологии и сертификации от 8 августа 1995 г. N 425 межгосударственный стандарт ГОСТ 2.114-95 введен в действие в качестве государственного стандарта Российской Федерации с 1 июля 1996 г.

Изменение N 1 принято Межгосударственным советом по стандартизации, метрологии и сетификации (протокол N 18 от 18 октября 2000 г.)

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

Наименование национального органа по стандартизации

Госстандарт Республики Беларусь

Госстандарт Республики Казахстан

Изменение N 2 принято Межгосударственным советом по стандартизации, метрологии и сертификации (протокол N 24 от 5 декабря 2003 г.)

За принятие изменения проголосовали национальные органы по стандартизации следующих государств: BY, KZ, KG, RU, TJ, TM, UA [коды альфа-2 по МК (ИСО 3166) 004]

5 ИЗДАНИЕ (апрель 2011 г.) с Изменениями N 1, 2, принятыми в марте 2001 г., марте 2005 г. (ИУС 6-2001, 6-2005), с Поправкой (ИУС 12-2000, 10-2006)

ВНЕСЕНА поправка, опубликованная в ИУС N 2, 2016 год

Поправка внесена изготовителем базы данных

1 ОБЛАСТЬ ПРИМЕНЕНИЯ

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

* В части требований к разработке и оформлению ТУ на пищевые продукты на территории Российской Федерации действует ГОСТ Р 51740-2001.

(Измененная редакция, Изм. N 1)

2 НОРМАТИВНЫЕ ССЫЛКИ

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

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

ГОСТ 15.001-88* Система разработки и постановки продукции на производство. Продукция производственно-технического назначения

* На территории Российской Федерации действует ГОСТ Р 15.201-2000.

ГОСТ 28388-89 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения.

(Измененная редакция, Изм. N 1).

3 ОСНОВНЫЕ ПОЛОЖЕНИЯ

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

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

3.3 ТУ разрабатывают на:

— одно конкретное изделие, материал, вещество и т.п.;

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

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

3.5 Если отдельные требования установлены в стандартах или других технических документах, распространяющихся на данную продукцию, то в ТУ эти требования не повторяют, а в соответствующих разделах ТУ дают ссылки на эти стандарты и документы в соответствии с ГОСТ 2.105.

3.6 ТУ оформляют на листах формата А4 по ГОСТ 2.301 с основной надписью по ГОСТ 2.104 (формы 2 и 2а), а титульный лист оформляют по ГОСТ 2.105 со следующими дополнениями:

Схемы, чертежи и таблицы, иллюстрирующие отдельные положения ТУ, выполняют на листах форматов по ГОСТ 2.301, при этом основную надпись выполняют по форме 2а ГОСТ 2.104.

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

— обозначение ТУ указывают на каждом листе в верхнем правом углу (при односторонней печати) или в левом углу четных страниц и правом углу нечетных страниц (при двусторонней печати);

— подписи лиц, предусмотренные в основной надписи по ГОСТ 2.104, указывают на титульном листе, а для ТУ, выполненных на магнитных носителях, по ГОСТ 28388;

— изменения указывают в листе регистрации изменений, который помещают в конце ТУ (рекомендуемая форма листа регистрации изменений по ГОСТ 2.503).

(Измененная редакция, Изм. N 2).

3.7 Обозначение ТУ присваивает разработчик.

3.7.1 На изделия машиностроения и приборостроения ТУ обозначают по ГОСТ 2.201.

Также допускается использовать для обозначения ТУ двойное обозначение:

— обозначение ТУ, как неосновного конструкторского документа по ЕСКД;

(Измененная редакция, Изм. N 2).

3.7.2 На материалы, вещества и т.п. обозначение ТУ рекомендуется формировать из:

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

— года утверждения документа.

Пример обозначения ТУ для Российской Федерации:

Источник