2.4. Формирование требований к системе

После утверждения положительных результатов маркетингового исследования идеи продукта для рассмотрения проекта выполняют анализ осуществимости задачи. Нужно оценить различные технологические подходы, которые могут быть рассмотрены при ответе на заданные функциональные требования. В целом необходимо определить различные возможные подходы к проектированию будущей системы, которые можно использовать для удовлетворения требований. Выполнить оценки наиболее вероятных альтернатив и аналогов с точки зрения производительности, эффективности, требований к логистике и техническому обслуживанию; а также экономических критериев жизненного цикла. Исследуются альтернативные применения технологий. Например, при проектировании средств связи можно выбирать между оптоволоконной технологией, сотовой (беспроводной) или традиционной с проводами. При разработке конструкции самолета нужно определить долю использования композитных материалов. При создании большой системы любого типа понять, как следует использовать интегральные микросхемы, печатные платы, системы на кристалле и др. Альтернатив может быть много, однако количество возможностей должно быть сужено до нескольких вариантов, соответствующих наличию ожидаемых ресурсов (т.е. человеческих сил, материалов и технологий) и бюджета.

Необходимым компонентом для продвижения по этапам разработки является «Концепция эксплуатации». Это документ, описывающий ожидаемые характеристики разрабатываемой системы с точки зрения пользователя (не путать со спецификацией, где изложен весь набор требований заинтересованных сторон к системе, подсистемам и элементам). Его задачей является наглядное описание целей создания системы, «что» она должна делать, а не «как». Документ также должен определять любые критические требования или цели производительности на верхнем уровне (сформулированные качественно либо количественно) и их системное обоснование. Форма изложения документа относительно свободная, можно найти много шаблонов в интернете.

В тексте «Концепции эксплуатации» должна содержаться следующая информация.

1. Почему необходима система и предварительный обзор самой системы.

2. Описание полного жизненного цикла системы от развертывания до вывода из эксплуатации.

3. Описание сценариев, иллюстрирующих конкретные эксплуатационные мероприятия, связанные с использованием системы.

4. Указание условий, при которых система используется и обслуживается.

5. Изложены различные аспекты использования системы, включая производство, техническое обслуживание, поддержку и утилизацию.

6. Перечисление различных классов пользователей, в том числе операторов, сопровождающих, партнеров, их различных навыков и ограничений.

7. Определены границы системы, ее интерфейсов и связей с другими системами.

Руководство по разработке концепции эксплуатации удобно готовить в группе заинтересованных лиц программы. При этом:

a) не следует указывать какие-либо особенности системы;

b) не нужно описывать, как идет процесс и как должна выполняться функция, надо только перечислить потребности системы;

c) в рабочую группу рекомендуется включить все заинтересованные стороны (до 15 чел.), которые должны иметь полномочия принимать окончательные решения;

d) желательно собрать всех участников группы в одном месте в одно и то же время, по крайней мере дважды;

e) модератор группы должен обладать навыками руководства группой и следить за ее работой;

f) следует ограничить размер разрабатываемого документа, не ограничивая полученную извне информацию;

g) модератору следует убедиться, что уровень технического языка в документе не препятствует пониманию текста.

После уточнения концепции эксплуатации на этапе анализа необходимо сформировать архитектуру системы, чтобы определить ее особенности, далее сформировать требования к системе и провести ее декомпозицию для упрощения стадии синтеза.

Термин «архитектура системы» обозначает основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития (ГОСТ Р 57100—2016).

Архитектура включает организованный нисходящий выбор и описание вариантов проектирования для всех важных системных функций и подфункций, для обеспечения совместимости и удовлетворения окончательных системных требований. Она содержит наиболее важные, связывающие весь проект, стратегические реализационные решения, изобретения, инженерные компромиссы; допущения и их соответствующие логические обоснования того, как система будет удовлетворять системным требованиям; все основные логические, физические, статические и динамические структуры, альтернативные решения, допущения и обоснования. Основные положения процесса разработки архитектуры:

1) каждая система имеет архитектуру;

2) архитектура определяет основные компоненты системы;

3) архитектура определяет обоснование компонентов и структуры;

4) архитектура определяет отношения компонентов структуры и их взаимодействия;

