• Важны не требования, а непрерывно уточняющиеся поведенческие модели (модели изменения состояний в ходе функционирования), то есть сценарии использования. Эти модели отражают непрерывно меняющийся набор гипотез о том, что должна делать успешная система. Поскольку вопрос об успешности системы (успешности подсистемы, и т. д. по уровням), то в этих моделях должны учитываться и внешние проектные роли (а внутренние проектные роли вполне могут быть внешними проектными ролями для подпроектов: разработчик самолёта будет внешней проектной ролью по отношению к разработчику авиадвигателя).
Концепция системы – это описание основной идеи модульного синтеза: каким образом какой-то набор конструктивных частей целевой системы исполняет роли функциональных частей системы, чтобы в конечном итоге выдать требуемый от системы сервис на уровень надсистемы. Архитектура системы при этом накладывает на концепцию системы ограничения: говорит о такой разбивке на модули, которые дают необходимые архитектурные характеристики: высокую скорость развития/evolvability для времени создания системы, возможность масштабирования как увеличения производительности по мере роста потребности в сервисе системы, собственно самой производительности системы, и т. д.
Всё то же самое нужно делать в масштабах всего проекта, какой бы большой он ни был (и чем больше проект, тем строже это отслеживать: маленький беспорядок может нанести существенный убыток в большом проекте).
вроде стандарта именования инженерных рабочих продуктов IEC 81346 (он хорош для отражения нескольких разных способов разбиения системы на части, это обсуждалось в курсе «Практическое системное мышление»), хорошо раскрыты в короткой (188 страниц) книге Frank Watts «Configuration Management for Senior Managers» [3] (2015).
Это документ на пару страниц текста, имеющий следующий формат (текст пишется в виде рассказа для разработчиков):
• Заголовок/title — короткое имя для принятого решения.
• Ситуация: описывает различные соображения в части влияния на архитектурные характеристики, в том числе именно тут описываются конфликты разных системных уровней, которые требуют оптимизации.
• Решение: что делать, чтобы достичь предположительного квазиоптимума (например, использовать какой-то архитектурный стиль или стандарт для межмодульного интерфейса)
• Статус: это предложение, это обязательно для выполнения, это решение уже отменено каким-то другим предложением (всё меняется, в том числе архитектурные решения)
• Последствия: что ожидается после реализации решения, в том числе «позитивные» (скажем, «производительность вырастет впятеро») и отрицательные (скажем, «вносить изменения придётся не в один, а в три разных модуля»).
Узнают потребности внешних проектных ролей, узнают структуру клиентской предметной области (реинжиниринг надсистемы), то есть делают концепцию использования. Никакого испорченного телефона, промежуточных «аналитиков».
