Бизнес-требования определяют смысл проекта и обосновывают его необходимость. Если мы в какой-то момент теряем фокус, то всегда можем возвращаться к бизнес-требованиям, как к исходной точке, и опираться на них.
Бизнес-требования — это удобный инструмент договоренности: они объективны, компактны и понятны стейкхолдерам. Если бизнес-требования хорошо определены, на них просто и эффективно строить контрактные отношения.
Из бизнес-требований вытекают критерии приёмки проекта. К ним применяются те же критерии качества, что и к другим типам требований, включая тестируемость. Критерии выполнения бизнес-требований фактически являются готовыми критериями приемки и оценки результатов проекта.
Бизнес-требования используются для определения рамок проекта. В различных стандартах, либо определение рамок является частью бизнес-требований, либо наоборот.
Бизнес-требования помогают принимать решения о приоритетах. Например, как решить, какую особенность системы важно реализовать раньше, а какую – позже? Если мы понимаем, как функции связаны с теми или иными бизнес-требованиями, такое решение принять легко: при известном приоритете бизнес-требования будет понятен и приоритет связанных с ними функции. А если не понимаем, то спорить можно до бесконечности, и никогда так и не договориться.
И, наконец, в Scrum бизнес-требования являются (во всяком случае, так должно быть) основным инструментом владельца продукта для управления продуктовым бэклогом и для согласования его с другими стейкхолдерами.

В разных традициях общий термин «требования» понимается по-разному. Наиболее широко употребляемые сейчас трактовки этого термина пришли из инженерии программного обеспечения.

Понятие требований в инженерных стандартах

Стандарт IEEE 610.12−1990 определяет требования как

«Условие или возможность, необходимые причастному лицу для решения проблемы или достижения цели»;
«Подлежащее выполнению условие или способность, которой должно обладать решение или его компонент для соответствия контракту, стандарту, спецификации или другому формальному документу»;
«Документированное представление условия или возможности в соответствии с п.п. 1 или 2».

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

Второе определение, напротив, говорит о требовании как о том, что требуется от чего-то (т. е. от решения).

Первое определение охватывает понятия «бизнес-требований» и «требований стейкхолдеров», а второе «требований к решению» (функциональных и нефункциональных).

Инженерный стандарт ISO/IEC/IEEE 29148 версии 2011 года упоминает, но не определяет понятия бизнес-требований. Он использует понятие «требования стейкхолдеров» (Stakeholder Requirements) и считает бизнес-требования разновидностью требований стейкхолдеров. (В версии 2018 года ISO/IEC/IEEE 29148 уже различает Business Requirements и Stakeholder Requirements)

Российский ГОСТ 34.601−90 (тоже очень технический, а не бизнес-ориентированный) вообще не использует понятие бизнес-требований, а упоминает только «требования пользователя» (т.е. организации-эксплуатанта автоматизированной системы).

Six Sigma — не инженерный стандарт, а организационно-управленческий подход, но на него ссылается стандарт ISO. Здесь появляется понятие бизнес-требований, которые определяются как «Критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от [конкретного] решения». В этом определении особо подчеркивается, что эти активности не должны быть привязаны к какому-то конкретному решению, то есть подразумевается, что решения, могут быть разными.

Six Sigma также вводит понятие Business Requirement Definition (BRD) — документа спецификации бизнес-требований, в который, в том числе, включаются потребности и ожидания клиента.

Понятие требований в бизнес-анализе

Руководство к своду знаний по бизнес-анализу (BABOK Guide) в предыдущих версиях использовало определение стандарта ISO, однако за несколько лет практики его применения стали очевидны проблемы, связанные с недостаточной бизнес-ориентированностью этого определения. Версия 3 BABOK Guide определяет требования с другого ракурса. Вот три самых важных момента в этом новом определении:

Если в инженерном стандарте требования — это «то, что нужно кому-то или что требуется от чего-то», то BABOK Guide определяет требование как «пригодное для использования представление потребности», то есть фокусируется на том, что нужно.
BABOK Guide подчеркивает, что требование любого уровня должно фокусироваться на понимании приносимой пользы: зачем нужно.
BABOK Guide уточняет, что форма представления может значительно варьироваться в зависимости от обстоятельств (не предписывает какую-либо форму представления или шаблон).