5) поведение компонентов является частью архитектуры;

6) определения архитектуры не фиксируют, что представляет собой компонент;

7) архитектура не является единой или единственной структурой.

Наиболее полезное описание архитектуры состоит из нескольких представлений, обеспечивая «интегрированное» представление о продукте.

Базовое представление архитектуры системы содержит описание систем и соединений, обеспечивающих или поддерживающих функции исполнения сценариев системы, включая графику.

Представление операционной архитектуры включает описание задач и действий, операционных элементов и информационных потоков, необходимых для выполнения или поддержки основной функции системы.

Представление технической архитектуры формулирует минимальный набор правил, регулирующих расположение, взаимодействие и взаимозависимость частей или элементов системы, целью которых является обеспечение соответствия системы удовлетворять заданному набору требований.

Описание архитектуры должно обеспечивать явные связи между различными представлениями, для интеграции облика и поддержки совместимости функций системы. Рекомендуется ознакомиться с ГОСТ Р 57100—2016 «Системная и программная инженерия. Описание архитектуры». Пример одного из возможного множества изображений архитектуры самолета показан на рис. 6.

Создание и развитие архитектуры является началом процесса проектирования системы. Здесь устанавливают связи между требованиями и проектом.

Требованием называют заданную (ожидаемую) количественную или качественную характеристику или свойство объекта, а также связанные ограничения и условия (ГОСТ Р 59194—2020). Оно необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества).

Рис. 6. Вариант схемы архитектуры самолета

В стандарте ISO 9000 «Система менеджмента качества» сформулировано, что требование является документально изложенным критерием, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения.

Требования к системе являются ключевым компонентом процесса ее создания. Требования определяют, что система должна делать и управляют ее развитием. Требования не являются спецификациями. Они определяют функции, характеристики и задачи системы в части окружающей среды. В процессе разработки системы, изображенном в виде итерационных петель (риc. 5), петля требований открывает цепочку базовых действий по созданию нового продукта. Есть несколько причин, зачем нужны требования.

• Требования определяют цель программы, например, получить «правильный» продукт для выхода с ним на рынок в подходящее для этого время, для захвата рыночной ниши или получить прибыль от реализации проекта.

• Требования определяют нужды (проблемы) заинтересованных сторон, или иначе, бизнес-требования.

• Требования определяют вариант создания продукта, т.е. процедуры, регламенты, системные требования.

• Требования определяют ограничения, связанные с решением или проектом по его реализации, а именно сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства и т. д.

Посредством требований уточняются формулировки или характеристики продукта, который разработчик хочет или должен получить. Требования также являются предметом договорных обязательств по созданию системы, составной частью документирования поставленной задачи, содержат значения, используемые при общении с заказчиком.

Технический процесс системного проектирования начинается с функциональных требований. В интересах разработчика сохранить как можно большую свободу проектирования. Затем функциональные требования обычно декомпозируют. При этом задача декомпозиции вводит новые входные и выходные данные и среду для исполнителя. Нужно минимизировать объем информации, которую приходится передавать между подсистемами. Функциональные спецификации нижнего уровня являются основой для закупок услуг по проектированию. Они записываются в виде границ. Например, указано, что масса продукта должна быть меньше или равна 25 кг.

Успех любой создаваемой системы и ее эксплуатации зависит от следующих факторов:

1) готова ли рыночная среда к внедрению системы (когда потребности рынка обусловлены «окном возможностей»);

2) как обеспечено позитивное восприятие пользователем функциональности, пригодности и доступности системы;

3) способность системы выполнять эксплуатационные требования пользователя (эффективность системы);

4) время возврата инвестиций (ресурсов, затраченных на эксплуатацию и обслуживание системы), т.е. экономическая эффективность продукта.

Правильная формулировка пакета требований к системе крайне важна для обеспечения перечисленных факторов прогнозируемого успеха, так как именно этот набор является основой формирования будущей системы. Этапы процесса системной инженерии включают также анализ и верификацию требований в разных частях жизненного цикла. При этом необходимо регулярно проверять трассировку требований «сверху вниз», т.е. влияние требований верхнего уровня на требования к подсистемам. Кроме того, требования уточняются на всех этапах процесса разработки.

