Руководство по своду знаний бизнес-анализа (Business Analysis Body of Knowledge - BABOK Guide) –

это международный признанный стандарт практики бизнес-анализа. Он обобщает опыт ведущих

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

ВАВОК версии 3 появилась в апреле 2015 г.

Международный институт бизнес-анализа (IIBA)

КЛЮЧЕВАЯ
КОНЦЕПЦИЯ ОПИСАНИЕ

Change (Изменение) Акт трансформации в ответ на потребность.

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

Need (Потребность) Проблема или возможность, которой необходимо заняться.

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

Solution (Решение) Конкретный способ удовлетворения одной или более потребностей в

Контексте (context).
Решение удовлетворяет потребность путем решения проблемы, с
которыми сталкиваются заинтересованные стороны, или позволяет
заинтересованным сторонам воспользоваться существующей
возможностью.

Stakeholder Группа или человек, имеющие отношения к изменениям, потребностям

(Заинтересованная или Решению.
сторона)
Заинтересованные стороны часто определяются в терминах
заинтересованности, воздействия и влияния на изменения.
Заинтересованные стороны группируются на основе их связи с
потребностями, изменениями и Решением.

Value (Ценность) Стоимость, значимость или полезность чего-либо для заинтересованных

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

Context (Контекст) Обстоятельства, которые оказывают влияние, на которые оказывается

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

Схема классификации требований

 Бизнес-требования: высказывание целей, задач и результатов, которые описывают почему было

инициировано изменение. Они могут применяться для всего предприятия, бизнес-области или для
конкретной инициативы.
 Требования заинтересованных сторон: описывают потребности заинтересованных сторон, которые
должны быть выполнены для удовлетворения бизнес-требований. Они могут служить в качестве моста
между бизнес-требованиями и требованиями к Решению.
 Требования к Решению: описывают возможности и качества Решения, которые удовлетворяют
требования заинтересованных сторон. Они обеспечивают соответствующий уровень детализации,
позволяющий вести разработку и внедрение Решения. Требования к Решению можно разделить на две
подкатегории:
 Функциональные требования: описывают возможности, которые Решение должно иметь в
терминах поведения и информации, которой Решение будет управлять;
 Нефункциональные требования или требования к качеству обслуживания: не относятся
непосредственно к поведению функциональности Решения, а скорее описывают условия, при
которых Решение должно оставаться эффективным, или качества, которым Решение должно
удовлетворять.
 Переходные требования: описывают возможности, которые Решение должно иметь и условия,
которым Решение должно удовлетворять, чтобы обеспечить переход от текущего состояния к будущему
состоянию, но которые будут не нужны после того, как изменения будут осуществлены. Эти требования
отличаются от других типов требований, поскольку они носят временный характер. Переходные
требования относятся к таким темам как — преобразование данных, обучение и обеспечение
непрерывности бизнеса.
7.1 Уточнение и моделирование требований

Цель

Цель «Определить и смоделировать требования» состоит в том, чтобы проанализировать,

обобщить и уточнить результаты выявления в требованиях и проектах.

Описание

Требования «Укажите и модель» описывают методы анализа результатов извлечения и создания

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

ВАЖНо

Во многих ИТ-средах слово «дизайн» используется специально для технических проектов,

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

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

Входные данные

Результаты выявления (любое состояние): моделирование может начинаться с любого

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

7.1.4. Элементы

.1 Требования к моделям

Модель - это описательный и визуальный способ донести информацию до определенной

аудитории, чтобы поддержать анализ, общение и понимание.

Модели могут также использоваться для подтверждения знаний, выявления информационных

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

Бизнес-аналитики выбирают один или несколько из следующих форматов моделирования:

 Матрицы: матрица используется, когда бизнес-аналитик моделирует требование или

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

Используя один или несколько форматов моделей, бизнес-аналитики определяют конкретные

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

Модельные категории могут включать в себя:

 Роли: Модели представляют организации, группы людей, роли и их отношения внутри

предприятия и решения. Методы, используемые для представления людей и их ролей,
включают организационное моделирование, матрицу ролей и разрешений и список
заинтересованных сторон, карту или персон.
 Обоснование: Модели представляют «почему» перемен. Методы, используемые для
