Второе поколение инженерии требований
Опубликованы minutes к шестнадцатому заседанию INCOSE, на котором puln докладывал о системах управления требованиями (СУТ) в системной инженерии -- http://community.livejournal.com/incose_ru/9396.html. Там есть ссылка на два часа видео (в принципе, видео могло быть и больше, только при подключении флешки для демонстрации пары специально припасенных одним из участников обсуждения слайдов был выдернут шнур камеры для освобождения USB-разъема. В пылу дискуссии это не было замечено).

Обсуждение споткнулось на понимании того, как СУТ обслуживают работу с требованиями на схеме V-диаграммы



Это классическая схема из всех учебников по инженерии требований, но тут она дана не в разрезе инженерии требований в целом, а с точки зрения маленькой части: управление требований. Встал вопрос, как используется СУТ в части 1. обеспечения соглашений (включая практики инженерии требований и квалификации), и 2. обеспечения архитектурного проектирования, реализации, интеграции и испытаний.

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

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

Моделирование самих требований еще не завоевало место под солнцем. Так, классики "текстовых требований" для систем типа DOORS пишут (http://download.boulder.ibm.com/ibmdl/pub/software/dw/ru/download/eBook_RU_Requirements_Engineering.pdf), что "Некоторые употребляют термин «моделирование требований». Это термин является неверным по сути. Моделируется реализация системы, а не требования к ней". У классиков СУТ старого поколения модели отдельно, а требования -- тоже отдельно.

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

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

Факт X становится требованием, когда записано "должен быть X" или "может быть X". Подробно об этом можно почитать в диссертации Andries Van Renssen, который подробно про это рассказывает для факто-ориентированного описания Gellish (http://repository.tudelft.nl/file/313741/306185). Абсолютно аналогична ситуация со всеми современными САПР (замечание в сторону: Gellish планируется на сегодня как ISO 15926-11, но выход этой части стандарта будет позже, чем в 2010 году. С другой стороны, ISO 15926-7 определяет фактоориентированное описание, в противовес атрибутному на EXPRESS и OWL. Так что все сказанное относится и к ISO 15926. Более того, все сказанное верно и для других концептуальных схем, используемых в современных САПР от Dassault Systemes, Intergraph, Bentley, AVEVA и т.д.).

Приведем ссылку на статью еще одного геллишевца Leo van Ruijven -- Requirement management, traditional and a second generation scenario, 2006г.. В этой статье прямо говорится про второе поколение управления требованиями.

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

Итак, моделирование, появившись, съедает традиционную работу с огромными списками текстовых требований, требовавших специализированного документооборота. Заинтересованные стороны в model-driven requirement engineering честно при этом говорят (Software & Systems Requirements Engineering: In Practice, by Brian Berenbach, Daniel J. Paulish, Juergen Kazmeier, Arnold Rudorfer. ): "В зависимости от изощренности используемого инструмента моделирования, полная реализация URML может позволить организации проводить большинство мероприятий инженерии требований c URML [моделями], порождая по потребности без специальной о том заботы такие артефакты, как документы или спецификации требований" ("Depending on the sophistication of the modeling tools used, a full implementation of the URML would permit an organization to do most of its RE activities with a URML, generating artifacts such as documents or requirement specifications as needed on an ad hoc basis").

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

Я утверждаю, что при смене управления требованиями существенно поменяется и сама инженерия требований, управление требованиями в которой является важной (и даже определяющей) составной частью, но явно не единственной. Главные практики дисциплины инженерии требований (дисциплина = объединенный общей предметной/domain онтологией набор практик) по проекту ISO/IEC 29148 "Инженерия требований", это определение требований заинтересованных сторон, и анализ требований. Управление требований определяется (наряду с ) как "Управление требованиями объединяет те дела, которые записывают и сопровождают становящиеся требования и возникающие из [выполнения] мероприятий инженерии требований связанные исторические сведения и сведения о контексте. Управление требованиями таже устанавливает инструкции для определения, контроля и публикации базисов требований для всех уровней [структуры] целевой системы. Результативное управление требованиями происходит в контексте организационных и технических практик, как это определено в ISO/IEC 15288 и ISO/IEC 12207 (Requirements management encompasses those tasks that record and maintain the evolving requirements and associated context and historical information from the requirements engineering activities. Requirements management also establishes procedures for defining, controlling, and publishing the baseline requirements for all levels of the system-of-interest. Effective requirements management occurs within the context of an organization's project and technical processes as defined in ISO/IEC 15288 and ISO/IEC 12207).

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

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

Я думаю, что этот подход "электронной работы с ранее бумажными требованиями" прошлое поколение, хотя и с модными словами типа URML, Unified Requirement Modeling Language. В классификации Dassault Systemes -- это PDM, product data management. Есть данные, мы не интересуемся, какие они по сути (у них собственная схема данных, которая открыта, если они нам специально потребуются в другой информационной системе), и мы обеспечиваем их надлежащее хранение и выдачу по особым запросам. PDM -- это не про интеграцию данных, это про interoperability, когда легко обеспечить незначительным программированием взаимодействие двух каких-то указанных информационных систем. Например, системы требований и 3D-САПР. Системы требований, и P&ID САПР. Беда в том, что этих разнообразных САПР развелось очень много, со всеми систему управления требований не насвязываешь. Интеграции данных (произвольная выборка данных из разных хранилищ, обеспечиваемая внешней библиотекой справочных данных) при таком подходе прошлого поколения нет.

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

Это все не исключает инженерии требований как содержательной дисциплины: в любом случае, нужно выявлять и анализировать то, что нужно, кому нужно, когда нужно, зачем нужно, как эта потребность удовлетворяется, как проверяется соответствие этой потребности и т.д.. Для этого все равно нужно иметь специальный инструментарий, способный отобразить эту группу описаний -- "система управления требованиями", конечно, нужна, как нужна "система управления геометрией" ("геометрия" -- это 3D описания, к ним обычно привязываются и все остальные описания, т.е. P&ID, electrical etc.). В современных САПР есть много разных domain specific languages со своими редакторами, для группы описаний, затрагивающих аспект "долженствования" тоже может быть спец.редактор, связанный с 3D-описанием примерно так же, как P&ID. Его и назовем СУТ второго поколения, которая будет работать со специфической моделью данных "деонтики", связанной с фактами всей модели системы (а то еще и моделями обеспечивающих систем -- организационной моделью, например). Весь вопрос в том, как эти ранее stand-alone редакторы потихоньку сползаются в единую коллаборативную интерактивную среду, поддерживающую множество предметно-специфичных языков: 3D-описания, описания диаграмм P&ID, описания требований в их деонтической части и т.д.. Сначала полностью автономные системы, потом в рамках "семейств САПР" (Dassault Systemes V5, Intergraph SmartPlant Enterpise и т.д.) обмен файлами при "публикации" в "репозиторий-со-схемой", использующийся для многих уже по факту полуавтономных САПР -- это поддерживают сейчас практически все поставщики САПР. Позже -- непосредственная работа с общим репозиторием, пока из "больших" систем это реализовано только у Dassault Systemes. См. обсуждение технологий этого обеспечиваемого онтологическими технологиями слияния в http://ailev.livejournal.com/748188.html.

Если поглядеть не только на сбор-анализ требований и проектирование-конструирование, но и на изготовление, то нужно обратить внимание тренд к унификации языка для представления цепочки "требования-->набор моделей-->программа для изготовления на станках", который обсуждается в подходе порождающего производства (Stephen Fox, Generative Production Systems for sustainable product creation, 2009, http://www.vtt.fi/inf/pdf/workingpapers/2009/W129.pdf).

Аналогичные тренды по изменению работы с требованиями наблюдаются не только для САПР "железных" и "железобетонных" систем, но и в других классах информационных систем. Например, для явное выделение проблемы инженерии требований для организаций-систем проходит в другой терминологии (business rules, см.Манифест организационных норм http://ailev.livejournal.com/693597.html), но по сути представляет собой все то же самое: начав с заявления о том, что "к организации есть требования, и системы работы с этими требованиями должны быть семантическими, а не "полнотекстовыми", авторам пришлось признать, что "требовательная" часть занимает всего 15% от объема предлагаемого ими стандарта моделирования требований (OMG SBVR, Semantic Business Vocabulary and Rules, http://ailev.livejournal.com/692588.html), а все остальное посвятить описанию способа моделирования фактов об организации, который затем предполагается использовать во всех "частных" (аналогичных "частным" САПР в машиностроении) моделях. В принципе, этот ход приводит к новому пониманию архитектуры предприятия (Enterprise Architecture), где собственно архитектуру предприятия начинают, наконец, отклеивать от архитектуры IT-систем предприятия, и вставлять в более общий ряд моделей -- требования-архитектура-"модель для изготовления"-"модель as build с историческими данными". Старые архитектурные подходы (все эти TOGAF, "по Захману" и т.д.) трещат по всем швам, хотя и представляют собой такой же нынешний мейнстрим, как "управление требованиями с использованием DOORS и IRqA".

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

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

Так что задачей является создание методологии/дисциплины инженерии требований, соответствующей современной моделе-ориентированной системной инженерии (http://ailev.livejournal.com/728605.html). Для моделирования инженерии требований используем ситуационную инженерию методов -- http://ailev.livejournal.com/750878.html. И положим это все кирпичиком в PraxOS.