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