Не совсем уверен, что правильно пониманию внешние проектные роли. Предположим целевая система это велосипед, на котором катается велосипедист. Моя функция, например, создать руль для этого велосипеда и передать в команду по сборке велосипеда.
Мои внешние проектные роли для проекта создать руль получается будет команда по сборке велосипеда (соединяльщик руля с остальной частью, принимающий качество руля).
С другой стороны, функцию велосипеда задаёт велосипедист и он тоже внешняя проектная роль.
Да. Если команда разработчиков для вас - внешняя, то есть вы не в команде (ориентируюсь на “передать”).
Как-то отвечал на подобный вопрос:
Может помочь такое правило:
Система не существует без Надсистемы.
И их всегда нужно рассматривать в паре.
Для случая руля велосипеда (дальше-РВ) , какие могут быть пары система-надсистема?
Варианты:
В каждом варианте - различные Надсистемы и различные внешние проектные роли, у которых могут быть свои предметы интересов.
Т.е. начать стоит начать с определения пары или пар система-надсистема, в рамках которых Вы мыслите.
Вы для руля велосипеда написали не надсистемы (рассматриваемые в момент использования руля, отношение часть-целое между системой и надсистемой), а практики систем создания (момент создания руля и монтажа его в надсистему), причём даже не системы-создатели (отношение создания), а практики этих систем – но в случае конструкторского бюро это подразделение, а не практика (конструирование).
Вы курс “Моделирование и собранность” проходили? Он обязателен как пререквизит для курса “Системное мышление”. Там учат присвоению типов и проверке по типам. Вот тут проверка по типам отношений и типам указанных вами объектов не проходит.