4) архитектура определяет отношения компонентов структуры и их взаимодействия;
5) поведение компонентов является частью архитектуры;
6) определения архитектуры не фиксируют, что представляет собой компонент;
7) архитектура не является единой или единственной структурой.
Наиболее полезное описание архитектуры состоит из нескольких представлений, обеспечивая «интегрированное» представление о продукте.
Базовое представление архитектуры системы содержит описание систем и соединений, обеспечивающих или поддерживающих функции исполнения сценариев системы, включая графику.
Представление операционной архитектуры включает описание задач и действий, операционных элементов и информационных потоков, необходимых для выполнения или поддержки основной функции системы.
Представление технической архитектуры формулирует минимальный набор правил, регулирующих расположение, взаимодействие и взаимозависимость частей или элементов системы, целью которых является обеспечение соответствия системы удовлетворять заданному набору требований.
Описание архитектуры должно обеспечивать явные связи между различными представлениями, для интеграции облика и поддержки совместимости функций системы. Рекомендуется ознакомиться с ГОСТ Р 57100—2016 «Системная и программная инженерия. Описание архитектуры». Пример одного из возможного множества изображений архитектуры самолета показан на рис. 6.
Создание и развитие архитектуры является началом процесса проектирования системы. Здесь устанавливают связи между требованиями и проектом.
Требованием называют заданную (ожидаемую) количественную или качественную характеристику или свойство объекта, а также связанные ограничения и условия (ГОСТ Р 59194—2020). Оно необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества).
Рис. 6. Вариант схемы архитектуры самолета
В стандарте ISO 9000 «Система менеджмента качества» сформулировано, что требование является документально изложенным критерием, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения.
Требования к системе являются ключевым компонентом процесса ее создания. Требования определяют, что система должна делать и управляют ее развитием. Требования не являются спецификациями. Они определяют функции, характеристики и задачи системы в части окружающей среды. В процессе разработки системы, изображенном в виде итерационных петель (риc. 5), петля требований открывает цепочку базовых действий по созданию нового продукта. Есть несколько причин, зачем нужны требования.
• Требования определяют цель программы, например, получить «правильный» продукт для выхода с ним на рынок в подходящее для этого время, для захвата рыночной ниши или получить прибыль от реализации проекта.
• Требования определяют нужды (проблемы) заинтересованных сторон, или иначе, бизнес-требования.
• Требования определяют вариант создания продукта, т.е. процедуры, регламенты, системные требования.
• Требования определяют ограничения, связанные с решением или проектом по его реализации, а именно сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства и т. д.
Посредством требований уточняются формулировки или характеристики продукта, который разработчик хочет или должен получить. Требования также являются предметом договорных обязательств по созданию системы, составной частью документирования поставленной задачи, содержат значения, используемые при общении с заказчиком.
Технический процесс системного проектирования начинается с функциональных требований. В интересах разработчика сохранить как можно большую свободу проектирования. Затем функциональные требования обычно декомпозируют. При этом задача декомпозиции вводит новые входные и выходные данные и среду для исполнителя. Нужно минимизировать объем информации, которую приходится передавать между подсистемами. Функциональные спецификации нижнего уровня являются основой для закупок услуг по проектированию. Они записываются в виде границ. Например, указано, что масса продукта должна быть меньше или равна 25 кг.