Таблица 5. Требования владельца и пользователя системы (СХ1) для потребности (П1)
Вариантов требований может быть очень много. Можно вспомнить про парковки, про влажность воздуха, про авторегулирование освещения и многое другое. Требования всегда имеет смысл ранжировать. Уровень важности того или иного требования может оценить каждый стейкхолдер. При этом, каждый стейкхолдер может быть «по секрету» взвешен, на предмет собственной важности. Снимать требования в зависимости от их низкого ранга «просто так», конечно, нельзя. Но так легче понять, какие требования можно вынести на обсуждение со стейкхолдерами, как необязательные. А уже потом убрать.
Требованиям должна в конечном итоге соответствовать реализация, поэтому даже в начале проекта необходимо иметь некоторое представление о вариантах архитектуры системы. Это во многом ограничивает требования и их фокусирует.
Всегда фиксируйте каждое новое требование в процессе работы над проектом. Когда новые требования начнут противоречить исходному техническому заданию идите к менеджеру. Это очень серьезная проблема, которую нельзя игнорировать.
Составьте список стейкхолдеров целевой системы, определите их реальные потребности в ходе переговоров, маркетинговых исследований, консультаций с экспертами. Отталкиваясь от потребностей, вы сможете точнее формулировать требования к системе и быстрее согласовывать их со стейкхолдерами.
Глава 3. Функциональное моделирование
Сбор и анализ требований будет гораздо эффективнее, если кроме «послойного осаждения» в документации, они еще отразятся в функциональной модели системы.
Иногда о функциональной модели говорят: «Взгляд снаружи внутрь». То есть, в какой-то мере, функциональная модель представляет собой структуризацию и уточнение требований до той степени, когда не возникает вопросов, что именно должна делать целевая система. Давайте попробуем нарисовать функциональную модель системы умный бизнес-центр. Для этого нам необходимо назвать ее основную функцию. Мы снова вернулись к этому вопросу. Можно было бы нарисовать вот такую схему «на салфетке» (рис. 3).
Рис. 3. Контекстная функциональная модель системы управления потреблением электроэнергии и воды в бизнес-центре
Если мы напишем все функции системы через запятую в одном названии, то, фактически, мы словом «система» подменим, просто, некоторое объединение. На самом деле, мы будем проектировать в таком случае несколько разных систем, которые работают в некоторой связке: одна управляет электроэнергией, а другая водоснабжением (может быть еще несколько аналогичных систем). Никакого системного эффекта здесь не просматривается. Можно было бы обобщить до понятия «ресурсы», но, опять таки, это обобщение не раскроет системного эффекта, возникающего при связанном функционировании перечисленных систем.
Еще одна неувязка заключается в том, что большинство требований относятся не столько к «коробочке с проводами», как мы охарактеризовали умный дом, сколько к некоторой инфраструктуре всего здания. То есть наших стейкхолдеров интересуют не сигналы управления на выходе, а конкретные действия по регулированию воды или электричества. Должен ли входить в нашу систему, например, кондиционер? И все-таки, кто же наши пользователи? Владельцы бизнес-центров, персонал, арендаторы или системные интеграторы, монтирующие «коробочку с проводами» в инфраструктуру здания? А может быть, мы должны проектировать всё здание «под ключ» вместе с умным бизнес-центром внутри?
Первый вариант, который мы рассмотрим, будет заключаться в укрупнении задачи. Давайте назовем функцией системы поддержку комфорта в бизнес-центре (рис. 4). Таким ходом мы ставим себе задачу четкого определения термина «комфорт», вплоть до математической формулы. Для начала давайте декомпозируем комфорт, например, вот в такой кортеж:
Комфорт = <Температура воздуха, Влажность воздуха, Уровень автоматизации, Экономия>
Можно декомпозировать дальше:
Уровень автоматизации = <Включение и выключение эскалаторов, Автоматическая подача воды порциями и т.д.>
Когда мы знаем структуру, можно предложить различные математические критерии оценивания этого самого комфорта, например с помощью развесовки и суммирования. Каждый из субкритериев можно привести к нормализованному виду от 0 до 1, тогда задача оценки уровня комфорта не составит никакого труда. Но не будем углубляться в оценку это предмет системного анализа, а не системной инженерии. Проблема в том, что поддержать тот или иной уровень комфорта система может только тогда, когда в неё входят приборы, взаимодействующие со средой, например, тот же кондиционер. Коробка с проводами сама по себе комфорт не обеспечивает это не ее функция. Системный инженер должен обязательно обсудить с менеджерами такую проблему. Скорее всего, будет предложено не выходить за рамки идеи коробки с проводами. Оборудовать здание кондиционерами, электроприборами и батареями не совсем та задача, которую мы хотели решать сначала.
Комфорт = <Температура воздуха, Влажность воздуха, Уровень автоматизации, Экономия>