Представим себе ситуацию. Есть компания, большая компания, бизнес которой связан или не связан с ИТ, типа Лукойла, Роснефти, МТС, Люксофт и т.д.
Так вот у них много подрядчиков, в том числе на разработку ПО и в частности на разработку ТЗ и требований. Так же есть свое подразделение Разработки, которая пишет ПО, разрабатывает требования. Компания хочет ревьюировать внешние ТЗ и создавать у себя базу знаний требований, чтобы была возможность безболезненного смены подрядчика и следовательно чтобы у них всегда была актуальная база требований.

Как в таком случае можно управлять требованиями, а скорее кучей приходящих ТЗ??

Есть три варианта:
1. Принимать ТЗ и складировать их у себя в проектных папках. Но тогда встает вопрос про связывание требований, их синхронизации и прав доступа
2. Принимать ТЗ из вне и тупо перебивать их в СУТ (система управления требований). Тогда быстро произойдет рассинхронизация
3. Заставить подрядчиков работать во внутренней СУТ. Вариант хороший, но какие есть подводные камни??

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

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

Пример не о СУТ, но, на мой взгляд, ситуация похожая.

У нас, например, есть два трекера запросов - "внешний" на сайте компании (с входом для зарегтистированных партнёров) и "внутренний". Точнее, было два. Внешний уже два года мёртвенький - ни одного запроса. Оглядываясь назад, можно сказать, что это результат нашей недальновидной политики: сначала мы создали этот внешний трекер, чтобы переложить часть работы по сбору требований и учёту запросов на партнёров, а потом обнаружили, что "перевод запросов на человеческий язык" требует ещё бОльших трудозатрат. Поэтому вернулись к старой схеме: собираем запросы многочисленными способами (встречи, телефон, mail, онлайн-мессенджеры), а учитываем их в удобном для нас виде только после "первичной обработки".

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

Тут я должен отметить, что практически не знаком с коммерческими системам учёта требований и "большими процессами" типа RUP. Может, в них реализованы некоторые волшебные возможности, которые в конечном итоге позволяют всем участникам разговаривать на одном языке? (честно говоря, слабо верится) Когда-то имел дело с ГОСТами (в испытательной организации-представителя заказчика), но тогда у меня сложилось впечатление (возможно, ошибочное), что работать "строго по госту" могут себе позволить только предприятия ВПК, у которых в избытке ресурсов и которым некуда спешить.

1. Ситуация не похожая. В вашем случае Вы зависите от Клиентов, они вас могут и вправе послать вас ... заполнять самим эти шаблоны. Тут же наоборот - мы диктуем что хотим, а подрядчики исполнят
2. На счет обучения и следования правил. Да ты прав, тут надо как минимум писать регламенты и инструкции
3. Про ГОСТ - это ты зря, выкидываем что не нужно и заполняем действительно ценные разделы, как например цели и задачи

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

Про ГОСТ - это ты зря, выкидываем что не нужно и заполняем действительно ценные разделы, как например цели и задачи

А по моему ничего не зря, что это за ГОСТ из которого все выкидываешь. И опять же о чем речь о ТЗ или о всех спектрах работ и оформлений документаций?
Если только о ТЗ - то слов из песни не выкинешь, а если о процессе по ГОСТ - ну так это же само собой.

Правда еще вопрос ГОСТ какой?

...Так вот у них много подрядчиков, в том числе на разработку ПО и в частности на разработку ТЗ и требований. Так же есть свое подразделение Разработки, которая пишет ПО, разрабатывает требования. Компания хочет ревьюировать внешние ТЗ и создавать у себя базу знаний требований, чтобы была возможность безболезненного смены подрядчика и следовательно чтобы у них всегда была актуальная база требований.
Как в таком случае можно управлять требованиями, а скорее кучей приходящих ТЗ??

1. Компании нужно для начала создать корпоративный стандарт на документацию требований и форму их представления и заставить подрядчиков следовать ему.
2. Компании нужно заставить подрядчиков вносить изменения в ТЗ при их наличии, чтобы требования были актуальны. Т.е. имеем поставленный в компании процесс работы с требованиями вообще.
3. Создать единый репозиторий требований на базе некого тула и загонять все туда. При необходимости давать доступ туда подрядчикам, чтобы сами вколачивали требования.

