Как составить ТЗ для IT‑аутсорсинговой компании?

Зачем нужно в ТЗ в IT‑аутсорсинге и заказной разработке?

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

1. ТЗ помогает Заказчику четко объяснить свои требования и не обмануться в ожиданиях от проекта.
2. Исполнитель может точно рассчитать бюджет работ и сроки сдачи проекта.
3. ТЗ фиксирует ответственность сторон, исключая двусмысленность.
4. Все участники проекта с двух сторон ориентируются на один документ => команда смотрит в одном направлении.

По этим причинам составление ТЗ — это первый этап любого проекта.

Кто составляет техническое задание на разработку ПО: заказчик или разработчик?

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

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

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

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

Порядок работы с ТЗ

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

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

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

Какие разделы должны быть в ТЗ обязательно?

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

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

Скачать стандарт составления ТЗ для стран ЕАЭС можно в конце статьи.

Цели создания ПО

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

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

Требования к ПО

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

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

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

Нефункциональные требования. Нефункциональные требования — это все, что не связано непосредственно с функциональностью, но критически важно для работы ПО.

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

Требования к надежности объясняют, как система будет справляться с ошибками, сбоями и восстановлением после них.

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

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

1. Например, по данным InfoWatch количество скомпрометированных персональных данных за прошедший год выросло более, чем на 30%.
2. А согласно ГК «Солар»: за 2024 год среднее количество веб‑атак на домены российских компаний выросло с 15 до 65 млн событий ИБ в месяц.

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

Порядок приема проекта

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

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

Скачать самый новый стандарт составления ТЗ для стран ЕАЭС можно по ссылке.