Одной из основных функций бизнес-аналитика, как специалиста, есть создание бизнес-требований, но многие заказчики не понимают зачем они собственно говоря нужны и считают лишней тратой времени их оформление.
Я уже не один раз затрагивал этот вопрос в своем блоге, но сейчас хочу поделиться с вами выжимкой материала найденном в интернете. Надеюсь он будет вам полезным.
Источник материала: https://systems.education/biz-req и https://systems.education/biz-req-dev
Роль Бизнес-требований (БТ)
- Бизнес-требования определяют смысл проекта и обосновывают его необходимость
- Бизнес-требования – это удобный инструмент договоренности: они объективны, компактны и понятны стейкхолдерам
- Из бизнес-требований вытекают критерии приемки проекта
- Бизнес-требования используются для определения рамок проекта
- Бизнес-требования помогают принимать решения о приоритетах
- В Scrum бизнес-требования являются (во всяком случае, так должно быть) основным инструментом владельца продукта для управления продуктовым бэклогом и для согласования его с другими стейкхолдерами
Требования в бизнес-анализе
Версия 3 BABOK Guide определяет требования таким образом:
- «пригодное для использования представление потребности», то есть фокусируется на том, что нужно.
- требование любого уровня должно фокусироваться на понимании приносимой пользы: зачем нужно
- форма представления может значительно варьироваться в зависимости от обстоятельств
Для формулирования требования потребность нужно поместить в какой-то контекст. Например потребность «Люди испытывают ежедневную потребность в пище» слишком общая. Если ее поместить в контекст морского путешествия, то требование становится уже более осмысленным: «Продукты питания, используемые в рационе моряков, должны сохранять пригодность для употребления в пищу в течение, как минимум, 30 дней при температуре до +30оС и высокой влажности, поскольку моряки длительное время вынуждены обходиться без поставок продовольствия».
Способы выполнения требования могут быть разными и они называются решениями.
Потребности, требования, решения, контекст
- Голубой блок обозначает контекст проекта и его элементы.
- Красный блок в левой части — потребности бизнеса и стейкхолдеров.
- Желтый блок в центре — бизнес-требования, требования стейкхолдеров и требования к решению.
- Зеленый блок справа — решения, удовлетворяющие требования (бизнес-процессы и информационные системы).
Потребности бизнеса, подлежащие удовлетворению в конкретном контексте, отражаются в бизнес-требованиях.
Решением для бизнес-требования обычно является бизнес-процесс или организация, выполняющая множество бизнес-процессов.
Когда бизнес-процесс реализуется в качестве решения, в нем начинают участвовать конкретные люди (стейкхолдеры), у которых возникают потребности, связанные с участием в бизнес-процессе. Из этих потребностей вырастают требования стейкхолдеров, а из них — требования к решению.
Полное решение состоит из бизнес-процессов и [информационных] систем, поддерживающих и обеспечивающих эти процессы. Системы реализуют требования к решению.
Пример определения бизнес-требования на основе анализа потребности
Для поддержания нужных товарных запасов на складах компании, их необходимо регулярно (BR-INV-01) пополнять через формирование заказов поставщикам.
Размер поддерживаемого запаса каждого товара должен определяться, исходя из оптимизации затрат и минимизации рисков упущенной прибыли (BR-INV-02).»
В тексте этого требования есть две ссылки: BR-INV-01 и BR-INV-02. Здесь BR означает «бизнес-правило» (Business Rule), а INV — Inventory (запас). Это ссылки на бизнес-правила, определяющие то, с какой именно регулярностью нужно пополнять запасы, и каков алгоритм расчета оптимального товарного запаса.
Бизнес-правило — один из типичных артефактов, сопровождающих бизнес-требования.
Артефакты бизнес-анализа, сопровождающие бизнес-требования
По мере определения бизнес-требований появляются:
- Доменные модели — высокоуровневые информационные модели предметной области.
- Глоссарий предметной области.
- Модели состояния объектов управления: на этом этапе мы определяем, какими объектами мы хотим управлять, и какие состояния нас интересуют (или какие состояния мы хотим отслеживать).
- Метрики и показатели этой деятельности, которые говорят нам о том, что важно для бизнеса и как мы оцениваем то, насколько хорошо или плохо, лучше или хуже выполняется его деятельность.
- Бизнес-правила: описания применяемых в данной компании алгоритмов, нормативов, ограничений, проверок, и политик.
- Бизнес-правило должно быть сформулировано на языке бизнеса. В описании бизнес-правил не должны использоваться технические термины. Язык написания бизнес-правил должен быть понятным представителю бизнеса, не являющимся IT-специалистом. После описания бизнес-правил, постарайтесь абстрагироваться от своих технических знаний, поставьте себя на место представителя бизнеса, руководителя компании, для который вы разрабатываете продукт. Понятен ли вам написанный документ? Не содержит ли документ технических терминов, указания систем и языков программирования?
- Бизнес-правило должно описывать правило бизнеса, а не работу системы. Описание бизнес-правил должно содержать те требования бизнеса, которые должна решить система, но без описания работы системы. Например, у бизнеса есть правило: «Отслеживать время прихода и ухода сотрудников на рабочее место». Бизнес-правило не должно содержать описания, как достичь соблюдения данного правила: будет ли сотрудник записываться в журнал прихода и ухода, или на входе будет стоять автоматическая пропускная система, которая будет фиксировать время.
- Бизнес-правило должно описывать ограничения: какие операции не могут быть выполнены. Ограничительные бизнес-правила могут определять ограничения пользователей. Например: “В полис ОСАГО страховщик может вписать не более 5-ти водителей”; «Оформить заказ-онлайн может только клиент компании».
- Бизнес-правило подчиняется бизнесу: принять, изменить, отменить. Представители бизнеса могут изменять бизнес-правила, вносить поправки или отменять.
Рассмотрим несколько примеров бизнес-правил и требований к системе
| Бизнес-правило | Требование к системе |
| Постоянный посетитель библиотеки может отложить для себя до 10 книг. | Посетитель, имеющий карточку в библиотеке; посещающий библиотеку не менее 1 раза в месяц является постоянным.
Постоянный посетитель должен иметь возможность отложить для себя 10 книг. |
| Клиент компании может оформить заказ с оплатой курьеру. | Клиент компании-пользователь, имеющий учетную запись в интернет-магазине компании. Для оформления заказа, пользователь должен быть авторизован в системе.
Пользователь, должен иметь возможность оформить заказ. Заказ может быть оформлен: с доставкой по указанному адресу; с оплатой наличными при получении; с оплатой банковской картой при получении. |
Требования стейкхолдеров
При проектировании бизнес-процесса, необходимого для выполнения бизнес-требований, необходимо учитывать потребности и требования людей, участвующих в этом бизнес-процессе. Такие люди называются причастными лицами (стейкхолдерами). О них я уже писал в своем блоге.
Предположим, мы проектируем бизнес-процесс поддержания товарных запасов на складах компании. Одной из разновидностей стейкхолдеров будут закупщики — специалисты, которые формируют заказы поставщикам. Если мы придем к такому человеку и попросим рассказать, чем он занимается и в чем нуждается, мы услышим примерно следующее:
Как специалисту, отвечающему за поддержание запасов, мне нужно иметь возможность:
- Автоматически рассчитывать заказ по каждому товару с использованием определенного алгоритма (здесь прозвучит то же самое бизнес-правило, которое упоминалось в бизнес-требовании). Почему автоматически? Потому что мне надо на 4 складах поддерживать 3000 товарных позиций, поступающих от 100 поставщиков — это невозможно или крайне сложно обрабатывать вручную.
- По любой позиции автоматически рассчитанного заказа видеть то, как именно была посчитано это значение и почему оно именно такое — алгоритм может не учитывает какие-то известные мне нюансы. Например, ожидаемое значительное повышение или снижение продаж.
- Менять количество в автоматически рассчитанном заказе — в конечном счете за заказ отвечаю я, а не система. Система не может учесть всё, и если я считаю нужным поменять заказанное количество, у меня должна быть возможность это сделать.
- Смотреть для проверки не на все 3000 позиций, а только на те, где расчеты системы могут быть вызвать сомнения. Например, недостаточная история продаж, высокая волатильность продаж или другие подобные факторы.
Например:
Как специалисту, отвечающему за поддержание запасов, для формирования заказов поставщикам мне нужно:
- Автоматически рассчитывать заказ по каждому товару с использованием BR-INV-02;
- по любой позиции заказа иметь возможность посмотреть детали расчета и
- вручную изменить заказываемое количество,
- видеть отдельно те позиции заказа, по которым, возможно, требуется моя корректировка (BR-INV-03)
Обычно требованиям стейкхолдеров сопутствуют дополнительные артефакты:
- Карты стейкхолдеров (показывают, кто участвует в процессах)
- Модели и другие описания процессов
- Варианты использования (Use Cases)
- Образцы данных, с которыми работают стейкхолдеры (помогают понять ситуацию и потребности стейкхолдеров)
Функциональные и нефункциональные требования
Нефункциональные требования (НФТ) определяют свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.
Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.
Почему бизнес-требования так важны
Бизнес-требования играют важную роль на проекте, поскольку помогают определить смысл проекта и обосновать его необходимость. Именно бизнес-требования, как правило, используются для определения рамок проекта, то есть входят в состав концепции проекта.
Ввиду своей понятности всем заинтересованным лицам, бизнес-требования служат артефактом, на основе которого удобно заключать договоренности. Чем ниже уровень требований, тем больше нюансов, а значит, сложнее договариваться.
Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.
Также бизнес-требования часто используются на проекте для приоритизации решений: если есть понимание, как то или иное решение связано с БТ, приоритизировать его не составит труда. Именно БТ являются снованием для принятия решений в ходе проектирования и внесения изменений в реализацию проекта.
Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.
Какие бывают бизнес-требования?
Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.
Исходя из определения Six Sigma, классификация требований будет опираться на критичные активности, т. е. бизнес-требования могут быть связаны с:
- Определением значимых характеристик продуктов или услуг.
- Распознаванием и обработкой событий.
- Принятием решений (своевременность, правильность).
- Сбором, обработкой, хранением и предоставлением информации.
- Обеспечением возможности выполнения действий (субъект, действие, объект, время, условия, способ).
- Предотвращением возможности выполнения действий (субъект, действие, объект, время, условия, способ
Вид БТ: Значимые характеристики продуктов или услуг
Примеры БТ:
- Скорость обслуживания — очередь на кассе должна быть не длиннее 4 покупателей.
- Своевременность доставки — клиент должен получить пиццу горячей и не умереть ожидая ее.
- Простота получения услуги — оформление предварительно одобренного кредита должно завершаться за одно посещение клиента.
Вид БТ: Распознавание и обработка событий
Примеры БТ:
- Банк должен своевременно получать оповещения о сбоях в работе банкоматов.
- К моменту начала этапа работ, все нужные материалы и оборудование должны находиться на объекте строительства и быть готовыми к использованию.
- Сотрудники должны быть своевременно проинформированы о назначенных им задачах.
Вид БТ: Принятие решений
Примеры БТ:
- По каждому обнаруженному дефекту, на основе имеющейся информации, должно быть оперативно принято решение о способе его устранения в соответствии с протоколом реакции на аварийные ситуации.
- Решение о выдаче кредита должно приниматься на основании…
- Отпускная цена на товар для конкретного клиента определяется на основании… в зависимости от …
Вид БТ: Сбор, обработка, хранение и предоставление информации
Примеры БТ:
- С момента обнаружения дефекта и до его полного устранения должна регистрироваться и храниться следующая информация.
- Инвестиционный банк в конце каждого рабочего дня должен направлять Регулятору информацию о…
- Для принятия решений об участии в тендере необходимы результаты предварительной оценки себестоимости проекта.
Вид БТ: Обеспечение возможности выполнения действий
Примеры БТ:
- В случае неудовлетворенности качеством обслуживания, клиент должен иметь возможность направить жалобу по телефону, по электронной почте или через сайт компании.
- Клиент должен иметь возможность отказаться от заказа до момента его отправки.
- Покупатели должны иметь возможность оформить и оплатить покупку самостоятельно посредством мобильного приложения.
Вид БТ: Предотвращение возможности выполнения действий
Пример БТ:
- Должна исключаться возможность доступа к защищенным ресурсам лиц, не являющихся сотрудниками компании.
Проблемы в бизнес-требованиях
- Неконкретность (слишком абстрактная формулировка)
- Невозможность проверки (нет понимания, что является индикатором выполнения требования)
- «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
- Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
- Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
- Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
- Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
- Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
- Привязка к конкретному решению, в том числе — конкретный бизнес-процесс
Примеры некорректных бизнес-требований
Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?
- Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесет сокращение времени обработки заказа?
- Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
- Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
- Внедрить ERP — Кому и зачем это нужно? В чем проблема?
Типовые ловушки аналитика
Проблемы с требованиями, как правило, возникают, когда аналитик попадает в одни и те же типовые ловушки. Вот основные ловушки аналитика при работе с бизнес-требованиями:
- Формальность — «пишу, потому что надо здесь что-то написать».
- Узкие рамки анализа — не рассматриваем ничего, что выходит за рамки проекта.
- Превращение в аудит — выясняем все обо всем «на всякий случай».
- Превращение метода в цель — строгое следование определенному шаблону с превращением средств в цель и потерей основной цели проекта.
Что можно сделать с каждой из этих ловушек?
| Ловушка | Описание | Решение |
|---|---|---|
| Формальность | «Пишу, потому что надо здесь что-то написать» | Ставить себя на место читателя (необходимо понимать, что и для кого мы пишем). |
| Узкие рамки анализа | Фокусировка только на том, что относится к проекту, т.е. не рассматриваем ничего, что выходит за рамки проекта | Анализировать область шире, чем те рамки, которые хотим установить для проекта. |
| Превращение в аудит | «На всякий случай» выясняем все обо всем | Постоянно спрашивать себя: «как это связано с проектом?» |
| Превращение метода в цель | Строгое следование определенному шаблону с превращением средств (канва бизнеса, бизнес-процессы, стейкхолдеры) в цель и потерей основной цели проекта | Задать себе вопрос: «можно ли обойтись без э |
Документирование бизнес-требований
В практике бизнес-аналитика присутствует два основных подхода документирования требований:
1. Монолитно
- Все требования описываются вместе в виде структурированного повествовательного текста.
- Возможны ссылки на элементы требований (цели, метрики, предположения, риски и т. п.).
2. Дробно
- Каждое требование описывается отдельно.
- Каждому требованию присваивается уникальный идентификатор.
- Возможна трассировка к конкретному бизнес-требованию.
Шаблон монолитного описания БТ
Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:
- Контекст.
- Описание возможности.
- Бизнес-цели.
- Метрики успешности.
- Образ результата (Vision).
- Деловые риски.
- Предположения и зависимости бизнеса.
Советы Вигерса по описанию БТ
- Сокращайте шаблон в соответствии с потребностями.
- Заполняйте не сверху вниз, а по мере поступления информации.
- Пустой раздел — признак его ненужности или необходимости дополнительного изучения.
- Не повторяйте то, что уже описано в другом месте — сошлитесь на имеющееся описание.
- Исходите из возможности повторного использования БТ в других проектах.
- Выявляйте конфликты, противоречия и выносите на обсуждение.
- Проводите повторное рассмотрение БТ при каждой смене лиц, принимающих решения, чтобы убедиться, что понимание БТ не изменилось
Шаблон дробного описания БТ
Ниже представлен авторский шаблон дробного описания бизнес-требований. Он состоит из нескольких ключевых элементов:
1. Заголовок, который включает в себя:
- Уникальный идентификатор.
- Краткое описание.
2. Определение, развернутое объяснение, что из себя представляет БТ.
3. Источник, откуда это требование взялось.
4. Зависимости, если они есть между другими требованиями.
5. Обоснование, краткое пояснение мотивации.
6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.
