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

Мне кажется, что разработчики TFS не предполагали такого его применения. TFS хорошо работает, когда КП (это же "комплексный проект", да, или что-то в таком роде?) - это Project Collection, проект - это Project, требование - это Requirement, если вы работаете по CMMI, или User Story, если по Agile. В вашем случае, судя по всему - CMMI.
А вы смотрели примеры по ссылке Process Guide, которая образуется в корне сайта проекта TFS (шаблон CMMI 5.0) сразу после его создания?

Мне кажется, что разработчики TFS не предполагали такого его применения. TFS хорошо работает, когда КП (это же "комплексный проект", да, или что-то в таком роде?) - это Project Collection, проект - это Project, требование - это Requirement, если вы работаете по CMMI, или User Story, если по Agile. В вашем случае, судя по всему - CMMI.
А вы смотрели примеры по ссылке Process Guide, которая образуется в корне сайта проекта TFS (шаблон CMMI 5.0) сразу после его создания?

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

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

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

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

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

Коллеги, привет. Спасибо за конструктивные ответы. TFS никто не будет ставить.

Про ЧТЗ. В этом на мой взгляд нет смысла, так как разработчикам все равно придется читать гору документации

Про системы  управления требованиями - подумаю. Будут ли еще серебряные пули?

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

Для этого линки типа Affects / Affected by рекомендуется использовать.
Навскидку из форумов: http://blogs.objectsharp.com/post/2012/02/22/Requirements-Traceability-in-Visual-Studio.aspx
С учетом трассировок в TFS все хорошо, с визуализацией - действительно, не очень.
http://mickyd.wordpress.com/2011/06/19/team-foundation-server-has-great-traceability-until-you-need-to-report-on-it/
Но никто не мешает найти какой-нибудь плагин к студии, или написать свой плагин для нужной визуализации. БД TFS имеет достаточно простую структуру и хорошо документирована, сам сервер легко интегрируется, особенно легко - со всеми микрософтовскими продуктами.

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

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

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

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

мелкософт сами признаются, что полноценного функционала СУТ в ТФС нет.

Ну, они обычно так признаются, когда их просят показать, как реализован функционал, например IBMовской линейки FocalPoint -> Doors. Если с чем попроще сравнивать, то спорят

признаться вы меня своим вопросом про process guide поставили в тупик. поковырялся, что-то не нашёл. бегло в инете тоже не нашёл.

Это я ошибся, конечно, не process guide, а Process Guidance. Самая нижняя ссылка в левой колонке сайта проекта TFS, после Team Web Access, Dashboards и т.д.
Ведет по умолчанию (если проект не кастомизирован) для проекта, сделанного по шаблону CMMI 5.0 на ссылку:
http://msdn.microsoft.com/en-us/library/dd997574(VS.100).aspx
Там надо начинать с Artifacts (CMMI).

С Cradle мы связывались. не впечатлил он моё руководство.
у нас требования к интеграции не только в том, чтобы сынтегрить две системы, но и в том, чтобы не сломать существующую аналитику в тфс - отчёты, выгрузки и прочее.
Вчера встречались с IBM - нашли они способ поженить RRC и TFS - есть малоизвестная буржуйская контора - TaskTop - они разработали шину для интеграции RRC и TFS. вчера нам показали архитектуру. вроде всё очень даже устраивает.
что до остальных вопросов - да, мы не ведём учёт атомарных требований в тфс. это чудовищно, понимаю, но это так
Каждый аналитик на своей задаче как ему удобно ведёт учёт требований. или не ведёт. полная демократия)
я пришёл сюда год назад и инициировал эту бучу с RRC.
как костыли перед внедрением СУТ, предложил руководству использовать excel для управления требованиями и генерации реквайрментов в тфс под задачами. кто-то впечатлился, кто-то нет. у нас специфика особая - мы иногда даже предложения по реализации пишем вообще без требований :-) 
что до трассировок в ТФС - это надо потратить довольно много времени и написать все скрипты для минимизации заведения айтемов в нём. под это нет внутреннего заказчика у нас, ибо "и так работает" и требования мы не учитываем в тфс. но если IBM не нашёл бы решения, то, скорее всего к этому бы мы и пришли - продумали актуальную иерархию артефактов тфс с учётом трассирования, визуализировали и прочее.
под любое усовершенствование, внедрение или пересмотр существующего функционала внутри компании-разработчика всегда должен быть внутренний заказчик(потребность в усовершенствовании/Изменении) без этого все предложения обречены на провал.

Вчера встречались с IBM - нашли они способ поженить RRC и TFS - есть малоизвестная буржуйская контора - TaskTop - они разработали шину для интеграции RRC и TFS.

Ага, ну тогда расскажите потом, как оно на практике синтегрировалось, и сколько времени и человеко-месяцев понадобилось. Будет интересен ваш опыт.
У нас интеграция / миграция TFS <-> существующие системы сейчас от 3 до 5 человек требует, и уже поболе 5 человеко-лет затрат скушала. (Согласно оценкам руководства, идет успешо).