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

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

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

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

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

В качестве примера рассмотрим предварительный список функций системы (таблица 5), разработанный в разделе 2.3 для инкубатора.

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

Функция включения и выключения источника тепла относительно независима от других и может быть включена в функцию «Управление источником тепла».

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

Самая верхняя диаграмма зависимостей для термостата инкубатора показана на рисунке 2.

Диаграмма зависимостей на рисунке 2 как бы открывает нам чёрный ящик системы из контекстной диаграммы на рисунке А-1, показывая основные функции термостата и зависимости между ними.

На схеме показаны две функции, описанные в п. 2.5.1 («Управление интерфейсом пользователя» и «Управление источником тепла»), а также дополнительная функция «Управление режимом», введенная для управления режимами системы.

На диаграмме измеряемые переменные показаны в виде стрелок, которые входят в функции («Текущая температура» и «Настройки пользователя). Изменяемые переменные показаны в виде стрелок, которые выходят из функций («Регулятор нагрева» и «Обратная связь от пользователя»).

Зависимости данных между функциями показаны в виде стрелок, соединяющих их («Режим», «Желаемый диапазон» и «Вкл/Выкл термостата»).

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

Так, работа функции «Управление источником тепла» зависит от значения внутренней переменной «Желаемый диапазон», указанной в функции «Управление интерфейсом пользователя», поэтому стрелка должна идти от функции «Управление источником тепла» к функции «Управление интерфейсом пользователя». Однако такой подход к изображению диаграмм зависимостей не интуитивен и противоречит гораздо более широко распространённому подходу, когда стрелки указывают направление потока данных. Практическое влияние такого подхода на спецификацию незначительно, хотя технически спецификация требований не подразумевает передачу данных.

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

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

Упомянутый выше подход может также облегчить переиспользование требований, так как области, наиболее подверженные изменениям, с большей вероятностью будут локализованы (расположены в одном месте, не расползутся по всей документации). Чтобы системно подойти к повторному использованию требований, вы можете использовать анализ совместимости и изменчивости. Этот вид анализа поможет определить, какая часть требований постоянна, а какие части могут изменятся [40]. Затем эту информацию можно использовать в качестве входной при анализе функциональности.

Описание внутренних переменных диаграммы зависимостей может быть расположено вместе с диаграммой. Пример для термостата инкубатора показан в таблице A-7. Приведём её здесь:

Описание внутренних переменных может быть приведено в спецификации той функции, в которой каждая из них вводится; также как измеряемые и изменяемые переменные описываются в тех внешних объектах, с которыми связаны. Например, внутренняя переменная «Безопасный диапазон» для термостата инкубатора была бы определена в функции «Управление интерфейсом пользователя», а внутренняя переменная «Режим» была бы определена в функции «Режим управления».

Со временем система развивается, и одного уровня функций может оказаться недостаточно. Декомпозиция функций на более мелкие позволяет создавать сколь угодно большие спецификации. Пример будет показан на рисунках 6, 7 и 8 в разделе 2.6.

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

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

В оригинальной базовой методологии [4, 5 и 6] и даже в структурированном анализе с использованием диаграмм потоков данных [41] подробные требования были представлены в функциях самого низкого уровня. Также и в разделе 2.8 говорится о том, как подробные требования к поведению и производительности системы определяются на самом низком уровне функциональной архитектуры.

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

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

На рисунке 3 показан пример высокоуровневых требований к функции «‎Термостат». В них указано только, что термостат установит значение регулятора нагрева и переменных, управляемых обратной связью пользователя. При этом как именно они будут установлены, там не описано. Как показано на контекстной диаграмме на рисунке А-1, функция «‎Термостат» устанавливает только две регулируемые переменные: регулирование температуры и обратную связь от пользователя.

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

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

REQ-1: Термостат должен установить значение переменной «Регулятор нагрева», чтобы поддерживать текущую температуры в инкубаторе в желаемом диапазоне температур.

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

Во-вторых, это смешивает то, что система будет делать с тем, почему она это делает, то есть смешивает обоснование с самим требованием (см. раздел 2.11).

Полная спецификация того, как должно быть установлено значение переменной «Регулятор нагрева», представляет собой удивительно сложный алгоритм, учитывающий его текущий режим, текущую температуру, желаемый температурный диапазон и его предыдущего состояния (см. приложение A.5.1.3 для полной спецификации этого алгоритма).

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

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

В следующем разделе мы рассмотрим архитектуру с точки зрения ограничений реализации.

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