Бизнес-правила и их роль в разработке ПО. Литература для бизнес-аналитиков

Всем привет! В статье хочу поговорить об интересном материале из книги «Разработка требований к ПО» К. Вигерса и Д. Битти. Поговорим о том, что такое бизнес-правила, чем они отличаются от бизнес-требований и с чем их едят.
Погнали!

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

Бизнес-требования в данном случае просты: необходимо перенести действующий процесс из оффлайн-режима с кучей бумажной работы в онлайн-режим, что поможет сократить затраты на бумагу, зарплату проводящим тестирование и etc… После этого аналитик приступит к формированию функциональных требований, одно из которых будет гласить как-то так: «Тестирование проводится ежегодно в чч:мм для следующих групп лиц: группа 1, группа 2, группа 3».

Но что такое «ежегодно»? Почему не еженедельно, не ежемесячно, откуда этот параметр вообще взялся из бизнес-требований? Ответом на данный вопрос может быть следующее: в организации заказчика действует такая корпоративная политика, или правило. Такой набор законов и стандартов, принятых в компании называется бизнес-правилами.

Немного теории
Бизнес-правило — это сформулированное ограничение, допущение или порядок работы компании/отрасли. С точки зрения информационных систем — бизнес-правила — это указания, которые определяют или ограничивают работу. Бизнес-правила устанавливают бизнес-структуру и влияют на деятельность компании. Их источниками могут быть как вышестоящие органы, так и сама организация. За соблюдением бизнес-правил могут следить как люди, так и ПО.

Бизнес-правила могут быть разных видов: факты — утверждения о бизнесе; ограничения — что может или не может делать система; политики организации — не берем на работу детей; государственные нормативы — детей на работу брать запрещено; отраслевые стандарты — дети не пригодны для работы до 18 лет; активаторы операций — как только дитю исполнилось 18 лет — его можно привлекать на работу; выводы; вычисления. Бизнес-правила должны быть атомарны — то есть короткими и простыми. Один тезис — одно предложение.

Бизнес-правила — ценный источник требований.
Они могут влиять на следующие типы требований к ПО:
1) Бизнес-требования. Создавать бизнес-цели (например являться тем, для чего вообще нужно создать программный продукт)
2) Пользовательские и функциональные требования. Отображать ограничения (ролевые, функциональные и тд)
3) Атрибуты качества
4) Бизнес-процессы.
С учетом такого влияния нужно рассматривать бизнес-правила как очень ценный блок информации, который стоит хранить отдельно: и желательно не на словах.

Хранение и документирование бизнес-правил
Все просто: если бизнес-правила не хранить, их владелец может уволиться или умереть, правила потеряются, а вы потеряете важную часть процесса = времени и денег. Если хранить в разных местах — устанете поддерживать. Хранить все в кучу сплошным текстом — не разберетесь потом самостоятельно. Не валидировать важность бизнес-правил — потеряете самые важные из них в желании записать все на свете.
Документировать бизнес-правила или нет? Мое мнение — да, но давайте посмотрим правде в лицо — у нас с вами и так хватает «бумажной» работы. Чтобы не закопаться в правилах, советую разделить их по видам и по возможности документировать только те, которые не меняются каждые 5 минут (либо добавить всем правилам какой-то статус + дату, когда они появились, автора и их обоснование).
Выявление бизнес-правил
Если вы с пристрастием будете выпрашивать у пользователя «а каковы и больше нитаковы ваши правила?« — в лучшем случае вы узнаете одно-два из них. Правила можно собирать постепенно: в процессе сбора требований, обратив внимание на фразу пользователя "это всегда так работает", "у нас постоянно так" и так далее, изучить существующие регламенты/документацию.

Выявление + документация бизнес-правил поможет в реализации программных продуктов. Вот такие они важные и полезные!

Всем спасибо за прочтение! (Ввиду загруженности проектами я пишу редко, но стараюсь не забрасывать блог)