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

Шрифт:

2.3. Управление жизненным циклом проекта и продукта

Задача управления жизненным циклом системы состоит в создании управленческих механизмов для принятия локальных решений на каждой из стадий ЖЦ, учитывая все последствия для следующих этапов, и затем позволяют вносить необходимые корректировки в процессы на других стадиях ЖЦ. Сложность объектов, созданных инженерами, определяется их размерами и количеством частей. Если современный пассажирский самолет включает примерно 100 тысяч деталей (без учета крепежа), то нефтяная океанская платформа насчитывает до 10 миллионов деталей. В системной инженерии представлены правила, инструменты и технологии для разработки продуктов и систем любой сложности.

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

a) определить, что является базовой системой;

b) описать общие этапы жизненного цикла проекта, их цели, деятельности, продукцию и ворота принятия решений, которые их разделяют;

c) описать типичные цели разработки для каждой из фаз ЖЦ проекта.

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

1. Управление процессом проектирования и разработки продукта.

2. Управление процессом технологической подготовки производства.

3. Управление процессом производства.

4. Управление процессами закупки ПКИ, материалов, заготовок, запчастей.

5. Управление процессом испытаний изделия (стендовых, сертификационных, государственных, приемо-сдаточных).

6. Управление процессом логистической поддержки изделия.

7. Управление процессом ППО.

8. Управление процессами подготовки эксплуатирующего состава и персонала ППО.

9. Обеспечение качества на всех этапах ЖЦ за счет процессов управления качеством, управления конфигурацией, реализации процессов системной инженерии.

10. Обеспечение планируемого темпа производства продукта.

11. Достижение заданной трудоемкости разработки и изготовления системы.

12. Управление процессом утилизации при списании изделия.

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

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

Рис. 4. Типовая схема процесса ЖЦ

Структура управления жизненным циклом системы включает все, что должно быть сделано для выполнения программы или проекта в различных фазах, разделенных точками принятия ключевых решений или контрольными рубежами (КР). Напомним, что КР это события, в ходе которых лицо, принимающее решение, определяет готовность программы или проекта к переходу на следующий этап жизненного цикла. В соответствии со стандартом ГОСТ Р 57193—2016 на контрольных рубежах ЖЦ должны быть выполнены главные задачи программы за предыдущую стадию: гарантировано, что последующая доработка организационных и технических базисов приемлема и приведет к удовлетворительной верификации и валидации продукта; обеспечена приемлемость риска перехода на следующую стадию; продолжено стимулирование командной работы поставщика и заказчика.

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

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

a) приемлемо: переходить к следующей стадии проекта;

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

c) неприемлемо: не переходить; продолжать эту стадию и повторить пересмотр, когда будет готовность;

d) неприемлемо: вернуться на предыдущую стадию;

e) неприемлемо: заморозить мероприятия проекта;

f) невосстановимо: закрыть проект.

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

Сегодня требования системной инженерии изложены в ряде стандартов ГОСТ РФ.

• ГОСТ Р 57193—2016 (ISO/IEC/IEEE 15288:2015). Системная и программная инженерия. Процессы жизненного цикла систем.

• ГОСТ 56136—2014. Управление жизненным циклом продукции военного назначения. Термины и определения.

• ГОСТ 56135—2014. Управление жизненным циклом продукции военного назначения. Общие положения.

• ГОСТ Р 57100—2016 (ISO 42010:2011). Системная и программная инженерия. Описание архитектуры.

• ГОСТ Р 57101—2016 (ISO/IEC/IEEE 16326:2009). Системная и программная инженерия. Процессы жизненного цикла. Управление проектом.

• ГОСТ Р 58876—2020. Системы менеджмента качества организаций авиационной, космической и оборонной промышленности. Требования.

• ГОСТ Р 59194—2020 Управление требованиями. Основные положения.

• ГОСТ Р 59193—2020. Управление конфигурацией. Основные положения.

• ГОСТ Р 58054—2018. Изделия авиационной техники. Управление конфигурацией. Общие положения.

• ГОСТ Р 56923—2016. Информационные технологии. Системная и программная инженерия. Процессы жизненного цикла программных средств.

Продвижение по звеньям процесса по мере разработки сопровождается верификацией каждого шага, возвратом к предыдущему результату для проверки прогресса работ. При формировании процессов используют особенности описания систем, изложенные в стандарте ГОСТ Р 57193—2016:

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

b) иерархическое восприятие физической структуры системы;

c) объект любого уровня иерархической структуры может рассматриваться как система;

d) характерные свойства на границе системы возникают в результате взаимодействия между элементами системы;

e) люди могут рассматриваться как внешние пользователи по отношению к системе (например, экипаж самолета) и как элементы в рамках системы (например, персонал завода-производителя);

