Бизнес-анализ от а до я: гид для начинающих
Шрифт:
В проектах по созданию крупных систем для поддержки бизнеса телекоммуникационных компаний, например, для одного модуля «система управления клиентами», может быть разработано 400-500 функциональных требований. При таких объемах информации создание документа, который хранит все связи между требованиями, становится абсолютно необходимым. Были случаи, когда именно благодаря этому документу удавалось находить несоответствия в связях и избавляться от ненужной работы, например, когда обнаруживалось функциональное требование, которое фактически не было связано ни с одним бизнес-требованием и, соответственно, уже не
По мере работы я начал самостоятельно формулировать функциональные требования к новым бизнес-требованиям, освоив процесс за 3-4 недели. Я уже мог понимать, как из бизнес-требования формируется функциональное требование и впоследствии превращается в дизайн.
Ранее я кратко упомянул о своих рабочих активностях в течение дня. Теперь я хочу рассмотреть их под другим углом и поделиться процессом создания конкретных артефактов на примере, как я разрабатывал функциональное требование и документировал дизайн для него. Эти примеры вымышлены и созданы мной для наглядности; они не содержат коммерческой информации.
Сейчас мои личные ощущения таковы, что процесс создания функционального требования и дизайна к нему по своей структуре не сильно изменился со временем. Изменились инструменты, формат и терминология стали более современными, но подход и акцент остались прежними. Если бы я сейчас вернулся к работе над проектом с аналогичным контекстом, методологией и условиями, скорее всего, я бы использовал тот же подход к созданию и написанию требований/дизайна, что и десять лет назад.
Сейчас, спустя полтора-два месяца работы в качестве бизнес-аналитика в моей первой ИТ-компании, я начинаю создавать функциональные требования для новых компонентов системы. Под 'новыми' я имею в виду, что теперь я несу ответственность за разработку требований на основе заранее подготовленных и утвержденных с клиентом бизнес-требований для всех новых компонентов. Моя задача состоит в том, чтобы создать функциональное требование и разработать дизайн к нему.
Создание требований
Рассмотрим бизнес-требование: «Профиль компании должен содержать информацию о кредитоспособности компании». Это требование от бизнеса и клиента ясно формулирует необходимость проверки платежеспособности компании-покупателя перед совершением коммерческих операций с предоставлением товаров в рассрочку.
На основе этого бизнес-требования я разработал функциональное требование: «ФТ-СУК-КР-1. Система должна предоставлять на главной странице профиля компании обобщенную информацию о кредитном статусе клиента, включая кредитный статус, кредитный рейтинг и текущие кредитные условия».
Давайте разберём идентификатор этого требования: «ФТ-СУК-КР-1». «ФТ» означает «Функциональное Требование». «СУК» указывает на систему, к которой относится требование – Система Управления Клиентами. «КР» обозначает конкретный модуль или компонент системы – Кредитный модуль. Номер требования – 1. Правила создания таких идентификаторов позволяют легко определить, о чем идет речь в требовании. Текст требования может быть изменен, но идентификатор остается неизменным и играет ключевую роль в матрице связей/отслеживания и в любых других документах, связанных с этим требованием. Функциональное
«Система» – это кажущееся простое слово подтверждает, что именно наша система должна реализовать указанную функциональность. Это утверждение дает 100% гарантию включения функции в систему.
«должна» – ключевое слово, указывающее на обязательность поддержки функциональности системой, в отличие от формулировок «может» или «будет». Такая точность важна, так как любая неоднозначность может стоить значительных сумм, а разные трактовки могут использоваться как заказчиком, так и исполнителем.
«на главной странице…» – указывает на конкретное местоположение и содержание функции, что помогает точно определить, где именно будет реализована функция в интерфейсе.
«информацию о:…» – здесь конкретно перечисляются параметры, которые должна отображать система. Это может включать параметры, которые обязательно будут реализованы, а также те, которые могут быть добавлены позже, если это будет возможно в рамках проекта.
Таким образом, мы подробно описываем каждый аспект требования, обеспечивая его полную прозрачность и предотвращая возможные недоразумения в будущем. Так формируется функциональное требование.
Возможно, у вас возник вопрос: «Как, исходя из краткого и общего бизнес-требования, вы сформулировали такое детализированное функциональное требование? Откуда взялись детали о месте и содержании информации?». Часть ответа заключается в моем доменном опыте, о котором я упоминал ранее. Многолетняя работа в бизнесе и опыт использования различных бизнес-систем, которые обычно содержат похожий набор параметров и функций, позволяют мне предложить наиболее подходящий подход к информации о платежеспособности клиента для нашей системы.
Вторая часть ответа касается процессов, связанных с документированием требований. Помимо написания самого документа, в процесс включены коммуникационные действия, такие как обсуждение требований, их обновление и подписание. Написанное мной функциональное требование не будет сразу же переведено в дизайн. Сначала оно пройдет внутреннее обсуждение с моим ведущим бизнес-аналитиком, в ходе которого могут быть внесены правки. Затем следует обсуждение с клиентом, возможные дополнительные изменения и окончательное подписание требования. Только после всех этих этапов начнется документирование дизайна для этого функционального требования.
Дизайн требования
Получив подписанное функциональное требование, я приступаю к разработке дизайна, который описывается в документе, называемом "Спецификация по функциональному дизайну" (Functional Design Specification). Стоит отметить, что подходы, описываемые здесь, адаптированы под конкретный проект и могут отличаться в зависимости от контекста.
Как начинается процесс? Сначала я создаю уникальный идентификатор для дизайна, например, ФД-СУК-КР-1. "ФД" здесь обозначает "Функциональный Дизайн". Затем формируется короткое название дизайна, которое будет использоваться как заголовок документа, например, "Просмотр кредитной информации на главной странице компании". Функциональное требование может соотноситься как с одним, так и с несколькими дизайнами.