Пример построения процесса системной инженерии на базе 3SL Cradle

Requirements Definition and Management Using Cradle
Перевод: Юлия Куксенок

Пример построения процесса системной инженерии на базе 3SL Cradle, аналог которого использует NASA в своих проектах.

Содержание статьи

  1. Введение
  2. Разработка и управление требованиями
    • Разработка концепции системы и требований заинтересованных сторон
    • Определение границ системы и ее контекста
    • Определение элементов системы
    • Определение функций и поведения системы
    • Привязка функций по элементам системы
    • Планирование анализа и верификации системных требований
    • Генерация документации для системы и элементов системы
    • Трассируемость системной верификации и валидации (V&V)
  3. Трассируемость в руководстве по системной инженерии INCOSE (v.3.2.2) 

Перед чтением статьи, рекомендуем посмотреть презентацию

1. Введение

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

requirements_management_1

Узлы «AND» (кружки с символом «AND» внутри) на рисунке выше сигнализируют, что некоторые из этапов, находящиеся между двумя узлами «AND», могут выполняться параллельно — например, этапы 3,4 и 5.

Узлы «Iterate» (кружки с символом I внутри) означают, что все этапы, расположенные между двумя такими узлами, повторяются для каждого уровня системной архитектуры.

Где Уровень 1 в этой иерархии обозначает систему в целом, а каждый объект следующего уровня определяется как «элемент системы» (т.е.  дочерний элемент родительского объекта в иерархии, который соответствует системе в целом). На самом нижнем уровне системной иерархии элементы системы представляют собой элементы технического обеспечения (Hardware Configuration Items), элементы программного обеспечения (Computer Software Configuration Items) и персонал.

requirements_management_2

Этапы с 2 по 7 повторяются для каждого элемента системы, для которых должны быть разработаны системные требования. Подробная информация обо всех этапах представлена в разделе 2.

В разделе 3 описывается таблица, которая показывает трассировку между этими восемью этапами и аналогичными видами деятельности, описанными в Руководстве по системной инженерии INCOSE (v.3.2.2). Данная таблица показывает, что задачи по Разработке и управлению требованиями, описанные в этой статье, соответствуют Руководству INCOSE и ISO / IEC 15288: 2008.

После прочтения данного документа, у вас будет более полное представление о  ценности применения такого инструмента системного проектирования, как Cradle для всего процесса разработки и управления требованиями.

2.  Разработка и управление требованиями

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

Этап 1Разработка концепции системы и требований заинтересованных сторон. Эти действия выполняются в начале проекта и необходимы для определения границ проекта, подготовки документа концепции функционирования системы (ConOps), после чего  осуществляется разработка требований заинтересованных сторон и публикуется документ Stakeholder Requirements Document (SRD).

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

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

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

Этап 5Привязка функций к элементам системы. На этом этапе функции и соответствующие входы/выходы (определенные на этапе 4) назначаются различным подсистемам и интерфейсам. Это, так называемое, распределение функций (functional allocation). При этом определяется поведение конкретных элементов системы.

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

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

Этап 8Трассируемость системной верификации и валидации (V&V). На этой стадии осуществляется фиксация в базе данных статуса каждой задачи по верификации и валидации с трассировкой обратно к требованиям и функционированию системы. С помощью трассировки определяются те требования с их связями к проектным решениям, которые возможно придется изменить.

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

