Управление требованиями к архитектуре АДМ

Управление требованиями к архитектуре АДМ

В этой главе рассматривается процесс управления требованиями к архитектуре в рамках ADM. 17.1 задачи
Цели этапа управления требованиями заключаются в следующем:

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

17.2 подход

17.2.1 Общие положения
Как показано кружком "управление требованиями" в центре графика ADM, ADM постоянно управляется процессом управления требованиями.

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

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

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

17.2.2 Разработка Требований

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

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

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

Функциональные потребности
Нефункциональные требования
При определении требований архитектор должен учитывать:

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

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

17.2.3.1 Бизнес-Сценарии
Одним из эффективных методов, описанных в самой TOGAF, являются бизнес-сценарии, которые являются подходящим и полезным методом для выявления и документирования бизнес-требований, а также для формулирования видения архитектуры, отвечающей этим требованиям. Бизнес-сценарии подробно описаны в части III, 26. Бизнес-сценарии и бизнес-цели.

17.2.3.2 Требования Инструменты
Существует большое и постоянно растущее число коммерческих готовых инструментов (COTS), доступных для поддержки управления требованиями, хотя и не обязательно предназначенных для требований архитектуры. Веб-сайт Volere содержит очень полезный список ведущих инструментов требований

17.3 входы

Исходными данными для этапа управления требованиями являются:

Заполненный архитектурный репозиторий (см. Часть IV, 36.2.5 Architecture Repository),
Организационная модель архитектуры предприятия (см. Часть IV, 36.2.16 организационная модель архитектуры предприятия), в том числе:
Сфера деятельности организации влияние
Оценка зрелости, пробелы и подход к их разрешению
Роли и обязанности для архитектурной команды(ов)

Ограничения на архитектурную работу
Бюджетные потребности
Стратегия управления и поддержки
Адаптированная архитектурная структура (см. Часть IV, 36.2.21 адаптированная архитектурная структура), включая:
Метод индивидуальной архитектуры
Индивидуальный архитектурный контент (результаты и артефакты)

Настроенные и развернутые инструменты
Заявление архитектурное произведение (см. Часть IV, 36.2.20 заявление архитектурное произведение)
Видение архитектуры (см. Часть IV, 36.2.8 видение архитектуры)
Требования к архитектуре, архитектура, заполнение технического задания (см. Часть IV, 36.2.6 требования к архитектуре спецификация)
Оценка воздействия требований (см. Часть IV, 36.2.18 оценка воздействия требований)

17.4 шаги
Этапы этапа управления требованиями описаны в таблице ниже:

Шаги По Управлению Требованиями	АДМ фаза действия
Базовые требования: Определение приоритетов, вытекающих из текущей фазы АДМ Подтвердите участие заинтересованных сторон в результирующих приоритетах Запись приоритетов требований и их место в репозитории требований	Идентификация / документирование требований-используйте бизнес-сценарии или аналогичный метод
Определите измененные требования и запишите приоритеты: Определение измененных требований и обеспечение приоритизации требований архитектором(архитекторами), ответственным за текущий этап, а также соответствующими заинтересованными сторонами Запишите новые приоритеты Убедитесь, что любые конфликты выявляются и управляются на всех этапах до успешного завершения и определения приоритетов Создание заявления о влиянии требований (см. 36.2.18 оценка влияния требований) для руководства архитектурной группой	Определение измененных требований: Устранение или переоценка приоритетов Добавление требований и переоценка приоритетов Изменение существующих требований
Измененные требования могут поступать по любому маршруту. Чтобы обеспечить надлежащую оценку и приоритетность требований, этот процесс должен направлять этапы ADM и регистрировать решения, связанные с требованиями. На этапе управления требованиями необходимо определить степень удовлетворенности заинтересованных сторон принятыми решениями. Там, где есть неудовлетворенность, фаза остается подотчетной, чтобы обеспечить разрешение проблем и определить дальнейшие шаги.	Оценка влияния измененных требований на текущую (активную) фазу Оценка влияния измененных требований на предыдущие этапы Определите, следует ли внедрять изменения или отложить их до более позднего цикла ADM; если необходимо принять решение о внедрении, оцените временные рамки внедрения управления изменениями Заявление о влиянии требований к выпуску, версия n+1
Обновите репозиторий требований информацией, относящейся к запрошенным изменениям, включая затронутые мнения заинтересованных сторон	Реализация требований, вытекающих из фазы Н Архитектура может быть изменена в течение ее жизненного цикла на этапе управления изменениями архитектуры (фаза H). Процесс управления требованиями обеспечивает соответствующее управление новыми или изменяющимися требованиями, вытекающими из фазы Н.
	Внедрить изменения на текущей фазе

 

17.5 выходы

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

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

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

Навигация

Набор документов TOGAF предназначен для использования с фреймами. Для навигации по документу:

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

 

Загрузки

Загрузка TOGAF®, стандарта открытой группы, доступна по лицензии с информационного веб-сайта TOGAF. Лицензия предоставляется бесплатно любой организации, желающей использовать стандарт TOGAF исключительно для внутренних целей (например, для разработки архитектуры информационной системы для использования внутри этой организации). Книга также доступна (в печатном виде и в формате pdf) в книжном магазине Open Group в качестве документа G116.