Для требований в целом необходимо построить OIM (object information model -- из ISO 15926, метамодель -- из OMG, абстрактный синтаксис -- в language workbenches, "рабочую онтологию" -- из СМД-методологии), которая будет выражаться в разного сорта диаграммах (не обсуждается в ISO 15926, диаграммы -- в OMG, конкретный синтаксис -- в language workbenches, схемы в СМД-методологии), адресующих разные группы описаний. Эту метамодель нужно будет затем выразить в терминах объемлющей онтологии (онтологии интеграции данных) -- в нашем случае в ISO 15926.
Для этой работы выражения OIM требований в ISO 15926 нужно будет разобраться со специфически онтологическими вопросами: где мы говорим о создании экземпляра модели требований, согласно метамодели, а где речь идет только об уточнении требований, а где сами проектные решения или даже реализованная (т.е. реальная) по этим проектным решениям система (для случая системной инженерии требований эта работа выполняется прямо сейчас на базе находок стандарта ISO 24744 в проекте PraxOS -- http://praxos.livejournal.com/. Скорее всего, для требований придется делать аналогичный проект -- и решать абсолютно аналогичные задачи (ибо для требований, как и для методов могут быть использованы совершенно разные специфические предметные онтологии, зависящие от конкретной ситуации, к которой прилагаются "типовые" решения. Требования также могут быть повторноиспользуемыми и "типовыми", и т.д.).
Тут еще нужно подумать, как OIM собственно требований (в инженерии требований это OIM для product model) связано с OIM инженерии требований в целом как метода (где product model является только частью общей модели, а кроме того как минимум есть process model, project model, organizational model инженерии требований).
Поэтому я бы поставил в план работ по PraxOS переинтерпретирование моего позавчерашнего поста про моделе-ориентированную инженерию требований (http://ailev.livejournal.com/801113.html) в духе сказанного в данном тексте. Моделе-ориентированную инженерию требований нужно моделировать, сапожник должен быть в сапогах.
По итогам моделирования, конечно, нужно будет переопределено и уточнено содержание дисциплины "инженерия требований" (предыдущий немоделеориентированный вариант был собран тут: http://ailev.livejournal.com/769827.html) -- для современного варианта моделе-ориентированной инженерии требований (http://ailev.livejournal.com/801113.html, причем с учетом переинтерпретации из предыдущего абзаца. То есть работа будет весьма итеративной).
Затем все то же самое нужно будет проделать с OIM инженерии системной архитектуры -- с учетом того, что само понятие системной архитектуры как продукта работы намного хуже определено, чем понятие требований. Но глаза боятся, руки делают.
