Коллеги, не знаю сюда ли моя тема. Если что извиняйте

Суть проблемы. Есть объемная система состоящая из нескольких больших модулей. На каждый из модулей есть ЧТЗ страниц не менее 100 в каждом. Система не стоит на месте развивается добавляются новые фичи. И вот столкнулись с проблемами:

1) Каждая вторая из новых фич затрагивает не только модуль в котором должна быть реализована но и краем - другие модули. Естественно анаитики пишут требования к одной фиче  одновременно в нескольких ЧТЗ.

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

3) Разработчикам очень тяжело пролистывать несколько сотен страниц чтобы добраться до нужных требований.

Несомненно кто-то уже сталкивался с подобными проблемами. Вопросы следующие:

1) Что можно сделать с точки зрения изменений в процессах описания требований, чтобы в один момент времени Система соответствовала документации и наоборот.
2) Как упростить жизнь программистам чтобы до необходимых им требований можно было бы легко добраться

Заранее спасибо за конструктивный и дельный ответ.

>1) Каждая вторая из новых фич затрагивает не только модуль в котором должна быть реализована но и краем - другие модули. Естественно анаитики пишут требования к одной фиче  одновременно в нескольких ЧТЗ.
Имхо это правильно.

> 2) Есть вероятность, что требования по каждой, допустим, 4й из фич не будут реализовываться именно в этой фазе а в следующей или через одну. Но записать их куда-то тоже надо
Как вариант, указывать для каждого требования фазу. Может быть, кто-то ещё варианты подкинет...

> 3) Разработчикам очень тяжело пролистывать несколько сотен страниц чтобы добраться до нужных требований.
А куда денешься? Ну попробуйте разбить на более мелкие документы...

На мой взгляд, логичный вариант -- отдельный небольшой документ с требованиями на доработку этого базового модуля. Если доработки оказывают влияние на другие модули -- указать в документе.

А вообще, я бы сначала настроил правильное именование документов.

Например,
ТЗ 00 -- Общее ТЗ на всю систему
ТЗ 01 -- ЧТЗ [Название модуля]
ТЗ 02 -- ЧТЗ [Название модуля]

Документы с требованиями на доработку:

ТЗ 011 -- [Название дорабатываемого функционала в базовом модуле 1]
ТЗ 021 -- [Название дорабатываемого функционала в базовом модуле 2]
...

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

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

В своем ответе, конечно же, я имел в виду отсутствие СУТ.

Не совсем понял это:

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

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

Вроде бы TFS включает в себя систему управления требованиями, трассировки требований там реализованы.

ахаха))) вы делаете мне смешно
к сожалению, ТФС не располагает никакими средствами управления требованиями. только, как я выше написал, excel и ведение матриц трассировок ручками с синхронизацией с айтемами ТФС.

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

ТФС совершенно не заточена под анализ и не предполагает управление требованиями. политика ТФС в том, что аналитики и архитекторы выступают для разработки и тестирования в роли заказчиков и формируют "требования" - таски на разработку. в этапах разработки и тестирования ТФС хорош. многие процессы он автоматизирует и упрощает.
но в качестве системы управления требованиями он вообще никакой.
в нашей компании вопрос управления требованиями стоит очень остро и я ответственный от аналитики по реализации СУТ у нас. мы уже полгода ведём переговоры с IBM но пока поженить их СУТ с TFSdoc не получается. завтра, вот, они встречу организовали - может нашли решение.
Майкрософт мне написал следующее: да, ТФС в этом плане некомильфо, юзайте решения, интегрированные с TFS
http://www.edevtech.com/products.html
 http://www.technosolutions.com/topteam_analyst.html

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

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

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

ахаха)))ТФС совершенно не заточена под анализ и не предполагает управление требованиями. политика ТФС в том, что аналитики и архитекторы выступают для разработки и тестирования в роли заказчиков и формируют "требования" - таски на разработку.

Ссылки интересные, спасибо, почитаем.
Для анализ и разработки требований у нас Sparx Enterprise Architect, затем самопальная утилита конвертирует их в TFS. Шаблон проекта от Microsoft MSF for CMMI 5.0 со своими доработками вроде бы обеспечивает устраивающую всех трассируемость требований - от бизнес-требований продуктового департамента до системных и требований к компонентам. Таски для разработчиков (Work Item Type = Task) подвешиваются под требования (Work Item Type = Requirement).
Воркфлоу тасков и требований разных типов разный.
А у вас, как я понял,  Work Item Type = Requirement и Work Item Type = Change Request не используется?

с айтемами понимаю, а зачем Вам документы туда-сюда таскать? Может достаточно одного места для хранения документов, по такой схеме

Документы (СУТ) <-> items (СУТ) <==> items (TFS)?

документы таскать туда-сюда нужно, ибо помимо аналитики есть архитектура, разработка и тестирование.
фишка в том, что в СУТ артефактом является требование или его реализация в виде ФТ или ВИ или TC. СУТ оперирует на уровне этих сущностей. при необходимости из артефактов собирается документ по шаблону.
ТФС же хранит артефакты как документы. плодить айтемы в ТФС под каждую задачу, когда у нас, бывает, МТС по сотне требований в рамках одной задачи выкатывает за аналитическую фазу, а задач в релизе - несколько десятков - не совсем удобно и опасно для головы. особенно учитывая ту форму, в которой айтемы живут в ТФС.
другими словами, как реализовать общий процесс для всей разработки, а не только для архитектуры и анализа: если мы оперируем уровнем артефактов СУТ, то они должны быть доступны на любой стадии процесса разработки, если мы от них отказываемся, то нужно придумать, как жить с двумя независимыми системами. в общем, проблема пока не поддаётся решению средствами IBM. посмотрим, что они завтра скажут

Ссылки интересные, спасибо, почитаем.
Для анализ и разработки требований у нас Sparx Enterprise Architect, затем самопальная утилита конвертирует их в TFS. Шаблон проекта от Microsoft MSF for CMMI 5.0 со своими доработками вроде бы обеспечивает устраивающую всех трассируемость требований - от бизнес-требований продуктового департамента до системных и требований к компонентам. Таски для разработчиков (Work Item Type = Task) подвешиваются под требования (Work Item Type = Requirement).
Воркфлоу тасков и требований разных типов разный.
А у вас, как я понял,  Work Item Type = Requirement и Work Item Type = Change Request не используется?

ну так это не ТФС, а EA+ самопал.
у нас почти такой же процесс. только без ЕА. я модельки в нём набиваю, но смутно представляю себе как вести учёт и трассировку требований к проекту в нём. когда совсем задница мы в екселе ведём трассировки с синхронизацией с ТФС.
а так пока управляем требованиями с помощью силы головы и какой-то матери
а можно подробнее про ваш процесс управления требованиями и EA?

Таски для разработчиков (Work Item Type = Task) подвешиваются под требования (Work Item Type = Requirement).
Воркфлоу тасков и требований разных типов разный.
А у вас, как я понял,  Work Item Type = Requirement и Work Item Type = Change Request не используется?

у нас не совсем так. подписанный с заказчиком КП делется на requirements, каждый проект живёт под requirement, под ним задачи на предложение по реализации, HLA, ПМИ, разработку по модулям, подсистемам и прочее формируются в виде leadtask.
CR-ы - да, мы не используем.