Бизнес-анализ от а до я: гид для начинающих

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

Когда пользователь взаимодействует с системой, она реагирует на его запросы и действия определённым образом. Ожидания от реакции системы на использование определённой функции и называются функциональным требованием. Поскольку сначала создаётся система, а затем пользователь начинает пользоваться её функциями, мы называем это функциональным требованием. Это требование к тому, как должна работать функция системы, иначе система не будет нужна пользователю, если она не соответствует его функциональным требованиям.

Теперь перейдём к документированию дизайна функционального требования. Для начала уточню, что я подразумеваю под 'дизайном': это описание, спецификация или план, который демонстрирует, как должна работать или выполняться функция, чтобы соответствовать функциональному требованию. Интересный факт: если вы зададите вопрос в англоязычной поисковой системе о том, что значит слово 'design', то вам покажут определения, упоминающие 'план' или 'спецификацию' и 'функцию', даже не связанную с ИТ-сферой.

Почему акцент на документировании дизайна? Всё просто. Основная цель бизнес-аналитика почти всегда заключается в подготовке документа или артефакта для команды разработчиков, чтобы они могли создать систему именно так, как её планирует использовать пользователь. Наличие только функционального требования без дизайна не даст разработчикам необходимой информации о том, что именно нужно создать. В моей 10-летней практике я не встречал случаев, когда было бы иначе. Хотя в интернете можно найти мнения, что в рамках некоторых 'гибких' методологий разработки, продукты создаются именно так – разработчикам передаётся только требование, и они каким-то образом создают то, что нужно.

Процесс документирования дизайна может занимать различное время и объем работы. Одно требование может быть оформлено на полстраницы формата А4 и занять 30 минут для написания. Другое требование может распространяться на 10 страниц и требовать неделю работы.