TrackStudio - интересная штучшка, во всяком случае по описанию более чем.
Но опять же: Как на счет генерации документации??

Вот как и обещал иерархия требований.
Надо еще добавить раздел: Functional Requirements

TrackStudio - интересная штучшка, во всяком случае по описанию более чем.
Но опять же: Как на счет генерации документации??

Там есть Detailed report, есть экспорт в XML/MS Project. Думаю, из всего этого что-нибудь можно смудрить. По крайней мере я видел очень симпатичные отчеты на основе обработки этим XML-ек через XSLT.

Я бы еще разделил на Пользовательские требовния и Функциональные .. по классике ;-)

Ну, я тоже этим баловалась, и могу сказать следующее: там, где не нужно общего доступа к отдельным файлам, хранимым в репозитории (модели, документы, требования) - wiki вполне применима.
Но в условиях часто изменяемых требований и большого объема проектной документации (+ состыковка нескольких аналитиков, создающих модели, между собой) - не самая удобная вещь.
Оптимальным лично мне кажется другой вариант: wiki - как инструмент первичного ("быстрого") сбора требований от заказчика, и дальнейшее использование уже более-менее привычной системы, предназначенной для управления требованиями.
Кстати, преимущество wiki - только возможность доступа к ней отовсюду. А вот что касается управления контентом в ней, прав доступа, многоязычности и т.д. - здесь у wiki скорее проблемы, чем преимущества.

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

Так все прямо в Вики и надо писать, а не в виде вордовых файлов выкладывать. Тогда все проблемы уходят. остаётся только одновременное изменение моделей. Но тут наверное можно прикрутить SVN какой нить.

Кстати, преимущество wiki - только возможность доступа к ней отовсюду. А вот что касается управления контентом в ней, прав доступа, многоязычности и т.д. - здесь у wiki скорее проблемы, чем преимущества.

Преимущество здесь одно - цена. Т.к. многие системы УТ имеют веб интерфейс. А все перечисленные проблемы в Вики решаемы.

... многие системы УТ имеют веб интерфейс....

Разве? Например?

Разве? Например?

Requsite, DOORS/Net точно имеют, а про Caliber точнее скажет Юра.

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

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

Ну не "почему-то", а вполне понятно - под веб нужны другие проектировщики с другими мозгами, а на вторую команду денег нет.

Так все прямо в Вики и надо писать, а не в виде вордовых файлов выкладывать. Тогда все проблемы уходят. остаётся только одновременное изменение моделей. Но тут наверное можно прикрутить SVN какой нить

Да мы, в общем, так и сделали в конце концов - я же говорю: для того, для чего wiki можно использовать, она использовалась.
Но у wiki (в отличие от Requisite Pro + SoDa) есть один недостаток: эта система не выгружает текст, который вбит в нее, в документ Word (и потому Вам придется либо руками переносить все в Word, либо исхитряться скрестить Wiki и DocBook какой-нибудь, когда заказчик у Вас потребует все-таки какой-нибудь отчетик ему настрочить и документик в красивой синей папочке (Blue Book - для тех, кто понимает) на стол положить.
Вот тогда будет сложно, конечно. До тех пор - все ништяк.

А все перечисленные проблемы в Вики решаемы.

Да, решаемы. Я знаю. Но - трудоемко. Если деньги, уплоченные мне за все то время, которое я буду тратить на решение этих проблем, пустить на цели приобретения софта, боюсь, что мы наскребем на лицензию Rational Software :-)

Если деньги, уплоченные мне за все то время, которое я буду тратить на решение этих проблем, пустить на цели приобретения софта, боюсь, что мы наскребем на лицензию Rational Software :-)

MS Word стоит дешвеле :-), его и пользовать для целей создания ДОКУМЕНТАЦИИ требований.

MS Word стоит дешвеле :-), его и пользовать для целей создания ДОКУМЕНТАЦИИ требований.

Если говорить серьезно, то есть "примочка" к MS Word у Sybase, она входит в пакет Sybase Power Designer. Там есть макросы специальные для Word, они позволяют помечать требования как требования и даже связывать их с определенными элементами модели. Это не полоноценное управление требованиями, конечно, но уже почти Borland-овского уровня продукт (ну и цели, наверное, тоже общие: RAD - он порождает некий общий концепт, однако).

2 Наталья Желнова
Ну у Вики я вижу одну большую проблему - генерация документа. Но никто этим не занимался, плагин я думаю написать недолго.
Все остальное решаемо без больших трудозатрат:
1. Трассирока - шаблон или в Confluence есть ссылки прям
2. Атрибуты - шаблон
3. Права - есть во многих Вики
4. Что еще??

Если говорить серьезно, то есть "примочка" к MS Word у Sybase, она входит в пакет Sybase Power Designer. Там есть макросы специальные для Word, они позволяют помечать требования как требования и даже связывать их с определенными элементами модели. Это не полоноценное управление требованиями, конечно, но уже почти Borland-овского уровня продукт (ну и цели, наверное, тоже общие: RAD - он порождает некий общий концепт, однако).

Ну до Borland CaliberRM, (а так же DOORS и ReqPro) по функциональности он не дотягивает явно. Requirements там скорее как опиция, а основные фичи -- это проектирование.