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

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

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

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

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

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

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

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

2.6.7 Пересмотрите границы системы, чтобы отразить изменения в измеряемых и изменяемых переменных.

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

2.6.9 Сделайте ревью диаграммы зависимостей, чтобы учесть новую функциональную архитектуру.

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

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

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

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

В следующем разделе мы подробнее разберём, как пересматривать архитектуру.

Далее к разделу 2.6.1