Техническое задание и технические требования. Техническое задание: законодательные требования и сложившаяся практика

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

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

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

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

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

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

Научно-исследовательских работ,

Опытно-конструкторских работ,

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

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

Техническое задание должно содержать три основных раздела:

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

2. перечень документов, требующих совместного рассмотрения Заказчиком и Разработчиком,

3. порядок сдачи и приемки результатов разработки.

При необходимости техническое задание может содержать также требования к подготовке и освоению производства.

Конкретное содержание технического задания определяют Заказчик и Разработчик, а при инициативной разработке - Разработчик.

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

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

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

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

Научно-техническая информация,

Патентная информация,

Характеристика рынка сбыта,

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

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

Прогнозируемые показатели технического уровня и качества,

Основное назначение,

Характеристика рынка сбыта,

Технические и тактико-технические характеристики,

Уровень стандартизации и унификации,

Технико-экономические показатели

Патентно-правовые показатели,

Специальные требования к изделию и др.

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

Общий порядок разработки и утверждения технического задания устанавливает Государственный стандарт России ГОСТ 15.001-88

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

Техническое задание оформляют в соответствии с общими требованиями к текстовым конструкторским документам согласно Государственного стандарта ГОСТ 2.105-95.

Таблица 1

	Основные разделы технического задания	Примерный перечень вопросов, рассматриваемых в разделе
	Наименование и область применения (использования).	Наименование и условное обозначение разрабатываемой продукции. Краткая характеристика области ее применения. Общая характеристика объекта, в котором используют продукцию.
	Основание для разработки	Полное наименование документа, на основании которого разрабатывают продукцию. Организация, утвердившая этот документ, и дата его утверждения. Наименование и условное обозначение темы разработки.
	Цель и назначение разработки	Эксплуатационное и функциональное назначение, перспективность производства продукции.
	Источники разработки	Перечень научно-исследовательских и других работ. Перечень экспериментальных образцов и макетов.
	Технические (тактико-технические) требования	Состав продукции и требования к конструктивному решению. Требования к техническим показателям. Требования к надежности. Требования к технологичности. Требования к уровню унификации и стандартизации. Требования безопасности. Эстетические и эргономические требования. Требования к патентной чистоте. Требования к составным частям продукции, сырью, исходным и эксплуатационным материалам. Условия эксплуатации. Дополнительные требования. Требования к маркировке и упаковке. Требования к транспортировке и хранению. Специальные требования.
	Экономические показатели	Ориентировочная экономическая эффективность и срок окупаемости затрат. Предельная себестоимость. Предполагаемая годовая потребность в продукции. Экономические преимущества разрабатываемой продукции по сравнению с аналогами.
	Состав и этапы разработки	Стадии разработки, этапы работ и сроки их выполнения (сроки, указываемые в техническом задании, являются ориентировочными: основные сроки указываются в плане работ или в договоре на разработку нового изделия). Предприятие-изготовитель разрабатываемого изделия. Перечень документов, предъявляемых на экспертизу, этапы, на которых она проводится, и место проведения.
	Порядок контроля и приемки	Перечень конструкторских документов, подлежащих согласованию и утверждению. Перечень организаций, с которыми следует согласовывать документы. Общие требования к приемке работ на стадиях разработки. Количество изготавливаемых опытных образцов продукции.
	Приложения к техническому заданию	Перечень научно-исследовательских и других работ, обосновывающих необходимость проведения разработки. Чертежи, схемы, описания, обоснования, расчеты и другие документы, которые должны быть использованы при разработке. Перечень заинтересованных организаций, с которыми согласовывают конкретные технические решения в процессе разработки продукции. Перечень нового технологического оборудования, необходимого для выпуска новой продукции.

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

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

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

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

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

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

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

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

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

Виды ТЗ (технического задания)

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

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

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

Структура технического задания

Структура технического задания (форма технического задания) выглядит следующим образом:

