Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Управление требованиями

Если до сих пор мы в PraxOS рассматривали системную инженерию как набор подходов (системного, процессного, архитектурного и т.д.), то традиционное рассмотрение системной инженерии проходит именно в рамках нескольких предметных дисциплин -- управления требованиями (requirement management, requirement engineering), управления жизненным циклом (подразумевающее следование какой-то определенной refence process model и прохождение доказательств и синхронизаций при переходе от стадии к стадии), архитектурный синтез (означающий обязательное использование высокоуровневых описаний системы, абстрагированных от ее материального воплощения) и т.д.

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

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

Управление требованиями нельзя свести к какому-то одному процессу системной инженерии (например, в ISO 15288 такого процесса нет). Управление требованиями затрагивает все части Vee-диаграммы:
-- требования собираются
-- требования анализируются
-- инженерные решения трассируются к требованиям
-- на этапах проверки и приемки (верификации и валидации) обеспечивается доказательство (evidence) выполнения требований (assurance case)
-- требования передаются между сторонами при приобретении и поставках.

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

Поскольку системная инженерия подразумевает рекурсивное и итеративное использование процессов, то состав и содержание требований непрерывно изменяется. Для требований используется управление конфигурацией (учет изменений состава и содержания требований), обеспечиваемые специальным типом учетных систем -- IT-системами управления требований (DOORS, CaliberRM, IRQA, MKS Integrity, Rational RequisitePro и т.д.). Не нужно обращать внимание на то, что большинство этих IT-систем затрагивает работу с требованиями в программной инженерии. Миры системной инженерии как целого и программной инженерии как частного стремительно сближаются, и в большинстве случаев инструментарий (IT-системы, процессные стандарты, оценка процессов и т.д.) программной инженерии могут быть использованы и для системной инженерии в целом (включая вопросы создания киберфизических систем и человеко-системной интеграции).

Учитывая то, что отдельные (элементарные) требования выступают в самых разных ролях по отношению к другим требованиям, а также другим элементам системы, ее описаниям и моделям, поддерживаемые этими IT-системами онтологии довольно велики. Связь IT-систем управления требований друг с другом (нельзя ожидать, что в крупном проекте системной инженерии управление требованиями проходит в границах одной организации, и ограничится использованием только одной IT-системы управления требованиями) и с другими IT-системами (поддерживающими, например, facility model и project model, системами АСУ ТП и т.д.) происходит классическим образом -- с использованием mapping через общую онтологию. Поэтому изучать дисциплину управления требованиями лучше сразу в терминах такой нейтральной по отношению к используемым IT-системам онтологии.

Есть несколько главных кандидатов на описание общепринятой онтологии управления требованиями:

1. Специализированные стандарты управления требованиями (например, Requirement Interchange Format, используемый немецкими автостроителями -- (http://www.automotive-his.de/rif/doku.php?id=welcomeeng, текущая версия RIF 1.2 -- http://www.prostep.org/fileadmin/freie_downloads/Empfehlungen-Standards/ProSTEP_iViP/PSI6_RIF_1.2_Mapping-Table.pdf). Это представляется лучшим вариантом на сегодняшний день -- стандарт отражает текущую лучшую практику, обобщенную по нескольким коммерчески успешным IT-система поддержки требований. Это относительно свежий стандарт, первый его драфт датируется февралем 2005г. Читать его будущим специалистам по управлению требованиями невозможно, ибо этот стандарт сделан программистами для программистов.

2. Cтандарты интеграции данных жизненного цикла (например, ISO 15926 или Gellish). По большому счету, это то же самое, что RIF, но при сегодняшнем состоянии дел по развитию данных стандартов можно априори считать, что качество онтологии управления требованиями в этих стандартах может оказаться ниже, чем приемлемо для специалистов по управлению требований. Однако, переход от "стандартов одной дисциплины" типа RIF к "междисциплинарным" стандартам интеграции данных типа ISO 15926 является магистральной линией. Одна из актуальных на сегодня задач системной инженерии -- это обеспечение в RDL ISO 15926 полного функционального аналога RIF.

3. Онтология требований, встроенная в язык системной инженерии SysML. Увы, этой онтологии совершенно недостаточно, даже если скрестить RIF и SysML, как это предлагается в http://www.omg.org/docs/syseng/08-06-07.pdf. Выражение требований, совмещенное с архитектурными диаграммами, подходит только для тривиальных случаев, и очень плохо масштабируется для больших систем. Несмотря на то, что SysML является чуть ли не обязательным языком системной инженерии по версии INCOSE, использование этого языка для архитектурной работы с очень большими системами, а также выражение на нем требований в PraxOS не рекомендуется.

С управлением требований связаны не только форматы представления самих требований, но и форматы доказательств (decision gates, предполагающие демонстрацию evidence выполнения требований). После длительной дискуссии в качестве метода представления результатов выступает assurance case (подробнее см. http://ailev.livejournal.com/578461.html, основной стандарт ISO 15026). Так что представление assurance case как структурированного набора claims, arguments и evidence таже входит в управление требованиями. Более того, системная инженерия рекомендует сегодня, чтобы assurance case создавался на самых ранних стадиях работы и непрерывно поддерживался в актуальном состоянии, и проверялся при каждом доказательстве при переходе от одной стадии ЖЦ к другой. Современное стояние дел в области доказательства выполнения требований в форме такого предписанного артифакта, как "assurance case": https://buildsecurityin.us-cert.gov/swa/downloads/WG_Outbrief_Croll.pdf -- полным ходом идет становление новой предметной области.

Assurance предлагается считать частью управления требований, а IT-cистема управления требованиями тем самым является одновременно и системой обеспечения assurance (поддержки артифакта assurance case). Дискуссию о том, как отображается assurance на валидацию и верификацию мы тут разворачивать не будем -- но это проблема, требующая своего решения.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 38 comments