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

Например, для бизнеса требование о возможности управления информацией о клиентах может включать от 100 до 200 функциональных требований. Одно из них может формулироваться как «Система должна предоставлять пользователю возможность создать профиль клиента», другое – «Система должна поддерживать в профиле клиента следующие 10 параметров:…» и так далее. Из таких требований четко становится понятно, какая функция системы ожидается, например, функция создания профиля пользователя. Это функциональное требование также обсуждается с клиентом и подписывается им.

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

В проектах по созданию крупных систем для поддержки бизнеса телекоммуникационных компаний, например, для одного модуля «система управления клиентами», может быть разработано 400-500 функциональных требований. При таких объемах информации создание документа, который хранит все связи между требованиями, становится абсолютно необходимым. Были случаи, когда именно благодаря этому документу удавалось находить несоответствия в связях и избавляться от ненужной работы, например, когда обнаруживалось функциональное требование, которое фактически не было связано ни с одним бизнес-требованием и, соответственно, уже не было актуальным, или когда бизнес-требование изменялось или удалялось после недавних обсуждений с клиентом.

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

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

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

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

Создание требований

Рассмотрим бизнес-требование: «Профиль компании должен содержать информацию о кредитоспособности компании». Это требование от бизнеса и клиента ясно формулирует необходимость проверки платежеспособности компании-покупателя перед совершением коммерческих операций с предоставлением товаров в рассрочку.

На основе этого бизнес-требования я разработал функциональное требование: «ФТ-СУК-КР-1. Система должна предоставлять на главной странице профиля компании обобщенную информацию о кредитном статусе клиента, включая кредитный статус, кредитный рейтинг и текущие кредитные условия».

Давайте разберём идентификатор этого требования: «ФТ-СУК-КР-1». «ФТ» означает «Функциональное Требование». «СУК» указывает на систему, к которой относится требование – Система Управления Клиентами. «КР» обозначает конкретный модуль или компонент системы – Кредитный модуль. Номер требования – 1. Правила создания таких идентификаторов позволяют легко определить, о чем идет речь в требовании. Текст требования может быть изменен, но идентификатор остается неизменным и играет ключевую роль в матрице связей/отслеживания и в любых других документах, связанных с этим требованием. Функциональное требование включает в себя несколько важных пунктов, каждый из которых имеет ключевое значение:

«Система» – это кажущееся простое слово подтверждает, что именно наша система должна реализовать указанную функциональность. Это утверждение дает 100% гарантию включения функции в систему.