f) система может рассматриваться как отдельный, изолированный от внешней среды объект.

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

1. Комплексное техническое планирование, включая формирование планов процессов СИ и продуктов.

2. Управление требованиями: определение и управление требованиями, которые описывают желаемые характеристики системы.

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

4. Маркетинговая оптимизация: информация по принятию решений на основе анализа и отбора наиболее сбалансированных решений по требованиям рынка.

5. Синтез: этап преобразования требований в физические решения верхнего уровня системы.

6. Управление интерфейсами: определение и управление взаимодействиями между сегментами в рамках системы или взаимодействиями с другими системами.

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

8. Целостный анализ: проверка, что выполненная интеграция системы обеспечила требуемый уровень точности и аккуратности.

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

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

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

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

Наиболее контролируемым параметром является стоимость жизненного цикла (СЖЦ), то есть общая стоимость программы или проекта за запланированный жизненный цикл от формулировки до реализации. Для долгосрочных (на десятилетия) программ, таких как программы серийного выпуска авиационной техники или функционирования международной космической станции с полетами человека в космос, трудно установить продолжительность жизненного цикла для целей определения СЖЦ. Подробности приведены в главе 4.

Процесс разработки (ЖЦ проекта) в системной инженерии можно представить в виде нескольких взаимосвязанных итерационных петель (рис. 5).

Рис. 5. Процесс разработки системы, MIL_Std-499

Вышеприведенные шаги системной инженерии для удобства иногда декомпозируют, выделяя набор из 33 подпроцессов ЖЦ проекта (стандарт EIA 632 «Process for the Engineering of a System», имеет рекомендательный статус).

А. Поставки.
1. Поставка товаров.
Б. Приобретения.
2. Приобретение товаров.
3. Оценка производительности поставщика.
В. Планирование.
4. Стратегии реализации процесса.
5. Определение технических усилий.
6. График и организация работ.
7. Технические планы.
8. Указания (директивы) для работы.
Г. Оценки.
9. Прогресс исполнения планов и графиков.
10. Оценка соответствия требованиям.
11. Технические обзоры проекта.
Д. Управление.
12. Результаты управления.
13. Распространение информации.
Е. Определение требований.
14. Требования Заказчика.
15. Требования других заинтересованных сторон.
16. Технические требования к системе.
Ж. Определение проектных решений.
17. Представление логических решений.
18. Представление физических решений.
19. Указанные требования.
З. Реализация.
20. Реализация проекта.
И. Передача Заказчику.
21. Ввод в эксплуатацию.
К. Системный анализ.
22. Анализ эффективности.
23. Анализ рыночных альтернатив.
24. Анализ рисков.
Л. Верификация требований.
25. Проверка статуса требований.
26. Проверка требований Заказчика.
27. Проверка требований других заинтересованных сторон.
28. Проверка технических требований к системе.
29. Проверка представления логических решений.
М. Верификация системы.
30. Проверка конструктивных решений.
31. Проверка конечного продукта.
32. Проверка готовности продукта к эксплуатации.
Н. Валидация конечного продукта.
33. Сертификация конечного продукта.

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

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

•определить цели исследования ниши на рынке;

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

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

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

• оценить эффективность каждого варианта для каждого критерия;

• выполнить анализ чувствительности для избранных вариантов;

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

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

• сформировать бизнес-план для обоснования развития будущего продукта или системы.

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

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

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

1) были ли выполнены требования к системе и установленные ограничения;

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

3) достаточны ли имеющиеся данные для утверждения предварительного выбора;

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

5) если результаты нескольких альтернатив близки, необходим ли дальнейший анализ;

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

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

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

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

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

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

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

a) высокая стоимость цикла проектирование-сборка-испытания;

b) низкая технологическая зрелость, так как это новая конструкция;

c) умеренный объем единичного производства;

d) длительный ожидаемый срок службы (до 50 лет);

e) суровые условия эксплуатации в отдаленной пустынной местности с дистанционным управлением.

Описанные выше особенности влияют на адаптацию жизненного цикла следующим образом.

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

• Предполагается одна итерация разработки (создание прототипа) для дорогого штучного проекта.

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

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

1) низкая стоимость цикла проектирования-сборки-тестирования. программные системы могут быть разработаны в виртуальной тестовой среде;

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

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

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

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

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

a) очень высокая стоимость цикла проектирование-строительство-испытания;

b) высокая технологическая зрелость;

c) жесткие требования и граничные условия;

d) высокие эксплуатационные расходы и развертывание в удаленной среде;

e) отраслевые нормы и стандарты: в отрасли гражданского строительства существуют устоявшиеся стандартные процессы разработки и строительства;

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

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

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) время возврата инвестиций (ресурсов, затраченных на эксплуатацию и обслуживание системы), т.е. экономическая эффективность продукта.

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

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

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

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

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