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

Хочу в целом по посту прокомментировать. Я пробую отнестись к практике на предприятии после какой-то работы по ее внедрению как к решению (в смысле solution по Essence). Причем этот Solution собирается из кусков некоторой эталонной практики (дисциплины, описанной в стандартах и книжках; инструментов с рынка), изрядно подкрученной под потребности (needs, другие opportunities). Причем stakeholder needs относится к system definition как один к многим (то есть, для одной need может быть бесконечное число system definition). И вот если так смотреть, то у заинтересованных сторон в потребностях никогда не появится инженерия требований: этого не бывает в области проблем (я думаю, можно смотреть на customer area of concern как на область проблем). Зато в области решений под какую-то проблему может быть воткнута изрядно подкрученная инженерия требований. При этом понятно, что, возможно, кто-то наблюдал у заинтересованных сторон потребность, которую можно было бы закрыть подкрученной инженерией требований (пусть и не той, которая фронтирная). Я-то инженерию требований воспринимал в основном вместе с общением с заинтересованными сторонами (то есть - пойти зафиксировать потребности, переварить их в определение системы). Потребности для этого как раз я и не замечал. А всё, что касается аккуратного хранения уже зафиксированных требований (например, авиационных правил для авиации или каких-то других сводов сертификационных требований - которые существуют вне конкретного объекта), мне непонятно как закрыть инженерией требований с ходу. Я наблюдал потребность в хранении этих сводов не в виде документов, а в виде требований (то есть, решением было бы распарсить документ на требования, каждое требование было бы в какой-то базе уникальным и это требование крепилось бы к чему-то в настоящей системе). Но непонятно, что здесь от инженерии требований. То есть, это не та потребность, которую инженерией требований можно закрыть.