дак и не были мы в клиентах Борланда, токо теребили шефа насчёт покупки стартима :-(
"Дельпи", правда, был честно куплен, ещё в 90-ых, задолго до меня.

Как водиться одну коробку на всю компанию :-) ....

и не 2006-м, а весной 2007-го это было,
и были попытки проконсультироваться у манагеров Киевского представительства,
закосив под заинтересовавшихся потенциальных покупателей,
тягающих триал-версии и недоумевающих по имеющимся или остсутствующим возможностям,
так они затянули довгу чумацьку пісню:
"Вы нам опишите в почту техническую суть Ваших вопросов - мы перешлём в Москву...." ну, и далее - понятно.

Удивительно что они вам что-то пообщали ... но к этому моменту в Москве был только офис CodeGear, который по ALM тулам не работает. Ну да ладно :-).

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

Мне на самом деле было бы интересно узнать более подробно об этой связке и ее возможностях. Если есть информация, какие-либо материалы, я бы с удовольствием посмотрел на них.

А свою интеграцию Борландовских продуктов мы делали своими силами, как полагается, "топором и на коленях". :-(
Не знаю, стоит ли сразу выносить на форум обсуждение технических деталей по граблям, на которые пришлось понаступать?
Может, для начала лучше в почту, а уж полезные результаты - на форум, для общественности?

Думаю стоит описать в кратце процесс в рамках которого использовалась интеграция инструментария. Какая информация откуда куда поступала и почему. Т.е. каков был регламент работы с инструментарием. Это было бы думаю многим интересно.

Т.е. сначала ДД используется на уровне бизнеса, как некая сложная комбинация блок-схемы, IDEF3 и возможно DFD.
  Затем реализуются уже ВИ к системе и соотвественно ДД системы.

тогда точнее будет так:
- сначала ДД или БВИ на бизнес-уровне, а затем
- снова ДД или СВИ на уровне пользовательских требований?

всего по комбинаторному принципу получается 4 возможных варианта :-)

Согласен. Но применять диаграммы ВИ до деятельности или нет должно истекать из того, оправдано это или нет.

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

Хочу обратить внимание на "рулёзные" особенности ВИ:
- хорошее, а местами - единственное в своём роде, описание  КОНТЕКСТА процесса: пред-, пост-условие, ДЛ-ы, Заинтересованные Лица с их интересами и т.д.
(единственное в своём роде - в том смысле, что других мест для описания всего этого в стандартах на структуру соответствующих документов иногда вообще нет)
- СОЗНАТЕЛЬНО снижены требования к строгости и детальности описания САМОГО процесса.

В противовес(а точнее - в дополнение) к ВИ, ДД рулит:
- обеспечивает строгость и наглядность представления именно ПРОЦЕССА,
- даёт возможность учитывать в явном и стандартизированном виде поток входных\выходных объектов, да ещё и отслеживать их состояния на входе и на выходе каждой активности,
- показывает исполнителей каждой активности (свим-лайны),
- СОЗНАТЕЛЬНО абстрагируется от контекста: Интересы и Заинтересованные Лица, Цели ДЛ-ов и т.д.

тогда точнее будет так:
- сначала ДД или БВИ на бизнес-уровне, а затем
- снова ДД или СВИ на уровне пользовательских требований?
всего по комбинаторному принципу получается 4 возможных варианта :-)

Да вариантов не много :-) Дело и в вариантах,а в удобстве. Главное все равно в понимании  того, что нужно сделать. И совершенно не важно как и что. Главное чтобы все разговаривали на одном языке, так ведь?

Хочу обратить внимание на "рулёзные" особенности ВИ:
- хорошее, а местами - единственное в своём роде, описание  КОНТЕКСТА процесса: пред-, пост-условие, ДЛ-ы, Заинтересованные Лица с их интересами и т.д.
(единственное в своём роде - в том смысле, что других мест для описания всего этого в стандартах на структуру соответствующих документов иногда вообще нет)
- СОЗНАТЕЛЬНО снижены требования к строгости и детальности описания САМОГО процесса

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

