Как правильно составить техническое задание для разработки ИТ-системы

О том, как качественно и понятно составить техническое задание рассказывает старший эксперт практики ERP SAP группы компаний Лига Цифровой Экономики, Екатерина Синица.

ТЗ предназначено для окончательного формулирования требований к продукту проекта, в нашем случае – к информационной системе (ИС). Большинство проблем, связанных с разработкой и согласованием ТЗ, вызвано неполным охватом всех видов требований при их анализе. Напомним, они делятся на функциональные (требования к тому, ЧТО должна делать ИС) и нефункциональные (требования к тому, КАК должна функционировать ИС).

При анализе функциональных требований аналитик сталкивается со всем многообразием проблем нечеткого и неполного формулирования требований заказчиком. Чтобы обеспечить их полноту и непротиворечивость, полезно выстраивать иерархию (дерево) требований, на вершине которой будет цель проекта, на следующем уровне – бизнес-требования (понимание, зачем данная ИС нужна и какие бизнес-потребности удовлетворяет), еще ниже, раскрывая каждое бизнес-требование, будут располагаться пользовательские требования (бизнес-сценарии, user stories или use cases), а в самом низу – детальные функциональные требования с описанием действий ИС в каждом конкретном сценарии.

Анализируя нефункциональные требования, чаще всего забывают или недостаточно хорошо прорабатывают требования к интеграции со смежными системами. Чтобы снизить этот риск, необходимо привлекать к разработке ТЗ архитектора ИС и изучать ИТ-ландшафт заказчика.

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

Отдельная и очень большая проблема при анализе нефункциональных требований к ИС – работа с требованиями к интерфейсам. Здесь часто можно встретить слова об «удобстве», «эстетической привлекательности», «соответствии мировым тенденциям дизайна» и прочие образцы нечетких, субъективных, непроверяемых требований, реализовать и протестировать которые, вероятнее всего, не удастся. Лекарство от этой беды – детализация (попробуйте вместе с заказчиком расписать по пунктам, что означает требование «удобство для пользователя») и нахождение подходящих шкал для оценки степени реализации каждого такого требования. Иногда удается найти объективную, всеми признанную шкалу – например, взять цветовую схему интерфейса из корпоративного брендбука заказчика.

Частой ошибкой при разработке ТЗ является недостаточная детализация требований. Настройки и сценарии работы с ИС могут быть описаны слишком общо и поверхностно, целевые процессы формализуются на слишком высоком уровне. И когда дело доходит до реализации этих требований, у разработчиков возникает огромное количество вопросов. Чтобы дать максимально качественный результат этапа проектирования в виде ТЗ, целесообразно проводить:

1) Структурный анализ – моделирование структуры, понимание компонентов ИС и взаимосвязи между этими компонентами;

2) Анализ процессов – моделирование рабочего взаимодействия всех участников процесса, в котором предполагается задействовать ИС;

3) Функциональный анализ – моделирование всех возможных сценариев работы ИС и ее взаимодействия с акторами (пользователями) и смежными системами;

4) Информационный анализ – моделирование структуры данных (выделение объектов и их атрибутов, определение взаимосвязей между объектами) и потоков прохождения этих данных по процессам;

5) Анализ интерфейсов – моделирование (а в идеале прототипирование) пользовательских интерфейсов, проектирование рабочих мест пользователей.

Ошибки проектирования хорошо видны задолго до начала разработки, если мы пытаемся представить себе механизм их проверки. Неслучайно в ГОСТ 34.х документ «Программа и методика испытаний» является приложением к ТЗ. Настоятельно рекомендуется формировать сценарии тестирования ИС одновременно с фиксированием требований к этой ИС. Это позволит существенно повысить качество проектирования.

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

1. Банальное непонимание технических нюансов. Заказчик не будет подписывать то, что ему непонятно. Он передаст ТЗ на согласование в смежные структуры, профильные подразделения, экспертам и специалистам всех смежных служб – и этот процесс может затянуться на несколько месяцев. Такой проблемы может не возникнуть, если до начала согласования ТЗ, а в идеале – до начала его разработки, вы с заказчиком договоритесь о формировании рабочей группы, в которую войдут специалисты всех служб клиента, с которыми нужно будет согласовать документ. Этих людей вы будете задействовать в качестве источников требований, их мнению основной заказчик сможет доверять.

2. Страх, что после утверждения ТЗ будет невозможно внести изменения в требования к результатам проекта. Чтобы снять эти опасения и иметь возможность делать проекты в постоянно меняющейся бизнес-среде, были сформулированы принципы гибкой разработки Agile Manifesto. Но не все заказчики знают эти принципы, и не все команды им следуют. Лучше в самом начале договориться с заказчиком о порядке управления изменениями в требованиях на протяжении всего проекта. Тогда и для вас, и для заказчика согласованное ТЗ станет основой, «печкой» для начала разработки ИС, но ни в коей мере не терминальным ограничением на ее функциональность.

3. Базовое недоверие к поставщику. Заказчик может бесконечно долго вычитывать и придираться к малейшим шероховатостям в тексте ТЗ только потому, что ему кажется, что исполнитель некомпетентен, неаккуратен и все сейчас сломает. Этот страх снимается только опытом взаимодействия с данным клиентом. Именно поэтому так важна лояльность старых заказчиков – с ними и ТЗ быстрее согласовываются, и проекты легче делаются. Работая с заказчиком впервые, не экономьте на прототипах – если он увидит, что вы и впрямь умеете делать крутые решения, доверие к вашей команде возрастет.

Форматирование. Как ни странно, очень много сил и времени у команды может уйти на переделывание ТЗ в тот формат, который нужен заказчику. Рекомендуется заранее, до начала разработки ТЗ, согласовать с клиентом формат, а в идеале попросить в качестве шаблона ранее согласованное ТЗ по схожему проекту.

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

Внутреннее согласование. Очень часто разработчиков и тестировщиков не приглашают к согласованию ТЗ. А это неправильно, потому что только эти специалисты смогут вовремя заметить существенные ошибки, которые заказчик, весьма вероятно, пропустит.

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

a. ГОСТ серии 34.х и 19.х;

b. Стандарты ИСО/МЭК по системной инженерии;

c. Методологии внедрения конкретного ПО (ASAP, MSF, RUP и т. д.);

d. Рекомендации Свода знаний по бизнес-анализу (BABOK).