2.1     Этап 1 – Разработка концепции системы и требований заинтересованных сторон

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

  • Шаг 1.1 – Определение границ проекта. Четко определите и задокументируйте область границы проекта.
    • Создайте элемент верхнего уровня для системы в целом – так называемая, структурная декомпозиция системы (System Breakdown Structure, SBS), и опишите цель проекта, календарный план и ожидаемые заинтересованные стороны проекта.
      requirements_management_3
      ○ Соберите связанные с проектом исходные материалы и захватите его в базу данных Cradle, используя заданный тип элемента (например, REF DOC). Созданные элементы должны быть соединены с элементом верхнего уровня типа SBS,  соответствующего системе в целом для разрабатываемой системы.

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

  • Определите этапы жизненного цикла продукта (например, производство, функционирование, утилизация), для которых должны быть определены требования заинтересованных сторон.
  • Шаг 1.2 – Разработка вариантов использования. Разработайте варианты использования каждого применимого этапа жизненного цикла. Вариант использования – это задача. Например, вы можете определить вариант использования для этапа функционирования.
    requirements_management_5
  • Шаг 1.3 –  Разработка концепции функционирования системы. Создание документа Concept of Operations (ConOps) на основе вариантов использования/задач, которые были определены ранее.
    • Определите сценарий работы (один или несколько) для реализации каждого выявленного варианта использования или задачи.
    • Сценарий работы – это процесс, описывающий то, как система будет использоваться, производиться, тестироваться, развертываться, эксплуатироваться на протяжении жизненного цикла продукта. Типичный сценарий представляет собой  поток в форме «стимул-реакция» с описанием входов и выходов. Эти сценарии описываются с точки зрения  конечных пользователей, а не разработчиков продукта.
      requirements_management_6
    • Диаграмма типа PFD (Process Flow Diagram), может быть использована для описания сценария работы.Установите трассируемость между конкретным вариантом использования и рядом сценариев работы, разработанных с помощью PFD. Соедините сценарий работ­­ы с соответствующим вариантом использования.
      requirements_management_7
    • Как правило, требуется несколько сценариев для того, чтобы понять функциональные операции и входы/выходы, связанные с достижением каждой задачи и варианта использования.
    • Соедините элементы спецификаций вариантов использования с верхним уровнем системы (SBS) для обеспечения трассируемости.
  • Шаг 1.4 – Разработка требований заинтересованных сторон. Определите требования, которые задают предполагаемые сервисы, которые должны предоставляться системой, и взаимодействие, которое будет иметь система с рабочим окружением.
    • Используйте требования, цели и задачи, а также различные операции, выявленные в ходе разработки сценариев работы, чтобы выявить знания, необходимые для разработки конкретных требований заинтересованных сторон. После того, как создан новый элемент базы данных для предлагаемого требования, введите его описание, краткое обоснование, а затем свяжите перекрестной ссылкой с исходным материалом (т.е., с требованием или сценарием работы).
      requirements_management_8
    • Если есть исходный документ, который содержит полезную информацию, например, требования заинтересованных сторон или тесты, вы можете использовать Document Loader, чтобы разобрать документ на отдельные информационные части, которые автоматически загрузятся в хранилище данных Cradle в виде отдельных элементов.
    • Если какой-либо из созданных элементов по сути включает несколько требований, которые были захвачены из исходного документа, можно воспользоваться командой «разбить» для автоматического создания новых дочерних элементов, содержащих отдельные требования.
    • Используйте проверку соответствия (Conformance Checker) для верификации использования «плохих» или «хороших» фраз в описании требований.
    • Создайте документ с требованиями заинтересованных сторон (Stakeholder Requirements Document), проведите его рецензирование вместе с заказчиком, чтобы убедиться, что он является актуальным, соответствует его требованиям и однозначно понимается всеми заинтересованными сторонами.
    • Требования сторон и соответствующие сценарии работы будут основой для системного проектировщика для разработки производных требований на этапах 2 — 6. Эти производные требования называются системными требованиями (System Requirements).
  • Шаг 1.5 – Планирование валидации системы. Спланируйте действия по валидации системы, которые должны быть выполнены в процессе интеграции и тестирования путем разработки задач валидации (Validation Objectivities), которые должны быть использованы для проверки того, что система соответствует требованиям заинтересованных сторон, отраженных в документе Stakeholder Requirements. Каждая задача валидации (Validation Objective) определяет методы проверки, средства, оборудование и ресурсы, необходимые для выполнения проверки, а также она должна быть непосредственно связана с требованием сторон, которое подлежит проверке.
    requirements_management_9
  • Шаг 1.6 –  Проектные ограничения. Определите и отразите проектные ограничения в хранилище данных.
  • Шаг 1.7 – Захват определений понятий. Включите тип элементов для ведения общего глоссария системы, чтобы участники проекта могли вести список терминов и сокращений, которые могут быть включены в публикуемые документы.

