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

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

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

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

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

Возможно, у вас возник вопрос: «Как, исходя из краткого и общего бизнес-требования, вы сформулировали такое детализированное функциональное требование? Откуда взялись детали о месте и содержании информации?». Часть ответа заключается в моем доменном опыте, о котором я упоминал ранее. Многолетняя работа в бизнесе и опыт использования различных бизнес-систем, которые обычно содержат похожий набор параметров и функций, позволяют мне предложить наиболее подходящий подход к информации о платежеспособности клиента для нашей системы.

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

Дизайн требования

Получив подписанное функциональное требование, я приступаю к разработке дизайна, который описывается в документе, называемом "Спецификация по функциональному дизайну" (Functional Design Specification). Стоит отметить, что подходы, описываемые здесь, адаптированы под конкретный проект и могут отличаться в зависимости от контекста.

Как начинается процесс? Сначала я создаю уникальный идентификатор для дизайна, например, ФД-СУК-КР-1. "ФД" здесь обозначает "Функциональный Дизайн". Затем формируется короткое название дизайна, которое будет использоваться как заголовок документа, например, "Просмотр кредитной информации на главной странице компании". Функциональное требование может соотноситься как с одним, так и с несколькими дизайнами.

Описание дизайна:

"Описание: Данный дизайн позволяет пользователю видеть основные кредитные показатели компании-клиента на главной странице профиля. Эта информация помогает в принятии решений."

Входные условия:

Для использования функциональности пользователь должен авторизоваться в системе СУК, выбрать компанию и перейти на её главную страницу.

Описание функциональности:

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

Шаги/Сценарий:

На странице профиля компании система отображает раздел «Кредитная информация».

В разделе «Кредитная информация» отображаются следующие поля/данные:

Кредитный рейтинг (название) – текстовое, неизменяемое.

Кредитный рейтинг (значение) – неизменяемое, цифровое, двузначное число с поддержкой десятичного значения, диапазон значений от 0 до 10.

Кредитный статус (название) – текстовое, неизменяемое.

Кредитный статус (значение) – неизменяемое, графическое отображение в виде круга с тремя цветами: красный, желтый, зеленый.

Кредитные условия (название) – текстовое, неизменяемое.

Кредитные условия (значение) – неизменяемые, три текстовых поля со значениями:

а) разрешенная рассрочка: «ХХ» месяцев;

б) статус контракта: «активен», «неактивен» или «истек»;

в) размер задолженности: «нет» или «размер задолженности».

Кредитная история (название) – текстовое, неизменяемое, оформлено как ссылка (функциональность вне границ этого дизайна, см. ФД-СУК-КР-4).

Заключение:

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

Изменение данных:

В данном дизайне изменение данных не предусмотрено, так как у пользователя нет возможности изменять представленную информацию.