Читать книгу: «Системная инженерия на раз-два», страница 3

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

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

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

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

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

Требование – это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (стандарт ISO/IEC 29148 «Разработка требований»).

Есть несколько причин, зачем нужны требования:

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

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

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

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

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

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

Концепция эксплуатации должна ответить на ряд вопросов пользователя.

• Что требуется от системы с функциональной точки зрения?

• Какие основные и второстепенные функции должна выполнять система?

• Что ограничивает ее возможности?

• Что пользователи ценят в ожидаемом продукте?

• Когда необходимо построить и поставить систему?

• Каков запланированный жизненный цикл системы?

• Какова предполагаемая стоимость жизненного цикла системы?

• Где предполагается использовать систему?

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

Далее начинается процесс формирования из системных требований верхнего уровня набора требований к системе в терминах, понятных разработчикам. Следует изложить, что должна делать новая система, и насколько хорошо она должна это делать. Заявленные требования предоставляются заказчиками систем, например, через часто используемые запросы контрактных предложений (RFP) и рабочие задания (SOW). Эти требования обычно формулируются на языке заказчика, зачастую в виде пожеланий. Требования заказчика недостаточны для проектирования системы. Обычно они неполные, нечетко сформулированные, а иногда и противоречивы по своему характеру. Системные требования должны быть собраны, отфильтрованы, уточнены, декомпозированы и задокументированы. Для этапа разработки необходим полный, технически обоснованный и точный набор системных требований, которые необходимо реализовать.

Требования являются ключом к успеху проекта. Хорошие требования к системе или продукту должны быть:

• Специфичны, должны отражать только один аспект конструкции или характеристик системы. Кроме того, должны быть выражены в терминах потребности (что и как хорошо), а не решений (как).

• Измеримы, характеристика выражается объективно и количественно, может быть проверена при испытании.

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

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

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

Для сбора потенциальных требований можно использовать разные источники.

1. Интервью с пользователями для уточнения дизайна продукта и улучшения качества.

2. Опрос и анкетирование, которые широко используются в социальных исследованиях и анализе рынка.

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

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

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

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

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

– Требования к рабочим характеристикам, отвечающие на вопрос «как хорошо система исполняет нужные функции?»

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

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

– Политика и публичные законы, которые вносят ограничения по безопасности, экологии и шуму.

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

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

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

Функциональные (эксплуатационные) требования к системе должны решать следующие основные проблемы.

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

• Определить рабочие характеристики предполагаемых функций системы.

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

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

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

Написание хороших требований требует инженерных знаний системы, навыков общения с людьми и, прежде всего, способности мыслить критически и творчески. Сначала требование выражают в качественной форме. Например, «Автомобиль должен иметь возможность двигаться в прямом направлении и задним ходом, а направление движения должно выбираться водителем». Далее добавляют количественные оценки. Например, «Автомобиль должен проезжать в среднем 150 км с заправкой десяти литров топлива при следующих условиях: X, Y и Z» или «Уровень шума внутри автомобиля не должен превышать 55 децибел на скорости ниже 120 км в час, при движении по стандартному асфальтовому покрытию». Качественные и количественные требования заносят в документ, называемый техническим заданием (ТЗ). Выполнение требований, указанных в ТЗ, является обязательным для результата проекта.

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

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

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

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

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

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

На стадии концептуального проектирования основные действия по проектированию включают:

• определение пользователей и потребностей системы;

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

• проведение анализа технических, социальных и экономических проблем, связанных с проектированием системы, и разработку плана действий для ее создания;

• проведение функционального анализа на системном уровне для определения иерархической структуры функций системы и рабочих отношений между ними;

• документирование исходной функциональной базовой версии системы;

• проведение обзора концептуального дизайна.

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

Архитектура системы – это структура компонентов, их отношений, а также принципов и руководств, регулирующих их проектирование и развитие во времени (определение компании Boeing).

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

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

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

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

Процесс разработки верхнего уровня архитектуры системы показан на рис. 5. Процесс движется из верхнего левого угла по часовой стрелке. Этапы на схеме пронумерованы.

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

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

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

1. структура требований к системе;

2. функциональная структура конструкций, технологических систем и компонентов;

3. геометрическая структура (например, в каком отсеке изделия, на каком уровне находится оборудование);

4. структура разбиения работ проекта (см. раздел 2.2);

5. организационная структура задействованных при реализации предприятий.

Далее необходимо дополнить и распределить требования верхнего уровня на всю структуру системы для каждого компонента. Формирование проектных требований начинается с уточнения внешних требований верхнего уровня, поступающих от заказчиков. Затем эти требования верхнего уровня группируют по конкретным направлениям:

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

• Промышленные, производственные и испытательные требования.

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

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

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

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

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

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

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

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

Приведем пример формирования технических требований для разработчика на базе требований верхнего уровня системы. В пожеланиях клиента указано, что легковой автомобиль должен иметь систему климат-контроля. Чтобы пассажиры чувствовали себя комфортно в салоне автомобиля, система должна обеспечивать температуру внутри салона в пределах 20—29° C, когда температура наружного воздуха составляет от -20° C зимой до +45° C летом.

Систему управления климатом декомпозируют на группы подсистем:

• отопления, включающую теплообменник горячего воздуха, воздуходувку, регулятор скорости вентилятора, термостат и систему подачи горячего воздуха;

• подачи холодного воздуха, включающую теплообменник холодного воздуха, воздуходувку, регулятор скорости вентилятора, термостат и систему подачи хладагента;

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

Далее формируют требования для подсистем системы климат-контроля:

1. теплообменников горячего и холодного воздуха;

2. нагнетателя воздуха с регулируемой скоростью вентилятора;

3. трассы подачи горячей воды из системы охлаждения двигателя;

4. подачи хладагента от насоса кондиционера;

5. термостата;

6. системы воздуховодов и трубок для воздушных и жидкостных потоков;

7. электрической системы питания компонентов.

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

Для реализации сформулированных требований при разработке новой системы или продукта важно, чтобы проектное решение соответствовало сегодняшним возможностям организации. Вводится понятие зрелости технологии как меры готовности запуска нового продукта для конкретного технического решения. По существу, зрелость технологии также является мерой риска, ассоциированного с конкретным проектом. Уровень зрелости технологии связан с часто используемым уровнем технической зрелости производства нового продукта. Основной целью использования уровней технологической готовности является помощь управленческому персоналу в принятии решений, касающихся перехода на следующие стадии развития инфраструктуры компании или использования технологии. Расшифровки уровней зрелости технологий приведены в ГОСТ Р 58048—2017 «Трансфер технологий. Методические указания по оценке уровня зрелости технологий».

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

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