2.2      Этап 2 – Определение границ системы и ее контекста

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

  •  Шаг 2.1 — Создание контекстной диаграммы. Используя информацию, разработанную на предыдущих этапах, создайте контекстную диаграмму с помощью Physical Architectural Diagram (PAD). Цель данной диаграммы – определить внешние интерфейсы верхнего уровня для системы в целом или одного из элементов системы.
    • Нарисуйте предлагаемую систему в виде «чёрного ящика» — элемент системы в виде прямоугольника с закругленными углами в центре диаграммы.
    • Нарисуйте внешние сущности в виде прямоугольников вокруг символа предложенной системы.
    • Нарисуйте внешние интерфейсы между предлагаемой системой/ элементом системы и внешними сущностями, используя стрелки с аннотацией. Входы/выходы из сценариев работы представляют собой хорошую отправную точку для определения внешних интерфейсов
      requirements_management_10
    • Соедините контекстную диаграмму с основным элементом SBS, для которого выполняются этапы со 2 по 7.  Таким образом, создается трассировка, которая позволяет рецензентам перейти к элементу SBS и следовать по связям далее ко всей относящейся к нему информации. Во время последующих этапов, дополнительная релевантная информация будет связана с этим элементом.
      requirements_management_11
  • Шаг 2.2 — Определение внешних интерфейсов. Так как данная контекстная диаграмма была построена для системы в целом, а не для элемента системы более низкого уровня (составной части), информация об интерфейсах должна быть соединена с требованиями заинтересованных сторон к интерфейсам (Interface Stakeholder Requirement), которые подтверждают существование такого интерфейса. Другими словами, интерфейсы, показанные в контекстной диаграмме, должны быть связаны с требованиями заинтересованных сторон к интерфейсу. На следующем рисунке, показывающем представление запроса Cradle видно, что некоторые элементы интерфейса были оттрассированы к требованиям заказчика к интерфейсу.
    requirements_management_12

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

2.3      Этап 3 – Определение элементов системы

Система состоит из множества взаимодействующих элементов системы, каждый из которых вводится для того, чтобы реализовать  соответствующие системные требования. Элемент системы имеет структуру (как он построен) и поведение (что он делает). Примером системного элемента является элемент технического обеспечения (Hardware Configuration Items), элемент программного обеспечения (Computer Software Configuration Items), или человек, где все элементы вместе осуществляют заданную работу.

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

requirements_management_14

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

requirements_management_15

 

На этом этапе выполняются следующие действия:

  • Шаг 3.1 — Анализ исходной информации для элемента системы.
    • Используя информацию, полученную на этапе 1, или разработанную на этапах 3 — 7 предыдущего цикла проектирования, выполните анализ и исследование с целью выявления ошибок в исходном материале. Если ошибки обнаружены, задокументируйте их с помощью элемента типа ВОПРОС (ISSUE) и соедините с соответствующим элементом исходных данных.
    • Создайте элемент системы (элемент спецификации оборудования) для первичного элемента SBS, и соедините их вместе.
      requirements_management_16
    • Создайте элемент в базе данных для исследования альтернативного решения, и соедините его с соответствующим элементом SBS , таким образом, чтобы эта информация была известна и доступна во время рецензирования проекта.
      requirements_management_17
  • Шаг 3.2 — Определение нефункциональных системных требований. Цель этого шага заключается в определении желаемых физических характеристик для заданного системного элемента и затем в разработке производных системных требований для этого элемента. На следующем рисунке показан пример нефункциональных требований, которые присвоены первичному системному элементу.
    requirements_management_18
  • Шаг 3.3 — Определение подчиненных элементов системы. Примеры первичных элементов системы и подходящих подчиненных элементов, которые анализируются на данном цикле проектирования, представлены в следующей диаграмме. Переход на один уровень ниже в иерархии архитектуры системы, помогает проектировщикам определить недостающую информацию или противоречивые физические характеристики элементов системы.
    requirements_management_19

2.4    Этап 4 — Определение функций и поведения системы

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

Модель поведения состоит из трех компонентов:

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

 

requirements_management_20

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

Курица или яйцо?

requirements_management_21

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

requirements_management_20

