Разработка требований в аппаратной разработке

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

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

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

В этой статье вы получите четкое определение requirements engineering и поймете ее роль в разработке аппаратных продуктов. Мы рассмотрим как теоретический обзор, так и практическую схему ее применения в аппаратном проекте, с примерами из реальной практики, а также список наиболее распространенных ошибок и способов их избежать.

Ключевые выводы

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

Что такое Requirements Engineering?

Requirements engineering — это систематический, дисциплинированный подход к определению, документированию и управлению требованиями в процессе разработки аппаратного продукта.

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

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

Преимущества Requirements Engineering

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

Основные преимущества RE включают:

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

Развитие дисциплины Requirements Engineering

Requirements engineering уходит корнями как в системную инженерию, так и в программную инженерию. Эти направления развивались в разных инженерных контекстах, поэтому термин до сих пор может иметь немного разный охват в зависимости от источника.

В контексте программной инженерии основное внимание уделяется требованиям к программному обеспечению: что должно делать ПО, как оно должно себя вести и каким качественным характеристикам должно соответствовать. Инженеры-программисты обычно говорят о функциональных и нефункциональных требованиях, оформленных в виде user stories, use cases и acceptance criteria. В контексте системной инженерии охват шире. Под требованиями понимается вся система целиком, включая аппаратную часть, ПО, людей, процессы, интерфейсы, условия эксплуатации и другие характеристики системы. Системные инженеры говорят о системных требованиях верхнего уровня, декомпозированных на аппаратные, механические, электрические, firmware- и safety-факторы, и зафиксированных в виде формальных формулировок требований и матриц трассируемости требований.

В аппаратной разработке RE объединяет оба подхода. Она сочетает строгость и междисциплинарный охват системной инженерии, необходимые для учета стоимости bill of materials (BOM), тепловых ограничений и производственных ограничений, с трассируемостью по всему жизненному циклу, характерной для программной инженерии, чтобы требования оставались проверяемыми и связанными на протяжении всей разработки.

Смежные дисциплины по отношению к Requirements Engineering

Requirements engineering тесно связана с другими дисциплинами разработки продукта, особенно с системной инженерией и product management.

Системная инженерия

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

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

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

Product Management

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

Это также связано с RE, потому что именно такие высокоуровневые потребности клиентов и бизнес-цели становятся отправной точкой для определения требований к продукту.

Этапы процесса Requirements Engineering

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

Как описано в статье, опубликованной в журнале Requirements Engineering journal, распространенный учебный подход делит процесс RE на четыре ключевых вида деятельности (этапа):

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

Кто участвует в процессе

В рамках RE задействовано несколько ключевых ролей, которые совместно определяют, что должен делать продукт:

• Владелец требований: инженер, который берет расплывчатые потребности заинтересованных сторон, задает правильные вопросы и превращает их в набор требований, с которым инженерная команда действительно может работать в процессе разработки продукта. Часто это Systems Engineer, Lead Engineer или специалист с аналогичной ответственностью.
• Техническое product-лидерство: люди, которые взаимодействуют с заинтересованными сторонами или бизнесом, понимают их потребности, а затем превращают этот запрос в четкую цель продукта. Это могут быть Product Managers, Program Managers или аналогичные роли.
• Инженер-исполнитель: инженер, который использует определенные требования для проектирования и создания своей части продукта. Это могут быть Electronics, Mechanical, Software или Firmware Engineers.
• Ответственный за верификацию: человек, который определяет, как будут проверяться требования, и следит за тем, чтобы необходимые ревью и испытания были выполнены. Это могут быть Verification Engineers, Test Engineers или QA Engineers.

Практическая схема Requirements Engineering для аппаратной разработки

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

Ниже приведен практический взгляд на framework requirements engineering для аппаратной разработки, показывающий, как требования вписываются в каждый этап.

Запуск проекта: фиксация замысла

В начале проекта Technical Leads обычно получают расплывчатые входные данные, такие как запросы клиентов, requests for proposal (RFP), бизнес-цели или ограничения по стоимости, размерам или срокам. Например, клиент может попросить устройство меньшего размера, поддерживающее определенный сценарий использования.

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

Requirements Engineering: определение требований

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

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

Реализация: разработка проектных решений

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

Верификация и валидация: тестирование и подтверждение

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

Управление изменениями: пересмотр и итерации

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

Документация и передача: сдача проекта

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

Примеры инженерии требований

Инженерия требований в медицинских устройствах

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

Для медицинских устройств добавляется регуляторный уровень. Команды уделяют больше внимания прослеживаемости, верификации, документации и оформлению сопутствующих документов. Это помогает проходить регуляторное одобрение в рамках таких нормативных требований, как FDA 21 CFR Part 820 в США и ISO 13485:2016 в ЕС и на других рынках.

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

Инженерия требований в потребительской и промышленной электронике

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

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

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

Чтобы создавать надёжное оборудование, соответствующее требованиям безопасности, крайне важно сохранять связь между требованиями и изменениями в проекте. Узнайте, как MakeSafe Tools решает эту задачу, в полной истории успеха.

Как избежать распространённых ошибок в инженерии требований

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

Вот некоторые из наиболее распространённых ошибок, на которые стоит обратить внимание, и способы их избежать:

Программные инструменты для инженерии требований

Управлять небольшим набором требований относительно просто. Но по мере роста проекта поддержание порядка и актуальности требует всё больше усилий. На этом этапе способ управления требованиями начинает играть более важную роль.

На практике команды обычно используют один из следующих подходов:

• Электронные таблицы и документы: привычный и простой стартовый вариант, что делает его удобным для небольших проектов. Однако по мере роста проекта он требует всё больше ручной работы для сопровождения.
• Специализированные инструменты управления требованиями (RM): обеспечивают больше структуры и контроля по мере усложнения проектов. Компромисс в том, что некоторые такие инструменты также навязывают больше процессов, чем может быть нужно небольшой команде.

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

Для небольших команд по разработке аппаратуры, которые уже переросли электронные таблицы, но не нуждаются в крупном корпоративном RM-процессе, Requirements Portal — это практичный вариант, который стоит рассмотреть. Он разработан, чтобы дать небольшим командам более структурированный способ управления требованиями без избыточной сложности традиционной корпоративной системы.

Заключение и следующие шаги

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

Если вы хотите продолжить изучение инженерии требований, эти ресурсы станут хорошей отправной точкой:

• ISO/IEC/IEEE 29148:2018 содержит международный стандарт для процессов и практик инженерии требований. Он даёт дополнительные рекомендации о том, как требования следует формулировать, структурировать, документировать и сопровождать.
• NASA Systems Engineering Handbook содержит практические рекомендации о том, как требования создаются, формулируются, проверяются и используются в ходе разработки систем.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) объясняет, как требования вписываются в более широкий процесс системной инженерии и как различные части системы разрабатываются совместно.
• Журнал Requirements Engineering публикует исследования, примеры из отрасли и различные подходы к инженерии требований более подробно.

Если вы готовы перейти от теории к практике, попробуйте Requirements Portal и начните уже сегодня, бесплатно и без необходимости настройки, работать со структурированными требованиями в реальном проекте по разработке аппаратуры.

Часто задаваемые вопросы

Почему инженерия требований важна?

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

Какова роль инженера по требованиям?

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

В чём разница между инженерией требований и управлением требованиями?

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