Что такое ТЗ и с чем его едят?

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

• - чтобы описать цель работы. Каждая из сторон должна адекватно воспринимать поставленную цель. Ведь так может быть, что на разговоре два человека иногда плохо понимают друг друга, а после выясняется, что вообще все плохо, т.е. заказчик зря тратил деньги, а разработчик насиловал свой мозг по ночам.
• - чтобы описать задачи проекта. Для реализации даже самого просто проекта требуется решение ряда задач, так вот эти самые задачи должны быть по силам в решении разработчику и пределах финансирования заказчика.
• - чтобы определить отношения «заказчик – исполнитель». Можно сказать, самый важный пункт. В нем описывается срок исполнения, денежные суммы, форматы сдачи/приема и еще много других нюансов, которые все могут понадобиться при разрешении конфликтов.

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

Как правильно составить ТЗ?

Сейчас внимательно слушаем, а точнее читаем, я попытаюсь подразделить все техническое задание на разделы, конечно все очень обобщенно, но все же. Кстати, если уж совсем неймется и очень хочется вникнуть во все ГОСТы, стандарты и прочую волокиту, то милости просим на Вики!

- Общие положения. Составляя раздел «Общие положения» следует полно и развернуто описать глоссарий, потому что нужно помнить о том, что Заказчик и Исполнитель не учились на одном факультете (за исключениями) и первый не всегда может понять Ваши: «register_globals  включены!

Это может быть опасным!» Используя глоссарий, обе стороны  могут беспрепятственно понимать разговор о той или иной теме, а что в свою очередь способствует уменьшению затрат времени, а соответственно и денег.

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

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

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

Чтобы ознакомится лучше со сценариями использования, можно почитать тут

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

- Специальные требования:

• 1. Стандарты. Любой проект должен удовлетворять стандартам, будь то стандарты общего назначения (XHTML1. 0, CSS 2. 1 и др. ) или же стандарты эргономики (ISO/TR 16982:2002)
• 2. Системные требования. У каждой проектируемой системы есть свои системные требования, например, объем требуемой памяти.
• 3. Отказоустойчивость. Дублирование системных элементов, изучение и журналирование ситуаций по отказам или сбоям системы, способность восстановления системы после сбоя.
• 4. Требования по производительности системы. Возможность обрабатывать определенное количество пользователей,  как для примера.
• 5. Требования по безопасности системы.
• 6. Требования к пользовательскому интерфейсу.

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

- Риски. При организации любого проекта, возникают факторы, которые прямо или косвенно могут влиять на стоимость и сроки выполнения работ.

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

Итак подведем итоги:

Я немного напомнил себе и Вам что такое ТЗ.  Мотивировал себя к действию по исполнении заказа на сайт.  Скажем, для начала я доволен, со временем может и писателем стану...