Капитан неочeвидностьОдно не понятно. А чем обычный Microsoft Word не устроил? Или не столь обычный, но тоже стилистически, с автонумерацией и в целом таблично-рисунко-ссылочно годный OpenOffice Write?
Нас редакторы документов не устроили тем, что в них неудобно:
1) разрабатывать большие объёмы требований, с разными уровнями детализации, и читать эти документы
2) вести состояния требований в соответствии с ЖЦ требований
3) вести историю изменений и комментарии при согласовании требований
4) организовывать групповую работу над требованиями, в т.ч. workflow согласования, реализации, изменения по запросу
5) искать по требованиям, фильтровать их по опр. признакам
6) пояснять, иллюстрировать, визуализировать требования, создавать модели предметной области и аналитические модели
7) связывать требования между собой и с др. артефактами
8) изменять форму и детализацию представления требований (для разработчиков и QA - одна, для маркетинга - другая, для начальства различных уровней - третья).

Можно, но неудобно.

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

Но: к сожалению, культура работы с документами теряется. Люди, перегруженные информационным мусором, к-рый окружает их со всех сторон, "не осиливают" за раз ничего размером более 20 стр. 12-м кеглем. А короткие выгрузки с нужным уровнем детализации обычно укладываются в этот объём, их "осилить" легче, и есть больше шансов, что они это сделают, а не пропустят всё, "плюнув в будущее".

С другой стороны, у "hand-made" документов и требований есть свои плюсы. Системные аналитики, вынужденные постоянно проходиться по документу с требованиями, изучают его чуть ли не наизусть. Отсутствие автоматизированной системы иногда позволяет сделать работу менее формальной, более гибкой. Да и заказчики требований работают быстрее и ответственнее, когда с требованиями к ним приходит живой аналитик, а не письмо от системы управления требованиями.

ЮВ,
спасибо, использовали RequisitePro, CaliberRM, Enterprise Architect + RaQuest. Пока остановились на последнем. Хотя все эти системы тоже не очень-то удобны: то одного нет, то другого.