Такое решение не идеально, т.к. потребует затрат на поддержку репозитория требований, его анализ, связи  ... но, я бы сказал так -- для такой компании для начала нужно бы выстроить EA, потом внедрить процесс управления изменениями (в контексте EA как минимум), и требованиями как таковыми. Тогда станет видна СИСТЕМА и связи м/у различными приложениями, а следовательно и требований к ним. Вот где появится базис для анализа! Очевидно, что при такой постановки вопроса требования будут являться органичной частью этой системы.

Первые три пункта понял

Юра,

Под EA ты видимо имел в виду - Enterprise Аrchitecture

В общем, в данном случае относительно требований надо продумать политику (регламент) их изменения + построить первоначальный репозиторий требований, так?

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

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

Первые три пункта понял
Юра,
Под EA ты видимо имел в виду - Enterprise Аrchitecture
В общем, в данном случае относительно требований надо продумать политику (регламент) их изменения + построить первоначальный репозиторий требований, так?
Ну тут как раз и очень вероятна рассинхронизация, если не давать доступ к тулзе подрядчикам. Или при изменении требований подрядчики должны оповестить что и где поменялось??

Да, соори забыл что под EA еще можно понимать тул от Sparx :-), я имел ввиду именно Enterprise Architecture.
Худшим для организации, с т.з. затрат будет случай, когда подрядчики просто приносят новую версию ТЗ в виде файла Word, и нужно сажать аналитика (можно конечно стажера), который скурпулезно будет изучать документ, выяснять что изменилось и делать правки руками в репозитории требований. Это просто получается трудоемко. Но за все приходится платить, удешевить можно, только работой стажеров :-).
Вобщем идеальный вариант -- навязать подрядчикам использование процесса, формата и правил документирования требований и использование репозитория с тулом. Типа условие контракта. Иначе -- самим придется все отслеживать.
По середине вариант -- формальный процесс управления изменениями (в отношении требований в данном случае), тогда все изменения будут очевидны и не потребуют скурпулезного изучения каждый раз новой версии документа.

Юра,

Можешь раскрыть - что ты конкретно понимаешь под "формальный процесс управления изменениями (в отношении требований в данном случае)"??

Думаю, что это управление конфигурациями, которое Йордон считает самым главным процессом в безнадежных проектах. Configuration management в RUP. И я с ним согласна.

Это я тоже понял, я представляю процесс изменений и ЖЦ требований.
Но что именно Юра предлагает добавить в простой процесс внесения изменений в требование и отправку ее на разработку и тестирование??

В данном случае речь идет о том, что прежде чем изменить требование (непосредственно в документе или в репозитории, в данном случае не столь важно) - нужно внести некое предложение по изменению и пройти формальный approvement (с анализом конечно) по каждому изменению. Тогда становиться очевидным, КАКИЕ пункты документа (или items в репозитории) должны измениться. После утверждения - это изменение вносится. Предусловия -- требования должны быть recognisable, т.е. должны быть построены по определенным правилам (например иерархия + правила формулировка) и иметь свой ID. Тогда процесс внесения изменений упрощается в разы, особенно если сравнивать с ситуацией, когда приходит слабоструктурированный текст ТЗ в документе, где идентифицируются только разделы.
Как вариант по идентифицируемости требований -- старый добрый способ нумеровать подпункты для каждого отдельного statement в ТЗ, при этом подходе уже можно к чему-то адресоваться при изменениях. И для больших контор с советским прошлым такой формат написания ТЗ протащить легче ибо он часто использовался при написании ТЗ.

Юра,

Теперь понятно. Спасибо.

Возможно, имеет смысл завести СУТ для относительно редко изменяющихся высокоуровневых бизнес-требований, количество которых измеряется десятками, а также первичных документов, из которых они взяты (протоколов интервью, схем БП, анкет, регламентов, бланков и т.д.). И требовать от исполнителей общаться по бизнес-требованиям только через эту СУТ. В качестве подобной СУТ подойдёт практически любая wiki-подобная система. Например TikiWiki (http://info.tikiwiki.org/tiki-index.php), в ней поддерживается история редактирования.

А системные требования дать на откуп исполнителям: всё равно их чаще всего пишут неправильно, перемешивая с домыслами и элементами архитектуры, и если один исполнитель начнёт изучать системные требования, написанные другим, получится вдвойне испорченный телефон.

Вообще на входе требований в головную организацию должен быть выстроен жесткий процесс ревью требований с соответствующими шаблонами, регламентами и жестким контролем, тогда без разницы о каком уровне требований мы говорим.
На роль СУТ в данном случае может претендовать один из известных Wiki движков.