Без заголовка

1. Нет, симултрек у меня -- набор информационных моделей деятельности организации, а не "требования". В симултрек входят прикладные модели (зависящие от предметной области деятельности -- модель картошки в поле, самолета в небе и т.д.) и организационные модели (структура, процессы, финансы, люди и т.д.). В подтверждение того факта, что я знаю о существовании управления требованиями (даже не по отношению к софтверным проектам), я приведу свой старый пост по управлению реформами -- там оно прописано явно: http://ailev.livejournal.com/398953.html 2. Поэтому требования (на входе), работы (в процессе) а также конфигурации (на выходе) вместе с их "управлениями" являются составными частями для симултрека. И это в том случае, когда на выходе -- именно "конфигурации" (продукты), а не сервисы! Скажем, JIRA вполне может управлять issues в сервисных организациях (где issues могут пониматься как запросы на сервис, например). 3. Нет такого продукта, который хорошо бы делал управление требованиями, работами и конфигурациями (сейчас это три разных класса продуктов). 4. предполагаю, что управление требованиями и конфигурациями можно было бы сделать вокруг управления работами (в варианте JIRA, когда работы возникают вокруг issues -- в отличие от классического управления проектами, где работы возникают псевдостатически в виде WBS) и моя гипотеза была в том, что как управление требованиями, так и часть самой конфигурации (а именно -- файлы документов) можно было бы реализовать на wiki. 4. Понятно, что в мире хватает разных попыток объединить неообъединяемое, или приспособить неприспосабливаемое. Вот, например, http://www.codeproject.com/aspnet/OpenCollective.asp Мне бы хотелось предпринять какое-то более системное усилие, не на уровне "просто кодирования". Меня заботит методологическая сторона вопроса. 5. И важно еще отметить, что у меня в голове прежде всего несофтверные проекты, ибо для чисто софтверных проектов существуют и разные другие решения (основанные на том, что результат работ -- это набор файлов программ и тестов). 6. А чтобы еще запутать дело, сообщу, что в голове у меня даже не столько проекты, сколько программы -- совокупности проектов, выполняющиеся одновременно на одном и том же множестве ресурсов.