对于受规范环境中的软件开发，是否使用了区分基本需求和详细需求的方法？

Question

这个问题在受管制的环境中更适用。

我们的软件需求存储在Word文档中，这是一个企业范围内的CFR第11部分兼容文档库。这些要求得到许多组织的审查和批准。事实证明，还需要更多更详细的需求来正确实现特性，并在VS2010中进行链接和管理。我们在excel电子表格中使用Word文档中的需求，使用指向测试用例的指针(也存在于文档库中)来进行手动跟踪(此时)。同样，这一过程也有相当多的审查和批准。我们还没有正式将这些称为“基本需求”，但在我看来，它们似乎是必要的需求。软件开发人员和测试人员主要参与在VS2010中管理的需求和相关测试用例的编写、审查和批准。我的问题是:其他人是否处理需求层和相关的可跟踪性，以及如何处理这些问题？

Answer 1

在某种形状或形式上，可追溯性可以在(大部分)每个组织中找到。每个方法都有一些手动的方面，尽管它确实取决于

• 团队愿意付出多少努力，
• 最终结果会用到多少，
• 正在采用何种开发方法/做法，以及
• 每个连接都需要有多细粒度。

在大多数情况下，一般程序是相同的：

1. 创建需求(规范、用例、模型等)，并对其进行扩展和批准。
2. 创建测试计划和测试用例。
3. 然后，测试用例被链接到需求(S)，它的测试/需求被链接到测试它的测试用例(S)。(取决于需求/测试用例的编写方式，这可能是一种多到多的关系)。

Excel是保持这种组织良好的方法，但它可能很脆弱，而且容易出错。如果您的组织愿意投资于可跟踪工具，这将使流程更加简化。这些工具做各种事情，从跟踪需求，后续测试用例，以及在执行测试时发现的错误。他们还将有报告功能，这些功能有助于迅速将状态传达给管理人员。

我亲自使用过以下工具，可以为它们的功能提供担保：

• HP质量中心
• 丝绸之路中央测试管理器(也随发行管理器一起提供)
• 拉力软件

每个工具都可以全部使用，但它们也具有与其他工具同步的能力，因此，如果已经有Jira或Bugzilla用于缺陷跟踪，则可以将测试用例/需求链接到bug。

我妻子以前使用过Bugzilla和试视的免费组合，并且说它很好。(注意:Test胸只用于测试用例管理，因此它稍微偏离了主题，但也应该提到它。)

最后，我想提到行为驱动开发的想法，它直接在源代码中创建链接，因为需求是以一种方式编写的(使用Gherkin语言)，这样它们就可以转化为锅炉代码/模板/测试。我们曾在前一家公司尝试过这一点，这需要业务分析师的大力合作，但进展相当顺利。