Системный подход к управлению высокотехнологичными проектами. 2-е издание, переработанное и дополненное

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

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

• Учесть руководящие документы для создаваемого продукта или системы, ГОСТ, 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 Проверку инженерного менеджмента у подрядчиков.

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

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

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

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

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

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

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

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

Для перевода требований заказчика в технические характеристики продукта часто используют процедуру развертывания функции качества (quality function deployment, QFD). Метод QFD представляет собой один из инструментов проектирования изделий и процессов, помогающий преобразовывать пожелания потребителя в технические требования к изделиям и процессам их производств. Основная идея технологии QFD заключается в том, чтобы связать потребительские свойства, надежность (т.е. фактические показатели качества) и установленные в стандартах параметры продукта (вспомогательные показатели качества), между которыми всегда существует большое различие.

Метод (https://clck.ru/3FNPmg) основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Сначала потребительские характеристики преобразуются в технические. Затем технические характеристики преобразуются в характеристики компонентов, далее в характеристики процессов и в характеристики контроля продукта.

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

Одним из видов требований нижних уровней являются производные требования.

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

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