### Хорошее ТЗ это
1. Документ с идеями. Должно содержать принятые идеи.
1. Документ для разработчика. Должно быть настольным пособием для разработчика, на которое он должен ориентироваться, по нему работать.
1. Документ для заказчика. Поскольку заказчик может всегда проконтролировать, то что он получился сравнить с ТЗ и сказать, что мы вот так договаривались, давайте так двигаться дальше и т.д.
1. Юридический документ. Как правило, ТЗ прикладывают к договору, на основании ТЗ закрываются актами разные работы.
**Основная задача ТЗ –помочь создать качественный продукт**
ТЗ отвечает на вопрос "Что нужно реализовать". Здесь нет вопроса "как нужно реализовать", так как это хлеб разработчиков т.д. Оно дает разработчикам логику, оно дает им возможность не думать в той области на которую они не заточены, потому что разработчики не должны разбираться в бизнес требованиях, разбираться в потребности заказчиков, ему важно разбираться с задачей как реализовать то или иное решение и ТЗ дает хлеб разработчику.
### Прежде чем садиться за ТЗ, нужно разобраться с задачами.
Любой продукт выполняет задачи своего владельца. Задачи упираются в деньги или задачи бизнеса. И у нас есть пользовательские задачи. Пользователь выполняет свои задачи и генерит профит Заказчику - все довольны. Мы записываем задачи перед написанием ТЗ.
Например. Ферма катания на животных, создание заявок и т.п.
После того как мы составили задачи нашего продукта, дальше нам нужно подготовить пользовательские задачи. Для этого мы берем целевую аудиторию и придумываем живого человека, прописываем его и через его глаза прописываем задачу, которую он выполняет. И это НАДО ПРОГОВАРИВАТЬ с Заказчиком, так как он добавит мелочей, которые очень важны.
### Архитектура и Бумажный Тигр
Многие после этапа аналитики, начинают писать ТЗ, но пока мы должны заняться архитектурой проекта. Мы начинаем описывать всё по верхам.
* Структура системы. Какие есть компоненты. 
* Интерфейсы. Это не прототипы, а условные схемы. Указываем разные моменты. 
* Логические схемы. 
* Структуры данных
* Связь с внешними ресурсами.
Бумажный Тигр документ, который мы распечатываем на бумаге, привозим к Заказчику, перечеркиваем, перерисовываем совместно и не уходим, пока мы не добьёмся своего.
После согласования Бумажного Тигра переходим к разработке прототипов. Это схематичное отображение страниц, которое не отображает конкретного расположения элементов и отвечает только за наличие элементов, их общую логику и приоритет.
Крайне важно выдержать золотую середину - между прототипом и перебором картинок с цветами и анимацией. Этого делать не нужно.
Поле согласования прототипов мы начинаем делать дизайн-макеты. И только тут наступает красота. Почему перед ТЗ? Так как мы создаем ненужные ограничения и решения для дизайнера. И вот теперь приступаем к написаю ТЗ. ТЗ у нас завершает этап работы над продуктом и завершает этап дизайна.
### Требования к хорошему ТЗ
* однозначность.
* отчуждаемость. Написано так, чтобы разработчик из другой компании смог реализовать. Не нуждается в трактовке мудрецами.
* полнота. Вся необходимая информация для реализации продукта во всех его аспектах.
* системность. Требования должны быть описаны с разных сторон и ракурсов и давать полную картину.
* опрятность. Один шрифт, один цвет, правильная нумерация.
### Содержание хорошего ТЗ
ТЗ должно обладать следующей структурой.
С одной стороны ТЗ должно описывать внутренние шестеренки продукта, с другой стороны описывать интерфейсы, поскольку это неотъемлемая часть нашего продукта, с другой стороны описывать все то что лежит вне нашего продукта и это как-то увязывать между собой потому один из принципов - Системность.
Например
1. Общие положения
1. Назначение документа. Цель написания ТЗ. Формальности, обязательная часть.
1. Структура документа. Чтобы человек знал с чего начать.
1. Используемые термины
2. Технические требования.
1. Общие требования. Какие браузеры, адаптивная верстка.
1. Требования к системе. Требования к нагрузке и серверам.
1. Требования к верстке. Стандарты по которым работает верстальщик.
1. Требования к безопасности. Требования к устойчивости к DDoS, вирусные активности. Текущие реалии с РКН, Персональные данные, удаление запрещенной информации без остановки всей системы.
1. Прочие требования. Интеграция с внешними системами
3. Идеология. Общая идеология продукта. Полезно для тех, кто впервые видит наше ТЗ.
1. Какой продукт мы разрабатываем.
2. Задачи заказчика.
3. Целевые пользователи.
4. Архитектура системы. Разделы и взаимодействие. 
1. Дерево сайта
2. Описание шаблонов
3. Описание страниц к привязке к шаблонам.
5. Шаблоны интерфейсов. Когда мы описываем различные интерфейсы ТЗ, мы постоянно их привязываем к определенным сущностям. 
6. Функциональные сценарии. Поведение системы, результат, исключения, прочие вещи. Ссылаемся на бизнес правила. 
7. События. Не завязаны на действия пользователя, ссылаемся на правила бизнес. Например, заказчик решил, что заявки должны хранится 365 дней, пришло событие и мы их удаляем. 
8. Бизнес-правила. Например, заказчик решил, что заявки должны хранится 365 дней.
9. Структура данных. Это не описание Базы данных. Разработчик делает так как считает нужным. 
10. Справочники. Географические локации, категории товаров и т.д. Справочник должен опираться на наши сущности. 
11. Протоколы связи с внешними системами
12. Требования к системе администрирования. Описываем какими возможностями должна обладать админка, без привязки к интерфейсам, так как многие решения содержат минимальный набор для неё. 
### Последовательность написания ТЗ.
1. Интерфейс
2. Функционал
3. Структуры данных
4. Всё остальное
### А что делать дальше?
Обучать клиента работать с ТЗ. Надо садиться с ним и общаться, разбираться.
**Важно! ТЗ не должно всем нравиться - это инструмент, который должен выполнять свои задачи**