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

Question

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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. Пользовательские истории: используются для описания требований в виде краткого утверждения о том, что люди делают или должны делать при использовании решения.

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

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

Answer 13

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

Answer 14

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

Answer 15

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

Answer 16

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

Answer 17

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

Answer 18

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

Answer 19

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

Answer 20

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

Answer 21

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

Answer 22

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

Answer 23

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

Answer 24

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

Answer 25

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

Answer 26

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

Answer 27

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

Answer 28

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

Answer 29

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

Answer 30

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

Answer 31

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

Answer 32

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

Answer 33

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

Answer 34

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

Answer 35

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

Answer 36

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

Answer 37

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

Answer 38

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

Answer 39

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

Answer 40

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

Answer 41

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

Answer 42

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

Answer 43

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

Answer 44

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

Answer 45

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

Answer 46

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

Answer 47

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

Answer 48

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

Answer 49

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

Answer 50

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

Answer 51

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

Answer 52

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

Answer 53

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

Answer 54

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

Answer 55

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

Answer 56

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

Answer 57

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

Answer 58

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

Answer 59

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

Answer 60

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

Answer 61

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

Answer 62

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

Answer 63

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

Answer 64

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

Answer 65

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

Answer 66

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