Николай Войнов в своем отзыве о ReqLabs 2011 еще  26 марта 2011 г. написал: "Собственно все прошло довольно хорошо - активно, весело, иногда задиристо. Но ощущение осталось немного странное. От конференции обычно ожидаешь чего-то нового, неожиданного; структурируешь и по новому осознаешь некоторые известные темы; уходишь с новыми идеями. Но ничего из этого не случилось... Вроде как и темы интересные, докладчики грамотные, и диалог состоялся. Но системности не было, выводы недостаточно четкие".  И привел для примера Рецепт работы с требованиями - завершающие главы из книги Принципы работы с требованиями к программному обеспечению. Унифицированный подход.(это Дин Леффингуэлл, Дон Уидриг).     Оригинал: Рецепт работы с требованиями

У Николая ссылка на файл в формате .odt, на всякий случай пусть этот текст будет здесь полностью.
Вряд ли в нем есть что-то новое. Просто форма достаточно четкая.

А к чему, уважаемый Николай привел цитату из книги? К тому, что он показывает нам, что все уже известно? что то, что используется далеко от идеальности? или вообще далеко? или нет ничего нового, что грустно?

гы ... это я себе шпаргалку сделал лет пять назад, так и валяется ... стройная просто

Управление требованиями - это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе.

На этом можно закончить чтение статьи. Попытка смешать процессы управления и разработки требований ведет к очень неприятным результатам. Часто фатальным.

Buenos días, amigo!

Сергей, может дадите тогда свое определение процесса управления требованиям?

Сергей, может дадите тогда свое определение процесса управления требованиям?

Ага, мне тоже интересно узнать твое определение "управление" и "управление требованиями" , в частности.
Некоторые ссылки: http://habrahabr.ru/blogs/development/114571/

Для того, чтобы определение "легло" нужно работать в одном ментальном поле. А потому прежде чем чего то определять, предлагаю посмотреть CMMI.

Requirements Development - Process Management
Requirements Management - Project Management
Это в частности означает, что управлением и разработкой занимаются разные люди. Попытка отдать управление требованиями инженеру-аналитику может иметь фатальные для проекта последствия.
Проверено. Имеет. Как минимум, очень неприятные.

Requirements Development - третий уровень
Requirements Management  - второй уровень
Это в частности означает, что управление тербованиями нужно ставить до разработки требований. В противном случае - это выкинутые деньги. Чато это делают наоборот. С известным результатом. Попытка отстроить разработку требований без отстраивания управления требованиями может иметь фатальные для проекта последствия.
Проверено. Имеет. Как минимум, очень неприятные.

Спасибо, Сергей, за точку зрения. Но ты не ответил на вопрос Николая, дай свое определение управлению требований.
В чем ты не согласен с определением RUP?