7. Анализ требований и определение дизайна

Question 1

Что область знаний “Анализ требований и определение дизайна”
описывает?

Answer 1

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

Question 2

Какие ценности бизнес-анализа в рамках Анализа требований и определение дизайна?

Answer 2

Question 3

Какие задачи включает область знаний “Анализ требований и определение дизайна”?

Answer 3

1. Спецификация и моделирование требований
2. Верификация требований
3. Валидация требований
4. Определение архитектуры требований
5. Определение вариантов решения
6. Анализ потенциальной ценности и рекомендация решения

Question 4

В чем суть задачи “Спецификация и моделирование требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 4

Спецификация и моделирование требований: подробное
описание набора требований или дизайнов с использованием
аналитических методов.

Question 5

В чем суть задачи “Верификация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 5

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

Question 6

В чем суть задачи “Валидация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 6

Валидация требований: проверка того, что набор требований или
дизайнов полезен для бизнеса и поддерживает цели и задачи
организации.

Question 7

В чем суть задачи “Определение архитектуры требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 7

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

Question 8

В чем суть задачи “Определение вариантов решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 8

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

Question 9

В чем суть задачи “Анализ потенциальной ценности и рекомендация решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 9

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

Question 10

Как описывается модель базовых понятий бизнес-анализа области знаний “Анализ требований и определение дизайна” в рамках понятия “Изменение”?

Answer 10

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

Question 11

Как описывается модель базовых понятий бизнес-анализа области знаний “Анализ требований и определение дизайна” в рамках понятия “Потребность”?

Answer 11

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

Question 12

Как описывается модель базовых понятий бизнес-анализа области знаний “Анализ требований и определение дизайна” в рамках понятия “Решение”?

Answer 12

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

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

Question 13

Как описывается модель базовых понятий бизнес-анализа области знаний “Анализ требований и определение дизайна” в рамках понятия “Заинтересованная сторона”?

Answer 13

Заинтересованная сторона: лицо или группа лиц, имеющие отношение к изменению, потребности или решению.

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

Question 14

Как описывается модель базовых понятий бизнес-анализа области знаний “Анализ требований и определение дизайна” в рамках понятия “Ценность”?

Answer 14

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

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

Question 15

Как описывается модель базовых понятий бизнес-анализа области знаний “Анализ требований и определение дизайна” в рамках понятия “Контекст”?

Answer 15

Контекст: обстоятельства, влияющие на изменение, затрагиваемые им, или
обеспечивающие его понимание.

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

Question 16

Из каких элементов состоит диаграмма входной и выходной информации области знаний “Анализ требований и определение дизайна”

Answer 16

Question 17

В чем назначение задачи “7.1 Спецификация и моделирование требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 17

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

Question 18

В чем суть описания задачи “7.1 Спецификация и моделирование требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 18

Область знания “Спецификация и моделирование требований”
описывает практики анализа результатов выявления и создания
представлений этих результатов. Когда деятельность по спецификации и
моделированию фокусируется на понимании потребности, результаты
называются требованиями. Когда деятельность по определению и
моделированию фокусируется на решении, результаты называются
дизайнами.
ВАЖНО! Во многих IT-cообществах слово “дизайн” используется конкретно для
технических дизайнов, создаваемых разработчиками программного
обеспечения, архитекторами данных и другими специалистами в
области реализации. Все ожидаемые бизнесом результаты
обозначаются как “требования”.
В дополнение к моделям, используемым для описания требований, эта
задача также включает в себя сбор информации об атрибутах или
метаданных требований. Действия по определению и моделированию
касаются всех видов требований.

Question 19

Какая входящая информация для задачи “7.1 Спецификация и моделирование требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 19

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

Question 20

Какие элементы входят в задачу “7.1 Спецификация и моделирование требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 20

1. Моделирование требований
2. Анализ требований
3. Представление требований и атрибутов
4. Использование подходящих уровней абстракции

Question 21

В чем суть элемента “Моделирование требований” в рамках задачи “7.1 Спецификация и моделирование требований”?

Question 22

