我已经阅读并接受了很多关于在瀑布式环境中收集正式需求的知识：花费数月时间研究用例，将它们转化为规范，并最终交付一个没有人想要的臃肿的垃圾软件。
我现在从事的项目有一些特点：利益相关者是学者，开发团队非常小（2-3 FTE），总体时间框架很短（3-9 个月），利益相关者非常灵活关于产品的最终形状。（他们要求 A、B 和 C，但得到 A、X 和 Z - 没问题。）我们通常会定期接触利益相关者，如果有限的话：比如每周 1 小时。
以上的一些后果：
- 我们需要在与利益相关者面谈的 10 小时内完成编码，通常更少。
- 我们可以在整个过程中继续收集需求
- 范围非常灵活。时间和预算是固定的，但范围是当我们用完时间时完成的任何事情。
显然我们使用的是敏捷方法，但是因为团队成员是非常动态的，例如，没有真正的机会来建立一个可靠的 Scrum 流程。
在我担任 PM/客户联络员的角色中，我养成了收集电子表格（Google Docs）的需求，其类别如下：
- “我们现在可以实施”（我们认为我们已经足够了解它了，它是定义
- “需要更多细节/研讨会”
- “低优先级”（通常是一位用户曾经提到过的东西，但我们从那以后就没有听说过）
- “要继续讨论的大特性”（一个重要的新特性集，特别是与其他东西的集成。通常这些会很好，但我们只是不知道我们是否能及时完成它——在这种情况下，我们不应该开始。）
我的“方法论”没有解决的问题，我很想听听以下方面的建议：
- 及早发现阻碍因素 - 找出严重限制我们选择平台/技术/解决方案/...的需求
- 构建和安排未来的需求收集会议，以便我们知道在遇到不确定性迷雾之前我们可以在某个功能集上工作多长时间。
- 知道某件事是否具有足够高的优先级，它肯定会被淘汰（如果不是，就不要再花时间调查它了）
- 管理相互依赖的特征集
- 管理可以不同程度开发的功能（例如，以 30% 的成本获得 80% 的收益——我们如何知道是否应该花费另外 70%？）
- 管理选择（在一种情况下，我们是实现身份验证机制 X 还是 Y - 两者都做没有太大的好处，但两者都有很大的不确定性）
- 依赖关系：通常，在我们了解用户对 X 的反应之前，开始实施 Y 是没有意义的。
- 问题跟踪器中“需求”和“问题”之间的关系。您是否只是将所有内容都放入跟踪器中，并在您了解更多问题时不断更新问题，可能会拆分或合并它们？
所以 - 我很想听听其他人如何处理这些问题。搜索“需求工具”没有任何用处 - 只是一堆企业桌面 CASE 工具。