Структура технического задания для сайта

Титульный лист (позволяет понять, что это за документ за несколько секунд)

• название системы (позволяет понять, про что будет повествование дальше)

• автор ТЗ (нужно для того, чтобы понимать, кто отвечает за сие творение)

• дата написания ТЗ (очень необходимо, чтобы понимать насколько актуальная версия функционала отличается от того, что написано в доке)

• доп. информация при необходимости (здесь может быть подпись руководителя, заказчика, комиссии по подготовке ТЗ, виза тестировщика итп., в зависимости от фантазии исполнителя)

Содержание (полезная штука, если в ТЗ более 3-х листов)

1.       Общие сведения (здесь пишем важные формальные и неформальные вещи)

1.1. Назначение документа (зачем эта дока пишется, что в ней догма, а что нет, как её читать)

1.2. Цели разработки (зачем разрабатывается функционал, обычно, здравая цель выражается в долларах)

1.3. Используемые термины (все непонятные для заказчика слова, сокращения и аббревиатуры, которые будут использоваться по тексту)

2.       Общие требования к системе (здесь пишем много, казалось бы, кэповских вещей, которые, в последствии, спасут наши буйные головы)

2.1. Хостинг/Сервер (конфиг железки, конфиг программ, которые должны быть на этой железке, чтобы система работала как часы)

2.2. Требования к дизайну (цвет, шрифт, отступы, картиночки и всё такое, на что должен обратить внимание дизайнер перед включением полёта фантазии)

2.3. Требования к вёрстке (как должна работать вёрстка на разных устройствах в разных браузерах, на разных разрешениях)

2.4. Требования к контенту (кто предоставляет контент, на каком языке, что можно писать, а что нельзя, кто отвечает за опечатки)

2.5. Требования к работе фильтров (если есть поиск или каталог, скорее всего, есть фильтры. А фильтры, малята, - это дикая логика их совместной работы и лучше эту логику досканально прописать, чтобы потом не переделывать сто раз)

2.6. Требования к работе веб-форм (как происходит валидация, как форма реагирует на успешную отправку данных, какие масочки должны быть в полях)

2.7. Требования к работе пагинации (если есть каталог чего-либо, то есть пагинация, и важно на старте понимать, как эта пагинация будет работать: постранично, с автоподгрузкой, с подгрузкой по кнопке или ещё как?)

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

4.       Ролевая модель (общее описание того, какие роли есть в системе. Роли, малята – это пользователи, сценарии работы которых с системой отличаются. Если Васе доступна админка, а Петя может только посмотреть главную страницу – это две разные роли).

5.       Роль 1.

5.1. Основной пользовательский кейс для роли 1 (пользовательский кейс, он же сценарий, показывает от начала до конца, как пользователь с этой ролью должен работать в системе. Для одной роли может быть несколько таких кейсов. Не стесняйтесь, описывать нужно каждый и подробно).

5.2. Интерфейсы для роли 1 (в процессе реализации кейса пользователь взаимодействует с системой через интерфейсы (картинки, кнопочки, ссылочки, стрелочки. Интерфейсы нужно описывать, о чём скажем ниже).

5.2.1.       Общие элементы интерфейсов для роли 1 (обычно, есть общие элементы для интерфейсов одного раздела системы, вот тут их и описываем, чтобы ниже не писать по сто раз одно и то же. Например – шапка, подвал, меню, и тп.)

5.2.2.       Интерфейс 1. Логика работы элементов интерфейса (вот тут описываем всё, что наш любимый пользователь увидит на своём экране до перехода к следующему экрану. Описываем поэлементно, каждую кнопочку, ссылочку. Желательно с картинками из прототипа. Если есть какая-то логика работы у какого-то элемента (типа, если погода хорошая, то кнопка - зелёная), обязательно должно быть описано).

5.2.3.       Интерфейс 2. Логика работы элементов интерфейса.

5.2.4.       …..

6.       Роль 2.

6.1. Основной пользовательский кейс для роли 2.

6.2. Интерфейсы для роли 2.

6.2.1.       Общие элементы интерфейсов для роли 2.

6.2.2.       Интерфейс 1. Логика работы элементов интерфейса.

6.2.3.       Интерфейс 2. Логика работы элементов интерфейса.

6.2.4.       ……

7.       Роль N.

8.       Система уведомлений (здесь описываются все уведомления, которые ходят в системе (уведомления на почту, SMS, в какой-нить колокольчик, куда угодно). Должно быть чётко понятно: ЧТО отсылать, КОМУ отсылать, КОГДА отсылать).

9.       Система отчётов (как правило, любая мало-мальски сложная система связана с какими-то штуками, которые хочется считать, агрегировать, анализировать и тп. Вот отсюда и вырастает система отчётов. Здесь нужно описать, какие будут фильтры у отчётов, какие будут поля у отчётов, в каком формате они будут доступны, кому будут доступны и т.п.)

10.   Система логирования (если система сложная, неизбежны ошибки разного рода. Чтобы понимать, в чём косяк, иметь возможность проводить расследование, нужно писать систему логирования. В этом разделе должно быть описано, ЧТО логировать, КОГДА логировать, СКОЛЬКО хранить, КОМУ доступны логи).

11.   Интеграция с внешней системой 1 (в нашем диком мире всё взаимосвязано, посему, не надейтесь, что вашу систему участь интеграций обойдёт стороной. В этом и последующих разделах мы описываем, с какими внешними системами и, самое главное, КАК мы будем интегрироваться, тобишь - дружить. Дружить системы могут только по правилам, правила – это протокол или API. Вот и пишем здесь по каким правилам будет дружба нашей и какой-то внешней системы (по сути, тут чаще всего путь один: у внешней системы уже есть свои правила и нам нужно научить свою систему их понимать).

12.   Интеграция с внешней системой N.

13.   Порядок приёмки системы (немаловажный пункт, если доверия к заказчику не так много (например – это первый проект и мы не знаем, как заказчик себя поведёт). Необходимо максимально понятно и без разночтений прописать, как мы будем сдавать систему, что считается ошибкой, какие ошибки критичные, какие нет, как долго система будет на гарантии и будет ли вообще, какие условия гарантии).