В чем суть элемента “Моделирование требований” в рамках задачи “7.1 Спецификация и моделирование требований”?

Answer 22

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

Question 23

Какие бывают форматы моделирования?

Answer 23

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

Question 24

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

Answer 24

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

Question 25

В чем суть элемента “Анализ требований” в рамках задачи “7.1 Спецификация и моделирование требований”?

Answer 25

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

Question 26

В чем суть элемента “Представление требований и атрибутов” в рамках задачи “7.1 Спецификация и моделирование требований”?

Answer 26

Бизнес-аналитики определяют информацию о требованиях и их
атрибутах как часть результатов выявления. Требования должны
представляться явно и содержать достаточное количество деталей
чтобы соответствовать характеристикам качества требований и
дизайнов (см.Верификация требований (стр. 171)). Для каждого
требования или набора требований могут определяться различные
атрибуты. Эти атрибуты выбираются при планировании управления
информацией (см. Планирование управления информацией бизнес-анализа (стр. 53)).
Как составная часть определения требований, требования также могут
классифицироваться согласно схеме, описанной в задаче Схема
классификации требований (стр. 19). Обычно результаты выявления
содержат информацию различных видов, поэтому естественно ожидать,
что одновременно могут определяться различные виды требований.
Категоризация требований помогает убедиться в полноте понимания
требований, завершенности набора требований каждого вида, и что
между видами есть надлежащая прослеживаемость

Question 27

В чем суть элемента “Использование подходящих уровней абстракции” в рамках задачи “7.1 Спецификация и моделирование требований”?

Answer 27

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

Question 28

Какие руководства и инструменты относятся к задаче “7.1 Спецификация и моделирование требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 28

1. Нотации/стандарты моделирования: позволяют точно определять
   требования и дизайны в соответствии с аудиторией и назначением
   моделей. Стандартные шаблоны и синтаксис помогают обеспечить
   предоставление необходимой информации о требованиях.
2. Инструменты моделирования: программные продукты, облегчающие
   построение и хранение матриц и диаграмм для отображения
   требований. Эта функциональность может быть или не быть частью
   инструментов управления жизненным циклом требований.
3. Архитектура требований: требования и взаимоотношения между
   ними могут использоваться для проверки полноты и согласованности
   моделей.
4. Инструменты управления жизненным циклом требований:
   программные продукты, облегчающие запись, организацию, хранение
   и совместное использование требований и дизайнов.
5. Скоуп решения: границы решения задают границы для моделей
   требований и дизайнов.

Question 29

Какие техники используются для задачи “7.1 Спецификация и моделирование требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 29

1. Критерии приемки и оценки: используются для представления
   атрибутов требований, относящихся к критериям приемки и оценки.
2. Анализ возможностей бизнеса: используется для представления
   свойств или функций предприятия.
3. Канва бизнес-модели: используется для описания причин требований.
4. Анализ бизнес-правил: используется для анализа бизнес-правил с тем,
   чтобы определить и смоделировать их вместе с требованиями.
5. Моделирование понятий: используется для определения терминов и
   связей, относящихся к изменению и предприятию.
6. Cловарь данных: используется для записи сведений о данных,
   вовлекаемых в изменение. Сведения могут включать в себя
   определения, отношения к другим данным, источник, формат и
   использование.
7. Диаграммы потоков данных: используется для визуализации
   требований к потокам данных.
8. Моделирование данных: используется для моделирования
   требований, чтобы показать, как данные будут использоваться для
   удовлетворения информационных потребностей заинтересованных
   сторон.
9. Моделирование решений: используется для представления решений
   в виде модели, чтобы показать элементы требуемого принимаемого
   решения.
10. Функциональная декомпозиция: используется для моделирования
    требований с целью определения составных частей общей сложной
    бизнес-функции.
11. Глоссарий: используется для записи определений значимых бизнес-терминов в ходе анализа требований.
12. Анализ интерфейсов: используется для моделирования требований с
    целью выявления и валидации входной и выходной информации
    моделируемого ими решения.
13. Анализ нефункциональных требований: используется для
    определения и анализа атрибутов качества сервиса.
