与其他源代码控制相比，我注意到这里有关 MKS 完整性的帖子。有没有人使用 MKS Integrity 来管理需求？最近好吗？如果出现以下情况，我将不胜感激：
我注意到它宣传说它可以做很多其他事情，并可能与其他系统（JIRA、Test Link？）联系起来以协调流程（错误跟踪、测试和覆盖）——集成有多复杂？有人试图报告所有这些集成系统吗？
很多问题可能有很大的答案......我知道......但是任何关于任何一点的评论都会从堆栈溢出宇宙中得到赞赏:)
也许对你来说为时已晚，但我对 MKS-RM 的体验也很糟糕：一块昂贵的垃圾仍然让我们头疼。与其他工具的“集成”主要使用 SCC 接口，特别是在 Windows 7 64 位中，您可能会遇到一些问题，因为到目前为止 MKS 还没有 64 位版本。
与体面的关系数据库甚至 excel 相比，我真的看不到太多收益！
我们在工作中使用 MKS 进行版本控制、问题跟踪和需求管理。这一切都很糟糕。尽可能避免。MKS 需求管理非常缓慢、过于复杂和繁琐。
在与 DOORS 和 MKS RM 合作了 7 年后，我不得不说需求管理总体上被高估了。这只是戴领带的人的一种时尚表达方式。
到目前为止，我从 RM 工具中所看到的，没有什么是像样的 Wiki 引擎做不到的。想想 Redmine：它有 Wiki、问题跟踪和版本控制集成。
这个问题还有另一个方面，即专有工具的高昂价格。我们已经投入了大量工作来满足我们对 DOORS 的要求，然后突然高层管理人员决定退出 DOORS，因为它太贵了。多年的工作或多或少失去了。而且MKS比DOORS贵很多。
与主流观点相反，对开源工具的支持非常好，并且它们在导入/导出和与其他工具一起工作方面要好得多。并且不存在因节省成本而关闭整个工具的危险。