Системный подход к управлению высокотехнологичными проектами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дадим основные определения понятия архитектуры системы.

• Архитектура системы – это структура компонентов, их взаимоотношений, принципов и руководств, направляющих их проектирование с учетом эволюции во времени, связь между нуждами анализа и целью проекта, функциональный анализ и первое описание структуры системы (DoD, US).

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

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

Рекомендуется ознакомиться с ГОСТ Р 57100—2016 (ISO/IEC/IEEE 42010:2011) «Системная и программная инженерия. Описание архитектуры». Пример одного из возможного множества изображений архитектуры ВС показан на рис. 1.6.

Рис. 1.6. Вариант схемы архитектуры воздушного судна

Создание и развитие архитектуры – есть начало процесса проектирования системы. Здесь устанавливают связи между требованиями и проектом. Требования к системе являются ключевым компонентом процесса ее создания. Место процесса формирования требований в общем процессе СИ можно посмотреть на рис. 1.5.

Укажем формальные определения понятия «требование» из стандартов системы ISO.

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

ISO/IEC 29148 

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

«Требование – это документально изложенный критерий, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения».

ISO 9000 

«Система менеджмента качества»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к системе обычно разделяют на основные типы:

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

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

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

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

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

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

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

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

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

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

Метод QFD (http://studme.org/1608040210904/ menedzhment/tehnologiya_ razvertyvaniya_ funktsii_kachestva) основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Потребительские характеристики преобразуются в технические. Технические характеристики преобразуются в характеристики компонентов, далее в характеристики процессов и в характеристики контроля продукта.

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

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

Рис. 1.7. Примеры интерфейсов

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

Интерфейсы можно классифицировать на внешние и внутренние (по отношению к системе в целом или по отношению к области работ конкретного подрядчика). Разделение на внутренний и внешний интерфейсы внутри системы зависит от положения исполнителей в цепочке «заказчик-поставщик».

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

• При декомпозиции системы появляется определенное количество специальных элементов системы – внутренних интерфейсов, необходимых для установления связи между двумя функциями или процессами внутри системы. Типы и характеристики всех интерфейсов должны быть идентифицированы и определены. Внутренний интерфейс – это интерфейс, контролируемый данным конкретным исполнителем ОКР.

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

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

На рис. 1.8 показаны поставщики основных компонентов самолета SSJ-100. При стыковке участков работ разных команд в системе возникает множество интерфейсов. Их появление связано с наличием группы проектных команд, участием разных производителей агрегатов, использованием нескольких сборочных площадок, разделением работ внутри отдельных команд.

Рис. 1.8. Основные партнеры по производству самолета SSJ-100

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

1. Интерфейсы возникают как между подсистемами, так и между подсистемами и системой.

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

3. Должен быть определен один владелец каждого интерфейса, даже если это очевидно.

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

5. Требования к интерфейсу включают логические и физические интерфейсы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно изложить некоторые полезные правила формирования требований, как набор рекомендаций, чего следует «избегать» в тексте требований:

• хаоса: необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;

• «лазеек», таких как «если это необходимо», поскольку они делают требование бесполезным;

• помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;

• рассуждений;

• нечетких слов («обычно», «в основном», «часто», «нормально», «типично»);

• использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);

• принятия желаемого за требуемое («100% надежный», «приятный для всех пользователей», «безопасный», «подходящий для всех платформ», «не должен никогда ломаться», «быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем»).

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

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

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

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

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

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

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

В документах на английском языке используют пометки типа TBA (to be agreed – необходимо согласовать), TBC (to be complete – необходимо завершить), TBD (to be decided – необходимо принять решение). Однако на определенном этапе разработки при «заморозке требований» весь набор пустых ячеек для требований должен быть заполнен.