14. Организационное моделирование: позволяет бизнес-аналитикам
    моделировать роли, обязанности и коммуникации в рамках
    организации.
15. Моделирование процесса: используется для отображения шагов или
    действий, которые выполняются в организации, или которые должны
    быть выполнены для достижения желаемых изменений.
16. Прототипирование: используется для оказания помощи
    заинтересованным сторонам в визуализации внешнего вида и
    возможностей запланированного решения.
17. Матрица ролей и прав: используется для определения и
    моделирования требований, касающихся разделения обязанностей
    между пользователями и внешними интерфейсами при
    использовании решения.
18. Анализ корневых причин: используется для моделирования корневых
    причин проблемы в качестве обоснования.
19. Моделирование скоупа: используется, чтобы визуально показать
    границы решения.
20. Диаграммы последовательности: используются при определении и
    моделировании требований, чтобы показать, как и в каком порядке
    процессы работают и взаимодействуют друг с другом.
21. Список, карта или персоны заинтересованных сторон: используются
    для выявления заинтересованных сторон и их характеристик.
22. Моделирование состояний: используется для определения различных
    состояний части решения на протяжении жизненного цикла с точки
    зрения происходящих событий.
23. Варианты использования и сценарии: используются для
    моделирования желаемого поведения решения, показывая
    взаимодействие пользователя с решением для достижения
    определенной цели или выполнения конкретной задачи.
24. Пользовательские истории: используются для описания требований в
    виде краткого утверждения о том, что люди делают или должны
    делать при использовании решения.

Question 30

Какие заинтересованные стороны есть у задачи “7.1 Спецификация и моделирование требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 30

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

Question 31

Какая выходная информация получается из задачи “7.1 Спецификация и моделирование требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 31

Требования (определенные и смоделированные): любое сочетание

требований и/или дизайнов в виде текста, матриц и диаграмм

Question 32

В чем назначение задачи “7.2 Верификация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 32

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

Question 33

В чем суть описания задачи “7.2 Верификация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 33

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

Question 34

Какая входящая информация для задачи “7.2 Верификация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 34

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

Question 35

Какие элементы входят в задачу “7.2 Верификация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 35

1. Характеристики качества требований и дизайнов
2. Действия верификации
3. Чек-листы

Question 36

В чем суть элемента “Характеристики качества требований и дизайнов” в рамках задачи “7.2 Верификация требований”?

Answer 36

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

Question 37

В чем суть элемента “Действия верификации” в рамках задачи “7.2 Верификация требований”?

Answer 37

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

Question 38

В чем суть элемента “Чек-листы” в рамках задачи “7.2 Верификация требований”?

Answer 38

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

Question 39

Какие руководства и инструменты относятся к задаче “7.2 Верификация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 39

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

Question 40

Какие техники используются для задачи “7.2 Верификация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 40

1. Критерии приемки и оценки: используются для того, чтобы
   удостовериться в том, что требования сформулированы достаточно
   ясно для разработки набора тестов, способных подтвердить
   выполнение требований.
2. Отслеживание вопросов: используется для того, чтобы гарантировать,
   что проблемы или вопросы, выявленные в ходе верификации,
   контролируются и разрешаются.
3. Метрики и ключевые показатели эффективности (Key Performance
   Indicators, KPI): используются для определения того, как оценивается
   качество требований.
4. Рассмотрение: используется для проверки документации требований с
   целью выявления требований неприемлемого качества.

Question 41

Какие заинтересованные стороны есть у задачи “7.2 Верификация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 41

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

Question 42

Какая выходная информация получается из задачи “7.2 Верификация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 42

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

Question 43

В чем назначение задачи “7.3 Валидация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 43

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

Question 44

В чем суть описания задачи “7.3 Валидация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 44

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

Question 45

Какая входящая информация для задачи “7.3 Валидация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 45

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

Question 46

Какие элементы входят в задачу “7.3 Валидация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 46

1. Выявление предположений
2. Определение измеримых критериев оценки
3. Оценка соответствия скоупу решения

Question 47