Обратите внимание на формулировку «пригодное для использования представление потребности». А чем плохи сами потребности? Почему нужно использовать какое-то отдельное их представление и почему оно может быть (а может и не быть) «пригодным для использования» (usable)?

Дело в том, что формулировки потребностей как таковых звучат обычно очень тривиально. При виде формулировки потребности возникает вопрос: «Ну и что? Да, это так, это очевидно, но что с этим делать?»

Вот пример формулировки потребности:

«Люди испытывают ежедневную потребность в пище»

Но ведь это очевидно, верно? Казалось бы, с этим ничего невозможно сделать, так зачем об этом вообще говорить?

Всё изменится, если эту потребность поместить в какой-нибудь конкретный контекст. Например, предположим, что наш контекст — это морские путешествия во времена Колумба и Магеллана.

Потребность людей в пище, конечно, очевидна всем.

Но в контексте морских путешествий эту потребность уже можно сформулировать в виде требования, например, такого:

«Продукты питания, используемые в рационе моряков, должны сохранять пригодность для употребления в пищу в течение, как минимум, 30 дней при температуре до +30°С и высокой влажности, поскольку моряки длительное время вынуждены обходиться без поставок продовольствия».

Можно поразмышлять для тренировки над тем, в какие требования могла бы преобразоваться потребность в пище, если бы мы поместили её в другие контексты: школьного питания; работы на заводе или в офисе; постовой службы; пограничной службы; космических полетов. Очевидно, что требования будут совершенно разные, хотя потребность — одна и та же. Различие только в контексте.

Вернемся к нашему примеру с требованием о продуктах питания для моряков. Это требование уже можно выполнить, и его выполнение можно проверить.

Выполнить это требование можно разными способами. Можно, например:

Выбирать такие продукты, которые не портятся длительное время сами по себе (скажем, кокосы).
Можно применять разные формы консервации (в то время у мореплавателей пользовались большим спросом вяленые мясо и рыба).
Можно создавать специальную среду хранения, например, погружать продукты в вино или масло.

Способы выполнения требований называются решениями.

Бизнес-требования в бизнес-анализе

«Пригодное для использования представление потребности» — это определение требования вообще. Бизнес-требования BABOK Guide определяет как «Представление целей, задач и результатов, объясняющих зачем было инициировано изменение и как будет оцениваться успех». То есть бизнес-требования отвечают на вопрос «почему мы вообще хотим что-то менять, зачем это надо, и что это даст».

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

Есть ещё одно важное свойство бизнес-требований, о котором BABOK Guide не говорит явно, но которое нужно читать между строк и понимать: бизнес-требования не зависят ни от каких стейкхолдеров.

Иногда у аналитиков возникают трудности с различением того, является ли требование бизнес-требованием или нет. Встречается также упрощенное понимание, что всё, что сообщают представители бизнеса — это и есть бизнес-требования. Это не так.

Для проверки того, является ли некое требование бизнес-требованием, нужно задать себе такие вопросы: Может ли требование измениться, если завтра на месте того, кто сообщил это требование будет работать другой человек? Изменится ли требование если изменится бизнес-процесс? Если вы ответили «нет» на оба вопроса, то проверка пройдена успешно.

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

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

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

Программа переподготовки

«Business Analyst Bootcamp»

Курс для тех, кто хочет сменить профессию и начать работать в ИТ с хорошими перспективами, занимаясь исследованием задач и проблем бизнеса и постановкой задач на автоматизацию

Посмотреть программу курса

Взаимосвязь понятий: потребности, требования, решения, контекст

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

Голубой блок обозначает контекст проекта и его элементы.
Красный блок в левой части — потребности бизнеса и стейкхолдеров.
Желтый блок в центре — бизнес-требования, требования стейкхолдеров и требования к решению.
Зеленый блок справа — решения, удовлетворяющие требования (бизнес-процессы и информационные системы).

Потребности бизнеса, подлежащие удовлетворению в конкретном контексте, отражаются в бизнес-требованиях.

