Системный подход в управлении требованиями

Интересно, жду продолжения.

«который beeos будет вести на РИКе 28-29 июля» — а может это всё-таки в «Я пиарюсь?» а то тема не раскрыта (подобные общие фразы можно найти во многих стандартах, например том же CMMI), а есть только реклама события, или я не прав?

Кар Вигерс, например, кроме бизнес и функциональных требований выделяет еще нефункциональные. Короче, ваши мысли конечно же не «открытие» какое-то. Хотя, возможно, будет что-нибудь интересное из жизни. В любом случае, вы, явно правы в том, что анализ требований — наиболее рискованная часть разработки, которая требует особого внимания.
Интересен так же каким будет ваш взгляд на «специфику» интернет-проектов.

Тема интересная, но в статье вообще нет смысла. Можно было заменить на одно предложение «Мы придумали универсальную методологию и расскажем ее за деньги там-то.»

Управление требованиями — это:
1) управление рамками проекта и релиза — что в него включать, что не включать
2) управление статусом готовности продукта — трекинг состояния отдельных требований
3) управление трассировками требований между собой
4) управление трассировками требований на другие учётные единицы проекта — тесты, архитектурные модели, задачи, код

Зачем тут нужна методология? Что тут методологировать?