Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Есть вопросы..

ЩЕ>Сразу оговорюсь, что я посмотрел Калибер, многое в нем понравилось, но также и кое-чего нет.
ЩЕ>Сейчас попытаюсь описать идеальную систему управления требованиями, как я себе её вижу, для своего проекта. И хотелось бы получить затем коментарии двух видов.

ЩЕ>Итак, пусть у нас есть проект
ЩЕ>АВТОМОБИЛЬНЫЙ ЗАВОД.

ЩЕ>Этот проект состоит из бизнес объектов и приложений, которые собираются из этих бизнес объектов.
ЩЕ>Мы имеем объект КРЕСЛО
ЩЕ>и приложения ЛЕГКОВОЕ АВТО и МАРШРУТКА :
[........]

На самом деле я увидел в Вашем письме два направления мыслей:
1. структурную организацию требований без привязки к ИТ.
2. анализ проблемы создания конкретной прикладной системы с точки зрения ее архитектора/разработчика

Однако, с моей точки зрения, Вы пытаетесь решить вопрос (1) с точки зрения (2), т.е. если "переврать" описанные идеи — есть взгляд на организацию иерархии и атрибутики требований с точки зрения ОО-проектировщика (набор классов с атрибутами, изменямыми в run-time и т.п.) Первая аналогия, пришедшая в голову — обсуждение плюсов и минусов можественного наследования, применения интерфейсов и ссылок и т.п.

Я попытался набросать утрированный пример в CaliberRM:
(к вопросу о четкости — изображение 1024x768, так что IE его уменьшает автоматически — используйте кнопку IE "Expand to regular size")

Идея состоит в том, что вместо явного присутствия ссылки в дереве требований (как у Васм представлено в tree view [link]), я вынес это на уровень трейсов. В этом плане сама концепция Traceability в requirement Management является одним из ключей к превращению процесса работы над требованиями в нечто управляемое и версионируемое. Соответственно при генерации отчетов они могут присутствовать (все зависит от Вашего шаблона) в спецификации "изделия".

Таким образом сразу дерево требований по количеству вхождений в него уменьшается в разы (если не на порядок).
Я не стал строить N-е кол-во моделей автомобилей и комплектующих, но надеюсь что моя идея понятна

Да, безусловно для разных типов требований (например Вы можете завести отдельные категории комплектующихз или даже разные проекты, связанные через трейсы...) Вы моежет задасть разные custom-атрибуты и их группы, видимые в зависи мости от прав конкретных групп пользователей.

Что касается количественных ограничений — если не ошибаюсь (не сверялся с документацией) в одном проекте м.б. до 256 типов требований. Когда к нам пришел запрос по использованию Caliber для поддержки управления изменениями в одной достаточно крупной ИТ-службе — попытался залить (тестовый "залив" делал из маленького приложения, обращавшегося к Caliber 5.1 через его SDK) в один проект около 15 тысяч требований по 5 категориям — проблем не встретил.

Ряд европейских производителей автомобилей использует Caliber именно для описания требований к моделям.
Кстати, для управления требованиями именно к ПО по отношению ко всем пользователям Caliber отношение, думаю, будет не больше чем 2:3 (если не 50:50). Потому как очень многие компании используют его для определения функциональности промышленных изделий (автомобили, телефоны и т.п.), кто-то — для описания внутрикорпоративных бизнес-процедур, ..... — чего только не слышал от коллег из Европы и Штатов.

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

ЩЕ>+ очень хотелось бы (но это непринципиально), чтобы система содержала в себе сразу управление рисками, багтрекинкг, планировщик работ (аля МС-Прожект) и чтобы все это было интегрировано в одно приложение.

Это уже специализированный модуль ERP получается (например, SAP)

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

Трейсы могут вести в систему управления проектами (MSProject), SCCM (для StarTeam можно делать трейсы на файлы, CR и в частности дефекты, задачи и т.п.), средства оценки рисков (напримре, Estimate Pro).
Кроме того — есть SDK, позволяющий создавать хоть своего клиента (например, простейший пример клиента на ASP есть на Borland CodeCentral).

если что-то упустил, прошу извинить — еще раз перечитаю на свежую голову и попытаюсь, если необходимо, детализировать

С уважением,
Сергей Орлик
Borland