Тем не менее, стало окончательно ясно: срочно нужно сделать онтологию/метамодель/модель предметной области/модель данных/схему (ах, сколько разных школ про одно и то же!) артефактов/рабочих продуктов системной инженерии -- требований, архитектурных описаний, планов и т.д..
Ибо во всех работах про activity models и business rules стоит стон про отсутствие возможности нормальной онтологической работы: артефакты/рабочие продукты и их свойства оказываются плохо выразимы без онтологии, а практики/методы и процессы/проекты после этого "висят в воздухе".
Для примера: онтология (в данном случае информационных) артефактов предметной области такой дисциплины, как инженерия системной архитектуры (по версии MFESA, 136 страница из книжки, дважды кликабельно. Ну, а книжку найдите в Сети сами, это вам упражнение на сообразительность. Кто не нашел, пусть довольствуется презентацией http://www.sei.cmu.edu/library/assets/mfesatutorialoneday20090420.pdf):
Вот это все и нужно как указывать в качестве исходных и конечных продуктов стадий и активностей, так и отождествлять с болтающимися в репозиториях САПР информационными моделями объектов (OIM из ISO 15926).
Попробуем-ка мы пополнить глобальный RDL такой онтологией, да еще и в двух языках. Знатное будет упражнение.
Затем нужно озаботиться метамоделью, в которой можно выражение процесса (проектной = функциональной группировки работ и процессной = технологической группировки работ) увязывать с этими артефактами. И тоже грузануть в RDL (это означает, что в RDL для начала как минимум нужно будет грузануть метамодель BPMN 2 -- последовательность операций ведь нужно как-то обозначать).
А потом нужно будет понять, как из этого сделать целостную метамодель ситуационной инженерии методов, в которой проектная, процессная, организационная и артефактная (целевая) группы описаний/метамодели слились в едином порыве -- и придумать для этого нотацию.