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

А какова цель, преследуемая этим описанием, и кто будет потребителем результата?
Исходя из этого и следует описывать.

Если вас никто не направит к более современным документам, попробуйте посмотреть  ГОСТ 19 и 34. Понимаю, что пользоваться ими непросто, но это лучше, чем совсем ничего.

Стоп. 474 задал правильный вопрос - кто потребитель. Давай дождемся ответа.

А чисто гипотетически можно предложить нарисовать Д взаимодействия м\у элементами и текстом описать входящие\выходящие данные и правила трансформации

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

Чего только не напридумывает руководство различного уровня и заказчики :-). Главное назвать это громко -- "Архитектура <чего-то>" ... слово-то какое наукообразное!
Вобщем именно такой архитектуры "обмена данными", как таковой, не существует. Более того, не вполне понятно назначение такого документа.
 По классике выделяют бизнес-архитектуру, архитектуру информации и данных, архитектуру приложений (и в ее рамка программную архитектуру) и технологическую архитектуру. Иногда отдельно выделяют т.н. архитектуру безопасности, хотя по мне она "размазана" по всем вышеперечисленным архитектурам и выделять ее отдельно нет смысла -- просто остальные архитектуры следует проектировать с учетом требований информационной и прочей безопасности.  Следовательно, некоего стандарта на именно такого рода ДОКУМЕНТ не следует ожидать.
По сути, обмениваться данными может либо бизнес-процесс, либо какие-то информационные системы, зачастую в рамках некоего бизнес-процесса (если речь не идет о бакапах и прочих "технических" делах ...). Кроме этого, архитектура призвана в статической своей части показать интерфейсы различных компонент и в динамической части -- в рамках чего и каким образом эти компоненты взаимодействуют. Очевидно, что в процессе взаимодействия будет происходить обмен данными, который можно явно выделить.

Говоря о нотациях, можно использовать различные подходы -- от DFD, до UML Activity with object flow и Sequence\collaboration ...

vacoola, Вы ведь подобный вопрос уже задавали здесь недавно? В чем смысл повторения?

Объединил две темы

Для начала, извините за повторение. Думал что никто не отвечает и написал еще раз. Проверял по RSS правда.

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



 

Возьмите для этого SRS. Там как раз будут и цели проекта и ФТ и БПр и НеФТ. + еще нарисуйте диаграмму взаимодействия между системами, в ФТ укажите что нужна такая-то передача данных между такими-то Системами и ссылка на раздел БПр, где будет расписаны правила трансформации данных.