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

Содержание

Введение
ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.
А как же Agile?
Для чего нужно техническое задание
- Кстати, мы занимаемся разработкой сайтов!
Кто составляет техническое задание
Формат и структура технического задания
Пример технического задания

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…
И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):
• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.
Согласно ГОСТ 34 техническое задание должно включать следующие разделы:
1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки
При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.

ГОСТ 19

«ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.
Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:
Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий.
Согласно стандарту техническое задание должно включать следующие разделы:
1. Введение

1. Назначение
2. Область действия
3. Определения, акронимы и сокращения
4. Ссылки
5. Краткий обзор

2. Общее описание

1. Взаимодействие продукта (с другими продуктами и компонентами)
2. Функции продукта (краткое описание)
3. Характеристики пользователя
4. Ограничения
5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
2. Функциональные требования
3. Требования к производительности
4. Проектные ограничения (и ссылки на стандарты)
5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
6. Другие требования

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.
Данный стандарт содержит два шаблона спецификации требований:
• System requirements specification (SyRS)
• Software requirements specification (SRS)
System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.
SyRS может содержать следующие разделы:
1. Введение

1. Назначение системы
2. Содержание системы (границы системы)
3. Обзор системы
- 2. Функции системы
- 3. Характеристики пользователей
4. Термины и определения

2. Ссылки
3. Системные требования

1. Функциональные требования
2. Требования к юзабилити
3. Требования к производительности
4. Интерфейс (взаимодействие) системы
5. Операции системы
6. Состояния системы
7. Физические характеристики
8. Условия окружения
9. Требования к безопасности
10. Управление информацией
11. Политики и правила
12. Требования к обслуживанию системы на протяжении ее жизненного цикла
13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)
5. Приложения

1. Предположения и зависимости
2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.
SRS может содержать следующие разделы:
1. Введение

1. Назначение
2. Содержание (границы)
- 3. Обзор продукта
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователей
- 4. Ограничения
4. Термины и определения

2. Ссылки
3. Детальные требования

1. Требования к внешним интерфейсам
2. Функции продукта
3. Требования к юзабилити
4. Требования к производительности
5. Требования к логической структуре БД
6. Ограничения проектирования
7. Системные свойства ПО
8. Дополнительные требования

1. Предположения и зависимости
2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.
Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:
• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):
1. Введение.

1. Цель.
2. Краткая сводка возможностей.
3. Определения, акронимы и сокращения.
4. Ссылки.

2. Обзор системы

1. Обзор вариантов использований.
2. Предположения и зависимости.

3. Детальные требований

1. Описание вариантов использования.
2. Дополнительные требования.
3. Другие функциональные требования.
4. Нефункциональные требования.

4. Вспомогательная информация.
Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.
Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: «Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.
Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Как говорится, каждому проекту свое техническое задание. При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя.
Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.
Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
Также рекомендую ознакомиться со следующими материалами:

Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.
Правила составления Software requirements specification (читать вместе с комментариями)
Примеры ТЗ и другой документации по разработке АС для МЭР
ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ
Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine»

Техническое задание на разработку сайта: пример, образец и требования

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

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

Для чего нужно техническое задание

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

Кстати, мы занимаемся разработкой сайтов!

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

Абсолютно неинформативны.
Могут трактоваться по-разному.

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

Подробное ТЗ с объяснением каждой детали не оставит места для субъективной оценки.

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

Как видите, этот этап подготовки имеет колоссальное значение, поэтому им не стоит пренебрегать.

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

Фактически ТЗ на разработку сайта может составляться был человеком, но вот качество готового документа в таком случае остаётся под вопросом. Будет лучше, если за дело возьмётся опытный человек — например, проект-менеджер: так вы не только получите задание, но и сможете проверить компетентность разработчика.

Если задание путанное, наполнено туманными объяснениями с минимальной конкретикой, это повод задуматься о профессионализме выбранной компании. Это спасёт вас от бесперспективного сотрудничества.

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

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

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

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

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

Формат технического задания

Документ может создаваться в любом текстовом редакторе. Наиболее популярными являются Microsoft Word и Google Docs. Особенно удобно работать во втором сервисе — доступ к просмотру и редактированию осуществляется по ссылке, поэтому можно в любой момент создать примечание или внести правку.

Из общих правил оформления можно выделить:

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

В любом случае главное — удобство для обеих сторон.

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

Чёткого регламента на объем технического задания на разработку сайта нет: это показатель зависит от типа проекта, его сложности и масштабов. А вот структура примерно одинакова во всех случаях.

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

Есть ли специальные требования для написания ТЗ

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

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

— Нет: «Сайт работает быстро».

— Да: «Страница загружается за n-секунд при стабильном подключении к сети».

Второй совет. Отдавайте предпочтение развёрнутым описаниям.

— Нет: «Поиск должен быть удобным».

— Да: «Поиск по сайту должен содержать n-фильтров и сортировку выдачи по n-критериям».

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

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

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

Пример технического задания

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

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

Пример: Техническое задание на разработку сайта интернет-магазина косметики.

1. ВВЕДЕНИЕ

В документе содержится техническое задание для разработки сайта интернет-магазина магазина косметики N. Бренд занимает нишу 12 лет и специализируется на офлайн-продажах. Продукция ориентирована на молодых людей 16-25 лет, компания предлагает линейки для аллергиков и веганов.

2. НАЗНАЧЕНИЕ

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

3. СТРУКТУРА И ОПИСАНИЕ

На сайте будет 9 разделов:

3.1. Главная страница:

Шапка сайта с названием компании и логотипом бренда;
Контентный блок для описания акций;
Карта сайта;
Корзина;
Блоки разделов (Распродажа, Новая коллекция, Для веганов, Гипоаллергенно);
Партнёры;
Социальные сети;
Копирайт, контактные данные.

3.2 Общее оформление разделов:

Шапка;
Корзина;
Поиск по сайту, фильтры и сортировка;
Копирайт, контактные данные.

4. РАЗДЕЛЫ И СТРАНИЦЫ

4.1 Главная страница:

Шапка главной страницы — обложка с продукцией бренда, название и логотип. Карта сайта расположена под шапкой в одну строку. Ниже:

Строка поиска;
Корзина;
Фильтры поиска и сортировка;
Блок с акциями, текст на фоне изображения;
Блок с новыми коллекциями, текст на фоне изображения;
Блок этичной косметики с кнопкой «перейти» для перехода в раздел;
Блок с гипоаллергенной косметикой с кнопкой «перейти» для перехода в раздел;
Графические блоки с логотипами партнёров;
Логотипы с ссылками на социальные сети;
Нижняя панель с копирайтом (слева) и контактными данными (справа).

4.2 О магазине:

Страница оформляется по типовому шаблону: шапка и текстовый блок с описанием компании.

4.3 Каталог:

Строка поиска;
Корзина;
Фильтры поиска и сортировка;
Блок этичной косметики с кнопкой «перейти» для перехода в раздел;
Блок с гипоаллергенной косметикой с кнопкой «перейти» для перехода в раздел;
Блоки для каждого подраздела;
Логотипы с ссылками на социальные сети;
Нижняя панель с копирайтом (слева) и контактными данными (справа).

4.5 Подраздел:

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

Строка поиска;
Корзина;
Фильтры поиска и сортировка;
Позиции;
Список страниц с возможностью вернуться на первую и перейти на последнюю;
Логотипы с ссылками на социальные сети;
Нижняя панель с копирайтом (слева) и контактными данными (справа).

4.6 Карточка товара:

Строка поиска;
Корзина;
Фильтры поиска и сортировка;
Изображение товара слева;
Краткое описание справа;
Выбор модели;
Характеристики;
Логотипы с ссылками на социальные сети;
Нижняя панель с копирайтом (слева) и контактными данными (справа).
<… >

5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

Перечень технических требований:

Корректное отображение в Google Chrome, Safari;
Оптимизированная мобильная версия;
Мета-теги для продвижения в Google и Yandex;
Базовое разрешение десктопной версии 1024×768.

6. СЦЕНАРИИ

Сайт будет использоваться:

Для продаж;
Для изучения ассортимента и составления списка желаний;
Для получения информации о продукции бренда.

7. КОНТЕНТ

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

8. УСЛОВИЯ

Общий срок создания интернет-магазина составляет 60 дней. Из них:

20 — создание макетов и шаблонов;
30 — программирование и вёрстка;
10 — создание контента.

8.1 Этапы создания сайта:

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

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

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

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

Назначение технического задания

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

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

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

Состав типового технического задания

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

1) наименование – полное и краткое названия, условное обозначение разрабатываемого ПО;
2) назначение – то, для чего, в какой области и с какой целью разрабатывается ПО;
3) основание для разработки – документы, на основании которых производится разработка ПО;
4) функции – перечень и описание функций разрабатываемого ПО;
5) структура – описание архитектуры и компонентов разрабатываемого ПО;
6) пользовательский интерфейс – в современном мире обязателен;
7) надежность, безопасность, условия эксплуатации и проч. важные требования;
8) документация – какая документация, в каком объеме и в соответствии с какими требованиями ГОСТов будет также разработана;
9) стадии и этапы разработки – что и в какой последовательности разрабатывается;
10) порядок контроля и приемка – как именно будет происходить сдача разработанного ПО Заказчику.

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

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

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

Наименование документа	Наименование стандарта ГОСТ	Стоимость разработки	Срок выполнения	Пример выполнения
ТЗ на программное обеспечение	ГОСТ 19.201	060-240 тыс. руб.	до 1 месяца	Пример
ТЗ на автоматизированную систему	ГОСТ 34.602	060-240 тыс. руб.	до 1 месяца	Пример

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

Возможно, вас также заинтересует:

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

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

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

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

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

— основное назначение, технические и тактико-технические характеристики, уровень стандартизации и унификации;

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

— патентно-правовые показатели;

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

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

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

— патентная информация;

— характеристика рынка сбыта;

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

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

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

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

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

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

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

ГОСТ Р 15.201-2000. Система разработки и постановки продукции на производство (СРПП). Продукция производственно-технического назначения. Порядок разработки и постановки продукции на производство (приведены общие требования и краткие рекомендации по разработке).

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

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

ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления (приведен порядок построения ТЗ). Обобщая требования этих стандартов, порядок построения, изложения и оформления ТЗ можно свести к последовательности, представленной в таблице ниже.

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

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

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

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

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

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

— характеристики ремонтопригодности;

— возможность замены запасных частей без применения промышленной технологии;

— доступность и безопасность эффективного использования продукции инвалидами и гражданами пожилого возраста (для соответствующей продукции, предусмотренной законодательством Российской Федерации).

Техническое задание оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-95 (ЕСКД. Общие требования к текстовым документам) на листах формата А4 , как правило, без рамки и основной надписи. Номера листов (страниц) проставляют в верхней части листа над текстом.

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

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

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

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

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

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