Без заголовка

Это архитектура: модель операционного окружения (эксплуатирующей среды) системы со вписанной в нее моделью системы (как раз помянутые в конце холоны: матрешка систем). Другое дело, что инженер по требованиям интересуется социальной составляющей -- для него важны позиционеры в операционном окружении, и взаимоотношения между этими позиционерами. Устройство организации деятельности, конечно, инженер требований должен знать (кстати, в языки целей входят и tasks -- действия, которые нужно предпринимать, чтобы удовлетворять целям. Эти tasks описываются на чем-то типа упрощенных BPMN. Так что там с организацией все в порядке). Заодно знание "организации инженерного процесса" как таковой входит в общеинженерное умение, я об этом указал в самом начале текста. То есть общее знание про "организацию" в процессном заходе (ситуационная инженерия методов, являющаяся общей базой для ситуационной инженерии методов жизненного цикла, включая процессы использования системы) предусмотрено. Насчет полноты и согласованности системы требований: модель системы в системе ее окружения с оператором "должно быть так" и есть "система требований". У меня другая парадигма, у меня моделеориентированная системная инженерия, а не традиционная (со списком требований как набором деклараций о системе и развернутой моделью, удовлетворяющей этим декларациям: "набор требований Б--И--Р-А, сделайте модель системы! Модель системы: БЕЛИБЕРДА!". Для меня просто это модели системы разной степени подробности, сразу делаются в моделере. Стейкхолдерам предъявляются не тексты, а модели -- сразу, а не потом. Желательно модели делать в их присутствии, с их участием.