представления обоснования, включают в себя моделирование решений, моделирование
областей, холст бизнес-модели, анализ первопричин и анализ бизнес-правил.
 Поток деятельности: Модели представляют собой последовательность действий, событий
или курса, которые могут быть приняты. Методы, используемые для представления
потоков деятельности, включают моделирование процессов, сценарии использования и
сценарии, а также пользовательские истории
 Возможности: модели ориентированы на функции или функции предприятия или
решения. Методы, используемые для представления возможностей, включают анализ
бизнес-возможностей, функциональную декомпозицию и прототипирование.
 Данные и Информация: Модели представляют характеристики и обмен информацией
внутри предприятия или решения. Методы, используемые для представления данных и
информации, включают словарь данных, диаграммы потоков данных, моделирование
данных, глоссарий, моделирование состояний и анализ интерфейса.

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

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

.2 Анализ требований

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

предмет:

 все, что должно измениться, чтобы удовлетворить потребности бизнеса,

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

Требуемый уровень декомпозиции и уровень детализации, который должен быть указан,

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

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

.3 Представление требований и атрибутов

Бизнес-аналитики идентифицируют информацию для требований и их атрибутов как часть
результатов выявления. Требования должны быть представлены в явном виде и должны включать
достаточно деталей, чтобы они отражали характеристики требований и качество дизайна (см.
Проверка требований (стр. 141)). Различные атрибуты могут быть указаны для каждого
требования или набора требований. Эти атрибуты выбираются при планировании управления
информацией (см. Планирование управления информацией бизнес-анализа (стр. 42)).

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

.4 Реализовать соответствующие уровни абстракции

Уровень абстракции требования варьируется в зависимости от типа требования и аудитории для

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

Подход бизнес-анализа также может влиять на уровень абстракции и выбор моделей,

используемых при определении требований.

7.1.5 Руководство и инструменты

 Нотация моделирования / Стандарты: позволяют точно определить требования и дизайн,

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

7.1.6. Методы

 • Критерии приемки и оценки: используются для представления атрибутов критериев

приемлемости и оценки требований.
 • Анализ возможностей бизнеса: используется для представления функций или функций
предприятия.
 • Бизнес-модель Canvas: используется для описания обоснования требований.
 • Анализ бизнес-правил: используется для анализа бизнес-правил, чтобы их можно было
задавать и моделировать вместе с требованиями.
 • Концептуальное моделирование: используется для определения терминов и
отношений, относящихся к изменению и предприятию.
 • Словарь данных: используется для записи сведений о данных, связанных с изменением.
 Детали могут включать определения, связи с другими данными, происхождение, формат и
использование.
 • Диаграммы потоков данных: используются для визуализации требований к потокам
данных.
 • Моделирование данных: используется для моделирования требований, чтобы показать,
как данные будут использоваться для удовлетворения информационных потребностей
заинтересованных сторон.
 • Моделирование решений: используется для представления решений в модели, чтобы
показать необходимые элементы принятия решений.
 • Функциональная декомпозиция: используется для моделирования требований с целью
идентификации составных частей общей сложной бизнес-функции.
 • Глоссарий: используется для записи значения соответствующих бизнес-терминов при
анализе требований.
 • Анализ интерфейса: используется для моделирования требований с целью выявления и
проверки входных и выходных данных решения, которое они моделируют.
 • Анализ нефункциональных требований: используется для определения и анализа
качества атрибутов обслуживания.
 Организационное моделирование: используется, чтобы позволить бизнес-аналитикам
моделировать роли, обязанности и коммуникации внутри организации.
 • Моделирование процесса: используется для отображения шагов или действий, которые
выполняются в организации или которые должны быть выполнены для достижения
желаемых изменений.
 • Прототипирование: используется, чтобы помочь заинтересованным сторонам
визуализировать внешний вид и возможности запланированного решения.
 • Матрица ролей и разрешений: используется для определения и моделирования
требований, связанных с разделением обязанностей между пользователями и внешними
интерфейсами при использовании решения.
 • Анализ первопричин: используется для моделирования первопричин проблемы как
части обоснования.
 • Моделирование области: используется для визуального отображения границы области.
 • Диаграммы последовательности: используются для определения и моделирования
требований, чтобы показать, как процессы работают и взаимодействуют друг с другом и в
каком порядке.
 • Список заинтересованных сторон, Карта или Персоны: используются для определения