1. Цели проекта
В ТЗ необходимо указать каких целей хочет добиться компания, используя результаты завершенного проекта. Такими целями, к примеру, могут быть: выпуск нового товара, проведение ребрендинга компании или торговой марки, проведение рекламной кампании и т.д.
2. Описание компании заказчика
- Сфера деятельности и масштабы компании, ее миссия и позиции на рынке;
- Описание портфеля брендов компании - с какими торговыми марками работает фирма;
- Список главных компаний-конкурентов;
- Перечень основных конкурентных преимуществ компании и УТП (уникальное торговое предложение).
3. Описание ситуации и последних тенденций рынка , для которого разрабатывается бренд
- Ценовой сегмент продукта или услуг компании;
- Портрет потребителя (возраст, пол, географические данные, социальный уровень целевой аудитории);
- Тактические и стратегические маркетинговые цели компании (на период от 1 до 3 лет);
- Модель поведения потребителя и описание ситуаций, при которых потребитель совершает покупку;
- Описание основных характеристик существующего бренда, его концепции позиционирования, слогана, маркетинговых коммуникаций, необходимое в случае проведения ребрендинга.
4. Референсы
Перечень примеров аналогичных работ, которые нравятся заказчику в контексте данного проекта.
5. Требования
В данном разделе необходимо прописать все технические и функциональные требования к проекту. А также требования и пожелания заказчика к графике, тексту, цветовой гамме, к стилю, шрифтам,

Техни́ческое зада́ние (ТЗ , техзада́ние ) - исходный документ для разработки и испытания интернет магазина.

Понятие ТЗ

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

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

Можно сказать, что ТЗ — документ, в котором описывается, ЧТО нужно заказчику, в отличие от последующей проектной документации, в которой акцент переносится на ответ на вопрос, КАК этого достичь.

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

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

Место ТЗ в структуре проектирования

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

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

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

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

Стадии проектирования регламентированы стандартами. Это следующая последовательность:

• Техническое задание (по ГОСТ 2.103-68 к стадиям разработки не относится),
• Техническое предложение,
• Эскизный проект,
• Технический проект,
• Стадии рабочего проекта.

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

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

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

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

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

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

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

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

Необходимость ТЗ

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

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

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

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

Академик А. Н. Крылов рассказывал. На одной фабрике установили новую машину, но никак не могли её запустить. Тогда обратились за помощью к профессору университета. Приехав на фабрику, он долго ходил вокруг машины, внимательно что-то высматривая и к чему-то прислушиваясь. Затем, взяв молоток, ударил по её корпусу. И машина заработала. За свою помощь профессор запросил у правления фабрики 100 рублей (дело было в начале 20 века). Но правление фабрики посчитало, что за один удар молотком это слишком большая плата. На что профессор ответил, что сам удар стоит один рубль, а вот то, куда ударить - 99 рублей. Замечено, что если стоимость исправления проектной ошибки, допущенной на этапе технического проектирования принять за 1, то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и ТЗ!

Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:

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

Регламентированное ТЗ

Несмотря на свою важность, содержание ТЗ мало регламентировано нормативными документами (ГОСТ, ОСТ).

• ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению (кратко изложено содержание ТЗ);
• ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы (достаточно подробно изложены состав и содержание ТЗ);
• ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления (приведен порядок построения ТЗ).

В части выполнения научно-исследовательских работ ТЗ регламентируется следующими документами:

• ОСТ 95 18-2001. Порядок проведения научно-исследовательских и опытно-конструкторских работ. Основные положения.
• Приложение №3 к Правилам приемки НИОКР, утвержденным Приказом Роспрома 16.09.2004 №95. Техническое задание на научно-исследовательскую работу (приложен образец технического задания на разработку в рамках ГОЗ)

Разделы ТЗ по ГОСТ 34.602-89 (пример)

Согласно ГОСТ 34.602-89 ТЗ должно содержать следующие разделы (приведены в сокращенном виде):

