Посвящается моему другу, коллеге и соавтору в совместных исследованиях Валерию Сушкову.

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

В процессе решения этой задачи бизнес-аналитика могут подстерегать следующие засады:

• Коммуникация с заказчиком или какими-то заинтересованными сторонами затруднена по  некоторым причинам. Например, заказчик находится далеко, у заказчика нет времени на коммуникации с бизнес-аналитиком и т.д.

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

Крайним случаем является ситуация, когда заказчик говорит бизнес-аналитику: «Делайте, как написано в договоре (уставе проекта, документе о границах проекта). Там же все понятно».

Процесс работы с требованиями

В системной инженерии [1] выделяют 2 уровня требований: требования заинтересованных сторон и системные требования.

У К. Вигерса [2] мы встречаем несколько другую классификацию, в которой выделяются бизнес-требования, требования пользователей и требования к продукту (системные и  функциональные требования, ограничения и т.п.). Для дальнейшего рассмотрения эти отличия являются несущественными.

Традиционная схема работы с требованиями предполагает, что сначала выявляются требования заинтересованных сторон (включая требования пользователей), а затем на их основании определяются требования к системе. При необходимости процесс повторяется; требования разных уровней уточняются и согласовываются друг с другом.

На следующем рисунке представлена общая структура требований. С помощью стрелок показана традиционная последовательность работы с требованиями.

Однако в ситуации, когда требования заинтересованных сторон плохо определены, традиционная схема не очень-то работает.

Например, заказчик решил создать новый бизнес – платежную систему в Интернете типа PayPal или Yandex-деньги. Рамки проекта включают разработку приложения для такой платежной системы. Все попытки бизнес-аналитика выяснить требования заинтересованных сторон свелись к получению общего ответа заказчика: «Мы пока не можем предоставить более четкие требованиям, потому что сами не знаем».

Реверсивный анализ требований

Опытные бизнес-аналитики могут определить требования к системе, используя знания об аналогичных системах (продуктах), изучая системы конкурентов, создавая и исследуя прототипы и т.п. Действуя так, они применяют реверсивный анализ требований.

Схема процесса работы с требованиями при реверсивном анализе предполагает, что сначала выбирается аналог проектируемой системы, на основе аналога определяются требования к системе, а затем по этим требованиям восстанавливаются и согласовываются требования заинтересованных сторон.

На следующем рисунке представлена общая структура требований с требованиями из аналогов. С помощью стрелок показана последовательность работы с требованиями при реверсивном анализе.

 

В рассматриваемом примере с приложением для платежной системы бизнес-аналитик может проанализировать аналоги – приложения PayPal и Yandex-деньги — и сформулировать требования к приложению.

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

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

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

Заключение

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

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

Реверсивный анализ можно проводить параллельно с традиционной работой с требованиями. В тех случаях, когда на проекте работает несколько аналитиков, проведение реверсивного анализа можно поручить отдельному аналитку. На следующем этапе результаты анализа требований заинтересованных сторон, полученные по традиционной схеме (через коммуникацию), будут объединены с результатами реверсивного анализа.

Опытные аналитики часто используют реверсивный анализ для восстановления пробелов и неопределенностей в требованиях заинтересованных сторон. Для таких аналитиков может быть интересным более мощный инструмент реверсивного анализа – метод Value-Conflict Mapping Plus [3], который позволяет не только восстановить плохо определенные требования заинтересованных сторон, но и выявить скрытые противоречия в таких требованиях.

Ссылки

1. Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004

2. Вигрес К. Разработка требований к программному обеспечению. Microsoft Press, 2004

3. Kuryan A., Souchkov V. Value-Conflict Mapping Plus (VCM+): Adding Business Dimensions. TRIZfest-2014.

 

Автор: Андрей Курьян, бизнес-аналитик