• Динамическая эксплуатационная архитектура, где дано описание работы и взаимодействий элементов с течением времени при достижении заданных целей.
Также архитектуры могут меняться с течением времени. Это относится к типичным долгоживущим продуктам, таким как автомобили и самолеты, и особенно важно в отношении таких систем, как инфраструктура. По мере роста города, области, телефонной сети добавляются элементы, возникают новые сложности, и может потребоваться перепроектирование системы. Например, в Москве в 2022 г. была существенно изменена сеть и нумерация маршрутов наземного городского транспорта. Ограничения, налагаемые устаревающим наследием, могут оказаться крайне невыгодными. Так, сегодня борьба с автомобильными пробками в Москве вылилась в перепроектирование инфраструктуры большинства районов города.
Рекомендуется ознакомиться с ГОСТ Р 57100—2016 (ISO/IEC/IEEE 42010:2011) «Системная и программная инженерия. Описание архитектуры».
Создание и развитие архитектуры является началом процесса проектирования системы. Здесь устанавливают связи между требованиями и проектом. Требования к системе являются ключевым компонентом процесса ее создания. В стандарте ISO/IEC 29148 определено, что «Требованием называют утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (потребителем или внутренним руководящим органом обеспечения качества)».
Требования определяют, что система должна делать, и управляют ее развитием. Требования не являются спецификациями. Они определяют функции, характеристики системы, задачи в части окружающей среды. Требования формулируют цель программы, например, создать «правильный» продукт для выхода на рынок и получить прибыль от реализации проекта. Они определяют ограничения, связанные с решением или проектом по его реализации, а именно сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства, и так далее. Посредством требований уточняются формулировки или характеристики продукта, который разработчик хочет или должен получить.
В системных требованиях учитывают запросы заинтересованных сторон. Сюда входят корпоративные клиенты, заинтересованные в рынке системы, низких эксплуатационных и капитальных затратах; операторы системы, заинтересованные в ее производительности, долговечности, надежности, наличии запасных частей; пользователи, которые заботятся о комфорте, безопасности и удобстве использования. Эти стороны, в конечном счете, будут использовать систему, извлекать из нее выгоду, управлять, поддерживать в рабочем состоянии, влиять на нее или подвергаться ее воздействию.
Формирование проектных требований начинается с уточнения внешних требований верхнего уровня, поступающих от заказчиков. Затем эти требования верхнего уровня группируют по конкретным направлениям.
1. Требования к системе, где собраны требования к продукции, и ее характеристикам.
2. Промышленные, производственные и испытательные требования.
3. Требования к обеспечивающим процессам, включая применяемые технологии, управление проектом, качество и требования к закупкам.
Требования являются ключом к успеху проекта. Для хороших требований к системе или продукту важно наличие следующих свойств.
• Специфичность, чтобы отражать только один аспект конструкции или характеристик системы. Требования также должны быть выражены в терминах потребности (что и как хорошо), а не вариантов решений (как).
• Измеримость, когда характеристика выражается объективно и количественно, может быть проверена при испытании.
• Достижимость, техническая реализуемость при доступных затратах, параметры элементов должны соответствовать законам физики и современным технологиям.
• Прослеживаемость, когда требования нижнего «дочернего» уровня должны четко вытекать из требований более высокого «родительского» уровня. Требования, не имеющие «родителей», должны быть оценены для необходимости включения на данный уровень.
При выполнении анализа требования полезно классифицировать, разделяя на основные типы.
1. Функциональные требования, отвечающие на вопрос «что система должна делать?» Например, обеспечить связь между землей и самолетом.
2. Требования к рабочим характеристикам, отвечающие на вопрос «как хорошо система исполняет нужные функции?»
3. Экологические/нефункциональные требования (сценарии использования), отвечающие на вопрос «при каких условиях (экологии, надежности и доступности) система должна работать для удовлетворения данного требования?»
4. Ограничения системы. Точный характер ограничений может зависеть от предлагаемых решений. Необходимо учитывать внешние интерфейсы, налагаемые другими системами (габарит мотогондолы на самолете, условия хранения, транспортировки, эксплуатации, и др.).
5. Политика и публичные законы вносят ограничения по безопасности, экологии и шуму. Следует учесть угрозы, налагаемые известными возможностями потенциального конкурента, что также ограничивает диапазон практических вариантов проекта.
6. Требования к качеству (включая требования к безопасности).
7. Бизнес-требования (цена продукта, стоимость жизненного цикла, конкурентоспособность и др.).
8. Требования к процессам жизненного цикла продукта, включающие административно-организационные требования (скорость выхода на рынок, послепродажное обслуживание, и др.).
Функциональные (эксплуатационные) требования к системе должны включать следующие основные позиции.
• Сформулировать общую цель создания системы и перечислить основные функции, которые должна выполнять система. Для этого удобно определить набор эксплуатационных сценариев.
• Определить рабочие характеристики предполагаемых функций системы (например, размер, вес, скорость, диапазон, точность, мощность, и так далее.).
• Определить требования к жизненному циклу и использованию системы, включая предполагаемый срок ее службы. Задать режим использования системы, например, часы в день, дни в неделю, месяцы в году.
• Определить факторы эффективности системы, то есть стоимость жизненного цикла, доступность, средние интервалы времени между обслуживанием, логистическую поддержку, уровень квалификации обслуживающего персонала, и так далее.
• Определить факторы воздействия окружающей среды на работу и обслуживание системы, включая физические условия, климатическую зону, температуру, влажность, экологичность влияния системы на окружающую среду.
Требования заинтересованных сторон недостаточны для проектирования системы. Обычно они неполные, нечетко сформулированные, а иногда и противоречивы по своему характеру. Для этапа разработки необходим полный, технически обоснованный и точный набор системных требований, которые необходимо реализовать. Они должны быть собраны, отфильтрованы, уточнены, декомпозированы и задокументированы.
Цепочка проектирования системы (продукта) включает несколько шагов определения и разработки требований.
1. Определить и зафиксировать требования. Заинтересованные лица формируют набор требований верхнего уровня, зачастую эти требования входят в техническое задание контракта на разработку системы.
2. Провести анализ и декомпозицию полученных требований на нижележащие уровни системы для формирования указаний, необходимых исполнителям работ.
3. Сформировать производные требования.
4. Определить методы верификации требований.
Эти шаги могут выполняться параллельно, и, аналогично большинству технических процессов, реализуются посредством итераций.
Одним из видов требований нижних уровней являются производные требования.
• Производными называют требования, которые прямо не указаны в наборе требований заинтересованных сторон, но они должны быть сформулированы для технической реализации в компонентах системы, чтобы удовлетворить одно или несколько конкретных высказанных требований.
• Производные требования формируются на основе оперативного или технического анализа базовых требований в целях уточнения требований, или чтобы сделать базовые требования достижимыми.
Декомпозицию и получение производных требований в ходе разработки проекта выполняют тремя способами: по потоку, распределением и ответвлениями. Декомпозицией требований вниз по потоку называют прямую передачу их в подсистемы для обеспечения характеристик системы в целом. Распределение представляет собой количественный пропорциональный дележ требований верхнего уровня на нижний уровень. Ответвление требований формируют в виде пропорциональной характеристики, зависящей от специфической реализации.
Прослеживаемость (трассировка) и иерархия требований также являются важными компонентами для проверки происхождения и правильности формулировки. После декомпозиции требований верхнего уровня на нижние уровни свойство прослеживаемости идентифицирует отношения и связи между требованиями разных уровней и их источниками. Очень важно отслеживать, где были введены требования, уточнением какого требования они являются, а также обоснование этого действия. Это важно для отслеживания развития системы, и значительно упрощает управление конфигурацией.
Можно изложить некоторые полезные правила формирования требований, как набор рекомендаций, чего следует избегать в предложении для ОКР:
• хаоса, необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;
• лазеек, выражений типа «если это необходимо», поскольку они делают требование бесполезным;
• помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;
• неконкретных рассуждений;
• нечетких слов, таких как «обычно», «в основном», «часто», «нормально», «типично»;
• использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);
• принятия желаемого за требуемое («100% надежный», «приятный для всех пользователей», «безопасный», «подходящий для всех платформ», «не должен никогда ломаться», «быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем»).
