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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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