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

Про стейкхолдеров вы не все правильно понимаете. Главная задача системного инженера -- это обеспечить переговоры между стейкхолдерами, снимающие между ними противоречия. Считается, что люди разумные, и могут договориться. Придумывание технических решений для удовлетворения противоречивых требований является только маленькой частью. Вы по-прежнему считаете, что много-много маленьких лодочек выкачают нефть со дна моря или много-много моделей ракет вдруг доставять пару тонн груза на Луну. Нет, такого не бывает. Размер имеет значение. Это не значит, что в таких проектах не принимают участие тысячи и тысячи маленьких (да и больших) фирм. Роль планирования не преувеличена, когда вам нужно получить нефть со дна морского, или построить мост. Не будете планировать, в последний момент может не хватить секции моста: сам он поперек реки не соберется, сами по себе нужное число секций не будут изготовлены, много-много маленьких фирм без заказа никогда не начнут вдруг производить этот мост. А если они "договорились", то есть кто-то, кто их договаривал -- и договорился заодно о проекте и деньгах. Он и есть обычно заказчик (а по-западному owner). Проекты бывают хорошие и плохие, методы разработки бывают "все требования в начале" и "все требования по ходу дела". Рыночный успех вовсе не означает хорошего продукта, хороший проект вовсе не означает хорошей его реализации, хорошие требования вовсе не означают, что по ним будет сделано что-то достойное. Собственно, я об этом и говорю: нужно много чего предусмотреть, чтобы проект оказался хорошим -- а потом еще и иметь дисциплину соблюдения всего предусмотренного. В хороших методологиях разработки (т.е. в системной инженерии) предусмотрено, что требования меняются в течение всего хода проекта. Более того, в хорошей методологии говорится о разных (минимально -- трех) видах требований и разных процедурах проверки: верификации и валидации как минимум. Ваш пример с SAP эмоционален, но кто-то должен придумать альтернативу этой убогой серости. Если альтернатива неизвестна, будете пользовать SAP -- ну, или укажите, что можно использовать для нормального решения тех задач, которые ставят перед этой системой управленцы (и тут выяснится, что проблема в самой постановке задачи. Но это уже выходит за предмет обсуждения "плохого SAP", так ведь?).