Как правило, техзадание оформляется в виде приложений к договору на разработку программного обеспечения и является его неотъемлемой частью с момента подписания сторонами.
Если подготовку договора на создание ПО лучше поручить юристу (специалисту в составлении правовой документации), написание техзадания требует иных, технических (а не юридических) знаний, поэтому его разработкой должно заниматься лицо, обладающее знаниями в области программирования: программист, технический директор, иные лица при наличии достаточных знаний.
Ниже рассмотрена структура и требования к содержания ТЗ (образец техзадания), руководствуясь которыми можно грамотно составить техзадание. Представленный образец техзадания подойдет как к договору на создание ПО, так и договору авторского заказа (в отличие от первого, он заключается непосредственно с автором).
В зависимости от полноты и детализации можно выделить два вида технических заданий:
(1) «эскиз» — документ, содержащий общее описание создаваемого продукта без учета технологического аспекта реализации решения;
Форма 2 — ответ на техническое задание заказчика
(2) «технический проект» — представляет собой подробный проект, практическая реализация которого на следующем этапе приводит к созданию ПО.
Поскольку программа для ЭВМ согласно ст.1261 ГК РФ включает в себя также «подготовительные материалы, полученные в ходе разработки программы», автор «технического проекта» по праву может считаться соавтором программы. В то время как разработчик «эскиза», остается лишь автором документа под названием «техническое задание».
Общие требования к составу, содержанию и оформлению техзадания (образец техзадания) изложены в ГОСТ 34.602-89 и ГОСТ 19.201-78.
Так, согласно положениям ГОСТ, техзадание, как правило, включает следующие основные разделы:
Техзадание может дополняться различными приложениями со схемами, таблицами, расчетами и иными подобными материалами, используемыми при разработке программы.
Вне зависимости от того, какой из сторон договора поручена разработка техзадания, руководствуясь ГОСТом, стороны смогут избежать многих разногласий.
Максимально детализированное ТЗ может быть выгодно обеим сторонам договора:
— исполнителю, поскольку позволит четко определить свои обязательства относительно характеристик создаваемого ПО и, соответственно, избежать включения заказчиком дополнительных требований за рамками согласованного ТЗ;
— заказчику, соответственно, позволит четко сформулировать свои требования к продукту в целях его последующей идентификации (созданное ПО должно соответствовать характеристикам, изложенным в ТЗ; если условия техзадания не позволяют четко установить какое ПО должно быть создано в результате его реализации, заказчику будет проблематично подтвердить свои права на программный продукт).
Таким образом, технической задание является основополагающим документом не только в процессе создания ПО, но и для последующего закрепления прав на него, поэтому к его составлению необходимо подходить с особой внимательностью.
Урок 11: техническое задание на проект дома, суды с заказчиками.
Не редкость такие ситуации, когда исполнитель навязывает заказчику свои образцы техзаданий, однако следует помнить, что только заказчик знает какое ПО ему нужно и в наибольшей степени заинтересован в том, чтобы получить в результате такое ПО, которое будет удовлетворять всем его потребностям, а потому, ему следует принимать активное участие в разработке ТЗ.
Более 18 вариантов договора на разработку ПО. Различные модели тарификации. 100% защита прав на код, дизайн и алгоритмы.
Источник: www.it-lex.ru
Образец технического задания на разработку сайта
Ориентировочная структура ТЗ на создание сайта/веб-приложения
Техническое задание на разработку сайта/веб-приложения
Аннотация
В данном техническом задании сформулированы основные функциональные и технические требования к разрабатываемому сайту/веб-приложению.
Документ является основным источником требований для реализации проекта.
1. Цели создания сайта
Здесь приводится описание основных целей и задач проекта.
2. Целевая аудитория
Здесь описывается, кто является основным пользователем проекта и решаемая им задача/потребность.
3. Требования к сайту
3.1. Общие требования
В данном разделе приводятся общие требования к проекту, например доменное имя, название, языки и т.д.
3.2. Ролевая модель
Описание основных ролей, их возможностей и полномочий
Таблица 1 – Ролевая модель
- Взаимодействие с публичной частью сайта
- Регистрация
- Взаимодействие с публичной частью сайта
- Авторизация
- Взаимодействие с личным кабинетом пользователя
3.3. Функциональные требования к публичной части
В данном разделе перечисляются и описываются все функциональные требования для публичной части сайта, например:
- Просмотр каталога товаров.
- Добавление товара в корзину.
- Заказ обратного звонка.
- Регистрация.
- и т.д.
Для каждого функционального требования также должно быть конкретизированы детали, например, какие сведения должен указать пользователь при регистрации: Имя, телефон, email и т.д.
3.4. Функциональные требования к личному кабинету клиента
В данном разделе приводятся функциональные требования к личному кабинета клиента, аналогично пункту 3.3.
3.5. Функциональные требования к панели управления (администрирования)
В данном разделе приводятся функциональные требования к панели управления сайтом. Если сайт реализуется на базе какой-то CMS (система управления контентом) и используется ее стандартная панель управления, то также это необходимо указать.
3.6. Требования к структуре сайта
В данном разделе описывается структура сайта (разделы и связи между ними) для каждого типа пользователя (роли).
3.6.1. Структура публичной части сайта
Структура разделов публичной части сайта приведена на рисунке ниже.
Рисунок 1 – Структура публичной части сайта
Далее приводится описание каждого раздела, что в нем должно находиться в формате таблицы:
- Просмотр статьи
- Возможность фильтрации статей по дате и теме
- Голосование за статью
- Возможность оставить комментарий (только для авторизованных пользователей)
3.7. Архитектура сайта
Сайт представляет собой клиент-серверное веб-приложение, архитектура которого представлена на рисунке ниже.
Рисунок 2 – Архитектура сайта
Далее приводится описание всех архитектурных блоков приложения и связей между ними.
3.8. Требования к интеграциям
Приводится список систем, с которыми должна быть выполнена интеграция, а также приводятся ссылки на описание API/модулей для интеграции с данными системами или сервисами.
3.9. Технические требования
Указываются технические требования, такие как:
- На какой системе (платформе) должен быть разработан проект.
- Требования к используемым технологиям.
- Требования к техническим средствам.
- Требования к адаптивности.
- Требования к кроссбраузерности.
- и т.д.
3.10. Требования к дизайну
Приводятся требования к дизайну веб-интерфейса, а также указываются разрешения экранов, для которых должен быть разработан макет и брейкпоинты адаптации.
3.11. Требования к контенту
В данном разделе необходимо указать какой контент должен быть создан/добавлен Исполнителем, а какой предоставляется Заказчиком.
3.12. Требования к внутренней SEO оптимизации
В данном разделе приводятся требования по внутренней SEO оптимизации сайта.
3.13. Требования к к системам аналитики
В данном разделе приводятся требования по подключению систем аналитики и отслеживания.
3.14. Дополнительные требования
Указываются дополнительные требования, модули и компоненты, которые должны быть использованы в проекте, несколько примеров приведено ниже.
3.14.1. Поисковые подсказки
При поиске по товарам/услугам пользователю должны предлагаться варианты поисковых запросов, соответствующих введенному запросу.
Пример поисковых подсказок приведен на рисунке ниже.
Рисунок 3 – Умный поиск
3.14.2. Требования к уведомлениям
Для оперативного информирования пользователей о новостях и событиях должна выполняться отправка email уведомлений в случае наступления следующих событий:
- Регистрация пользователя;
- Формирование заказа;
- Изменение статуса заказа;
- Отправка обращения через форму обратной связи;
- Начисление бонусов;
- Новые товары.
3.14.3. Требования к управлению изменениями
Все изменения кода сайта должны внедряться с использованием системы контроля версий – git после предварительного тестирования на тестовом сервере.
4. Требования к документации
Приводится перечень разрабатываемой документации и требований к ней.
5. Стадии и этапы разработки
В данном разделе приведена последовательность этапов реализации проекта (состав этапов зависит от конкретного проекта).
Источник: uncore.ru