Добрый день, коллеги!

в процессе своей недолгой работы аналитиком столкнулась с такой проблемой:

каким образом, при изменении одного требования, не упустить необходимость изменить и связанные требования?

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

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

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

каким образом, при изменении одного требования, не упустить необходимость изменить и связанные требования?
буду благодарна,если поделитесь своим опытом 

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

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

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

Если Вы в аналитике недавно, скорее всего, возможности вашей "головы" еще ограничены. Тут уж как повезет: старайтесь, и будет получаться все лучше. А потом требовать усилий все меньше. Это нормально. Если же решите положиться на "инструменты"... Ну, пеняйте на себя, как говорится. Скорее всего, быстро получите удовлетворительный результат, но перспектив развития почти не будет. Как у современных бухгалтеров, которые разбираются не в бухгалтерии, а в том, куда надо нажать в 1С конкретной версии.

Делюсь. Для этого самое главное - голова на плечах.

Спасибо за мнение
Согласна с Вами, но все же считаю, что полагаться только лишь на голову не даст 100% гарантии того, что что-то не будет упущено. Ведь человеческий фактор никто не отменят.
Тем более голова не всегда поможет, если на проекте аналитик работает не  с самого начала, а перенимает работу у другого коллеги (сама с таким сталкивалась). Если проект уже шел довольно долго, и документации насобиралось прилично, то знания, где откуда и что поменять, у нового аналитика появятся далеко не сразу.

То, о чем Вы пишите - типичная задача трассировки требований.
Ее решают с помощью ведения требований и их связей в специализированных системах.
Мы, например, используем 3SL Cradle, поскольку в ней легче всего работать со связями.

Благодарю, особенно за линки )

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

Согласна с Вами, но все же считаю, что полагаться только лишь на голову не даст 100% гарантии того, что что-то не будет упущено. Ведь человеческий фактор никто не отменят.

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

Тем более голова не всегда поможет, если на проекте аналитик работает не  с самого начала, а перенимает работу у другого коллеги (сама с таким сталкивалась).

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

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

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

В общем, смотрите, что ближе лично Вам.

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

приходите 31-го марта вечером в Лабораторию Касперского, узнаете о том, как это делают в международной продуктовой компании:
https://laboratoriya-kasperskogo.timepad.ru/event/303252/

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

Вот, кстати, Humbert недавно проводил независимое сравнение 3SL Cradle  и Sparx EA, о котором будут рассказывать в Касперском.
Было бы интересно, если у него нашлось время поделиться мнением, применительно к той задаче, которую описала в начале Елена.

На мой взгляд, Sparx здесь проигрывает, т.к. он все-таки больше направлен на моделирование, модуль работы с требованиями и их связями у него гораздо слабее.

Прошу прощения, но я бы сделал окончательные выводы именно после знакомства с технологиями Касперского на вышеуказанной конференции. Сравнение для себя я сделал, но все таки оно не вполне корректно - если 3SL Cradle в качестве демо дает целостные проекты , то вот с рабочими проектами EA я еще не сталкивался, а на демопроекте EA выглядит как UML - рисовалка. Как раз хотел глянуть и послушать Сурину, чтобы оценить технологию в целом.

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

1. Сурина не Сурина, а вовсе даже Сурова и более того — модератор это раздела форума.
2. Управление изменениями они скорей всего реализуют в TFS (а не в EA), как часть процесса УТ.

До мероприятия можно посмотреть старые выступления Ирины и почитать расшифровки:
https://vimeo.com/70325086 TFS + EA. Созданы друг для друга?
https://vimeo.com/96520606 Шаблоны трассировок бизнес-требований на кросс-проектных продуктах
https://vimeo.com/100633408 Управление изменениями требований
https://habrahabr.ru/company/sqalab/blog/221909/ Использование трассировок на практике

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

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

Управлять требованиями можно в узком смысле и в широком.

В узком смысле – это версии требований, трассировки и «статусы» требований. Аналитикам обычно понятна только эта часть «управления», но те «статусы», которые не относятся напрямую к разработке требований, – это для них только следы процессов, которые находятся вне зоны их контроля.

Управление требованиями в широком смысле – это процесс, пронизывающий всю разработку. Программирование, тестирование, документирование, испытания, внедрение – всё это должно быть привязано к требованиям, и результаты этих процессов порождают те самые «статусы». Отвечает за этот процесс управления требованиями обычно менеджер (проекта или продукта).

TFS – это инструмент командной работы. Его интеграция с инструментом разработки требований типа EA позволяет всем участникам процессов разработки получать требования в виде, пригодном для использования в их процессах, и автоматически фиксировать результаты их труда в тех самых «статусах».

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

Может им просто попробовать Cradle и станет легче? Хотя они столько уже вложили в свою интеграцию, что врядли смогут перестроиться.

Касперский компания не проектная, а продуктовая, отличается примерно как завод от стройки. Могу предположить, что репозиторий кода и управление его движением у них основное. Я Cradle изучил еще недостаточно, но насколько я понял репозитория у него нет, даже такого куцего, как у EA. Так же не заметил в Cradle следов для организации  межпроектного взаимодействия (впрочем как и у ЕА).

Так что осмелюсь предположить, что основным двигателем прогресса у Касперского были разработчики, а EA они в качестве погремушки для аналитиков прикрутили. И он для этих целей опять же лучше подходит - можно легко регулировать уровень использования, открытая СУБД (с возможностью миграции на любую другую)

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