что входит в понятие "управление требованями":
- выявление "бизнес-требований" заказчиков; не только "пассивный" сбор, но и "активное" предложение, например, разработка и утверждение UC
- систематизация, приведение их к "системным требованиям"
- оценка сложности, ценности, приоритета реализации требований, создание baseline'ов ("планов выпуска") продукта
- постановка задач на основании системных требований, учёт требований при проектировании реализации
- написание тестовых сценариев на основании требований
- написание тех. документации и маркетинговых материалов на основании требований (в основном UC)
...
и ещё многое другое - см. Леффингуэлла, Вигерса, Коберна, RUP.

что подразумевает "система управления требованиями":
- грубо говоря - многопользовательскую БД с информацией о требованиях;
- процедура работы с требованиями при разработке ПО, жизненный цикл требований
...
и ещё многое другое - см. RequisitePro, CaliberRM, DOORS, EnterpriseArchitect.

ist-stylishА если бы Вы сами писали систему управления требованиями, на какие моменты обратили бы внимание прежде всего? что в ней самое важное?
Чтобы системой было удобно пользоваться:
- аналитикам - вводить, искать, трассировать;
- программистам - просматривать на досуге;
- менеджерам - сводить в baseline, генерировать внушительные документы.
Хорошо бы, чтобы можно было настраивать ЖЦ требований, вести по ним обсуждения прямо в системе. И чтобы в эту систему можно было импортировать информацию из уже существующих.

А в идеале хотелось бы видеть требования, задачи, модель и ошибки в одном месте, и чтобы их можно было связывать друг с другом. Причём чтобы велись они как в хороших специализированных продуктах.
Вот бы в Power Designer можно было вести требования, как в CaliberRM, сделать на их основании планы, как в MS Project, и тут же хранить ошибки, как в Bugzilla. Хорошо бы и код с отладкой туда же, и контроль конфигурации для всего этого хозяйства, и администрирование не слишком сложное. Но такого монстра точно нормальным сделать нельзя, обязательно многое будет "недо" - TFS и StarTeam подтверждают:) .

ist-stylishв этой связи еще один вопрос возникает, какая лучше всего субд для самописной системки подходит? какие параметры критичны?
Любая современная многопользовательская. Наверное, даже файл-серверная. Требований обычно - до тысячи, и читают их значительно чаще, чем изменяют. Даже с историей изменений - всего-то десятки тысяч записей.
А зачем писать самим? Чем существующие не устраивают? Если только ценой - то есть GPL, например: OSRMT .