Мне кажется, здесь изначально есть некоторая терминологическая путаница. Если мне не изменяет память, в терминологии ГОСТ модуль - это элемент конфигурационного управления, в то время как подсистема - часть архитектурного деления системы. Поэтому лично я хотела бы спросить у Павла, что же именно его интересует: разбиение системы на модули (и, соответственно, реализация требований к конфигурируемости создаваемого ПО) - или выделение подсистем для разрабатываемой системы.

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

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

Если мне не изменяет память, в терминологии ГОСТ модуль - это элемент конфигурационного управления, в то время как подсистема - часть архитектурного деления системы. Поэтому лично я хотела бы спросить у Павла, что же именно его интересует: разбиение системы на модули (и, соответственно, реализация требований к конфигурируемости создаваемого ПО) - или выделение подсистем для разрабатываемой системы.

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

До этого момента смутно предствлял, что такое конфигурация, в частности объект конфигурации. Нашёл ответ (ссылка на источник):

- Программная конфигурация – набор функциональных и физических характеристик программного обеспечения, сформулированная в документации или воплощенная в продукте (см. IEEE 610.12-90, Standard Glossary for Software Engineering Terminology). Программная конфигурация может рассматриваться как составная часть общей системной конфигурации.
- Элемент программной конфигурации (software configuration item, SCI) – фрагмент программного обеспечения, вовлеченный в процесс конфигурационного управления и рассматриваемый как одна (атомарная) сущность в рамках SCM-процесса (см. IEEE 610.12-90). Программные элементы, потенциально полезные в качестве элементов программной конфигурации (SCI), включают планы, спецификации и документы (например, полученные в результате моделирования и проектирования), программные инструменты, исходный и исполнимый код, библиотеки кода, данные и словари данных, а также документацию по установке, сопровождению, эксплуатации и использованию программного обеспечения.

Вот ещё: "Конфигурационные объекты (КО) могут представлять собой стол или самолет, если рассматривать оборудование, или программные средства в виде инсталляционных пакетов, если речь идет о программных средствах."

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

Наталья, похоже, это именно то, о чем я хотел сказать.

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

Как я понимаю, HLA - это высокоуровневый анализ.
То есть, получается, если предполагается создавать большую систему (например ERP), логично и необходимо делить её на подсистемы. Но, при этом, для аналитика достаточно указать логику взаимодействия и передачи данных из одной подсистемы в другую.

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

Хотя, назревает вопрос:
- А как связать требования к модулям с пользовательскими требованиями (ВИ)?

Коллеги, возможно покажется, что каша в голове, но, желаю, в конце концов, разобраться в данном вопросе.