Техническое задание является важной составляющей процесса разработки программного обеспечения. Как иногда шутят: “Без ТЗ – результат ХЗ”. Разумеется не под каждую задачу мы пишем техническое задание. Бывают случаи, что это просто нерентабельно. И проще с заказчиком обговорить требуемую функциональность и приступить к работе. Однако, когда дело касается объемной разработки, без технического задания не обойтись.
Порой мы используем для описания простой текст. Разуется разбавляя его скриншотами с различными стрелочками, выделениями и тому подобное. Ниже представлена картинка с примером:
Безусловно описанный выше способ используют большинство IT-компаний. Бывают случаи когда технические задания на разработку 1С занимают 100, 200 или 300 страниц. Документ проходит долгие стадии согласования с клиентом. В результате исполнитель и заказчик получают конкретные требования к информационной системе. Аналогично и мы используем этот способ. Однако когда дело касается сложной разработки новых модулей, большой объем информации сложно структурировать в текстовом документе. Мы для себя открыли, что удобно использовать “Интеллект-карты”, или как их еще называют MindMap.
Интеллект-карты позволяют выстроить иерархически описание требований. Таким образом очень просто ориентироваться в техническом задании как программисту 1С, так и аналитику. Очень удобно единожды описать общие правила разработки, сценарии тестирования. Например, мы использовали данный способ для описания задания на разработку 1С модуля “Строительство”. Данный модуль разрабатывается к программе 1С:Управление нашей фирмой и позволяет автоматизировать небольшие строительные компании.
Все мы знаем, что конфигурация 1С имеет иерархическую структуру, состоящую из справочников, документов. А внутри них находятся реквизиты, формы и так далее. Например, ТЗ на разработку документа 1С “План строительства” выглядит следующим образом:
Разработчик помечает зеленым цветом выполненные задачи. При необходимости вставляет примечания или вопросы, относительно задач, которые требуют уточнения. В результате мы получаем удобное взаимодействие разработчика, аналитика и тестировщика.
Автор статьи
