В итоге было признано:
• Важны не требования, а непрерывно уточняющиеся поведенческие модели (модели изменения состояний в ходе функционирования), то есть сценарии использования. Эти модели отражают непрерывно меняющийся набор гипотез о том, что должна делать успешная система. Поскольку вопрос об успешности системы (успешности подсистемы, и т. д. по уровням), то в этих моделях должны учитываться и внешние проектные роли (а внутренние проектные роли вполне могут быть внешними проектными ролями для подпроектов: разработчик самолёта будет внешней проектной ролью по отношению к разработчику авиадвигателя).
Концепция системы – это описание основной идеи модульного синтеза: каким образом какой-то набор конструктивных частей целевой системы исполняет роли функциональных частей системы, чтобы в конечном итоге выдать требуемый от системы сервис на уровень надсистемы. Архитектура системы при этом накладывает на концепцию системы ограничения: говорит о такой разбивке на модули, которые дают необходимые архитектурные характеристики: высокую скорость развития/evolvability для времени создания системы, возможность масштабирования как увеличения производительности по мере роста потребности в сервисе системы, собственно самой производительности системы, и т. д.
Поэтому акцент в системной инженерии сейчас делается не на «привлекать разово прикладного специалиста/специалиста-предметника/„business domain expert“/„subject matter expert“ для разработки версии описания», а обеспечить понимание предметной области/business domain прикладным разработчиком и архитектором.
