Как составить техническое задание?

  • Печать

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

Мы будем рассматривать написание ТЗ именно к разработке или модернизации информационных систем.

ТЗ содержит основные технические требования, предъявляемые к информационным системам и исходные данные для разработки; в ТЗ указываются назначение каждого объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т. п.) документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.

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

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

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

Цели проекта. Цели должны быть четко сформулированы. Желательно донести в этой части до Исполнителя за счет чего Вы собираетесь извлекать прибыль или что конкретно заставит Заказчика почувствовать удовлетворение от результатов проекта. Невозможно написать теническое задание без пробелов или неопределенностей. Исполнитель часто не может обратиться к Заказчику для прояснения того или иного момента технического задания, поэтому он аппелирует к Целям проекта. Кроме того при составлении технического задания Исполнителю легче предлагать решения, потому что он заранее может определить способствует то или иное решение достижению целей проекта или нет.

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

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

Допущения и ограничения. Как правило, этот раздел заполняется Исполнителем, однако, Заказчику тоже важно знать о назначении этого раздела. Любая разработка программного обеспечения ведется в некоторых ограничениях. Это позволяет не раздувать стоимость до бесконечности, а также довести проект до логического конца. В этом разделе перечисляют как правило следующие допущения и ограничения: перечисляется функциональность выходящая за рамки проекта, задачи выходящие за рамки проекта, технические ограничения, зависимости от внешних условий, которые могут повлиять на принятые обязательства.

Несколько правил для написания технического задания:

Правило первое: расписывать все, что только возможно. Для того, чтобы у вас с программистом были нормальные деловые отношения, стоит расписывать каждый шаг, который должен сделать программист. Иначе вы можете получить продукт, совершенно отличающийся от того, который вы задумали. Затем придется все переделывать, а это дополнительные затраты и время. А сейчас временем нужно дорожить. Поэтому стоит потратить один вечер для написания технического задания, и еще один вечер для его проверки. Если вы забудете что-то написать – это уже ваши проблемы. За вас программист ничего не будет додумывать. Он сделает так, как вы ему написали.

Правило второе: стоит делать пометки и рисунки. Не думайте, что сказать «сделай отчет по остаткам товара» будет достаточным, если вы хотели получить какие-либо определенные данные в отчете, возможность отборов и группировок в нем. Все это нужно либо нарисовать на обычной бумаге, если вы будете видеться с программистом, либо сделать электронный рисунок, наприме. в Excel-e. Так вы сможете быть уверенным, что работа по внешнему виду будет именно такой, как вы хотели.

Правило третье: никогда не пишите большое техническое задание. Большие задания сложнее выполнять. Это как задачи по математике. Большую стоит решать долго, чем маленькую. Так и программистам. Лучше делать много небольшой работы, чем одну но большую. Вам в этом тоже есть выгода. Вы будете видеть, насколько быстро программист выполняет задание, но главное не скорость, а насколько качественно. Если выполнение будет на высоком уровне, значит можно с каждым разом усложнять технические задания.

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