1. Общие сведения
   1. полное наименование системы и ее условное обозначение;
      Пример:
      Полное наименование системы: Автоматизированная система «Управление»
      Условное обозначение: АСУ
   2. шифр темы или шифр (номер) договора;
      Пример:
      Договор № ХХХ от ДД.ММ.ГГГГ
   3. наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
      Пример:
      ЗАКАЗЧИК Наименование заказчика: ООО «МИР» Юридический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Почтовый адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Фактический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Телефон: +7 903 456 67 67 Факс: +7 903 453 34 54 Адрес электронной почты: [email protected] ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО «БанкСтрой», г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423400000000234
      ИСПОЛНИТЕЛЬ Наименование исполнителя: ООО «ДЯТЕЛ» Юридический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Почтовый адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Фактический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Телефон: +7 495 345 63 63 Факс: +7 495 433 34 54 Адрес электронной почты: [email protected] ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО «БанкСтрой», г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423400000000234
   4. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
   5. плановые сроки начала и окончания работы по созданию системы;
   6. сведения об источниках и порядке финансирования работ;
   7. порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.
2. Назначение и цели создания системы
3. Характеристика объекта автоматизации
   1. краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
   2. сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
4. Требования к системе
   1. Требования к системе в целом;
   2. Требования к функциям (задачам), выполняемым системой;
   3. Требования к видам обеспечения.
5. Состав и содержание работ по созданию системы
   1. перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;
   2. вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);
   3. программа работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
   4. перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организации-исполнителей (при необходимости).
6. Порядок контроля и приемки системы
   1. виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
   2. общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
   3. статус приемочной комиссии (государственная, межведомственная, ведомственная).
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
   1. приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
   2. изменения, которые необходимо осуществить в объекте автоматизации;
   3. создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
   4. создание необходимых для функционирования системы подразделений и служб;
   5. сроки и порядок комплектования штатов и обучения персонала.
8. Требования к документированию
   1. согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и научно-технической документации отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;
   2. требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
   3. при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.
9. Источники разработки: документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

Вид и состав требований ТЗ

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

• Цели в функциональном виде. Изделие является лишь материальным носителем определенных функций , выполнение которых и позволяет достигать заданные цели (удовлетворять потребности ). Но одну и ту же функцию могут выполнять разные устройства. Поэтому функциональное, а не предметное указание цели расширяет область возможных решений, что необходимо для поиска оптимального решения. Также, функция - более четкий термин для описания сути назначения устройства. Уточнение целей и назначение соответствующих им функций - наиболее важная часть работы по составлению ТЗ;
• Выполнение функций, реализующих заданные потребности, всегда увязывается с удовлетворением определенных требований (см. перечень типовых требований к техническим устройствам), которые делают изделия более привлекательными, учитывают и конкретизируют особенности производства и эксплуатации и т. п. Для удобства требования по виду подразделяют на три группы:
  • условия, характеризуются конкретными значениями данных (формально их можно представить в виде равенств). Например, масса изделия должна составлять 10 кг, применять сталь 40Х, место эксплуатации - тундра. Важную часть условий формирует оценка доступных ресурсов;
  • ограничения, задают допустимую область данных (формально их можно представить в виде односторонних или двусторонних неравенств). Например, вес изделия не должен превышать 10 кг, применять углеродистые стали;
  • показатели качества (которые преобразуются в критерии оптимизации), задают только перечень характеристик и направление поиска предпочтительного значения (максимальное или минимальное значение, например, вес изделия должен быть минимальным, а удобство обслуживания - максимальным). Конкретное значение показателя становится известным только в конце этапа или всего цикла проектных работ и служит мерой предпочтения в процессе поиска оптимального варианта (основой выбора окончательного варианта).

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

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

При формировании системы требований обязателен анализ следующих источников:

• Доступность ресурсов, находящихся в распоряжении заказчика и разработчика: финансовые, производственные, людские, временные. Все ресурсы взаимосвязаны, например, за счет увеличения финансирования проекта можно добиться сокращения периода разработки. Следствием степени доступности является введение ограничений на методы и точность решения проектной задачи, что, в свою очередь, влияет на вид выбираемой модели. Так, при ограниченности времени ведут оценочные расчеты упрощенными методами или используют готовое программное обеспечение, стандартные методики, типовое оборудование, стандартные и покупные детали и узлы и т. д. В то же время модель, метод и точность решения должны обеспечивать исполнение требований ТЗ, даже если они и высоки.
• Учет требований надзорных и лицензионных органов при проектировании, например, технологических комплексов (производств). В соответствии с законами Российской Федерации любое производство требует получения региональной лицензии на эксплуатацию. Помимо этого многие производства лицензируются надзорными органами и подлежат с их стороны контролю. Наиболее часто контролирующими являются региональные органы Ростехнадзора, Росстандарта, Минрегион России (бывш. Госстрой), Роспотребнадзора, Росприроднадзора, ГПС, МВД России, Роструда.
• Жизненная среда проектируемой системы. Она задает требования, характеризующие взаимное влияние спроектированной системы и окружающих её живых и неживых объектов и внешней среды. Основные указания на нее приводятся в технических требованиях в условиях потребления будущей продукции. Эти условия могут быть охарактеризованы достаточно обобщенно и нуждаться в конкретизации.

Составление списка требований ТЗ

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

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

Прежде, чем приступить к разработке электрического освещения в быту, Эдисон провел исследования, при каких условиях оно выдержит конкуренцию в цене, яркости и удобстве с газовым освещением (рожком). Он до тонкостей изучил газовую промышленность, разработал план центральной электростанции и схему линий электропередач к домам и фабрикам. Затем подсчитал стоимость меди и других материалов, которые потребуются для изготовления ламп и добычи электроэнергии с помощью динамо-машины, движимой паром. Анализ данных определил не только размеры лампы, но и её конкурентоспособную цену, равнявшуюся 40 центам. И лишь когда Эдисон убедился, что сможет решить проблему электрического освещения, он принялся работать над лампой накаливания с угольной нитью, помещенной в стеклянный шар, из которого откачан воздух. В поисках материала нити он опробовал около 6 000 разновидностей растительного волокна.

Анализ задания заказчика

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

Следует выявлять и стараться избегать решения следующих задач:

• задачи, не соответствующие общественным потребностям - криминальные, аморальные, негуманные. Их решение - дело совести разработчика;
• технические псевдозадачи, с ошибочно выдвинутыми целями. Это - задачи, которые уже имеют решение, либо не имеют объективных предпосылок для своего решения (преждевременные задачи, но это нуждается в обосновании, чтобы отказ в решении не был следствием психологической инерции или других субъективных причин);
• химерические задачи. Это - задачи с ошибочно поставленной целью, достижение которой противоречит законам физики (например, создание устройства с КПД более 100 %, устройства мгновенного действия и т. п.), либо абстрактно выдвинутые задачи, принципиально не имеющие решения (типа философского камня).

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

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

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

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

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

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

Конкретизация целей проектирования

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

В процессе поиска наиболее полной и точной формулировки строится цепочка функций (дерево целей) - от первоначально предложенной до окончательно принятой. Этому помогает ответ на вопрос «Зачем это нужно?» (и другие вопросы метода контрольных вопросов). В большинстве случаев за приведенной в требованиях целью стоит необходимость выполнения (последовательно или одновременно) нескольких функций. Цепочка функций строится для каждой из них.

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

Обработка собранной информации

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

Абстрагирование предназначено дать такую формулировку требованиям, чтобы избежать предопределения путей решения задачи (не создавать психологических барьеров). Для получения «сильных» решений рекомендуют проводить усиление системы требований и обострение противоречий путем формулирования ИКР.

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

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

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

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

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

Проблемами оценки качества посредством количественных показателей занимается наука «Квалиметрия».