В чем суть элемента “Выявление предположений” в рамках задачи “7.3 Валидация требований”?

Answer 47

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

Question 48

В чем суть элемента “Определение измеримых критериев оценки” в рамках задачи “7.3 Валидация требований”?

Answer 48

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

Question 49

В чем суть элемента “Оценка соответствия скоупу решения” в рамках задачи “7.3 Валидация требований”?

Answer 49

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

Question 50

Какие руководства и инструменты относятся к задаче “7.3 Валидация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 50

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

Question 51

Какие техники используются для задачи “7.3 Валидация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 51

1. Критерии приемки и оценки: используются для определения метрик
   качества, подлежащих соблюдению для принятия заинтересованной
   стороной.
2. Анализ документов: используется для выявления
   задокументированных ранее бизнес-потребностей с целью валидации
   требований.
3. Финансовый анализ: используется для определения финансовых
   выгод, связанных с требованиями.
4. Отслеживание вопросов: используется, чтобы гарантировать, что
   любые проблемы или вопросы, выявленные в ходе верификации,
   контролируются и решаются.
5. Метрики и ключевые показатели эффективности (Key Performance
   Indicators, KPI): используются для выбора подходящих мер
   эффективности решения, компонента решения или требования
6. Рассмотрение: используется для подтверждения согласия
   заинтересованной стороны с тем, что их потребности
   удовлетворяются.
7. Анализ и управление рисками: используется для определения
   возможных сценариев, способных изменить приносимую требованием
   выгоду.

Question 52

Какие заинтересованные стороны есть у задачи “7.3 Валидация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 52

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

Question 53

Какая выходная информация получается из задачи “7.3 Валидация требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 53

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

Question 54

В чем назначение задачи “7.4 Определение архитектуры требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 54

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

Question 55

В чем суть описания задачи “7.4 Определение архитектуры требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 55

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

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

Question 56

Какая входящая информация для задачи “7.4 Определение архитектуры требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 56

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

Question 57

Какие элементы входят в задачу “7.4 Определение архитектуры требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 57

1. Точки зрения и представления требований
2. Шаблонные архитектуры
3. Полнота
4. Соотнесение и верификация отношений требований
5. Архитектура информации бизнес-анализа

Question 58

В чем суть элемента “Точки зрения и представления требований” в рамках задачи “7.4 Определение архитектуры требований”?

Answer 58

Точка зрения — это набор соглашений, определяющих как
представляются требования, как эти представления организуются, и
как они будут связаны. Точки зрения дают шаблоны для учета
интересов конкретных групп заинтересованных сторон.
Точки зрения на требования часто включают стандарты и руководства
для:
• типов моделей, используемых для разработки требований,
• атрибутов, включаемых и систематически используемых в
различных моделях,
• используемых нотаций моделирования,
• аналитических подходов, используемых для выявления и
поддержания соответствующих отношений между моделями.
Ни одна точка зрения не может в одиночку определить всю архитектуру.
Каждая точка зрения сильнее в некоторых аспектах требований и слабее
в других, поскольку разные группы заинтересованных сторон имеют
разные интересы. Попытка вложить слишком много информации в
какую-либо одну точку зрения слишком усложнит ее и ухудшит ее
назначение. К примерам точек зрения относятся:
• Модели бизнес-процессов,
• Модели данных и информация,
• Взаимодействие пользователей, включая варианты использования
и/или пользовательский опыт (user experience),
• Аудит и безопасность,
• Бизнес-модели.
Каждая из этих точек зрения имеет разные нотации и техники
моделирования, и каждая из них важна для обеспечения связного
конечного решения. Вряд ли будет успешным решение, на которое
бизнес-аналитик смотрел лишь с точки зрения бизнес-процесса.
Аналогично, попытка объединить множество точек зрения в одну
единственную точку зрения сделала бы ее слишком сложной для
анализа, а также содержащей информацию, не имеющую отношения к
конкретным группам заинтересованных сторон.
Фактические требования и дизайны для конкретного решения с
выбранной точки зрения называются “представление”. Набор
представлений образует архитектуру требований конкретного решения.
Бизнес-аналитики связывают, координируют и объединяют требования в
представления, имеющие смысл для различных заинтересованных
сторон. Этот набор скоординированных и взаимодополняющих
представлений дает основу для оценки полноты и согласованности
требований.
Короче говоря, точки зрения говорят бизнес-аналитикам, какую
информацию они должны предоставить каждой группе
заинтересованных сторон, чтобы учесть ее интересы, тогда как
представления описывают фактически созданные требования и
дизайны.

