19.02.2013 Как написать Техническое Задание

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

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

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

1. Вариант 1 «ТЗ, которое нужно ПМ-у от заказчика»

Вот разделы, которые важны для ТЗ от заказчика. Информация, предоставляемая в этих разделах, помогает менеджеру проекта или аналитику правильно спроектировать систему.


- Виденье. В этом разделе должно быть чётко описано, почему понадобилась автоматизация. Например, что сейчас неудобно при выполнении бизнес-задач без системы. Какие задачи вообще не выполняются, и не могут быть выполнены без системы. Какие цели предполагается достичь с помощью автоматизации.

- Бизнес-процессы. Нумерованный список бизнес-процессов, шаги которых требуется автоматизировать. Для каждого процесса – чёткий перечень шагов. При описании процесса важно не смешивать ответвления и исключения (расширения) с основным сценарием. Шаги, в которых есть расширения необходимо пометить, а сами расширения описать отдельно.

Описывать процессы допускается двумя способами: 

• 1) как есть сейчас, т.е. без системы; 
• 2) как должно быть, т.е. с системой;

Независимо от выбранного способа каждый шаг бизнес-процесса должен быть сформулирован следующим образом: <исполнитель> <делает>. Например, «Менеджер отдела продаж высылает запрос на создание нового заказа в отел закупок».

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

- Роли пользователей. Перечень пользователей, и какие задачи будут выполнять с помощью системы (варианты использования системы). По сути, перечисляются шаги бизнес-процессов, которые должны выполняться с помощью системы. Каждый шаг коротко описывается, чтобы подчеркнуть, как именно он будет выполняться с помощью системы, и какой от этого ожидается положительный эффект.

В этом же разделе указываются права пользователей.

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

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

2. Вариант 2 «ТЗ, которое нужно дать программисту»

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

- Назначение системы и краткое описание предметной области. Этот раздел должен быть кратким и ни в коем случае не должен содержать всю информацию раздела «Виденье» из ТЗ от заказчика.

- Роли пользователей. Список ролей и список вариантов использования. Варианты использования не расшифровываются. Этот раздел нужен программисту, чтобы он смог примерно оценить общий объем работ. Неплохо нарисовать несложную UML-диаграмму – как правило, придаёт наглядности.

- Сущности системы. Здесь необходимо перечислить список основных сущностей системы и связей между ними. По каждой сущности набор полей. Также желательно перечислить справочники системы. Данный раздел поможет программисту правильно спроектировать БД.

- Бизнес-модули. Должен быть приведен список модулей и краткое описание каждого модуля. Например, модулями могут быть следующие: «Склад», «Договора», «АРМ бухгалтера». Неплохо по каждому модулю перечислить список хотя бы основных задач.

- Задачи по каждому модулю. Детальное описание каждой задачи с приведением экранных форм.

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