bebop
Практически сейчас дискутируется форма в которой должен быть РепозиторийТребованийКСистеме

2) Есть вторая идея - что репозиторий должен представлять из себя System Requirements Specification (buyr) содержащую ссылки на документацию по проектам. В свою очередь самые подробные требования к ПО будут только в документации по проектам. С этой идеей мне пока не всё понятно.

3) Есть третья идея - что нужен только ГлавныйVision на систему (analyst_). Который тоже будет как-то ссылаться на детальные требования. Только проекты на доработку надо будет уже заводить под Реквизитом (сейчас это просто вордовые документы в сети). Для нас этот подход означает всё за 1.5 года наработатнное выкинуть и начать делать заново. Скорей всего, не пройдёт.

Я постараюсь пояснить, и если получится -- привести все к "общему знаменателю". Отвечу сразу да, на SyRS есть соотв. стандарт IEEE 1233, но я не зрая сказал про "a-la SyRS". Если вы не знакомы с ним, не забивайте голову -- и без нее можно обойтись.
Что важно ... важно иметь высокоуровневые требования (Features или в "простонародье" -- фичи), которые бы давали предстваление о системе в целом (задавали контекст для отдельных модулей). Не суть важно какой документ будет адаптирован для их содержания (что будет их контейнером) -- SyRS или Vision (из Vision просто нужно выбросить маркетинговое бла-бла, если это вам не важно, и может быть и бизнес-цели и т.п. ... it depends, как говорят "настоящие консультанты" :-) и это отметил г-н analyst_ в совем постинге). Важно что они (фичи) ДОЛЖНЫ БЫТЬ. Детализация фич (я думаю что примерно это же имел ввиду и г-н Майевтик только выразил это как "...представляют собой решения по реализации требований более высокого уровня", где слово "реализация" была не совсем верно интерпретирована другими) -- это уровень локальных SRS. Г-н Майевтик справедливо отмечает, что важно иметь репозитарий требований -- из которого можно в нужный момент получать те самые документы-контейнеры (часом не CaliberRM используете, Майевтик?) с актуальными версиями требований. Но это уже extension нашей темы ...

Т.е. идея проста -- высокоуровневые требования (фичи) с указанием к какой подсистеме они относятся - в едином общем репозитарии, из которого можно быстро получить документ (аналогия/метафора -- как получается отчет по данным из БД), детали (но по подсистемам разложенные!) в отдельных репозитариях (примем так, чтобы не запутывать людей) -- из которых можно получать актуальные SRS. Такой подход поможет решить в частности описанные вами проблемы (ниже цитата):
"Делаем Проект111 для бухгалтерии, одновременно хорошо описали несколько юз-кейсов и бизнес-правил о том как отдел закупки работает с таможней.
Прошло полгода. Аналитик проекта111 уволился. Делаем проект222 для отдела закупок. Никому в голову не придёт искать что-то в SRS проекта111. Всё требования начинаем писать с нуля."

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

Это концептуальное решение ... теперь о его автоматизации. Инструментарий управления требованиями несомненно позволит облегчить этот труд -- в частности решить проблемы версионирования, базовых линий требований, и поддержки связей на уровне, например, ФИЧИ -- ДЕТАЛЬНЫЕ ТРЕБОВАНИЯ. Если инужны другие трэйсы к другим типам требований -- не вопрос, но эта связь фундаментальная вещь в вашем случае, IMHO. Кроме все инструменты управления требованиями имеют возможность импорта требований из ваших документов в свой репозитарий. Далее -- дело техники разложить что к чему относится (по подсистемам например), хотя задачка займет некоторое конечное время, а как без этого ...

Надеюсь прояснил ...

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

byur Детализация фич (я думаю что примерно это же имел ввиду и г-н Майевтик только выразил это как "...представляют собой решения по реализации требований более высокого уровня", где слово "реализация" была не совсем верно интерпретирована другими)

Хотя может я и не прав насчет неверной интерпретации, посмотрел тут http://beskov.livejournal.com/14493.html, и особенно ссылку в начале таблицы на те комментарии которые приводятся нами в SWEBOK и ... если честно не совсем понял в части Белого ящика -- почему требования к системе отождествляются с проектированием и архитектурой?

analyst_Кстати почему я предлагаю именно вордовский документ и RequisitePro. Потому что только в документе (в противоположность отдельным требованиям в БД) можно хранить такие вещи, как вводная часть, цели проекта, причины инициации проекта, бизнес-анализ, описание заинтересованных лиц, ссылки на другие документы в конце концов.
CaliberRM, в отличие от реквизита, не поддерживает создание требований в документе (он их только генерирует постфактум), а описанные выше вещи в виде требований хранить не очень то приятно :)

тут конечно можно поспорить ;-), особенно на тему "приятно/не приятно" работы с инструментом ... я так без проблем stakeholders/users list хранил в CaliberRM, как и бизнес-требования и т.п. не испытывая неудобств. Ну суть не в этом ... я думаю, что вопрос автоматизации -- он важен, но на первом месте -- собственно "концептуальное решение".