Давно пылится материал, решил опубликовать:
http://ooprogramme.blogspot.com/

Возможно, что подход не нов, и этот велосипед давно изобретён

в общем случае присутствуют следующие основные шаги:

...

2. сбор требований заказчика по автоматизации бизнес-процесса;

Собирать можно только то, что где-то лежит готовое. Обычно требования не лежат готовыми, их нужно выявлять, помогая ЗЛ осознавать их деятельность, интересы, намерения. Кроме заказчика есть и другие источники требований, прежде всего — потенциальные пользователи.

3. структурирование требований к системе автоматизации;

Вроде в заголовке было ПО, почему вдруг здесь система автоматизации?

4. детализация требований;

А как же моделирование и анализ, как средства обеспечения качества требований (прежде всего — полноты и непротиворечивости)?

5. утверждение требований в виде документа Техническое задание;

Это в общем-то случае? В общем случае происходит согласование принятых решений относительно назначения, внешнего устройства и поведения системы/продукта. Эти решения могут лечь просто протоколом встречи (во внутренней разработке), строками в бэклог и т.д., а не только в ТЗ.

6. управление изменениями требованиями на этапах разработки, тестирования и эксплуатации системы.

Шаги 1-5 — вообще не про управление. Они про создание требований. Это всё равно, что включать работы по производству автомобиля в понятие «управление
автомобилем».

Управление требованиями — это прежде всего управление рамками, приоритетами и статусом готовности требований, а потом уже трассировками и изменениями.

Вы сначала вообще разберитесь, о чём пишете.

Вы сначала вообще разберитесь, о чём пишете.

 

Узнаю родные рассейские форумы .)))

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

А по поводу определений, рекомендую прочитать для начала хотя бы первый абзац вот отсюда:

http://ru.wikipedia.org/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%BC%D0%B8

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

Зачем тратить своё время, если невооружённым глазом видно, что вы ошибаетесь в фундаментальных вещах?

А по поводу определений, рекомендую прочитать для начала хотя бы первый абзац вот отсюда:
http://ru.wikipedia.org/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%BC%D0%B8

1. В википедии представлены не согласованные мнения экспертов, а мнения гиковской толпы. Хотите, завтра в этой статье будет написано нечто совсем иное?

2. Согласованные мнения экспертов тоже устаревают.

Что важно:

1. Вы вообще молодец, что решились выразить и описать своё мнение.

2. Было бы ещё лучше, если бы вы назвали себя и дали контакты. А то получается, что у какого-то анонима есть мнение. И что?

Более-менее вменяемое разделение разделения и управления требованиями описано в CMMI — действительно экспертном источнике по процессам создания ПО.
http://en.wikipedia.org/wiki/Process_area_(CMMI)#Requirements_Development_.28RD.29
http://en.wikipedia.org/wiki/Process_area_(CMMI)#Requirements_Management_.28REQM.29

2. Было бы ещё лучше, если бы вы назвали себя и дали контакты. А то получается, что у какого-то анонима есть мнение. И что?

Отпишу в личку.
Если совсем кратко: практика разработки ТЗ и управления аналитическим подразделением с 2001 года.

Зачем тратить своё время, если невооружённым глазом видно, что вы ошибаетесь в фундаментальных вещах?
1. В википедии представлены не согласованные мнения экспертов, а мнения гиковской толпы. Хотите, завтра в этой статье будет написано нечто совсем иное?
2. Согласованные мнения экспертов тоже устаревают.

Честно говоря, просто нашёл первую ссылку в гугле, чтобы не уходить в бессмысленный спор по терминологии.
Меня это определение в вики вполне устраивает.

Глаз, всё-таки вооружите и прочитайте текст. Интересно мнение по существу, а не "учёба" новичков.