Решением для бизнес-требования обычно является бизнес-процесс или организация, выполняющая множество бизнес-процессов.

Когда бизнес-процесс реализуется в качестве решения, в нем начинают участвовать конкретные люди (стейкхолдеры), у которых возникают потребности, связанные с участием в бизнес-процессе. Из этих потребностей вырастают требования стейкхолдеров, а из них — требования к решению.

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

Какие бывают потребности

Большинство людей имеют одни и те же основные потребности, отраженные в распространенной модели — пирамиде Маслоу.

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

У любой организации тоже есть ограниченный набор типовых потребностей, например, безопасность, непрерывность, эффективность, конкурентоспособность. Архитектор предприятий Даг Макдэвид предлагает рассматривать любую организацию не как механическую конструкцию, а как живой организм, имеющий естественные потребности связанные с его выживанием и развитием: саморегуляция, адаптация, восстановление, производство, воспроизводство, коммуникация и т. п. (Doug McDavid, Sustaining the life of your business, LinkedIn, January 25, 2015).

Вы можете предложить свою классификацию — в практической работе важен не конкретный «идеальный» перечень потребностей, а понимание того, что у организации любого вида существуют объективные потребности, имеющие важное значение в конкретном контексте.

Что такое контекст

Контекст — важная часть бизнес-требований. Лингвисты говорят «Контекст — это король».

Применительно к предприятию в общем, контекст — это все обстоятельства и факторы, которые не являются частью предприятия, но влияют на него, затрагиваются им или определяют его смысл.

К контексту относятся:

Рыночная среда
Спрос
Конкуренция
Структура подразделений компании
Физическое воплощение подразделений (здания, оборудование, и т. п.)
То, как в компании организовано управление, какие существуют бизнес-процессы. Любое изменение, любое решение реализуются не в вакууме, а в конкретных условиях, на конкретном предприятии. Мы не можем поменять всё, и мы не собираемся это делать. Мы меняем лишь какую-то часть деятельности предприятия, а всё остальное остается неизменным и, следовательно, является для нас контекстом. Важно зафиксировать, какая часть деятельности предприятия остается неизменной и образует контекст для нашей работы.
Люди, которые участвуют в деятельности предприятия, и технологии, которые на нем используются. Решение, прекрасно работающее в одной компании, может совсем не работать в другой. Часто заказчик отвечает на предлагаемое решение: «Да, решение прекрасное, но наши люди не смогут так работать, чтобы оно приносило пользу». И мы не можем поменять всех людей, это нереально. В этом случае сотрудники предприятия для нас являются элементами контекста.
Информационные системы и данные. Например, для внедрения системы могут быть нужны определенные данные, а если их нет, то для того чтобы их собрать в нужном формате, может потребоваться внедрить ещё несколько систем и поменять множество бизнес-процессов. Следовательно, отсутствие или наличие данных — это тоже контекст.

Как получается, что информационные системы в некоторых случаях являются решением, а в других — контекстом?

Предположим, мы делаем систему управления автотранспортом, и нам нужно интегрироваться с бухгалтерской системой. То, что мы собираемся создавать или менять — в данном случае это система управления автотранспортом — часть решения. Бухгалтерскую систему мы менять не планируем. Мы должны её упомянуть, поскольку она участвует в интеграции. Однако она будет являться частью контекста, а не решения, и это упоминание должно быть в бизнес-требовании.

Пример определения бизнес-требования
на основе анализа потребности

Предположим, наш заказчик — торговая компания.

Потребность бизнеса очевидна: чтобы продавать товары, компании нужно их где-то брать — либо оперативно получать от поставщиков, либо поддерживать на складе нужный запас. Эту потребность можно сформулировать так:

«Торговой компании необходимо постоянно иметь в наличии или оперативно получать нужные товары в нужном количестве.»

Это проекция базовой потребности бизнеса в непрерывности деятельности на бизнес-модель конкретной компании.

Потребность в непрерывности бизнеса: Для большинства организаций непрерывность деятельности — критический фактор существования. Например, банк не может полностью прекратить свою деятельность, а через месяц, как ни в чем ни бывало, ее продолжить — у него есть требующие поддержания активы и обязательства.