заинтересованных сторон и их характеристик.
 • Моделирование состояний: используется для указания различных состояний части
решения на протяжении жизненного цикла с точки зрения происходящих событий.
 Сценарии: используется для моделирования желаемого поведения решения путем
демонстрации взаимодействия пользователя с решением для достижения конкретной
цели или выполнения конкретной задачи.
 • Пользовательские истории: используются для указания требований в виде краткого
изложения того, что люди делают или должны делать при использовании решения.
7.1.7. Заинтересованные стороны

Любая заинтересованная сторона: бизнес-аналитики могут решить выполнить эту задачу

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

7.1.8. Выходы

Требования (уточненные и смоделированные): любая комбинация уравнений и / или дизайнов в

форме текста, матриц и диаграмм.

7.2 Верификация требований

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

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

Качественная спецификация хорошо написана и легко понятна предполагаемой аудитории.

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

Наиболее важной характеристикой требований к качеству и качества является пригодность для

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

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

7.2.4 Элементы
.1 Характеристики требований и качества конструкций
Хотя качество в конечном итоге определяется потребностями заинтересованных сторон, которые
будут использовать требования или проекты, приемлемые требования к качеству проявляют
многие из следующих характеристики требований к качеству:

• Автономное: автономный и способный быть понятым независимо от других требований

или проектов.
• Завершенное: достаточно для направления дальнейшей работы и на соответствующем
уровне детализации для продолжения работы. Требуемый уровень полноты различается в
зависимости от точки зрения или методологии, а также от точки жизненного цикла, где
требование изучается или представляется.
• Последовательное: соответствует выявленным потребностям заинтересованных сторон и
не противоречит другим требованиям.
• Краткое: не содержит постороннего и ненужного контента.
• Выполнимое: разумно и возможно в рамках согласованного риска, графика и бюджета
или считается достаточно выполнимым для дальнейшего изучения с помощью
экспериментов или прототипов.
• Однозначное: требование должно быть четко сформулировано таким образом, чтобы
было ясно, удовлетворяет ли решение соответствующей потребности.
• Проверяемое: способен проверить, что требование или проект были выполнены.
Приемлемые уровни проверки выполнения зависят от уровня абстракции требования или
проекта.
• Приоритетность: ранжирование, группировка или согласование с точки зрения важности и
ценности по сравнению со всеми другими требованиями.
• Понятное: представлено с использованием общей терминологии аудитории.

.2 Проверочные мероприятия

Действия по проверке обычно выполняются итеративно на протяжении всего процесса анализа

требований.

Проверочные мероприятия включают в себя:

• проверка соответствия стандартам эффективности организации для бизнес-анализа,

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

.3 Чек-лист

Чек-листы (контрольные списки) используются для контроля качества при проверке требований.

Контрольные списки могут включать стандартный набор качественных элементов, которые

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

7.2.5 Руководство и инструменты

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

7.2.6 Методы
• Критерии приемки и оценки: используются для обеспечения того, чтобы требования были
изложены достаточно четко, чтобы разработать набор тестов, которые могут доказать, что
требования были выполнены.
• Отслеживание элементов: используется для того, чтобы гарантировать, что любые
проблемы или проблемы, выявленные в ходе проверки, решаются и решаются.
• Метрики и ключевые показатели эффективности (KPI): используются для определения
того, как оценивать качество требований.
• Обзоры: используются для проверки документации требований, чтобы определить
требования, которые не имеют приемлемого качества.

7.2.7 Заинтересованные стороны

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

Поэтому все заинтересованные стороны могут быть вовлечены в эту задачу.

7.2.8 Выходы
Требования (проверено): набор требований или проектов, которые имеют достаточное качество
для использования в качестве основы для дальнейшей работы.

7.3 Валидация требований

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

7.3.2 Описание
Проверка требований - это постоянный процесс, который обеспечивает соответствие требований
заинтересованных сторон, решений и переходных процессов бизнес-требованиям и соответствие
проектов требованиям.

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

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

7.3.4 Элементы
.1 Определение допущений

Если организация запускает беспрецедентный продукт или услугу, может возникнуть

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

.2 Определение измеримых критерий оценки

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

.3 Оценка согласованности с объемом решения

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

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

7.3.5 Руководство и инструменты

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

