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