requirements_management_22

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

  • Шаг 4.1 — Разработка функциональной модели для первичного элемента системы.
    • Используя исходные требования из предыдущего цикла проектирования, определите необходимые функции и их входы и выходы, как проиллюстрировано на следующем рисунке.
      requirements_management_23
    •  Две наиболее часто используемых нотации для функционального моделирования – расширенная блок-схема функций (enhanced Functional Flow Block Diagram, eFFBD) и блок-схема алгоритма (UML/SysML Activity Diagram). В приведенном ниже примере была использована eFFBD.
      requirements_management_24
  • Шаг 4.2 – Разработка функциональных требований и связей с функциями.
    • Соедините каждую функцию с соответствующим существующим требованием (заинтересованной стороны или системным), или создайте и свяжите новые производные системные требования с функцией. Таблица трассируемости (показана ниже) может использоваться для проверки того, что каждая функция связана с одним или несколькими требованиями. Команда должна просмотреть данные в этой таблице, чтобы убедиться, что трассировка выполнена правильно.

requirements_management_25

  • Шаг 4.3 – Обеспечение трассируемости к исходным требованиям.
    Все производные требования должны трассироваться к актуальным исходным требованиям (системным или заинтересованных сторон).
    Если источник производных требований не может быть идентифицирован, определите, необходимо ли удалить производное требование. Если выявлено, что производное требование актуально – определите, нужно ли изменить исходный материал, чтобы учесть отсутствующие исходные требования. Пример обратной трассировки показан ниже.
    requirements_management_26
  • Шаг 4.4 — Создание и связывание интерфейсных требований с определениями данных.
  • Логический вход/выход в функциональных моделях помогает получать/ проверять интерфейсы между элементами системы на этапе 5, и разработать требования к интерфейсам. Cradle автоматически создает следующие виды таблиц входов/выходов функций, чтобы обеспечить хорошую видимость интерфейсной информации, которая должна быть связана с соответствующими требованиями к интерфейсам. Во второй таблице ниже приведен пример, где пользователи создали и соединили новые требования к интерфейсам.
    requirements_management_27
    requirements_management_28
  • Шаг 4.5 — Декомпозиция функций.
    • На этапе 3, после того как первичный элемент системы для текущего цикла проектирования разбит на составные части (на один уровень вниз по иерархии), необходимо провести оценку каждой функции, определенной в первой части этапа 4, чтобы понять, возможно ли провести ее декомпозицию на подфункции, которые могут быть однозначно распределены по компонентам системы. Сам процесс распределения происходит на этапе 5. Следующий рисунок иллюстрирует концепцию этого процесса.
      requirements_management_29
  • Шаг 4.6 – Декомпозиция функциональных требований и определение связей с функциями.
    • Во всех случаях, когда производится декомпозиция функции, должна быть проведена оценка требований, связанных с родительской функцией, чтобы определить, применимы ли они к подфункциям в неизмененном виде или они также должны быть декомпозированы.
      requirements_management_30

2.5  Этап 5 – Привязка функций по элементам системы

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

requirements_management_31

 

На этом этапе решаются следующие задачи:

  • Шаг 5.1 – Привязка функций элементам системы.
    • Каждая функция верхнего уровня, определенная на этапе 4, должна быть привязана к первичному элементу системы для текущего цикла проектирования. Это позволяет сформировать список функций, которые будут выполняться элементом системы. Функции связываются с элементами связью типа allocate.
    • Каждая функция самого нижнего уровня, определенная на этапе 4, должна быть привязана к одному из подчиненных элементов первичного элемента системы.
    • Пример трассировки привязки функций по элементам системы показан на следующем рисунке:
      requirements_management_32
    • Пример трассировки элемента системы к присвоенной функции и далее к назначенным требованиям показан на следующем рисунке:
      requirements_management_33
  • Шаг 5.2 — Определение физических интерфейсов между элементами системы.
    • Определите входы/выходы, которые должны быть между функциями, распределенными по разным элементам системы. Эта информация должна быть соотнесена с соответствующим физическим интерфейсом между элементами системы. Следующее представление Cradle позволяет пользователю установить определения данных для входов и выходов, которые могут проходить через физический интерфейс между элементами системы. Обратите внимание, что на рисунке ниже Target Track Data проходит между сенсорной системой (Sensor System) и системой управления огнем (Fire Control System), поэтому должен быть определен механизм физического интерфейса для поддержки передачи этого потока информации.
      requirements_management_34
    • Физическая модель подчиненных элементов первичного элемента системы также может использоваться для определения интерфейсов между элементами системы. Следующий рисунок показывает такую модель:
      requirements_management_35
  • Шаг 5.3 – Привязка нефункциональных требований системным элементам.
    На этапе 3 были выявлены физические характеристики первичного элемента системы и были разработаны нефункциональные требования. На этом этапе, данные нефункциональные требования уточняются по мере необходимости, и эти требования переходят к подчиненным элементам элемента системы. На следующем рисунке, требования R.55 и R.56 выводятся из требования Р.12 и соединяются с подчиненными элементами системы.
    requirements_management_36
  • Шаг 5.4 – Выполнение пробной привязки.
    Для того чтобы достичь подходящего проектного решения, вы балансируете между производительностью, сложностью и риском, проводя пробные привязки. Это означает изменение распределений и/или изменение входов/выходов функциональной модели, чтобы получить сбалансированное проектное решение.

