Статьи
Что писать в техническом задании
Введение
Сложно переоценить роль технического задания (ТЗ) в успехе разработки программной системы. От ТЗ зависит буквально всё, начиная от сроков разработки до надежности создаваемого продукта и юридических прав на него. Практически каждый, кто заказывает разработку, в разговоре с ним всегда подтверждает понимание необходимости тщательно подойти к написанию этого документа. Так же отзываются и разработчики: гораздо легче работать в условиях определенности, чем при непрерывном появлении новых подразумеваемых деталей. Однако, когда дело доходит до старта очередного проекта, постановка задачи делается на словах, а ТЗ зачастую готовится формально и задним числом. Это впоследствии приводит к множеству проблемных вопросов, взаимным претензиям между заказчиком и исполнителем, а иногда даже к закрытию проекта.
Вместе с тем, совершенно понятно, почему ТЗ не редко получается не вполне качественным. Это происходит из-за реальной сложности правильной разработки данного документа, которая заключается в необходимости проработки некоторых деталей, о которых в начале проекта обычно предпочитают не задумываться. С одной стороны, ТЗ должно четко описать функционал будущей системе и ее характеристики, а с другой, не накладывать лишних ограничений на имплементацию, которые можно отдать на усмотрение разработчика. Необходимо соблюдение некоторого баланса между однозначностью формулировок и излишним углублением в детали реализации.
В качественно составленном ТЗ заинтересованы и заказчик и разработчик. Подробнее о причинах этой заинтересованности будет описано в отдельной статье. А сейчас давайте перейдем к описанию формального предназначения ТЗ и к составу сведений, которые необходимо в него включать.
Техническое задание - это документ, с помощью которого заказчик в однозначных для понимания формулировках определяет все значимые для него характеристики будущего программного продукта.
Совсем не обязательно ТЗ должно быть единым документом. Оно может быть оформлено иерархическим набором согласованных между собой документов, если продукт предполагает декомпозицию на подсистемы, или компоненты.
ТЗ пишется до заключения договора на разработку, т.к. является одним из основных предметов договора, ведь именно описанный в ТЗ продукт будет необходимо разработать в соответствии с договором. Формулировка задачи, описанная в ТЗ, определяет сроки и стоимость разработки, а значит, возможно, и выбор исполнителя. Последний пункт является основной предпосылкой для того, чтобы ТЗ разрабатывалось именно заказчиком, а не аналитиками компании-разработчика.
Заказчик - для формулировки текстом идеи проекта.
Исполнитель - для анализа требований, оценки и планирования работы, имплементации системы, или отказа от разработки.Заказчик и разработчик - для сдачи/приемки результатов разработки.
Состав технического задания
Основные разделы ТЗ:
1. Описание разрабатываемой системы и ее предназначение.2. Функциональные требования
3. Нефункциональные требования к системе (или эксплуатационные характеристики системы)
4. Интеграции с внешними системами, если они требуются
5. Перечень результатов разработки
6. Требования к средствам разработки, оформлению кода, процессу разработки
7. Порядок сдачи/приемки результатов
Идеальным вариантом представления функциональных требований является список сценариев использования. Про написание сценариев есть достаточно много литературы, но в качестве основного момента хочется выделить то, что сценарии должны писаться без указания способа реализации. Например, необходимо исключить такие фразы, как “Пользователь нажимает на кнопку Старт”. Потому что отсюда сразу появляется ничем не обоснованное ограничение, что должна присутствовать именно кнопка, а не другой элемент UI. И в дополнение к тому, кнопка должна называться именно “Старт”, что исключает выбор исполнителем более удачного названия, а также сразу вносит неоднозначность в локализацию интерфейса. Вместо этого стоит применять фразы вида “Пользователь активирует начало обработки данных”, которые дают свободу действий разработчику. Конкретика появится позже, после того, как сценарии использования декомпозируются разработчиком в требования и в проект архитектуры и интерфейса. Заранее, на этапе написания UI практически невозможно проработать все детали в согласованном виде.
Нефункциональные требования - это такие параметры будущей системы, как производительность, объем занимаемой памяти, требования к целевой архитектуре и операционной системе, к надежности, обслуживанию, квалификации обслуживающего персонала и конечных пользователей и другие особенности, которые невозможно сформулировать в виде процесса.
В ТЗ необходимо явно перечислить, что именно исполнитель передает заказчику в результате работы. Это снимет массу вопросов в будущем при приемке результатов и может повлиять на длительность проектных работ, а также на их стоимость. Потому что одно дело просто выдать заказчику скомпилированный инсталляционный пакет, а совсем другое - настроить сборку системы на стороне заказчика и прогон набора модульных и нагрузочных тестов. Здесь же перечисляется вся проектная и эксплуатационная документация, которая должна быть подготовлена исполнителем, такая как инструкции, руководства по развертыванию и эксплуатации, план проекта и план тестирования, отчеты о тестировании.
Порядок сдачи/приемки разработанной системы должен быть расписан как можно более конкретно. Фразы вида “проверяется выполнение всех перечисленных функциональных и нефункциональных требований” не имеют смысла, такое поведение и без того очевидно. Должен быть указан четкий набор критериев, или метрик, по которым будет определяться окончание разработки и отладки системы. Здесь может быть отсылка к методике приемо-сдаточных результатов, которая будет являться одним из артефактов работы, либо к сессии демонстраций работы системы силами разработчика, а также соблюдения критически важных для заказчика параметров, таких как точность вычислений, или время выполнения операций. Отличным показателем достигнутой надежности будет допустимое число выявленных дефектов в течение определенного времени тестовой эксплуатации.
Оформление технического задания
Саму разработку ТЗ тоже можно рассматривать как проект. И в соответствии с этим подходом, она должна удовлетворять некоторым требованиям. Только в отличии от разработки программной системы, требования к ТЗ уже априорно определены. Все перечисленные выше разделы можно считать функциональными требованиями к ТЗ. В таком случае, нефункциональные требования - это то, как необходимо писать ТЗ, т.е. это требования к стилю изложения материала.
Прежде всего, ТЗ должно быть написано в полностью однозначных формулировках, чтобы их даже при желании невозможно было истолковать неправильно. Для этого стоит избегать субъективных характеристик. Нет никакого смысла писать о том, что разрабатываемый UI должен быть удобным, или красивым. Для каждого человека эти слова могут обозначать совершенно разные понятия. Обе эти характеристики вообще не имеет указывать в ТЗ, потому что любой исполнитель и без того будет стараться сделать красиво и удобно (в рамках согласованного бюджета, конечно). Однозначность изложения материала должна обеспечиваться даже в ущерб стройности изложения. Например, следует вообще избегать использования слов “он”, “она”, “его”, “ее” и так далее. Вместо них лучше повторно использовать явное наименование объекта. То есть не “Описание системы и ее предназначение”, а “Описание системы и предназначение системы”. Так менее правильно с точки зрения русского языка, но зато более однозначно.
Во-вторых, весь текст должен быть написан настолько просто, насколько это возможно. Без каких-либо украшательств и сложных оборотов. Просто писать - сложно. Но к простоте необходимо стремиться. ТЗ не является маркетинговым материалом, оно не должно произвести впечатление на читателя, у него другая цель: поставить задачу на разработку. И данная цель не будет достигнута, если исполнитель не правильно поймет формулировки. Но если все предложения и речевые обороты в ТЗ будут иметь примитивную форму, то это не помешает пониманию сути, а наоборот поможет.
И в-третьих, все используемые термины должны быть определены в словаре. Термины и сокращения должны однозначно пониматься обеими сторонами проекта: и заказчиком и разработчиком. Самый простой способ достичь этого - использовать словарь и список сокращений. При этом формулировки терминов тоже должны быть простыми и однозначными.
Заключение
Корректно сформулированное техническое задание существенно повышает шансы на успех разработки программной системы за счет более предметной коммуникации между заказчиком и разработчиком системы и позволяет более плодотворно разрешать спорные ситуации в ходе разработки и при ее завершении. Как известно, в хорошо сформулированной задаче уже содержится половина решения.
Компания “Бюро Ревью” поможет вам разработать качественное техническое задание для реализации вашей идеи.
Юрий Михайлов
08.09.2024