7.3.6 Методы
• Критерии приемки и оценки: используются для определения показателей
качества, которые должны соблюдаться для достижения согласия
заинтересованной стороны.
• Анализ документов: используется для определения ранее задокументированных
бизнес-потребностей с целью проверки требований.
• Финансовый анализ: используется для определения финансовых выгод, связанных
с требованиями.
• Отслеживание элементов: используется, чтобы гарантировать, что любые
проблемы или проблемы, выявленные во время проверки, решаются и решаются.
• Метрики и ключевые показатели эффективности (KPI): используются для выбора
подходящих показателей производительности для решения, компонента решения
или требования.
• • Отзывы: используется для подтверждения того, соглашается ли
заинтересованная сторона с удовлетворением их потребностей.
• • Анализ и управление рисками: используется для определения возможных
сценариев, которые могут изменить выгоду, обеспечиваемую требованием.

7.3.7 Заинтересованные стороны

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

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

7.4 Структуризация и организация требований

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

7.4.2 Описание
Архитектура требований - это структура всех требований изменения.

Архитектура требований объединяет отдельные модели и спецификации вместе, чтобы

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

Бизнес-аналитики используют структуризацию требований для:

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

Структуризация требований предназначена не для демонстрации прослеживаемости, а для того,

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

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

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

7.4.4 Элементы
.1 Требования Точки зрения и виды

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

• типы моделей, используемые для требований,

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

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

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

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

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

Фактические требования и проекты для конкретного решения с выбранной точки зрения

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

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

.2 Шаблонные архитектуры

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

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

Структурирование требований в соответствии с различными точками зрения помогает обеспечить

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

7.4.5 Руководство и инструменты

• Программное обеспечение для управления архитектурой: программное обеспечение для
моделирования может помочь управлять объемом, сложностью и версиями отношений в
рамках архитектуры требований.
• Правовая / нормативная информация: описывает законодательные нормы или правила,
которые необходимо соблюдать. Они могут влиять на архитектуру требований или ее
результаты. Кроме того, договорные или основанные на стандартах ограничения также
могут быть рассмотрены.

7.4.6 Методы
• Моделирование данных: используется для описания структуры требований
применительно к данным.
• Функциональная декомпозиция: используется для разбиения организационной единицы,
области продукта или других элементов на составные части.
• Интервью: используется для совместного определения структуры требований.
• Организационное моделирование: используется для понимания различных
организационных единиц, заинтересованных сторон и их отношений, которые могут
помочь определить соответствующие точки зрения.
• Моделирование области: используется для определения элементов и границ архитектуры
требований.
• Семинары: используются для совместного определения структуры требований.

7.4.7 Заинтересованные стороны

• Эксперт предметной области предметной области, эксперт предметной области
реализации, руководитель проекта, спонсор, тестер: может помочь в определении и
подтверждении архитектуры требований.
• Любая заинтересованная сторона: может также использовать архитектуру требований для
оценки полноты требований.

7.4.8 Выходы
Архитектура требований: требования и взаимосвязи между ними, а также любая контекстная
информация, которая записывается.

7.5 Определение вариантов решения

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

7.5.2 Описание
При разработке может быть определен один или несколько вариантов решения.

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

7.5.3. Входы
• Стратегия изменения: описывает подход, который будет применяться при переходе в
будущее состояние. Это может иметь некоторое влияние на проектные решения с точки
зрения того, что возможно или возможно.
• Требования (подтвержденные, приоритетные): только утвержденные требования
• Рассматривается в вариантах решений. Знание приоритетов требований помогает в
предложении разумных вариантов дизайна. Требования с наивысшими приоритетами
могут заслуживать большего веса при выборе компонентов решения для наилучшего их
соответствия по сравнению с требованиями с более низким приоритетом.
• Архитектура требований: полный набор требований и их взаимосвязи важен для
определения вариантов проектирования, которые могут удовлетворить целостный набор
требований.

7.5.4 методы
.1 Определение подходов к решению

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

Подходы к решению включают в себя:

• Разработка: компоненты решения собираются, конструируются или разрабатываются

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

Во всех этих подходах предлагаемая интеграция компонентов также рассматривается в рамках

варианта проектирования.

.2 Определить возможности улучшения

Предлагая варианты решений, может возникнуть ряд возможностей для улучшения работы
бизнеса, которые можно сравнить.

