Помимо концептуальной модели бизнес-анализа есть еще ряд ключевых терминов, которые нам необходимо разобрать, прежде чем двигаться дальше. Первый важный термин - это информация по бизнес-анализу. Казалось бы, что это такое? Многие задачи по бизнес-анализу заканчиваются тем, что бизнес-аналитик использует эту информацию по бизнес-анализу, либо она у него выходит на выходе - это некое общее собирательное понятие информации по бизнес-анализу.
BABOK дает следующее определение - это информация любого рода на любом уровне детализации, которую бизнес-аналитик анализирует и преобразовывает. Используется в качестве входных данных или является результатом работы бизнес-аналитика.
Примером может быть что угодно - любые промежуточные результаты, исходные данные, какие-то требования, дизайн этих требований, дизайн решения - все, что угодно, все это называется «информация по бизнес-анализу». Это не только требования - это важно понимать.
Следующее - это дизайн. У нас получается так - есть потребность и есть требования. Требования - это некое представление потребности, с которым можно дальше работать. То же самое и дизайн. Мы не можем сразу перейти от потребностей к решению, здесь промежуточно есть два шага: потребность, требования, дизайн этого решения, которое будет удовлетворять требованию, и решение. Дизайн - это представление какого-то решения, с которым можно дальше работать.
Пример - у вас есть некое требование уменьшить время на какую-то операцию, например подбор и упаковку товара. Его можно по-разному себе представить, какой бы дизайн придумать? А дизайн очень простой - необходимо просто нарисовать схему процесса и новый процесс будет являться этим решений. Такой пример дизайна.
Дизайн может быть документом и сильно варьироваться в зависимости от обстоятельств.
Следующие понятие, которое важное и используется в бизнес-анализе - это риск, потому что бизнес-аналитик сотрудничает с другими заинтересованными сторонами для выявления оценки приоритизации рисков. Потому что любое решение, которое аналитик рекомендует заинтересованной стороне, несет в себе какой-то риск. Есть минимум каких-то рисков, но тем не менее, может произойти всякое, и заинтересованное лицо принимает решение с учетом этих рисков. Аналитик должен их выявить, оценить и приоритизировать. Он может порекомендовать одно решение, оно является низкорискованным, но при этом долгим. Или у нас есть какое-то быстрое решение, но оно рискованное. Заинтересованная сторона принимать решение, на какой же уровне риска она готова пойти.
Одно из самых важных определений на сегодня - это представление, что такое требование. Это представление потребности, пригодное для использования. У нас есть некая потребность, нам необходимо с этой потребностью дальше работать. Тогда мы эту потребность преобразуем в какое-то требование.
Требования могут формулировать в разных видах - это может быть классическая формулировка: система должна предоставлять то-то и то-то, это такое текстовое описание. В Agile требования формулируются в виде пользовательских историй: где-то это потребность, где-то это требование, в зависимости от детализации. Мне, как офицеру по безопасности необходимо, чтобы доступ к функциональности имел только определенный круг пользователей. Для чего мне это нужно? Для того, чтобы удовлетворить требованиям директивы по безопасности. Это требование, сформулированное в формате «пользовательские истории».
Можно сформулировать требования в виде use-кейса - это варианты использования. В разных форматах можно формулировать требования: в табличной форме, в виде модели, но главное - это то, что требование - это некое представление, детализация, уточнение потребности, с которым мы дальше можем работать - это важно.
Интересной особенностью BABOK является то, что в BABOK есть своя система классификации требований. Это одна из самых полезных частей BABOK, вы можете просто взять ее и использовать своей работе, потому что любой бизнес-аналитика работает с какими-то группами требований, и у него возникает вопрос: функциональные требования или нефункциональные требования, бизнес-функциональные требования или бизнес-требования, или требования заинтересованных лиц и так далее. В каком они находятся между собой соотношении? BABOK предлагает свою классификацию, пользоваться или нет - это ваше дело, но рассказать про нее я вам хочу.
Схема классификации требования в соответствии с BABOK 3.0. Эту всю схему можно представить себе в виде пирамиды и еще отдельно стоящего столбика. Все начинается сверху, и это бизнес-требования. Дальше я буду рассказывать по каждому этому типу требований более подробно. Все начинается с бизнес-требований. Бизнес-требования - это требования уровня всего предприятия или какой-то части предприятия. Это выше требований конкретных заинтересованных лиц, это вещи из стратегии, из миссии, из целей и задач.
Далее, требования заинтересованных сторон. Представим себе, что у нас есть какая-то стратегия на три года, и из этой стратегии вычленена какая-то цель. Она становится бизнес-требованием. Включен определенный круг заинтересованных сторон, и они дальше выдвигают свои требования, что им нужно, чтобы удовлетворить этому бизнес-требованию - это и есть требование заинтересованных сторон. Аналитик, выслушав эти требования заинтересованных сторон, что им нужно, он уже может сформировать требования к решению. Не обязательно к IT-системе, вспоминаем, что решение не только IT-системы, это может быть широкий круг вариантов.
Требования к решению делятся в BABOK на две большие группы - это функциональные требования к решению и нефункциональные требования решению. Если коротко, то функциональные требования - это что система должна делать, что она умеет делать, что она может делать, функции, которые она может выполнять, а нефункциональные - это как она это может делать, при каких условиях она может делать, как быстро и так далее. Нефункциональные требования — это как она может реализовывать свои функции.
Отдельно очень интересные требования, это специфика BABOK - это переходные требования - те требования, которые нам нужны временно, на состояние перехода из исходного состояния в целевое состояние. Когда мы уже перейдем в него, переходные требования нам уже становится не нужны.
Давайте поподробнее сейчас разберем эти типы требований, и в конце я вам расскажу пример, который я придумал.
Бизнес-требования. Я уже говорил, что это высокоуровневые формулировки - это могут быть какие-то цели, задачи, потребности предприятия, причина, по которой была инициирована какая-то активность по бизнес-анализу или проект. Это те задачи, по которым будет считаться, достигла или не достигла успеха какая-то инициатива по бизнес-анализу. Бизнес-требования зачастую сопровождаются какими-то метриками показателей успешности, и это выше требований определенных групп заинтересованных лиц - это на уровне всего предприятия.
Чаще всего они возникают из анализа всего предприятия в целом или какой-то его части. Например, в области закупок, продаж, производства и так далее. Это бизнес-требования.
Требования заинтересованных сторон - это те требования, которые должны быть удовлетворены, чтобы соответствующие бизнес-требования также были удовлетворены, все достаточно просто. У вас есть одно бизнес-требование, есть 10 заинтересованных лиц, каждый из них должен подумать о том, что ему нужно, чтобы свою часть этого бизнес-требования реализовать. Если мы удовлетворим все требования этих заинтересованных лиц, то мы сможем выполнить основное наше бизнес-требование, Логика такая, пирамидка - это может быть требование конкретной заинтересованной стороны или группы заинтересованных сторон, и по сути это мостик такой, соединительный элемент между бизнес-требованиями и требованиями к решению - это требование заинтересованных сторон.
Далее, опять таки интересно - это переходные требования. Сразу давайте к примеру. Переходные требования - это то, что касается непрерывности деятельности, или то, что мы не должны прерывать нашу деятельность более чем на сколько-то в момент нашей инициативы по переходу в целевое состояние. Или, например, мы выдвигаем требования к тому, как должна состояться миграция данных. Когда уже система заработает, эти требования к миграции данных будут уже не нужны. Или требования к промежуточному обучению персонала в ходе запуска этой системы и так далее. Это такой интересный тип требований, он временный или переходный, и он нужен только на момент, когда вы делаете это решение, запускаете его.
Далее, требования к решению. Требования к решению разделяются на две группы: функциональные требования и нефункциональные требования. BABOK не очень богат на какие-то примеры, практически примеров в своде знаний нет. BABOK не сопровождается никакими шаблонами, кейсами, этого всего нет. Есть только общие фразы на тему, что уровень детализации приемлем для последующей работы. Как сказать, что я разработал функциональные требования? Если вы можете эти функциональные требования дальше по цепочке передать, например, если вы бизнес-аналитик - системному отдать, он с ними работает и не приходит к вам возмущаться, наверное вы достигли приемлемого уровня детализации.
Откуда требования к решению рождаются? Из анализа требований заинтересованных сторон. Вы должны отслеживать, откуда взялось это функциональное требование. Если у вас спросят, откуда взялось и почему система должна это делать? Потому что это проистекает из требований заинтересованного лица такого-то, а это требование заинтересованного лица связано с этим бизнес-требованием. То, что я сейчас рассказываю, называется трассировка - отслеживание связи между требованиями. Не должно быть так, что требование само по себе. Откуда оно взялось? Лежит тут, никого не трогает.
Функциональные требования. Что решение должно делать уметь - они функциональны как, при каких условиях. Давайте разберем такой короткий пример: все вы знаете, что такое каршеринг. Я сейчас попробую сформулировать потребность, бизнес-требования, представить себе, что может потребовать заинтересованная сторона, в моем случае - это начальник гаража, будем считать, что к них собственный автопарк. Функциональные требования, нефункциональные и какие-то переходные требования. Итак, компания по каршерингу. Какая есть потребность у компании по картингу? Обеспечение непрерывности деятельности компании, чтобы у нас всегда были машины, они были на ходу. Определенный процент должен находиться в ремонте, это все понятно, но нам нужно обеспечить непрерывность. Если мы шесть часов в день стоим из-за того, что у нас нет машин, или нет водителей, или чего-то у нас нет - у нас проблема с обеспечением непрерывности деятельности компании. Это пример того как можно сформулировать потребность.
Какое бизнес-требование из этой потребности мы можем произвести? Бизнес-требование следующее - исправное состояние автотранспорта. Потребность у нас одна, бизнес-требований может быть уже несколько: исправное состояние автотранспорта, наличие трезвых водителей и так далее. Я возьму только одно бизнес-требование, получается такая вертикаль - по одному требованию на каждом уровне. Для этой потребности нужно, чтобы был исправен автотранспорт. Требование заинтересованной стороны с точки зрения начальника гаража: мне, как начальнику гаража, необходимо наличие актуальной информации по автомобильному парку. Неважно, свой он или чужой, арендованный и так далее. Необходимо понимать, что у меня есть в наличии с точки зрения начальника гаража - это его требование.
Заметьте, что здесь нет формулировок «система должна» и так далее. Я не знаю, что кто должен как начальник гаража, мне надо видеть наличие актуальной информации. Я не знаю, как вы это сделаете - мне это не важно.
Функциональные требования, которые можно произвести из этого требования заинтересованной стороны - решение должно поддерживать ведение справочника автомобилей с указанным перечнем атрибутов, можно сослаться на какое-то приложение с перечнем атрибутов, чтобы здесь не засорять.
Хорошо, актуальная информация по автомобильному парку, где будет написано, вот он, справочник, я вижу, какая марка, сколько осталось до ТО и так далее.
Нефункциональные требования. Какое может быть требование к этому решению нефункциональное, которое показывает наш справочник автомобилей? Например, что оно должно быть доступно не менее 360 дней в году - это просто пример, может быть и 364. Нефункциональное требование, допустим, связано с тем, сколько времени оно может быть в режиме обслуживания.
Какое может быть примерно переходное требование здесь? Решение должно содержать средства первоначальной загрузки с перечнем имеющихся автомобили из
Excel. Оно собрано в Excel в разных форматах, но мы как-то умудрились все это загрузить в систему и все, больше мы с Excel не работаем, у нас все только в нашей системе - это пример переходного требования.
На этом примере вы можете посмотреть эволюцию требования от потребности до переходного требования.
Типы требований, которые есть в BABOK: это схема классификации требований. Наверху бизнес-требования - это требования уровня всего предприятия или какого-то бизнес-домена, бизнес-части, закупки, производство, маркетинг. Далее, требования заинтересованных сторон, которые должны быть удовлетворены, чтобы были реализованы эти бизнес-требования. Требования заинтересованных сторон рождают за собой требования к решению, которые в свою очередь делятся на функциональные не функциональные. И особняком стоят переходные требования, которым решение должно удовлетворять при переходе из исходного положения нашего предприятия к целевому.
Лекция вводит слушателя в терминологический аппарат бизнес-анализа.
В начале дается определение информации по бизнес-анализу как любого рода информации, которую аналитик использует или производит. Далее вводится понятие дизайна как связующего звена между требованием и решением. Требование отвечает на вопрос «Что нужно?», а дизайн — «Как это примерно будет выглядеть/работать?». Также подчеркивается важность управления рисками, так как любое решение их содержит, и задача аналитика — сделать их видимыми для заказчика.
Центральная часть лекции посвящена классификации требований по BABOK, представленной в виде пирамиды:
• Бизнес-требования: Самый верхний уровень. Это стратегические цели организации, причины запуска проекта (например, «обеспечить исправное состояние автопарка»). Они связаны с миссией и метриками успеха всего предприятия.
• Требования заинтересованных сторон: Описывают нужды конкретных людей или групп (стейкхолдеров), чья работа должна измениться для достижения бизнес-требований (например, начальнику гаража нужна «актуальная информация об автопарке»).
• Требования к решению: Детализируют, что должна делать будущая система или изменение процесса. Делятся на:
o Функциональные: что система делает (функции, возможности).
o Нефункциональные: как система это делает (производительность, доступность, условия работы).
• Переходные требования: Стоят особняком. Это временные условия, необходимые для перехода из текущего состояния в целевое. Они теряют актуальность после завершения внедрения (например, требования к миграции данных из Excel, обучению персонала).
Вся эта цепочка подчиняется принципу трассировки: каждое функциональное требование должно быть прослежено до требования стейкхолдера и далее до бизнес-цели.
1. Бизнес-анализ оперирует не только требованиями. Важно понимать разницу между потребностью, требованием, дизайном и готовым решением.
2. Классификация требований BABOK — практический инструмент. Она помогает структурировать работу, не упускать из виду разные аспекты проекта (от стратегии до технических деталей) и четко разделять ответственность.
3. Связность требований критически важна. Понимание того, как конкретная функция системы связана с бизнес-целью компании, позволяет аналитику обосновывать свои решения и управлять изменениями.
4. Аналитик работает с рисками и переменами. Выявление рисков и формулирование переходных требований — прямая обязанность аналитика, обеспечивающая плавность и успешность внедрения изменений.
1. Что такое «информация по бизнес-анализу»? Приведите примеры, не являющиеся готовыми требованиями.
2. В чем разница между «требованием» и «дизайном» решения? Можно ли обойтись без этапа дизайна?
3. Какую роль в работе аналитика играет понятие «риск»?
4. Перечислите четыре основных типа требований по классификации BABOK.
5. В чем заключается разница между функциональными и нефункциональными требованиями?
6. Почему переходные требования выделяются в отдельную категорию? Приведите пример переходного требования для внедрения новой системы документооборота.
7. Что такое «трассировка требований» и зачем она нужна бизнес-аналитику?
