Скажите, а какие вы используете сценарии версионирования/бейсланирования документов требований в своих проектах?

Например, создали документ, сохранили как версию и отправили заказчику на согласование. А пока можете его дорабатавать, а потом он присылает результаты и [..тут мы что-то делаем с версиями..]

Или делаем заканчиваем релиз 6, а параллельно релиз 7 аналитику, и приходит изменение законодательства и надо его у честь в обоих релизах и вот тут мы [..используем бейслайны предусмотрительно сделанные или что-то еще..]

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

Например, создали документ, сохранили как версию и отправили заказчику на согласование. А пока можете его дорабатавать, а потом он присылает результаты и [..тут мы что-то делаем с версиями..]

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

Если речь про какую-то форму совместной разработки документа, то результаты "согласования" включаются в очередную версию документа. Которая публикуется, например, с примечанием "с учетом результатов рассмотрения документа [отв. лицо Заказчика] [дата]".

Или делаем заканчиваем релиз 6, а параллельно релиз 7 аналитику, и приходит изменение законодательства и надо его у честь в обоих релизах и вот тут мы [..используем бейслайны предусмотрительно сделанные или что-то еще..]

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

Для документов которые читает заказчик используем SVN.
Сделал версию -> коммит -> заказчику.
Этап согласования прошел -> коммит -> заказчику.

Для внутренней переписки добавляем циферку в конце документа, т.е. _1, _2 и т.д.

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

Лучше всего процесс, наверное, рассмотреть на документе ворд:
1. Аналитик шарашит документ, каждая новая версия - это изменение версии в названии файла + трек внутри документа в табличке версионности.
2. Аналитик отсылает документ Заказчикам(Разработчикам, Тестировщикам), версия N.
3. Аналитик что-то шарашит еще в документе, изменяя версии.
4. Аналитик получает документы с замечаниями от Заказчика, вносит изменения в свою последнюю версию по всем замечаниям, изменяет версию на N+M.
5. Аналитик отсылает документ Заказчикам, версия N+M.
6. Заказчики говорят, что все ок, тогда версия N+M считается согласованной - это бейслайн требований. Далее идет процесс разработки и изменений согласованных требований. Если есть еще замечания, то идем к п. 4.

Если один документ изменяют несколько аналитиков, то уже без СВН или СУТ не обойтись.

5. Аналитик отсылает документ Заказчикам, версия N+M.

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

Павел,

Спасибо за уточнение. Так как раз и делаю, просто сравнению версии N и N+M и посылаю документ с изменениям.

Коллеги, спасибо вам за кейсы, мы их учли и выпустили новую версию Devprom ALM 3.2, которая теперь умеет делать бейзлайны требований и тестовых сценариев, версионировать документы, а так же сравнивать документы различных версий/бейзлайнов между собой!

Будем признательны за обратную связь, готовы даже поделиться бесплатными лицензиями за хороших фибдек

Вот ссылка на полное описание изменений: http://devprom.ru/news/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F-Devprom-3-2

Коллеги, спасибо вам за кейсы, мы их учли и выпустили новую версию Devprom ALM 3.2,

Хитро.

Хитро.

Сергей, главное, на наш взгляд, чтобы полезно оказалось

Сергей, главное, на наш взгляд, чтобы полезно оказалось

Дмитрий, ваш подход мне кажется действительно правильным.

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

Сергей, спасибо за замечание, а в чем именно вы увидели неверное употребление терминов и, тем более, логическую несостыковку?