Некоторые общие примеры возможностей включают в себя:

• Повышение эффективности: автоматизируйте или упростите работу, выполняемую

людьми, путем реинжиниринга или совместного использования процессов, изменения
обязанностей или аутсорсинга.
• Автоматизация может также повысить согласованность поведения, уменьшив вероятность
того, что разные заинтересованные стороны выполняют одну и ту же функцию в
совершенно разных формах.
• Улучшите доступ к информации: предоставьте больше информации сотрудникам,
которые прямо или косвенно взаимодействуют с клиентами, тем самым уменьшая
потребность в специалистах.
• Определить дополнительные возможности: выделите возможности, которые могут
обеспечить будущую ценность и могут быть поддержаны решением. Эти возможности не
обязательно могут иметь непосредственное значение для организации (например,
программное приложение с функциями, которые организация ожидает использовать в
будущем).

.3 Распределение требований

Распределение требований - это процесс присвоения требований компонентам и выпускам

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

Требования могут быть распределены между организационными единицами, рабочими

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

.4 Описание параметров решения

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

Вариант решения обычно состоит из множества компонентов, каждый из которых описывается

элементом. Элементы могут описывать:

• деловая политика и деловые правила,

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

7.5.5 Руководство и инструменты

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

7.5.6 Методы
• Сравнительный анализ и анализ рынка: используется для определения и анализа
существующих решений и тенденций рынка.
• Мозговой штурм: используется для определения возможностей улучшения и вариантов
разработки.
• Анализ документов: используется для предоставления информации, необходимой для
описания вариантов решений и элементов решений.
• Интервью: используется, чтобы помочь определить возможности улучшения и варианты
дизайна.
• Лучшие практики: используются для определения возможностей улучшения.
• Mind Mapping: используется для определения и изучения возможных вариантов дизайна.
• Анализ первопричин: используется для понимания первопричины проблем, которые
будут затронуты в изменениях, чтобы предложить решения для их устранения.
• Опрос или вопросник: используется для определения возможностей улучшения и
вариантов дизайна.
• Оценка поставщика: используется для объединения оценки стороннего решения с
оценкой поставщика, чтобы гарантировать, что решение является жизнеспособным, и все
стороны смогут развивать и поддерживать здоровые рабочие отношения.
• Семинары: используются для определения возможностей улучшения и вариантов
дизайна.

7.5.7 Заинтересованные лица

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

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

7.6 Оценка потенциальной ценности

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

7.6.2 Описание
Анализ потенциальной стоимости и рекомендация решения описывает, как оценить и
смоделировать потенциальную стоимость, обеспечиваемую набором требований, проектов или
вариантов дизайна. Потенциальная стоимость анализируется много раз в течение изменения. Этот
анализ может быть запланированным событием или может быть вызван изменением контекста
или объема изменения. Анализ потенциальной ценности включает в себя рассмотрение того, что
в оценках есть неопределенность. Ценность может быть описана с точки зрения финансов,
репутации или даже влияния на рынок. Любое изменение может включать в себя сочетание
увеличения и уменьшения стоимости.

Варианты дизайна оцениваются путем сравнения потенциальной ценности каждого варианта с

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

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

7.6.4 Элементы
.1 Ожидаемые выгоды

Ожидаемые выгоды описывают положительную ценность, которую решение призвано

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

.2 Ожидаемые затраты

Ожидаемые затраты включают любое потенциальное отрицательное значение, связанное с

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

Ожидаемые расходы могут включать в себя:

• график,
• операционные затраты,
• покупка и / или реализация
• расходы,
• эксплуатационные расходы,
• физические ресурсы,
• информационные ресурсы и
• отдел кадров.

Ожидаемые затраты на один вариант решения учитывают совокупные затраты на компоненты

проекта.

Бизнес-аналитики также учитывают альтернативную стоимость при оценке ожидаемой стоимости

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

.3 Определение ценности

Потенциальная ценность решения для заинтересованной стороны основана на преимуществах

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

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

.4 Оценка вариантов разработки и рекомендация решения

Каждый вариант решения оценивается на основе потенциальной ценности, которую он должен

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

Поскольку затраты и усилия понимаются для каждого компонента решения, бизнес-аналитики

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

• Доступные ресурсы: могут быть ограничения в отношении количества требований,

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

