Читая Рамбо и Блаха "UML 2.0 Объектно-ориентировнное моделирование и разработка" и составляя лекции студентам по объектно-ориентированному анализу, столкнулся с проблемой терминологического характера.

Авторы (использую только русский перевод) выделяют две стадии этапа анализа: анализ предметной области и анализ приложения.

Насчет анализа приложения Денис-Майевтик как-то высказался в том смысле, что не понятно, как можно анализировать то, чего нет.

Внимательное прочтение трудов великих авторов дает пояснение этому вопросу.

Приведу полную цитату стр. 204

Этап анализа делится на две стадии. Сначала осуществляется анализ предметной области, а затем — анализ приложения. Анализ предметной области применяется к объектам реального мира, семантику которых охватывает приложение. Например, рейс самолета — это объект реального мира, который должна отражать система бронирования билетов. Объекты предметной области существуют независимо от приложений и имеют смысл для бизнес-экспертов. Эти объекты выявляются во время анализа предметной области или исходя из априорных соображений. Объекты предметной области в модели несут информацию об объектах реального мира и обычно являются пассивными. Анализ предметной области выделяет понятия и отношения, а функциональность при этом неявным образом содержится в модели классов. Конструирование модели предметной области сводится, главным образом, к принятию решений о том, какую информацию следует отразить в модели и как ее нужно представить.
За анализом предметной области следует анализ приложения, который относится к компьютерным аспектам приложения, видимым пользователям. Например, меню бронирования билета является частью системы бронирования авиабилетов. Объекты приложения существуют не в предметной области. Они имеют смысл только в контексте приложения. Однако эти объекты не являются чем-то внутренним по отношению к проекту, потому что их видят пользователи. Объекты приложения должны полностью удовлетворять пользователей. Модель приложения не предписывает конкретной реализации системы. Она описывает внешний вид приложения, которое воспринимается как черный ящик. Классы приложения нельзя определить на этапе анализа, но их часто можно взять из предыдущих приложений. В противном случае объекты приложения приходится придумывать на этапе анализа, как часть интерфейса с другими системами и с пользователями.

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

При этом, если слово "приложение" заменить на "система", то получим анализ системы или системный анализ.

Последнее словосочетание не слишком однозначно для русского и несет особую историческо-философскую нагрузку.

Цель этап анализа является построение аналитической модели и уточнение и утверждение требований к системе.

Может не имеет смысла делить этап анализа на анализ предметной области и анализ приложения (системы)?

Кто тогда видит это иначе и может предложить для обсуждения?

А Бизнес анализ и системный анализ и соответствующие модели, - это не то??

А Бизнес анализ и системный анализ и соответствующие модели, - это не то??

Про системный анализ я уже высказался. Ты что конкретно вкладываешь в это понятие?

Бизнес-анализ очень двоякий термин и имхо не равен анализу предметной области.

Про системный анализ я уже высказался. Ты что конкретно вкладываешь в это понятие?

Я вкладываю в эти понятии дисциплины РУП.

Бизнес-анализ очень двоякий термин и имхо не равен анализу предметной области.

Почему?

Странная у тебя манера отвечать вопросом.
Ну не хочешь делится мыслью. Может кто другой выскажется.

Термин бизнес-анализ мне не нравится в приницпе. В литературе я часто встречаю бизнес-аналитик = аналитик требований.

Потому бизнес-анализ читай анализ предметной области.

Я же рассуждаю несколько о ином

В литературе разброд и шатания. Да еше BABOK добваил энтропии :-). Переплетение бизнес-анализа и системного анализа (в контексте разработки ПО) происходит из-за ERPшников, у которых есть бизнес-процесс (которым занимается бизнес-аналитик) и есть, опа, техническое решение, которое автоматизирует этот БП. А консультант по SAP должен по-идее быть экспертом в предметке + уметь настраивать соответствующие модули. Требования как таковые им особо не нужны.
Лично я склонен использовать понятия RUP  для этого. Бизнес-анализ,  это все что связано с анализом именно бизнес-процессов. А бизнес-процессы могут быть и без использования ИТ как таковых. Анализ предметной области -- это по сути пляски вокруг domain model. Т.е. направленное уже больше в сторону разработки ПО активность, связанная с переводом понятий бизнеса на рельсы ООАП.

Хорошая мысль -- сделать обзорную статью на эту тему, в которой дать обзор методологий, стандартов в которых встречается понятие бизнес-анализа и бизнес-архитектуры (а это уже скорее ближе к EA и TOGAF/DoDAF/...) и про требования и системный анализ. После чего предложить собственное (комбинированное?) виденье того, что есть бизнес-анализ, а что есть требования и системный анализ.

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