К сожалению, плохо сформулированные требования являются главной причиной проблем на проекте. Требования определяют, что должно быть сделано, как хорошо и при каких ограничениях. Если разработчики получат неверные требования, проект и оборудование не будут работать. Требования являются причиной стоимости системы, бюджета проекта, графика работ, требуемых ресурсов, планов верификации, эксплуатационных процедур, т.е. всего в проекте!

Приоритетные требования (и связанные с ними ограничения и допущения) определяют решаемую проблему, они устанавливают, как будет определен успех проекта. Недопустимо, что многие команды начинают решать проблему до того, как достигнуто соглашение, что именно надо сделать.

В соответствии с иерархией структуры системы существует несколько уровней требований сверху вниз.

• Требования заинтересованных сторон являются верхним уровнем требований. Они отражают потребности пользователей, клиентов и других источников требований, таких как отраслевые, правовые, экологические нормы и требования высокого уровня внутри компании. В этих требованиях используют критерии качества для создания точного и понятного набора выполнимых и проверяемых требований, который является полным и последовательным.

• Системные требования расположены на следующем уровне. Их целью является установление точных технических требований для разработки системы. Системные требования основаны на требованиях заинтересованных сторон и их производных с учетом существующих технологий, компонентов и т. д.

• На нижеследующих уровнях формируют требования к подсистемам и компонентам. Целью этих требований является установление точных технических требований для разработки подсистемы или компонента. Они выводятся из системных требований с учетом существующих технологий, компонентов, интерфейсов и т. д.

Для инициации процесса формирования требований используют следующую информацию.

1. Исходные ожидания заинтересованных сторон, т.е. потребности, цели, результаты, допущения, ограничения, внешние интерфейсы для данного класса изделия.

2. Описание концепции эксплуатации для понимания системных целей, задач и ограничений. Включает сценарии, варианты использования и проектные задания.

3. Базовые стратегии поддержки для всех стадий ЖЦ (разработки, тестирования, производства, эксплуатации или утилизации конечного продукта).

4. Меры эффективности, т.е. соответствие результатов проекта критериям успеха (см. главу 3.8).

5. Другие данные. Например, для авиационных объектов все взаимодействия человека и системы, необходимые для эксплуатации, включая сборку, наземные операции, логистику, обслуживание в полете и на земле, эксплуатацию в полете и т. д.

Задача формирования требований в разных проектах может решаться разными путями. В начале процесса проводится выявление источников формирования требований. Каждый новый продукт реализует ряд специфических требований, которые позволяют сохранить конкурентоспособность на рынке. Некоторые источники формирования требований перечислены ниже.

•На высшем уровне полезно использовать опыт разработчиков по постановке целей. Следует организовать общение заинтересованных лиц и заказчика, которые нуждаются в соглашении с выработкой единого подхода к набору требований.

• Далее нужно определить цели и задачи программы (сформировать контракт на работу), установить допущения и ограничения, оговорить концепцию эксплуатации.

• Обсудить анализ проекта и маркетинг (вопросы сбыта продукции), уточнить матрицы критериев системы и выбранные приоритеты. Выполнить анализ иерархии, установить, какие функции должна иметь система и ее подсистемы для выполнения задач эксплуатации, провести предварительную декомпозицию и определить прослеживаемость требований на компоненты, оценить выявленные интерфейсы.

• Учесть руководящие документы для создаваемого продукта или системы, ГОСТ, ISO, федеральные и отраслевые нормы, и др.

• Определить границы системы и внешние интерфейсы. Уточнить влияние внешних систем на требования рассматриваемого проекта и стыковки по внешним интерфейсам (при наличии). Выявить эксплуатационное окружение, уточнить и задокументировать, какие дополнительные требования налагают внешняя среда и условия работы.

При выполнении анализа требования полезно классифицировать на основные типы:

A. Функциональные требования, отвечающие на вопрос «что система должна делать?». Например, обеспечить связь между землей и самолетом.

B. Требования к рабочим характеристикам, отвечающие на вопрос «как хорошо система исполняет нужные функции?». К предыдущему примеру нужно определить применимый диапазон радиоволн, набор данных и как часто требуется выходить на связь.