Если бизнес-модель компании предполагает поддержание товарных запасов на складе, то бизнес-требование можно сформулировать так:

«Для поддержания нужных товарных запасов на складах компании, их необходимо регулярно (BR-INV-01) пополнять через формирование заказов поставщикам.

Размер поддерживаемого запаса каждого товара должен определяться, исходя из оптимизации затрат и минимизации рисков упущенной прибыли (BR-INV-02).»

В тексте этого требования есть две ссылки: BR-INV-01 и BR-INV-02. Здесь BR означает «бизнес-правило» (Business Rule), а INV — Inventory (запас). Это ссылки на бизнес-правила, определяющие то, с какой именно регулярностью нужно пополнять запасы, и каков алгоритм расчета оптимального товарного запаса. Бизнес-правило — один из типичных артефактов, сопровождающих бизнес-требования.

Артефакты бизнес-анализа,
сопровождающие бизнес-требования

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

По мере определения бизнес-требований появляются:

Доменные модели — высокоуровневые информационные модели предметной области.
Глоссарий предметной области.
Модели состояния объектов управления: на этом этапе мы определяем, какими объектами мы хотим управлять, и какие состояния нас интересуют (или какие состояния мы хотим отслеживать).
Метрики и показатели этой деятельности, которые говорят нам о том, что важно для бизнеса и как мы оцениваем то, насколько хорошо или плохо, лучше или хуже выполняется его деятельность.
Бизнес-правила: описания применяемых в данной компании алгоритмов, нормативов, ограничений, проверок, и политик.

Отличие бизнес-требований от бизнес-правил состоит в том, что требования объективно следуют из сути бизнеса, тогда как бизнес-правила — результат договоренности конкретных людей. Например, любой компании, осуществляющей грузовые перевозки автотранспортом, необходимо поддерживать машины в работоспособном состоянии, нанимать водителей и вести учет перевезенных грузов — из этого вытекают соответствующие бизнес-требования, которые универсальны для всех компаний такого рода. То же, как именно это делается в конкретной компании, определяется ее бизнес-правилами, которые могут значительно отличаться от бизнес-правил другой компании.

Требования стейкхолдеров

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

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

“

Как специалисту, отвечающему за поддержание запасов, мне нужно иметь возможность:

Автоматически рассчитывать заказ по каждому товару с использованием определенного алгоритма (здесь прозвучит то же самое бизнес-правило, которое упоминалось в бизнес-требовании). Почему автоматически? Потому что мне надо на 4 складах поддерживать 3 000 товарных позиций, поступающих от 100 поставщиков — это невозможно или крайне сложно обрабатывать вручную.
По любой позиции автоматически рассчитанного заказа видеть то, как именно была посчитано это значение и почему оно именно такое — алгоритм может не учитывает какие-то известные мне нюансы. Например, ожидаемое значительное повышение или снижение продаж.
Менять количество в автоматически рассчитанном заказе — в конечном счете за заказ отвечаю я, а не система. Система не может учесть всё, и если я считаю нужным поменять заказанное количество, у меня должна быть возможность это сделать.
Смотреть для проверки не на все 3 000 позиций, а только на те, где расчеты системы могут быть вызвать сомнения. Например, недостаточная история продаж, высокая волатильность продаж или другие подобные факторы.

Примерно так будет рассказывать нам живой человек. «Пользовательская история» (User Story) — естественная форма представления требований стейкхолдеров, имеющая формат <роль> <задача> <нужная возможность>.

Например:

Как специалисту, отвечающему за поддержание запасов, для формирования заказов поставщикам мне нужно:

Автоматически рассчитывать заказ по каждому товару с использованием BR-INV-02;
по любой позиции заказа иметь возможность посмотреть детали расчёта и
вручную изменить заказываемое количество,
видеть отдельно те позиции заказа, по которым, возможно, требуется моя корректировка (BR-INV-03)

Обычно требованиям стейкхолдеров сопутствуют дополнительные артефакты:

Карты стейкхолдеров (показывают, кто участвует в процессах)
Модели и другие описания процессов
Варианты использования (Use Cases)
Образцы данных, с которыми работают стейкхолдеры (помогают понять ситуацию и потребности стейкхолдеров)