Question 59

В чем суть элемента “Шаблонные архитектуры” в рамках задачи “7.4 Определение архитектуры требований”?

Answer 59

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

Question 60

В чем суть элемента “Полнота” в рамках задачи “7.4 Определение архитектуры требований”?

Answer 60

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

Question 61

В чем суть элемента “Соотнесение и верификация отношений требований” в рамках задачи “7.4 Определение архитектуры требований”?

Answer 61

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

Question 62

В чем суть элемента “Архитектура информации бизнес-анализа” в рамках задачи “7.4 Определение архитектуры требований”?

Answer 62

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

Question 63

Какие руководства и инструменты относятся к задаче “7.4 Определение архитектуры требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 63

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

Question 64

Какие техники используются для задачи “7.4 Определение архитектуры требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 64

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

Question 65

Какие заинтересованные стороны есть у задачи “7.4 Определение архитектуры требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 65

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

Question 66

Какая выходная информация получается из задачи “7.4 Определение архитектуры требований” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 66

Архитектура требований: требования и взаимоотношения между

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

Question 67

В чем назначение задачи “7.5 Определение вариантов дизайна” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 67

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

Question 68

В чем суть описания задачи “7.5 Определение вариантов дизайна” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 68

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

Question 69

Какая входящая информация для задачи “7.5 Определение вариантов дизайна” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 69

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

Question 70

Какие элементы входят в задачу “7.5 Определение вариантов дизайна” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 70

1. Определение подходов к решению
2. Выявление возможностей улучшения
3. Размещение требований
4. Описание вариантов дизайна

Question 71

В чем суть элемента “Определение подходов к решению” в рамках задачи “7.5 Определение вариантов дизайна”?

Answer 71

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

Question 72

В чем суть элемента “Выявление возможностей улучшения” в рамках задачи “7.5 Определение вариантов дизайна”?

Answer 72

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

Question 73

В чем суть элемента “Размещение требований” в рамках задачи “7.5 Определение вариантов дизайна”?

Answer 73

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

Question 74

В чем суть элемента “Описание вариантов дизайна” в рамках задачи “7.5 Определение вариантов дизайна”?

Answer 74

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

Question 75

Какие руководства и инструменты относятся к задаче “7.5 Определение вариантов дизайна” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 75

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

Question 76

Какие техники используются для задачи “7.5 Определение вариантов дизайна” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 76

1. Бенчмаркинг и анализ рынка: используется для определения и
   анализа существующих решений и рыночных тенденций.
2. Мозговой штурм: помогают определить возможности улучшения и
   варианты дизайна.
3. Анализ документов: дает информацию, необходимую для описания
   вариантов и элементов дизайна.
4. Интервью: помогает определить возможности для улучшения и
   варианты дизайна
5. Анализ полученного опыта: используется для генерации идей
   относительно возможностей улучшения.
6. Карты ассоциаций: используются для определения и изучения
   возможных вариантов дизайна.
7. Анализ корневых причин: используется для понимания первопричины
   проблем, решаемых при изменении, чтобы предложить решения для
   их устранения.
8. Опрос или анкетирование: помогает определить возможности
   улучшения и варианты дизайна
9. Оценка вендора: соединяет оценку стороннего решения с оценкой
   поставщика, чтобы удостовериться в жизнеспособности решения и
   способности всех сторон развивать и поддерживать здоровые рабочие
   отношения.
10. Семинары: помогают определить возможности улучшения и варианты
    дизайна

Question 77

Какие заинтересованные стороны есть у задачи “7.5 Определение вариантов дизайна” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 77

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