Другие предложения могут включать отношения с предлагаемыми поставщиками, зависимость от

других инициатив, корпоративную культуру и достаточный денежный поток для инвестиций.

Бизнес-аналитики рекомендуют вариант или варианты, которые считаются наиболее ценным

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

7.6.5 Руководство и инструменты

 • Бизнес-цели: используется для расчета ожидаемой выгоды.
• Текущее состояние требований: предоставляет контекст, в котором работа должна быть
завершена. С его помощью можно определить и помочь количественно оценить ценность,
которую можно получить от потенциального решения.
• Описание будущего состояния: описывает желаемое будущее состояние, частью которого
будет являться решение, чтобы обеспечить соответствие вариантов проектирования.
• Результаты анализа риска: потенциальная ценность вариантов проектирования включает
оценку уровня риска, связанного с вариантами проектирования или инициативой.
• Область действия решения: определяет область действия решения, которое доставляется,
чтобы можно было сделать соответствующую оценку, находящуюся в границах области
действия.

7.6.6 Методы

Критерии принятия и оценки: используются для выражения требований в форме критериев

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

• Управление невыполненными работами: используется для последовательности

потенциального значения.
• Мозговой штурм: используется для определения потенциальных преимуществ
требований в духе сотрудничества.
• Бизнес-кейсы: используются для оценки рекомендаций относительно бизнес-целей и
задач.
• Бизнес-модель Canvas: используется как инструмент, помогающий понять стратегию и
инициативы.
• Анализ решений: используется для поддержки оценки и ранжирования вариантов
дизайна.
• Оценка: используется для прогнозирования затрат и усилий по выполнению требований в
качестве шага к оценке их стоимости.
• Финансовый анализ: используется для оценки финансовой отдачи различных вариантов и
выбора наилучшей возможной отдачи от инвестиций.
• Фокус-группы: используются для получения информации от заинтересованных сторон о
том, какие варианты дизайна наилучшим образом соответствуют требованиям, а также
для оценки ценностных ожиданий целевой небольшой группы заинтересованных сторон.
• Интервью: используется для получения информации от заинтересованных сторон о том,
какие варианты дизайна наилучшим образом соответствуют требованиям, а также для
оценки ценностных ожиданий отдельных заинтересованных сторон.
• Метрики и ключевые показатели эффективности (KPI): используются для создания и
оценки измерений, используемых при определении значения.
• Анализ и управление рисками: используется для выявления и управления рисками,
которые могут повлиять на потенциальную ценность требований.
• Опрос или вопросник: используется для получения информации от заинтересованных
сторон о том, какие варианты дизайна лучше всего соответствуют требованиям, и для
определения ценностных ожиданий заинтересованных сторон.
• SWOT-анализ: используется для определения сильных и слабых сторон, которые влияют
на ценность решений.
 • Семинары: используются для получения информации от заинтересованных сторон о том,
какие варианты дизайна лучше всего соответствуют требованиям, а также для оценки
ожиданий заинтересованных сторон.

7.6.7 Заинтересованные лица

• Клиент: представляет сегменты рынка, на которые влияют требования и решения, и будет
участвовать в анализе преимуществ этих требований и затрат на варианты
проектирования.
• Конечный пользователь: дает представление о потенциальной ценности изменения.
• Эксперт по предмету реализации: может быть вызван для опыта в реализации вариантов
дизайна с целью выявления потенциальных затрат и рисков.
• Менеджер проекта: управляет процессом отбора таким образом, чтобы при
осуществлении изменения они знали о потенциальных воздействиях на тех, кто
поддерживает изменение, включая риски, связанные с изменением.
• Регулирующий орган: может участвовать в оценке рисков, связанных с внешними
регулирующими органами, или накладывать ограничения на потенциальные выгоды.
• Спонсор: утверждает расходование ресурсов на приобретение или разработку решения и
утверждает окончательную рекомендацию. Спонсор захочет, чтобы его постоянно
информировали о любых изменениях потенциальной ценности или риска, а также
возможных издержек, так как он / она может предпочесть другой курс действий.

7.6.8 Выходы
Утвержденное реализация: определяет предложенное, наиболее подходящее решение на
основе оценки всех определенных вариантов разработки. Рекомендуемое решение должно
максимизировать ценность, предоставляемую предприятию.