用于快速收集与设计重叠的需求的工具和技术

Question

在瀑布式的环境中，我读过很多关于正式需求收集的知识，并且学到了很多:花几个月的时间研究用例，将它们转化为规范，并最终交付一个没人想要的臃肿的crapware。

我现在从事的项目有几个特点:利益相关者是学者，开发团队非常小(2-3 FTE)，总体时间框架很短(3-9个月)，利益相关者在产品的最终形状上相当灵活。(他们要求A，B和C，但得到A，X和Z-没有问题。)我们通常会定期接触利益相关者，如果有限的话:比如每周1小时。

上述情况的一些后果：

• 我们需要在风险承担者访谈时间10小时内获得编码，通常更少。
• 我们可以在整个过程中继续收集需求，
• 范围非常灵活。时间和预算是固定的，但是范围是在时间用完时完成的。

显然，我们使用的是敏捷方法，但是由于团队成员是非常动态的，因此没有真正的机会来构建一个坚实的scrum过程。

在我担任PM/client联系人的过程中，我养成了一种习惯，使需求收集电子表格(Google )的类别如下：

• “我们现在就可以实现”(我们认为我们已经很好地理解了它，并且定义了“
• ”更多的细节/工作，需要“
• ”低优先级“(通常是一个用户曾经提到的东西，但后来我们就没听说过)
• ”要继续讨论的大特性“(一个重要的新特性集，特别是与其他功能的集成)。通常这些都会很好，但我们只是不知道能否及时完成--在这种情况下，我们不应该开始)

。

我的“方法”没有解决的问题，我很想听听关于以下问题的建议：

早期捕捉显示停止器--发现严重限制我们选择platform/technology/solution/...

• Structuring的需求，并安排未来的需求收集会话，这样我们就可以在某个特性集上工作多长时间，然后才能到达uncertainty.

• Knowing的迷雾中，是否有足够高的优先级，它肯定会被削减(如果没有，请不要花更多的时间来研究)

• 管理可以在不同程度上开发的相互依赖的features

• Managing特性集(例如，以30%的成本获得80%的收益--我们如何知道是否应该使用其他的70%?)

• Managing选项(在一种情况下，我们是实现身份验证机制X还是Y)--这两者都没有多大好处，但both)

• Dependencies:经常存在很大的不确定性，在我们了解用户如何在问题跟踪器中的“需求”和“问题”之间对X.

• Relationship作出反应之前，开始实现Y是没有意义的。您是否只是将所有内容都抛到跟踪器中，并在了解更多问题时不断更新这些问题，可能会拆分或合并这些问题？

所以-我很想听听其他人是如何处理这些问题的。搜索“需求工具”并没有发现什么有用的东西--只是一堆企业级的桌面用例工具。

Answer 1

在我看来，您需要与涉众/业务/客户端进行更多的交互，以便1.为特性排序，2.为UAT创建一个测试计划，以便您知道何时可以停止添加特性。

只要您可以说有一组核心功能是必要的，并且会使用户感到高兴，那么灵活的范围就可以了。你说当你没有时间的时候，这个项目就完成了。那为什么还要做任何事？也许您可以缩小范围，直到您知道什么是绝对必要的功能，如果用户满意，不要费心添加更多。

Answer 2

这似乎也是我们面临的问题。我们使用问题跟踪器(bugzilla)来处理问题和需求。这在新模块的最初开发过程中运行得很好。但是，如果半年后您必须更改某些特性或扩展模块的功能，那么您所拥有的就是一大串完全非结构化的问题和需求。

此外，在讨论问题或需求的过程中提供了许多信息。这意味着要阅读大量的文本，其中大部分是一小部分信息。

因此，在结构化文档(word)中重写需求似乎是目前为止唯一的解决方案。