В противовес(а точнее - в дополнение) к ВИ, ДД рулит:
- обеспечивает строгость и наглядность представления именно ПРОЦЕССА,

особенно когда ВИ сложный

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

Но эта особенность появилась только в UML2 я имею в виду объекты, просто мы пользовались Розой, а она потоки объектов не разрешала размещать. Правда до UML2 ДД была подмножеством диаграмм состояний. А вот в UML2, ДД имеют совершенно иную интерпретацию, и построены на теории сетей Петри со всеми вытекающими отсюда особенностями логики переходов, правил срабатывания переходов, чтения диаграмм, проверки безопасности, живости сети. хотя мне кажется ценнее было бы E-сети, поскольку они безопасны по определению

- СОЗНАТЕЛЬНО абстрагируется от контекста: Интересы и Заинтересованные Лица, Цели ДЛ-ов и т.д.

Т.е. Вы полагаете - это зер гут? А почему если не секрет

Очень рад, что начал эту тему. Дело в том, что в ходе своей дейятельности мне не удается организовать управление требованиями. А хотелось бы поставить такую задачу в рамках практикума.

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

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

Что это будет за задача пока не понятно. Ясно, что некие предварительные материалы по ней будут. Хотелось бы расмотреть пусть не все - но некоторые этапы фиксации, управления и работы с требованиями.

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

В самом общем понимании что нужно будет делать:?
1. осуществить сбор требований
2. осуществить извлечение требований
3. осуществить ранжирование требований
4. осуществить моделирование части требований
5. осуществить фиксацию базовой линии

Предположим бизнес-цели или цели создания у нас будут поставлены.
мы будим формировать Видение. Сразу вопрос имеет ли смысл фиксировать бизнес-требования в системе управления требованиями? Если да то как грамотно это делать, Если нет то почему?

Далее функциональные требования будем в первую очередь описывать через прецеденты. Вопрос - ВИ и есть функциональные требования? имеет ли смысл разбивать ВИ на списки требований и фиксировать их в RaQuest? Или в RaQuest описать фичи? выделенные при создании Видения, а сами прецеденты описывать в рамках ЕА (Enterprise Arcitect) с трассировкой их к фичам описанным в RaQuest

особенно когда ВИ сложный

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

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

Главное мне не очень понятно с чего все-таки начать.

Прежде всего - уточнить программу, чтобы она соответствовала названию практикума:
- управление требованиями (2 уровень СММ)
- или дизайн требований (3 уровень СММ)

а то в названии - управление,
а в программе - и то и другое

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

 Предположим я буду использовать RaQuest или нечто другое

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

Прежде всего - уточнить программу, чтобы она соответствовала названию практикума:
- управление требованиями (2 уровень СММ)
- или дизайн требований (3 уровень СММ)
а то в названии - управление,
а в программе - и то и другое

Да нет никакой программы - есть мысли вслух.
По идее описывать требования я планирую их в рамках курса, где собираюсь дать что такое ребования их классификацию и правила работы с сними- вернее как правильно формулировать

По идее мне самому это шибко интересно.Вконце концов не получится в коллективе группы - я вполне могу этим заниматься кулуарно при ведение бакалавских и дипломных работ. Благо сейчас бакалавриат на 4 курсе а диплом на 5 - в результате грамотно поставленной работы у меня 2 года, да каждый год можно вовлекать потихоньку народ

- ДД СОЗНАТЕЛЬНО абстрагируется от контекста: Интересы и Заинтересованные Лица, Цели ДЛ-ов и т.д.
Т.е. Вы полагаете - это зер гут? А почему если не секрет

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

- или дизайн требований (3 уровень СММ)

А что есть дизайн? если проектирование системы по требованиям, то можно до него не доходить, или ограничить все это - как в гибкой методологии
Если это есть анализ требований - вот мне он и нужен, но анализ может затрагивать и дизайн. А какже иначе?

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

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

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

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

Думаю стоит описать в кратце процесс в рамках которого использовалась интеграция инструментария.

вот, собрал осколки документации, да ещё и не последней версии, но приблизительную картину должно дать

А что есть дизайн?

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

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

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

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