Александр Байкин, ведущий аналитик и консультант, UML2.ru  Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт   Данная статья рассказывает о пяти уровнях модели зрелости для управления требованиями и дает рекомендации по постепенному улучшению процесса управления требованиями. Данная модель сопоставима с моделью технологической зрелости организации (CMM - Capability Maturity Model), но дает расширенные рекомендации для дисциплины управления требованиями.        Оригинал: Пять уровней зрелости требований

Коллеги, bas в сооавторстве с Александром Новичковым опубликовал на  ibm.com статью, которая дает рекомендации по поэтапному внедрению «правильного» процесса управлениями требованиями. Читать всем!

Читаем!!!

По поводу вводной диаграммы про то, что большая часть ошибок содержится в требованиях.

Согласно последним исследованиям идеологов программной инженерии, это не так:
http://www.semat.org/pub/Main/PubsandRefs/software_quality_survey_2010.ppt

Кроме того, странно, что изменение требований отнесено к ошибкам - попахивает старпёрством.
"А вы не пишите баги!", "Требования не должны меняться".

Интересно, статья проходила закрытое Peer Review?

Непонятно, почему изложение идёт от 1-го лица единственного числа, если авторов двое.

5 (6) уровней зрелости требований - это ноу-хау авторов или перепевка? Из вводной и обвеса это непонятно.

За последние 20 лет придумано множество методологий, стандартов, сводов знаний, фреймворков (framework) и практик в области разработки ПО, таких как RUP, MSF, Agile, ГОСТ, ISO, CMMI, SWEBOK, BABOK и т.д. Я уже не говорю про гору книг по данной тематике.

Что такое "методология, стандарт, свод знаний, практика ... ISO"?

Короче, зажгли коллеги, учудили смелое.

Саша, а что нового в статье по сравнению вот с этим?

Саша, а что нового в статье по сравнению вот с этим?

Данная статья была взята за основу + добавлены свои мысли, что-то добавлено, что-то убрано, в частности уровень 3.1.

Цель была представить во-первых данную статью по-русски, во-вторых добавить российские реалии. В конце идет честно ссылка на приведенную статью.

Данная статья была взята за основу + добавлены свои мысли, что-то добавлено, что-то убрано, в частности уровень 3.1.

Цель была представить во-первых данную статью по-русски, во-вторых добавить российские реалии. В конце идет честно ссылка на приведенную статью.

спасибо, понял

А мне понравилось. Простым, понятным языком написано, всё разложено по полочкам. Только уровень 3.1 как-то сбоку прикручен.

Интересно, статья проходила закрытое Peer Review?

Нет не проходила, т.к. как обычно, надо было сдавать вчера.
Возможно из-за этого и есть некоторые неточности, нужно выпускать вторую версию

А мне понравилось. Простым, понятным языком написано, всё разложено по полочкам. Только уровень 3.1 как-то сбоку прикручен.

Гриша, спасибо В след редакции определим, что делать с уровнем 3.1.

Для меня остался неясным вопрос взаимосвязи между уровнями и определения уровня зрелости на проекте.

Какой у меня уровень зрелости, если требования структурированы (уровень 3), но не организованы (то есть не выполняются критерии к уровню 2)?

И, конечно, порадовал перечень инструментов:

... на помощь могут прийти специализированные инструменты: IBM Rational RequisitePro и IBM Telelogic Doors.

Исчерпывающий перечень. Но зато понятно, на каком сайте опубликована статья.