Я может быть пропустила сей момент, но я не увидела, где бы автор топика описал ЦЕЛЬ документирования ИС. Между тем, от поставленной цели такого мероприятия, как документирование, очень сильно зависит содержание документации, ее формат, вид, состав и последовательность разделов... в том числе и используемые инструменты.

bebop КомсомолкаЯ может быть пропустила сей момент, но я не увидела, где бы автор топика описал ЦЕЛЬ документирования ИС. Между тем, от поставленной цели такого мероприятия, как документирование, очень сильно зависит содержание документации, ее формат, вид, состав и последовательность разделов... в том числе и используемые инструменты.
Вобще-то я думал, что цель описана здесь

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

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

bebopЦель - существенно (в 2-10 раз) снизить трудозатраты на сбор и анализ требований к ПО. Контекст задачи описан по ранее приведённой ссылке.
Такая "хотелка" бессмысленна без логического продолжения "...за счет того-то и того-то...". Вы не обижайтесь, но когда в моем присутствии такие фразы выдают за ЦЕЛЬ, то я обычно советую: "Не вопрос! Нужно вообще перестать что-либо делать - и затраты сами упадут до нуля!"

Если судить по этому абзацу:
bebopПрошло полгода. Аналитик проекта111 уволился. Делаем проект222 для отдела закупок. Никому в голову не придёт искать что-то в SRS проекта111. Всё требования начинаем писать с нуля
То главная и наверно единственная проблема - отсутствие единого стандарта в ИТ предприятия вообще и в описании БП - в частности.

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

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

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

Третий вариант - посчитать затраты на первые два способа и таки смириться с ситуацией, когда требования к ПО через некоторое время приходится собирать повторно...

bebopИнтересует не описание БП, а описание требований к ПО. Это несколько разные задачи. Думаю, они требуют разного подхода.
Отнюдь. Если целью описания БП поставлена их (БП) оптимизация с помощью ИТ, то в данном случае "описание БП" и "описание требований к ПО" - две почти последовательные задачи, которые бессмысленны друг без друга. И подход к ним - одинаковый - разумно-бюрократический (кстати, бюрократия в умелых руках - эффективнейший инструмент).

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

bebop Комсомолка- формат, в котором создается такая документация, ПО, в котором такая документация разрабатывается (вплоть до указания релизов и сборок)
- периодичность и условия обновления такой документации
- порядок внесения изменений и перечень должностных лиц, которые могут их делать
- место и условия хранения исходных файлов этой документации
и т.д. и т.п.
Вот порядок, инструменты и ответственные лица при разработке требований к ПО, в контексте моей ситуации, как раз и интересуют.
КомсомолкаПервый вариант...
Второй вариант...
Третий вариант...Весь этот пост был про то как участники форума представляют себе первый или второй вариант. Я полностью присоединяюсь к вашему высокоуровневому видению ситуации. Однако практически, сейчас меня интересуют вопросы более низкого уровня абстракции (как).

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

bebopВы считаете, что решение к которому склонилось обсуждение:


-не самое оптимальное?
В данном случае - есть определенные сомнения.... Которые основываются на вашем рассказе о том, что никто из ваших коллег не смог разобраться в "наследии" уволившегося системного аналитика...

bebopПоследовательные, но разные. Их делают разные люди с разной целями.
Ну, значит, ни те, ни другие не представляют себе, зачем же В ИТОГЕ они это делают. Процесс ради процесса.

bebopПри разработке требований к ПО далеко не всегда начинают с реинжиниринга бизнес-процессов.
"Горит лампочка - собака выделяет слюну". (с) Павлов
"Пользоваель услышал словосочетание 'бизнес-процесс' - обязательно должен добавить 'реинжениринг'" (с) форум sql.ru

bebopНе всякий заказчик готов копать так глубоко.
А Вашей фирме программное обеспечение зачем нужно: чтоб эффективней работать или "шоб булО"?

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

bebopЕсли вы меня плавно подводите к теме консалтинга...
Консалтинг тут бессилен - я уже говорила.

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

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