Как мы пишем ТЗ для SugarCRM

Для любой заказной разработки, будь то сайт-визитка из одной страницы или сложная учетная система с 50 модулями, обязательно должно быть написано техническое задание. Конечно же, техническое задание для сайта и для учетной системы будут совсем разные – как по объему, так и по содержанию.

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

В общем виде наше ТЗ можно разделить на несколько основных частей:

• Бизнес требования
• Функциональные требования
• Сценарии использования
• Технические требования

Бизнес требования должны содержать ответ на вопрос «Для чего внедряется CRM?». Цели внедрения, как правило, определяют руководители отделов, директора – т.е. лица, принимающие решение о финансировании проекта.

Бизнес требования могут включать в себя описания текущих проблем, которые надо решать при помощи CRM системы, и обязательно, хотя бы в двух словах, как эти проблемы будут решаться в CRM. Т.е. написать просто «увеличить производительность менеджера» - нельзя, а вот «увеличить производительность менеджера за счет автоматического создания и рассылки пакета документов» - можно.

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

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

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

На больших проектах у сценариев использования есть две очень важные вспомогательные функции:

• На основе сценариев зачастую удается выявить «пробелы» в функциональных требованиях
• По сценариям очень удобно составлять планы тестирования системы.

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

• Описание справочников (модулей) системы: какие поля на каких модулях на каких страницах должны быть, как выглядят формы поиска, как модули связаны между собой. Для проектов, где много новых справочников (от 10) мы обязательно рисуем блок схемы взаимосвязей модулей в системе, без блок схем в таких проектах есть большой риск в требованиях не учесть какие-нибудь взаимосвязи.
• Описание бизнес логики, например, что должно произойти если нажать на какую-то кнопку.
• Описание новых отчетов (какие фильтры у отчета, как должен выглядеть результат и как его подготовить, как должен выглядеть график)
• Описание дополнительных подключаемых модулей (не справочников), например, модуль интеграции с АТС
• Описание бизнес процессов

В итоге у нас получается вот такая "матрешка" требований:

1. Бизнес требования (маленькая матрешка)
2. Функциональные требования описывают, как в CRM будут реализовываться решения для бизнес требований (средняя матрешка)
3. Технические требования детализируют как будут реализованы функциональные требования в программном коде (большая матрешка)

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