5. Усечение списка требований.
Большой объем информации хотя и способен дать максимально полное представление о решаемой задаче, но труднее удерживается в голове, усложняет решение задачи. Для сокращения сведений до разумного объема (под способности каждого конкретного разработчика, соответствие его финансовым, организационно-техническим, временным ресурсам) можно воспользоваться их ранжированием или разделением на группы обязательных к учету, желательных и несущественных. К обязательным относятся те, неудовлетворение которых существенным образом влияет на выбор вариантов решений. Это - функциональные параметры, условия взаимосвязи систем и их частей и другие. Желательные требования позволяют различить варианты по степени качества.

Стоит принимать во внимание слова Ли Якокки: «… беда в том, что ты учился в Гарварде, где тебе вбили в голову, что нельзя предпринимать никаких действий, пока не соберёшь все факты. У тебя 95 % информации, а для того, чтобы собрать недостающие 5 %, тебе понадобится ещё шесть месяцев. За это время все факты устареют, потому что рынок развивается гораздо быстрее. Самое главное в жизни - всё делать вовремя. … главная задача состоит в том, чтобы собрать все важные факты и точки зрения, которые вам доступны. Но в какой-то момент надо начинать действовать решительно. Во-первых, потому, что даже самое правильное решение оказывается неверным, если оно принято слишком поздно. Во-вторых, потому, что в большинстве случаев не существует такой вещи, как полная уверенность. Вам никогда не удастся собрать все 100 % информации. К сожалению, жизнь не будет ждать, пока вы оцените все возможные просчеты и потери. Иногда надо просто двинуться вперед наудачу и исправлять ошибки по ходу движения».

6. Сведение требований в единый документ и утверждение его заказчиком.

Литература

• Хорошев А.Н. Введение в управление проектированием механических систем: Учебное пособие. - Белгород, 1999. - 372 с. - ISBN 5-217-00016-3 Электронная версия 2011 г.

От автора: Как написать техническое задание (тз) на разработку сайта ? Тема достаточно обширная, и в рамках одной заметки ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, о том что нужно учесть и на что следует обратить сое внимание при составлении тз веб-сайта, я постараюсь изложить достаточно подробно.

Итак, техническое задание на разработку сайта

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

Давайте проанализируем такой пример:

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

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

JavaScript. Быстрый старт

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

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

Это пример всего-то банального календаря.

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

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

Из каких пунктов обычно состоит техническое задание?

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

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

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

Поехали по пунктам.

Описание

Здесь можно в пару предложений написать о предприятии, чем занимается. Что – то типа вступление сделать.

для кого — целевую аудиторию:

потенциальные покупатели

продавцы продукции (магазины, интернет-магазины)

сервисные центры

партнеры (фирмы)

потребители продукции (тот, кто уже купил)

Для чего нужен сайт:

Для повышения имиджа компании

Для увеличения продаж

Для удобства клиентов

Корпоративный

Сайт – визитка

Интернет магазин

Языковые версии:

Английский

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам.

Цели и задачи

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

Потенциальные покупатели продукции.

Цель: привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи:

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

Дать информацию о салонах-магазинах

Дать информацию о розничной торговой сети

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

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

Теперь перечисляем модули.

Функционал сайта

Для того чтобы перечислить функционал, нужно решить что ему необходимо:

Нужна ли регистрация

Нужен ли закрытый раздел (только для зарегистрированных пользователей)

Нужна ли форма обратной связи

И т.д. и т.п.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

После того, как все это описали, мы подбираемся к самому главному и интересному. Конечно, вся проделанная выше работа очень важна, но теперь становиться еще «жарче».

Описание функционала

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

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

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

Для начала нужно рассказать о компании. Тут могут быть страницы о компании, история компании, контакты, отзывы.

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

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

о компании

история компании

контакты

продукция

каталог продукции

отзывы о продукции

служба сервиса

гарантийное обслуживание

послегарантийное обслуживание

потребителю

покупка и доставка

пользование

о сервисе

магазинам и интернет магазинам

фотографии продукции

Часто задаваемые вопросы

сервисным центрам

Как стать сервисным центром

Часто задаваемые вопросы

партнерам

приглашение к сотрудничеству

Часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

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

Примерно так описывается общая логика работы.

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

«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание: попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

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

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

И не забывайте про задание!