Это я понимаю. ясно что любая модель отражает некоторые существенные моменты и  вданом случае сосредоточена на потоке работ и объектов если нужно,
однако контектс все равно отсается, хотя бы теже свимлайны

- контекст как таковой, кончно же остаётся,
- в ДД он показан существенно меньше, чем ВИ  - и это хрошо, чтоб не мешал понимать сам процесс,
- свим лайны и Пользователи Системы - не одно и то же:
-- свим-лайны - всего лишь инструмент визуализации, который
-- может иметь и другую смысловую нагрузку, например - этапы деятельности.

Гиблое это дело: одновременно учить студентов концепциям и средству автоматизации...
если хотим научить, что такое Требование и как им управлять - бумагу с карандашом в руки, да ещё и нелинованную :-)
И ДУМАТЬ-ДУМАТЬ-ДУМАТЬ, а компьютер - отобрать, чтоб не мешал.

Ну возможно. А что с бумагой и нелиновоной тут делается?

да по-сути, то же самое, что и при обучении ЮМЛу или бухгалтерии:

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

студент вынужденно остаётся без подсказок, а концепция, которая должна уложиться в его голове - без костылей и подпорок

А в этих рамках кроме пачки требований, которые нужно "разложить по полочкам" есть ещё и пачка соответствующих компонент продукта, тестов, доки, задач, исполнителей,заинтересованных лиц.
Сами объекты, связи между ними и динамика процесса разработки в проекте.

А вы не путаете управление требований с управлением проектом или процессом разработки в целом?

да по-сути, то же самое, что и при обучении ЮМЛу или бухгалтерии:

студент вынужденно остаётся без подсказок, а концепция, которая должна уложиться в его голове - без костылей и подпорок

такой подход интересный, только почему по сути тоже самое?
Вообще напридумывать кучу требований на 30 студентов - это очень сложная по-моему задачка.
Далее, естественно при чтении этих требований логика комбинации у всех своя, и варианты возможны самые разнообразные.
У нас уже с этим были проблемы. Преподаватель дал задачу - некий набор существительных и глаголов и сказал постройте семантические связи. Ну все стали строить: кто-то выбрал в качестве критерия минимальность связей, кто-то сделал группировки по своему. В результате оценка у всех 2 - типа не сходится с ответом у преподаателя.
Например еще, в рамках задачи были заданы такие слова музыка медведь сцена. Практически все написали, что типа цирк приехал и медведь танцует на сцене - всем 2. Поскольку преподаватель сказал, что какие вы дураки, какой медведь. Это группа "медведь" выступала.

Помоему точно так же будет и с обучением требований, UML если все вырвано из контекста. К тому же UML - просто символы. В требованиях коннчг больше смылса не спорю, может с ними и прокатит, только интересно где найти 300 требований, а по идее и еще больше :-)

управление требованиями предполагает, что требования, как таковые, появляются\обнаруживаются, формулируются, как-то документируются кем-то извне, что мы сами ещё этому не научились.

Вообще по классике, управление нуждается в объекте управлением - в данном случае требованиями и определяется функциями: сбор, учет, контроль, анализ, прогноз, планирование, оперативное управление (изменение), организация и координация, доведение до исполнителя.

Напомню, что по ГОСТ ТЗ пишет разработчик. Понятно что требования поступают извне, не нам же их придумывать самим.

Кроме того в РУП записано: "управление требованиями - систематизированных подход к поиску, документированию, организации и отслеживанию изменчивых требований к системе" К.Ларман "Применение UML2 и шаблонов проектирования" 3-е издание. М.:Вильямс, 2007, стр. 90

А вы не путаете управление требований с управлением проектом или процессом разработки в целом?

стараюсь не путать, но наверняка ошибки в представлениях имеются
поэтому давайте разделим мою задачу на форуме (поделиться опытом) по таким направлениям:
- правильно его изложить, как есть,
- проанализировать и выделить действительно стОящие части,
- оформить их в удобном для пользования другими.

Gevorg, на самом деле любой опыт полезен:
а/ если он верный - то им можно воспользоваться
б/ если в нем есть ошибки - то их можно понять

Кроме того любая попытка описать что-либо сразу вызывает потребность обдумать и сформулировать, а главное донести свое понимание. И тут сразу вылезают и собственные заблуждения и какие-то нелогичности.

Я поднял эту тему, поскольку попытался осмыслить, а что есть управление требованиями вообще. Как, когда и с помощью чего его применять на практике. И обнаружил, что вопросов больше, чем ответов. Более того - даже не сумел опеределиться, а когда же оно начинается и как выражается...

Потому практический опыт очень ценен... Такчто, чтобы Вы не предприняли - уже хорошо. А обсуждая, мы можем вместе прийти к лучшему пониманию, и возможно Вам будет польза

- правильно его изложить, как есть,

Да думаю именно так и нужно - это будет опорная точка

- проанализировать и выделить действительно стОящие части,

т.е. те интересные фишки, которые стоит развивать?

- оформить их в удобном для пользования другими.

Будет нужна помощь, обращайтесь

такой подход интересный, только почему по сути тоже самое?

по сути процесса обучения :-)

в примерах от меня студенту нужно освоить:
- процесс моделирования с помощью инструмента "система UML" (графические элементы, ООП-абстракции, шаблоны...),
- процесс бухучёта с помощью инструмента "система бухучёта" (план счетов, двойной учёт, дебет\кредит, актив\пассив...)