2.6  Этап 6 – Планирование анализа и верификации системных требований

  • Шаг 6.1 – Анализ требований. На этом этапе должны быть проанализированы системные требования, полученные на этапах 3-5, для определения их ясности, полноты, непротиворечивости и трассируемости обратно к требованиям заинтересованных сторон/системным, установленным в конце прошлого цикла проектирования.
  • Шаг 6.2 – Планирование верификации. Определите цели верификации, которые будут использоваться для проверки каждого системного требования. Каждая цель проверки должна определить методы, средства, оборудование и ресурсы, необходимые для выполнения верификации.
  • Шаг 6.3 – Создание базовой линии требований. Создайте базовую линию для требований в конце каждого цикла проектирования.

2.7  Этап 7 – Генерация документации для системы и элементов системы

  • Шаг 7.1 – Генерация отчетных документов.
    • Стандартизируйте внешний вид проектной документации, используя Document Publisher.
    • Все документы, которые могут быть сгенерированы на основе хранилища данных (Data Repository), должны быть созданы с использованием Document Publisher, а не вручную.
  • Шаг 7.2 – Генерация пакетов данных. Пакеты данных должны быть созданы на основе данных в хранилище проекта для поддержки рецензирования проекта (Project Review). Эти пакеты должны быть сгенерированы на основе данных из хранилища данных (Data Repository), а не созданы вручную.

2.7  Этап 8 – Трассируемость системной верификации и валидации (V&V)

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

  • Шаг 8.1 – Трассируемость верификации. Цель процесса верификации заключается в подтверждении, что системой выполняются указанные проектные требования (например, системные требования).
  • Шаг 8.2 – Трассируемость валидации. Целью данного процесса валидации является предоставление объективных доказательств, что услуги, которые предоставляются системой при использовании в соответствии с требованиями заказчиков, реализуют поставленные цели в соответствующем рабочем окружении.

3 Трассируемость в руководстве по системной инженерии INCOSE (v.3.2.2)

В этом разделе содержится схема, которая показывает трассировку между восьмью этапами процесса разработки и управления требованиями, описанными в данном документе  и  этапами технического процесса, описанными в Руководстве по системной инженерии INCOSE (v.3.2.2). Процессы, описанные в руководстве, соответствуют процессам жизненного цикла ISO / IEC 15288: 2008.

requirements_management_38

 

Процессы, описанные в этой статье, соотносятся с описаниями, которые содержатся в Руководстве по INCOSE в разделах: 4.1, 4.2, 4.3, 4.6, и 4.8. Трассировка показана в следующей таблице.

