Итак, обратимся к использующей системе бизнес-центру. Мы определили функцию использующей системы и можем выполнить функциональную декомпозицию следующим способом.
Определяем входные потоки:
внешние условия, включая погоду, механические воздействия, городской шум и другое;
ресурсы, приходящие к нам через инженерные коммуникации: вода, электричество, газ или еще что-то;
запросы на сервисы в любом бизнес-центре нужны санузлы, уборщицы или что-то более специфичное типа эскалаторов (сервис транспорта), центров печати.
Определяем выходные потоки:
мы ожидаем, что здание обеспечит нам внутренний комфортный климат, огородив от внешней среды;
мы ожидаем, что услуги/сервисы будут оказаны, в результате чего мы получим воду, напечатанные документы, поменяем местоположение и т. д.
Обращаю внимание, что рассуждение про потоки идет параллельно рассуждению о конструкции: здание, инженерные коммуникации, эскалаторы и т. д. То есть мы немного забегаем вперед, простраивая логическую архитектуру. Для системной инженерии это обычное дело, когда приходится перескакивать между разными точками зрения (частными методами описания), чтобы удержать в голове целостность системы. Для кого-то, возможно, было бы удобно нарисовать схему логической архитектуры уже сейчас в каком-то виде: показать стены, инженерные коммуникации, эскалаторы, санузлы и т. д. Я этого делать не буду. К логической архитектуре мы подойдем чуть позже. На данном этапе нам не столько важны варианты воплощения, сколько общая идея того, что происходит внутри использующей системы. Важно использующая система пока существует без «коробочки с проводами».
Рис. 6. Функциональная диаграмма использующей системы без целевой системы (как есть)
Далее нам надо понять, какие изменения претерпевают потоки, пока они доходят от входа к выходу, и как они влияют друг на друга внутри использующей системы. Это творческая задача, требующая хорошей технической подготовки. Каждый факт изменения потока мы фиксируем в виде той или иной функции, которую использующая система должна выполнять, чтобы реализовать свою главную функцию. Так и получается декомпозиция использующей системы.
Это один из возможных способов. Более академический вариант выполнить поиск аналогов, а также (что гораздо сложнее) найти описания функционирования этих аналогов, потом выбрать наиболее близкое к вашему случаю описание и представить его в виде функциональной модели.
Стейкхолдер (СХ1), то есть владелец бизнес-центра, хочет экономить. То есть хочет регулировать использование ресурсов так, чтобы ему это обходилось дешевле, а условия ведения бизнеса при этом держались на заданном уровне. Вставляем целевую систему в качестве новой функции и смотрим, что получилось (рис. 7). Будем целевую систему и потоки, связанные с ней, рисовать жирными линиями, чтобы смотрелось нагляднее. Введем идетификаторы для элементов: ПТ потоки; ИС использующая система; СОО системы в операционном окружении; ЦС целевая система, которую вы сейчас проектируете.
Рис. 7. Функциональная диаграмма использующей системы с целевой системой
Каждый поток, входящий или выходящий из использующей системы, может быть ассоциирован с потребностью.
Например, «ПТ3. Внешние условия» может быть ассоциирован с потребностью обеспечивать комфортные условия в условиях пустыни. «ПТ1. Запросы на сервисы» может быть ассоциирован с потребностью в определенном количестве людей, которых должен обслуживать центр. «ПТ2. Результаты сервисов» может быть связан с потребностями ускорения процессов, повышения качества. Условия среды в (ПТ6) сами по себе являются важной потребностью, ведь если мы просто будем экономить на всём, в бизнес-центре может стать, например, душно и жарко. Потоки (ПТ8) и (ПТ9), с одной стороны внешние, а с другой относятся к целевой системе. Эти потоки могут быть связаны с потребностями сервисного обслуживания, то есть дополнительно (СХ6) техобслуживание.
Например, «ПТ3. Внешние условия» может быть ассоциирован с потребностью обеспечивать комфортные условия в условиях пустыни. «ПТ1. Запросы на сервисы» может быть ассоциирован с потребностью в определенном количестве людей, которых должен обслуживать центр. «ПТ2. Результаты сервисов» может быть связан с потребностями ускорения процессов, повышения качества. Условия среды в (ПТ6) сами по себе являются важной потребностью, ведь если мы просто будем экономить на всём, в бизнес-центре может стать, например, душно и жарко. Потоки (ПТ8) и (ПТ9), с одной стороны внешние, а с другой относятся к целевой системе. Эти потоки могут быть связаны с потребностями сервисного обслуживания, то есть дополнительно (СХ6) техобслуживание.
Требования к целевой системе мы можем теперь разделить на 4 группы:
требования к управлению сервисами (Т2, Т3);
требования к управлению средой (Т1, Т4);
требования к мониторингу среды;
требования к мониторингу сервисов.
В скобках приведены идентификаторы тех требований, которые мы уже писали ранее. Как видно, мы интуитивно заметили только две группы требований. Требования к мониторингу сервисов могут быть связаны, например, с количеством сервисов, которыми система должна управлять, типами сервисов и их результатов; это могут быть расстояния, время, частота получения информации и многое другое. Мониторинг среды также имеет свои особенности, например: количество точек сбора информации, конкретные измеряемые характеристики, периодичность измерений и многое другое.