C. Экологические и нефункциональные требования (сценарии использования), основанные на стандартах, отвечающие на вопрос «при каких условиях (экологии, надежности и доступности) система должна работать для удовлетворения данного требования?».

D. Ограничения системы. Точный характер ограничений может зависеть от предлагаемых решений. Так, выбранный вариант реализации заданных характеристик может вести к концепции проекта, которая скажется на росте массы конструкции. Или необходимо учитывать внешние интерфейсы, налагаемые другими системами (габарит мотогондолы на самолете, условия хранения, транспортировки, эксплуатации максимальная скорость у земли, температура, квалификационные требования по электромагнитной совместимости и др.).

E. Политика и публичные законы вносят ограничения по безопасности, экологии и шуму, важны для понимания, какие концепции полезны и практичны. Следует учесть угрозы, налагаемые известными возможностями потенциального конкурента, что ограничивает диапазон практических вариантов проекта. Если система предназначена для замены существующей, план перехода может учитывать дополнительные ограничения на концепцию и программу (например, трудоемкость ниже существующей, скорость производства выше и др.).

F. Требования к качеству (включая требования к безопасности).

G. Бизнес-требования (цена продукта, стоимость жизненного цикла, конкурентоспособность и др.).

H. Требования к процессам жизненного цикла продукта, включающие административно-организационные требования (скорость выхода на рынок, послепродажное обслуживание и др.).

Подробные требования к проекту могут содержать следующие пункты.

 
   1 Технические данные.
   2 Планирование.
   3 План управления системной инженерией (СИП).
3.1 Процесс системного проектирования.
3.2 Системный анализ и управление.
3.3 Технологические вопросы (процессы, оборудование).
3.4 Обеспечение технической интеграции.
   4 Анализ эффективности.
4.1 Технологический анализ производства.
4.2 Анализ испытаний и верификации.
4.3 Анализ опытного производства и испытательных установок.
4.4 Эксплуатационный анализ сценариев расчетных и нештатных.
4.5 Анализ поддержки в эксплуатации.
4.6 Анализ обучения и соответствующего персонала.
4.7 Анализ процесса утилизации.
4.8 Анализ окружающей среды.
4.9 Анализ стоимости жизненного цикла.
4.10 Моделирование и цифровые двойники.
   5 Детальный график системного проектирования.
   6 Технические обзоры.
6.1 Планирование цепи обзоров.
6.2 Функциональные обзоры.
6.3 Обзоры системы по времени работ.
6.4 Организация сбора экспертных отзывов.
   7 Структуру разбиения работ (СРР).
   8 Требования к технической интеграции системы.
8.1 Надежность и ремонтопригодность.
8.2 Живучесть (где приложимо).
8.3.Электромагнитная совместимость.
8.4 Интеграция человеческих систем.
8.5 Безопасность системы для здоровья и воздействие на окружающую среду.
8.6 Безопасность системы от внешних воздействий.
8.7 Обеспечение качества.
8.8 Производство (технологические процессы, заготовки, инструменты, гибкие линии).
8.9 Интегрированную логистическую поддержку.
8.10 Испытания и оценки.
   9 Прочие требования к разработке.
9.1 Приобретаемые компоненты (ПКИ).
9.2 Использование метрической системы.
9.3 Контроль деталей, включая поставки от подрядчиков.
9.4 Управление, связь и коммуникации.
 

 
9.5 Прототипирование.
   10 Проверку инженерного менеджмента у подрядчиков.
 

Цепочка проектирования системы (продукта) включает несколько шагов определения и разработки требований.

• Определить и документально зафиксировать требования. Заинтересованные лица (включая заказчиков, пользователей и др.) формируют набор требований верхнего уровня, зачастую эти требования входят в техническое задание контракта на разработку системы.

• Провести анализ и декомпозицию полученных требований на нижележащие уровни системы для формирования указаний, необходимых исполнителям работ.

• Сформировать производные требования, вытекающие из заданных, для реализации детального проекта системы.

• Определить методы верификации требований.

Эти шаги могут выполняться параллельно, и, аналогично большинству технических процессов, реализуются посредством набора итераций.