需求规范的初稿已经完成，现在是评估需求、审查规范的时候了。此过程的一部分是确保规范中没有相当大的差距。不用说，这些差距会导致估计非常不准确、项目后期不可避免的范围蔓延，并最终导致死亡行军。
有哪些好的、有效的技术可以用来确定缺失的和隐含的需求？
我很高兴重新访问已接受的答案，只要有人提交更好、更全面的解决方案。
就我而言，与客户进行持续、频繁、坦率和双向的沟通是我认为的主要“技巧”。
这取决于。
这取决于您是否因交付您所说的交付或向客户交付高质量软件而获得报酬。
如果是前者，只需消除规范中的歧义，然后构建您同意的内容。尽量远离任何不可衡量的事物（如“快速”、“酷”、“活泼”等）。
如果是后者，Galwegian 所说的 + 时间，或者干脆削减一切并非绝对关键的东西，并尽快建立它。生产有一种非凡的方式来阐明您在分析中遗漏的内容。
以下是您如何找到缺失的要求。
将需求分解为微小的增量。真的很小。可以在两周或更短的时间内完成的东西。你会发现很多空白。
优先考虑那些最好先拥有的东西，其次才是真正无关紧要的东西。你会发现一些空白填充物并不重要。您还会发现一些最初的“要求”仅仅是可取的。
辩论关于什么对最终用户最重要以及为什么最重要的意见分歧。两个用户会有三种意见。你会发现有些用户没有头绪，他们的“要求”都不是必需的。你会发现有些人没有脊梁骨，不敢大声说出来的话是“必须的”。
只对前两三个达成共识。不要争论每一个细微差别。想象软件是不可能的。任何人都无法想象软件会是什么样子以及他们将如何使用它。大多数人的“要求”描述了如何努力解决他们今天所坚持的不充分的业务流程。
首先构建优先级最高、最重要的部分。给用户。
转到 1 并重复该过程。
“等等，”你说，“总预算呢？” 怎么样？你永远无法知道总预算。请执行下列操作。
查看步骤 1 中定义的每个增量。提供每增量价格。按优先顺序。这样人们就可以随心所欲地挑选。没有大而可怕的“有很多零的大预算估算”。都是可以商量的。
我一直在使用一种称为行为工程 (bE) 的建模方法，它使用原始规范文本来创建结果模型，当您拥有模型时，更容易识别需求的缺失或不完整部分。
到目前为止，我已经在大约六个项目中使用了该方法，从不到 100 个需求到超过 1300 个需求。如果您想了解更多信息，我建议您访问www.behaviorengineering.org，那里有一些关于该方法的非常好的论文。
我工作的公司创建了一个工具来执行建模。实际创建模型的工作量大约是新手 5 个要求，专家每小时大约 13 个要求。该方法的一个很酷的地方是，您不需要真正了解规范所针对的领域的任何信息。仅使用名词和动词等用户文本，建模者将在很短的时间内发现模型中的空白。
我希望这有帮助
迈克尔·拉森
相对于通用/整体模型评估模型元素的生命周期，例如
acquisition --> stewardship --> disposal
为了对规范中实体的生命周期进行更细粒度的分析，为需求中的主要实体制作 CRUDE 矩阵；这是一个矩阵，其中操作/应用程序作为行，实体作为列。在每个单元格中，如果应用程序创建实体，则放置一个 C，R 代表读取，U 代表更新，D 代表删除，或 E 代表“编辑”；“E”包含 C、R、U 和 D（大多数“主表维护”应用程序将是 Es）。然后检查每一列的 C、R、U 和 D（或 E）；如果缺少一个（E除外），请确定是否需要。矩阵的行和列可以重新排列（手动或使用亲和力分析）以形成通常对应于子系统的实体和应用程序的凝聚力组；这可能有助于以后的物理系统分布。
将“用户”实体列添加到 CRUDE 矩阵并为每个应用程序（或特性或功能区域或任何您想要调用的需求的处理/行为方面）指定它是否从用户那里获取输入也是有用的，为用户生成输出，或与用户交互（我为此使用 I、O 和 N，并且始终将用户设为第一列）。这有助于确定需要用于数据输入和报告的用户界面。
目标是检查规范的完整性；上述技术可用于检查实体的生命周期是否相对于已识别的实体和应用程序“关闭”
建立一个原型怎么样？
在阅读大量有关软件需求的文献时，我发现了这两本有趣的书：
问题框架：分析和构建软件开发问题迈克尔杰克逊（不是歌手！:-)。
实用软件要求： Bendjamen Kovitz 的内容和风格手册。
这两位作者确实从人群中脱颖而出，因为在我看来，他们正在做出非常好的尝试，将需求开发变成一个非常系统的过程——更像是工程而不是艺术或黑魔法。特别是迈克尔杰克逊对真正需求的定义——我认为这是我见过的最清晰、最精确的定义。
我不会为这些试图在此处的简短帖子中描述他们的方法的作者提供良好的服务。所以我不会那样做。但我会尝试解释，为什么他们的方法似乎与您的问题极为相关：它允许您将大部分（不是全部，而是大多数！）需求开发工作归结为处理一堆清单*告诉您您必须定义什么要求才能涵盖整个客户问题的所有重要方面。换句话说，这种方法应该将遗漏重要需求（包括那些经常保持隐含的需求）的风险降到最低。
我知道这听起来像是魔术，但事实并非如此。找到那些“神奇”的清单仍然需要大量的脑力劳动：你必须首先阐明客户的问题，然后彻底分析它，最后将其分解成所谓的“问题框架”（这些神奇的仅当它们与作者定义的一些典型问题框架非常匹配时才使用检查表）。就像我说的，这种方法并不能保证让一切变得简单。但它绝对承诺使需求开发过程尽可能系统化。
If requirements development in your current project is already quite far from the very beginning, it may not be feasible to try to apply the Problem Frames Approach at this point (although it greatly depends on how your current requirements are organized). Still, I highly recommend to read those two books - they contain a lot of wisdom that you may still be able to apply to the current project.
My last important notes about these books:
As far as I understand, Mr. Jackson is the original author of the idea of "problem frames". His book is quite academic and theoretical, but it is very, very readable and even entertaining.
Mr. Kovitz' book tries to demonstrate how Mr. Jackson ideas can be applied in real practice. It also contains tons of useful information on writing and organizing the actual requirements and requirements documents.
You can probably start from the Kovitz' book (and refer to Mr. Jackson's book only if you really need to dig deeper on the theoretical side). But I am sure that, at the end of the day, you should read both books, and you won't regret that. :-)
HTH...
我同意Galwegian。所描述的技术比“等待客户对我们大喊大叫”的方法有效得多。