В рамках Scrum-подхода команда разработки работает именно с требованиями стейкхолдеров, представляемыми в виде пользовательских историй, из которых образуется бэклог продукта (product backlog).

Отсутствие понятия бизнес-требований — один из недостатков Scrum-подхода. Между тем, именно бизнес-требования обеспечивают понимание смысла требований стейкхолдеров и дают возможность их приоритизировать. Работа с бизнес-требованиями — область (неявной) ответственности Владельца продукта (Product Owner), определяющего приоритеты для команды разработки. В этом подходе предполагается, что команде разработки не нужно заботиться о том, как и из каких соображений владелец продукта определяет приоритеты. Однако, для бизнес-аналитика, зачастую выступающего в роли владельца продукта, чрезвычайно важно понимать бизнес-требования как источник требований стейкхолдеров и критерий их важности.

Требования к решению

«Требования к решению» (solution requirements) — понятие, применяемое в бизнес-анализе для определения требований к продукту, позволяющему выполнить требования стейкхолдеров.

В системной инженерии решением является информационная система, поэтому требования такого рода называются «системными требованиями» или «требованиями к системе». В более широком понимании продуктом может быть бизнес-процесс, организационная структура или набор бизнес-правил, поэтому бизнес-аналитики предпочитают использовать более общий термин «решение» (solution).

Требования к решению описываются как способности решения, нужные для выполнения требований бизнеса и стейкхолдеров.

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

«Система управления запасами должна обеспечивать:

Возможность автоматического формирования предлагаемых заказов поставщикам по всем товарам, выбранным закупщиком. Формирование заказов должно выполняться в соответствии с алгоритмом BR-INV-01. …"

(Обратите внимание: здесь опять появляется ссылка на то бизнес-правило, которое мы определили в бизнес-требовании.)

Мы можем далее уточнить требование:

«Отображение позиции сформированного заказа должно содержать информацию о…»

Перечисление отображаемой информации должно ссылаться на модель данных предметной области.

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

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

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

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

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

В следующей статье о практике работы с бизнес-требованиями мы расскажем о том, как их документировать:

Два основных подхода к документированию БТ
Шаблоны для описания БТ
Классификация и примеры БТ
Направления поиска БТ
Типовые ошибки в БТ
Типовые ловушки при разработке БТ
Что делать с «магическими числами» в БТ
Как восстанавливать БТ, если они отсутствуют в уже идущем проекте

Читать 2-ю часть статьи

Программа переподготовки

«Business Analyst Bootcamp»

Посмотреть программу курса

Автор

Георгий Савельев

Эксперт по бизнес-анализу, член Международного института бизнес-анализа (IIBA), первый CBAP в России. Соавтор BABOK v.3.
Вице-президент IIBA Russian Chapter.

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

Участвовал в реализации более 50 проектов по разработке, внедрению и совершенствованию программного обеспечения.

С 1990 года занимается проведением тренингов и деловых игр для руководителей и специалистов. Автор статей по бизнес-анализу.

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

Участник профессиональных ассоциаций IASA, ABPMP Russian Chapter.

Научиться создавать эффективные бизнес-требования в Agile

Научиться создавать эффективные бизнес-требования в стиле Agile под руководством опытного наставника с использованием формата User Story, техник Impact Map и Story Map можно на нашем онлайн-курсе «Основы бизнес-анализа и Разработки требований в Agile»

СМОТРЕТЬ ПРОГРАМММУ

Другие статьи:

Книги

Стандарты

Международные и российские стандарты в области прикладного системного анализа и инженерии требований

Иллюзия требований при разработке программного обеспечения

Пол Ральф (перевод)

Что мы создаём в ИТ-проектах?

Денис Бесков

Постановка задачи на реализацию: зачем и как

ДЕНИС БОГДАНОВ | МИХАИЛ МАКСИМОВ

Remote Analyst. Первые шаги и частые вопросы

ДЕНИС БЕСКОВ

Как выполнить тестовое задание на вакансию ИТ-аналитика

ДЕНИС БЕСКОВ

Как разработать бизнес-требования?

ГЕОРГИЙ САВЕЛЬЕВ