<分区>
我注意到这里有关于 MKS Integrity 与其他源代码控制相比的帖子。有没有人使用 MKS Integrity 来管理需求？最近好吗？如果有任何关于它的见解，我将不胜感激:
我注意到它宣传它可以做很多其他事情，并且可能与其他系统(JIRA、Test Link？)结合以协调流程(错误跟踪、测试和覆盖)——集成有多复杂？有人试图跨所有这些集成系统进行报告吗？
很多问题可能有很大的答案......我知道......但是任何关于任何一点的评论都会受到堆栈溢出宇宙的赞赏:)
最佳答案
我们在工作中使用 MKS 进行版本控制、问题跟踪和需求管理。 这一切都非常糟糕。尽可能避免。 MKS 需求管理非常缓慢、过于复杂和繁琐。
在使用 DOORS 和 MKS RM 工作 7 年后，我不得不说需求管理通常被高估了。 这只是人们打领带时流行的一种表达方式。
到目前为止，我从 RM 工具中看到的是，没有什么是像样的 Wiki 引擎做不到的。 想想 Redmine:它具有 Wiki、问题跟踪和版本控制集成。
这个问题还有另一个方面，即专有工具的价格过高。 我们已经投入大量工作来满足我们对 DOORS 的需求，然后高层管理人员突然决定淘汰 DOORS 因为它太贵了。多年的工作或多或少地丢失了。而且 MKS 比 DOORS 贵很多。
与主流观点相反，对开源工具的支持非常好，而且它们在导入/导出和与其他工具的协同工作方面要好得多。并且不存在因节省成本而关闭整个工具的危险。
关于integration - MKS 完整性要求，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7250269/