Humbert,

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

Исходный посыл po_lena

"каким образом, при изменении одного требования, не упустить необходимость изменить и связанные требования?
А также буду рада услышать ваши предложения, как разрулить этот вопрос на проекте, где SRS ведется с помощью MS Word, а версионирование документа осуществляется в SVN."

В соответствии с исходными положениями, есть:
Спецификация требований в MS Word плюс SVN для хранение версий этого документа.
и задача легко управлять трассировкой требований.

Я предлагаю:
Две системы (MS Word+SVN) заменить на одну - 3SL Cradle,
Это позволит:
1) Легко перейти от MS Word к Cradle, благодаря Cradle Document Loader, при этом Cradle поэлементно сохранит все связи с исходными документами (трассировку).
http://www.youtube.com/watch?v=QKu5LLCnkOY

2) Использовать мощные функции Cradle по работе с трассировкой требований (аналогичного инструмента по удобству работы с трассировкой текстовых требований и моделей просто нет).

3) Управлять версиями требований в Cradle (т.к. это встроенная возможность), что позволит отказаться от SVN для версионирования спецификации и автоматически вести историю изменений содержания и атрибутов КАЖДОГО ОТДЕЛЬНОГО требования, а не документа в целом.

4) Управлять атрибутами требований в Cradle (приоритетами, статусами и др.), т.е. получить новые возможности, т.к. ни Word, ни SVN не позволяют этого делать.

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

Две системы  (MS Word+SVN) заменятся на две системы Sparx EA + TFS

1) Переход от MS Word к Sparx EA неоднозначен.
а) переносить требования из спецификации в модуль RM придется ручками?
б) Sparx EA - это все-таки инструмент для моделирования (Вы сами об этом написали).  Переводить всю спецификацию в UML-модели? А надо ли это в данном случае. В исходном посыле не отражено.

2) Трассировка разных типов текстовых требований в Sparx есть, но она гораздо слабее и менее удобна чем в Cradle. В Sparx модуль RM вырос как надстройка над UML-моделированием и он слабо развит.

3) Управлять версиями требований в TFS, причем управлять именно пакетами версий, а не версией каждого отдельного требования, поскольку Sparx поддерживает версионность только на уровне целых пакетов. Это также плохо влияет на возможность быстрой оценки изменений сквозь несколько версий.

4) Управлять статусами и приоритетами требований в Sparx (без возможности отслеживания истории изменений)


В соответствии с исходными условиями задачи второе решение  (Sparx EA +TFS) получается:
а) более затратным
б) менее продуктивным
в) менее эргономичным

Поэтому целесообразность сделанного предложения про EA+TFS в данном случае мне непонятна.
Более того, хочу отметить, что из участвующих в дискуссии, насколько мне известно, никто Enterprise Architect в реальной работе не использует.
Григорий вот даже выступал "Analyst Days 2015. Почему UML — плохой выбор для обучения аналитиков"
https://www.webursitet.ru/trainer/grigorii-pechenkin.html

------------------
На этом свою помощь топикстартеру считаю оказанной. Если те, кто реально используют Enterprise Architect, захотят обсудить его с теми, кто реально использует 3SL Cradle - welcome https://www.facebook.com/groups/sysdes/.

сообщение устарело

.

Коллеги предложили посмотреть на опыт Лаборатории Касперского. Посмотреть на чужой опыт всегда хорошо.
Поэтому целесообразность сделанного предложения про EA+TFS в данном случае мне непонятна…

Топикстартер просила поделиться своим опытом, а не только тем своим опытом, который точно подойдёт в её очень фрагментарно описанной ситуации:

буду благодарна,если поделитесь своим опытом 

Я рассказываю, где об этом опыте можно быстро и дёшево узнать (ссылки на открытые материалы, бесплатная встреча через 10 дней).

Я так вообще не фанат никакого ПО (а скорее открытых систем как класса) и считаю, что самое полезное, что можно будет извлечь из рассказов Ирины и Романа — это методические вещи по организации работы.

Связка EA + TFS, как и любого другого набора инструментов разных производителей, сама по себе довольно дорога в разработке, сопровождении и развитии, поэтому естественно такое себе могут позволить только крупные компании с достаточным штатом.

[Удалено как не относящееся к дискуссии]

Коллеги, если вам не нравится Cradle – аргументируйте.
Если вы считаете необходимым продвигать другой продукт – продвигайте на здоровье.

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

Сделайте в конце концов подраздел Cradle также, как это сделано для EA — и там сходите с ума.

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

Все сообщения шли строго в рамках запрошенной темы. Все приведенные факты объективны и легко проверяются.

Сделайте в конце концов подраздел Cradle также, как это сделано для EA — и там сходите с ума.

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

.

Если любители продукта об этом попросят - сделаем.

Это относится только к Cradle или к любым продуктам, используемым аналитиком?

Я вижу, как неприветствуются наезды, судя по тому, что фраза:

"хотя причины этого эмоционального порыва всем участникам обсуждения хорошо известны"

осталась

Автор удалила эту часть комментария.

Григорий вот даже выступал "Analyst Days 2015. Почему UML — плохой выбор для обучения аналитиков"
https://www.webursitet.ru/trainer/grigorii-pechenkin.html

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

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

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

К тому же TFS, например, легко подключается мощный инструмент тестирования от Microsoft. Это "погремушка" тестировщиков, в которой они разрабатывают и выполняют тест-кейсы и планы тестирования. А благодаря интеграции с TFS эти тест-кейсы трассируются прямо на код. Так что если вы что-то поменяли в коде, система автоматически определит, какие тест-кейсы эти изменения затрагивают, и предложит их выполнить повторно.

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