Или как формулировать бизнес-требования от ее лица

Привет! Меня зовут Саша, я бизнес-/системный аналитик в Касперском. Я занимаюсь анализом уже больше пяти лет и за это время я принял участие в различных проектах – от разработки системы поддержки принятия управленческих решений до развития системы заказов. В этой статье я хотел бы поделиться своими мыслями на тему формулирования бизнес-требований для описания поведения Системы.

Базовые правила

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

1. Не опускаться на уровень реализации. Каждое требование фиксирует возможность, действие или проверку, которые приносят значимый для бизнеса результат.

2. Больше говорим о пользователе, ведь именно он и будет потребителем того самого результата. Описываем, что он должен делать в рамках нашего решения, что может делать, что ему вообще недоступно.

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

Но все же - в каких случаях мы пишем от лица Системы? Давайте разберем.

Выполнение проверок

Как только появляются какие-либо проверки или, тем более, расчеты, мы должны однозначно понимать, кто их выполняет. А так как мы по-прежнему говорим о бизнес-требованиях, то и оперировать мы должны исключительно бизнес-терминами. Как следствие, формулировка будет звучать примерно так: «Система должна выполнить проверку такую-то». А теперь попробуем детализировать.

В первую очередь, мы описываем проверки крупными мазками, без детализации до системного уровня. Например: «Система должна поверить статус заказа: если заказ находится в статусах A или B, то происходит следующее». Никаких «если OrderStatus IN (A, B)» – бизнес-заказчик скорее всего просто не поймёт нас.

Второй важный момент – мы всегда должны фиксировать, что будет, если проверка не выполнена. В бизнес-требованиях удобнее всего использовать слово «иначе». Например: «Система должна проверить статус заказа: если заказ находится в статусах A или B, то происходит следующее, иначе – происходит другое».

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

Передача данных

Второй крупный кейс, когда нам следует писать от лица Системы – интеграции. Что же в этих случаях должна наша Система? Все довольно просто – мы фиксируем ответы на два вопроса: что делать и когда делать?

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

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

Интерфейсы

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

Что может отображать Система? В первую очередь, экранную форму, причем вряд ли пустую. Так и пишем: «Система должна отображать форму, содержащую следующий перечень полей для заполнения…».

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

Отдельно стоит зафиксировать отображаемые на формах элементы управления – читай, кнопки, которые доступны пользователям. При этом для каждой кнопки нужно указать, что произойдет после нажатия на нее. Как пример: «Система должна отображать элемент управления Отправить, взаимодействие с которым инициирует отправку чего-то куда-то».

А что Система не должна?

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

Короткий ответ: нет.

Развернутый ответ: нет, мы пишем требования исключительно в утвердительной форме. И на это есть несколько причин. Разберем парочку.

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

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

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

Но как все же сказать, что Система не должна чего-то делать? Тут есть два варианта.

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

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

Система должна исключить…

Нужно избавиться от каких-то полей в интерфейсе? Система должна исключить отображение таких-то полей. Становится меньше проверок? Система должна исключить выполнение проверок A и B. Просто и элегантно, как по мне.

Больше таких материалов в моем личном канале Analysts Deliver. Здесь я рассказываю о работе аналитика через призму собственного опыта.