Question 78

Какая выходная информация получается из задачи “7.5 Определение вариантов дизайна” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 78

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

Question 79

В чем назначение задачи “7.6 Анализ потенциальной ценности и рекомендация решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 79

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

Question 80

В чем суть описания задачи “7.6 Анализ потенциальной ценности и рекомендация решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 80

Задача “Анализ потенциальной ценности и рекомендация решения”
описывает, как оценить и смоделировать потенциальную ценность,
приносимую набором требований, дизайнов или вариантов дизайна.
Потенциальная ценность многократно анализируется в ходе изменения.
Этот анализ может быть плановым событием, а может инициироваться
изменением контекста или рамок изменения. При анализе
потенциальной ценности учитывается наличе неопределенности в
оценках. Ценность может быть описана в терминах финансов, репутации
или даже влияния на рынок. Любое изменение может содержать в себе
сочетание факторов, увеличивающих и уменьшающих ценность.
Варианты дизайна оцениваются сравнением потенциальной ценности
каждого варианта с другими вариантами. Каждый вариант содержит
смесь преимуществ и недостатков, подлежащих рассмотрению. В
зависимости от причин изменения, может не быть наилучшего
рекомендуемого варианта, а может быть очевидный лучший выбор. В
некоторых случаях это означает, что наилучшим вариантом может быть
начать работу над несколькими вариантами дизайна, например, чтобы
создать прототипы, а затем измерить эффективность каждого из них. В
других случаях все предлагаемые дизайны могут быть отклонены, и
может потребоваться дополнительный анализ для определения
подходящего дизайна. Также возможно, что лучшей рекомендацией
будет - ничего не делать

Question 81

Какая входящая информация для задачи “7.6 Анализ потенциальной ценности и рекомендация решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 81

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

Question 82

Какие элементы входят в задачу “7.6 Анализ потенциальной ценности и рекомендация решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 82

1. Ожидаемые выгоды
2. Ожидаемые затраты
3. Определение ценности
4. Оценка вариантов дизайна и рекомендация решения

Question 83

В чем суть элемента “Ожидаемые выгоды” в рамках задачи “7.6 Анализ потенциальной ценности и рекомендация решения”?

Answer 83

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

Question 84

В чем суть элемента “Ожидаемые затраты” в рамках задачи “7.6 Анализ потенциальной ценности и рекомендация решения”?

Answer 84

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

Question 85

В чем суть элемента “Определение ценности” в рамках задачи “7.6 Анализ потенциальной ценности и рекомендация решения”?

Answer 85

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

Question 86

В чем суть элемента “Оценка вариантов дизайна и рекомендация решения” в рамках задачи “7.6 Анализ потенциальной ценности и рекомендация решения”?

Answer 86

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

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

Question 87

Какие руководства и инструменты относятся к задаче “7.6 Анализ потенциальной ценности и рекомендация решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 87

1. Целевые показатели бизнеса: используются для расчета ожидаемой
   выгоды.
2. Описание текущего состояния: дает контекст, в рамках которого
   необходимо выполнить работу. Оно помогает определить и
   количественно оценить ценность, приносимую потенциальным
   решением.
3. Описание будущего состояния: описывает желаемое будущее
   состояние, частью которого будет решение, чтобы обеспечить
   пригодность вариантов дизайна.
4. Результаты анализа рисков: потенциальная ценность вариантов
   дизайна включает оценку уровня риска, связанного с вариантами
   дизайна или инициативой.
5. Скоуп решения: определяют скоуп поставляемого решения, чтобы
   можно было провести соответствующую оценку того, что находится в
   пределах рассматриваемых границ.

Question 88

Какие техники используются для задачи “7.6 Анализ потенциальной ценности и рекомендация решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 88

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

Question 89

Какие заинтересованные стороны есть у задачи “7.6 Анализ потенциальной ценности и рекомендация решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 89

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

Question 90

Какая выходная информация получается из задачи “7.6 Анализ потенциальной ценности и рекомендация решения” в рамках области знаний “Анализ требований и определение дизайна”?

Answer 90

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