в нашем примере нужно осваивать
- процесс управления требованиями,
- с помощью инструмента....?

вот, чтобы эффективно задать этот вопрос студенту и необходима "орг-мера":
Дать инструменты работы с требованиями в "чистом" виде, а не упакованными в пусть даже золотое ПО.

Вообще напридумывать кучу требований на 30 студентов - это очень сложная по-моему задачка.

она облегчается тем, что сущность требований должна быть примитивной, чтобы эти требования:
- легко "придумывались",
- однозначно понимались,
- однозначно трассировались,
- были легки в управлении (менеджменте),
- не интересны по смыслу (не отвлекали от менеджмента).

Вообще по классике, управление нуждается в объекте управлением - в данном случае требованиями и определяется функциями: сбор, учет, контроль, анализ, прогноз, планирование, оперативное управление (изменение), организация и координация, доведение до исполнителя.

здесь я для себя провожу аналогию с понятиями производство - логистика.
Мои бытовые представления позволяют легко отличать
процессы по добыче\переработке сырья или изготовлению устройства (дизайн требований) от
процессов по оценке качества, упаковке, маркировке, транспортировке, хранению (менеджмент требований)

получается, что
для менеджмента  - требование является объектом управления, а
для дизайна - выходным продуктом.

Кроме того в РУП записано: "управление требованиями - систематизированных подход к поиску, документированию, организации и отслеживанию изменчивых требований к системе" К.Ларман "Применение UML2 и шаблонов проектирования" 3-е издание. М.:Вильямс, 2007, стр. 90

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

Напомню, что по ГОСТ ТЗ пишет разработчик. Понятно что требования поступают извне, не нам же их придумывать самим.

нужно уточнить:
"извне" - я имел в виду, что извне изучаемого нами процесса менеджмента требований:
не принципиально, будет ли это эксперт от заказчика или сообразительный аналитик разработчика,
принципиально - что процесс "производства" требования пока остаётся таинственным и не рассматривается.

     ...не нам же их придумывать самим.

и такое случалось :-)
 причём - на полном серъёзе: в рамках работы над ТЗ пришлось
 продумывать и предлагать бизнес-процессы для только зарождающейся деятельности Заказчика,
 чтобы хоть как-то зафиксировать, а что же, собственно, будет автоматизироваться...

Вообще по классике, управление нуждается в объекте управлением - в данном случае требованиями

а поскольку управление требованиями идёт в контексте комплексного управления ВСЕМИ объектами процесса управления разработкой ПО,
то здесь же следует рассматривать и контекст из других объектов, так или иначе связанных или связываемых с требованиями.


если пойти дальше в распутывании терминологической паутины, то мне видится такое:
процесс разработки ПО состоит из:
- производственного процесса, для которого требование является
-- артефактом (в моём примитивном понимании - продуктом), и
- процесса управления, для которого требование - один из
-- объектов управления.

ЫМХО: Процесс управления разработкой ПО не получается разбить на несколько слабо связанных подпроцессов и рассматривать их по-отдельности,
уж сильно они переплетаются и много взаимосвязей.
Эффективным получается только рассмотрение Проекций этого процесса на различные оси по объектам управления:
 требований, кода\сборок, тест-кейсов\репортов, задачам и т.д.

... на самом деле любой опыт полезен:
...осмыслить, а что есть управление требованиями вообще. Как, когда и с помощью чего его применять на практике.
... вопросов больше, чем ответов.
Потому практический опыт очень ценен...

кроме практического опыта в использовании, у меня за прошедшие выходные появился ещё и небольшой опыт преподавания :-)
курса по управлению требованиями.

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

Времена радиолюбителей-академиков, собирающих по сараям свои приёмники, -  давно прошли.
Теория полупроводников и радиосхемы уже никого не интересуют, все спрашивают:
- где магазин?
- какой производитель и какая модель лучше?
- где ручки у приёмника и как их крутить?

она облегчается тем, что сущность требований должна быть примитивной, чтобы эти требования:
- легко "придумывались",
- однозначно понимались,
- однозначно трассировались,
- были легки в управлении (менеджменте),
- не интересны по смыслу (не отвлекали от менеджмента).

- отражали реальные потребности заказчика
- были проверяемы (в том числе правильно понимались тестировщиками, потому что "однозначное понимание" всё-таки существенно различается для программистов, тестировщиков, заказчиков, продавцов и маркетологов).

Добавляю исключительно по поговорке "у кого что болит, тот о том и говорит".

Странный движок всё-таки. Ввёл пост, нажал "отправить". Он говорит: "пока вы писали ответ, в теме появились новые сообщения".
Исправил свой пост, нажал "отправить". Так движок зачем-то перед отправкой отменил все мои изменения. Зачем тогда спрашивал, интересно?

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

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

как мы ошиблись, когда взялись делать настоящую, а не игрушечную функциональность.....

Странный движок всё-таки. Ввёл пост, нажал "отправить". Он говорит: "пока вы писали ответ, в теме появились новые сообщения".
Исправил свой пост, нажал "отправить". Так движок зачем-то перед отправкой отменил все мои изменения. Зачем тогда спрашивал, интересно?

Гриша, ну и что Вы испугались? Надо было продолжать и дело с концом. У меня такое частенько бывает, когда я пишу ответ и появляется некоторое новое сообщение. А то что не сохранил изменения - богу весть.

Gevorg, Вы это greesha  в пику или в одобрение казали?