Раздел Описание задачи в руководстве INCOSE Cradle — 8 этапов разработки  и управления требованиями
4.1 Процесс разработки требований заинтересованных сторон.Цель этого процесса заключается в определении требований для системы, которая может предоставить услуги, необходимые пользователям и другим заинтересованным сторонам в определенном окружении.На этом этапе идентифицируются заинтересованные стороны, вовлеченные в процессы жизненного цикла системы, их потребности, ожидания и пожелания. Они анализируются и трансформируются в общий набор требований заинтересованных сторон, которые выражают предполагаемое взаимодействие системы с рабочим окружением и относительно которых будет проверяться каждый сервис системы.
4.1.2.1 Идентификация пользователей и заинтересованных сторон 1.1 — Определение границ проекта
4.1.2.2 Определение потребностей 1.1 — Определение границ проекта
4.1.2.3 Фиксация исходных требований 1.4 — Разработка требований заинтересованных сторон
1.6 — Проектные ограничения
4.1.2.4 Инициализация базы данных требований 1.5 – Планирование  валидации системы
1.7 — Захват определений понятий
4.1.2.5 Разработка концепции функционирования системы 1.2 — Разработка вариантов использования
1.3 — Разработка концепции функционирования системы
4.1.2.6 Генерация документа системных требований 7.1 – Генерация отчетных документов
4.2 Процесс анализа требований.Целью этого анализа является преобразование представления о системе в виде требований заинтересованных сторон в техническое представление продукта, который может реализовать эти требования. В ходе этого процесса формируется представление о будущей системе, которая будет отвечать требованиям заинтересованных сторон и, насколько позволяют ограничения, не зависит от конкретной реализации. Это приводит к разработке измеримых системных требований, которые, с точки зрения поставщика, определяют какими характеристиками и их величиной должна обладать система, чтобы удовлетворить требования заказчика.
4.2.2.1 Концепции анализа требований 6.1 — Анализ требований
6.2 — Планирование верификации
6.3 – Создание базовой линии требований
4.2.2.2 Характеристики хороших требований 6.1 — Анализ требований
4.2.2.3 Определение  целей и назначения системы 2.1 — Создание контекстной диаграммы
2.2 — Определение внешних интерфейсов
4.2.2.4 Определение, разработка и уточнение функциональных требований и требований к производительности  4.1 – Разработка функциональной   модели для первичного элемента системы
4.5 — Декомпозиция функций
4.6 — Декомпозиция функциональных требований и определение связей с функциями
4.2.2.5 Определение других нефункциональных требований 3.2 — Определение нефункциональных системных требований
4.2.2.6 Разработка  деревьев спецификаций 3.1 – Анализ исходной информации для элемента системы
2.2 – Определение внешних интерфейсов
3.3 – Определение подчиненных элементов системы
4.2.2.7 Привязка требований и установление трассируемости 4.2 — Разработка функциональныхтребований и определение связей с функциями
4.3 — Обеспечение трассируемости к исходным требованиям
4.2.2.8 Генерация спецификаций системы 7.1 — Генерация отчетных документов
4.3 Процесс проектирования архитектуры.Целью этого процесса является синтез решения, удовлетворяющего системным требованиям. Этот процесс формирует и определяет сферы решения, выраженного в виде набора отдельных проблем, управляемых, концептуальных и, самое главное, реализуемых. Он определяет и исследует одну или несколько стратегий реализации на уровне детализации в соответствии с техническими и коммерческими требованиями системы, и рисками. Исходя из этого, архитектурное решение определяется в терминах требований к набору элементов системы, из которых состоит система в целом. Указанные проектные требования, появляющиеся в  результате данного процесса, являются основой для проверки реализованной системы и для разработки стратегии сборки и проверки.
4.3.2.1 Концепции проектирования архитектуры 5.1 — Привязка функцийэлементам системы
5.2 — Определение физических интерфейсов между элементами системы
5.3 — Привязка нефункциональных требований элементам системы4.4 — Создание и связывание интерфейсных требований с определениями данных
4.6 Процесс верификации.Цель процесса верификации – подтверждение, что указанные требования проекта выполняются системой.Этот процесс предоставляет информацию, необходимую для осуществления мер по устранению недостатков, которые исправляют несоответствия в реализованной системе или процессах, которые в ней действуют. 8.1 – Трассируемость системной верификации и валидации (V&V)
4.8 Процесс валидации.Целью данного процесса является предоставление объективных доказательств, что услуги, которые предоставляются системой при использовании в соответствии с  требованиями заинтересованных сторон, позволяют достичь поставленных целей при использовании в соответствующем окружении. Этот процесс выполняет сравнительную оценку и подтверждает, что все требования определены правильно. Выявленные отклонения записываются и направляют корректирующие действия. Валидация системы утверждается заказчиками. 8.1 – Трассируемость системной верификации и валидации (V&V)

Добавить комментарий