精确定位缺失要求的基本技术？

Question

需求规范的初稿已经完成，现在是时候评估需求review the specification了。此过程的一部分是确保规范中没有相当大的差距。毋庸置疑，这些差距导致了高度不准确的估计，不可避免的范围在项目后期蔓延，并最终导致死亡游行。

精确定位缺失和隐含要求的有效技术有哪些？

• 这个问题是关于实用技术，而不是一般建议，原则或指导方针。
• 缺少要求对于产品或服务的完整性至关重要，但没有想到或忘记，
• 隐含的要求是用户或客户自然认为将成为软件的标准部分，而无需明确要求。

_{我很乐意重新访问已接受的答案，只要有人提交更好，更全面的解决方案。}

Answer 1

就我而言，持续，频繁，坦率和与客户的双向沟通​​让我感到主要的'技巧'。

Answer 2

取决于。

这取决于您是否按照您所说的交付费用或向客户提供高质量的软件而获得报酬。

如果是前者，只需消除规范中的歧义，然后构建您同意的内容。尽量远离任何无法衡量的东西（如“快速”，“酷”，“活泼”等）。

如果是后者，那么Galwegian所说的+时间或者只是简单地切断所有并不是绝对堕落的关键并尽可能快地建立起来。制作有一种非凡的方式来阐明你在分析中错过的东西。

Answer 3

以下是找到缺失要求的方法。

1. 将需求分解为微小的增量。真的很小。可以在两周或更短的时间内建造的东西。你会发现很多差距。

2. 将这些优先考虑到最先拥有的东西，接下来的内容是什么并不重要。你会发现一些间隙填充物并不重要。您还会发现一些原始的“要求”仅仅是可取的。

3. 讨论对最终用户最重要的内容和原因的意见分歧。两个用户将有三个意见。你会发现一些用户没有线索，他们的“要求”都不是必需的。你会发现有些人没有脊椎，而且他们不够勇敢地说出来的东西是“必需的”。

4. 仅对前两名或三名达成共识。不要争论每一个细微差别。无法想象软件。任何人都无法想象将会使用哪种软件以及如何使用它。大多数人的“要求”描述了如何解决他们今天所困扰的业务流程不足的问题。

5. 首先构建最高优先级，最重要的部分。将它提供给用户。

6. GOTO 1并重复此过程。

<等等，“你说，”整体预算怎么样？怎么样？你永远不会知道整体预算。执行以下操作。

查看步骤1中定义的每个增量。提供每增量的价格。优先顺序。这样，有人可以随心所欲地选择。没有大的，可怕的“有很多零的大预算估计”。这一切都是可以谈判的。

Answer 4

我一直在使用一种名为行为工程（bE）的建模方法，它使用原始规范文本来创建结果模型，当您拥有模型时，更容易识别需求的缺失或不完整部分。

到目前为止，我已经在大约六个项目中使用了methodolgy，从少于一个houndred的需求到1300多个需求。如果你想了解更多，我会建议去www.behaviorengineering.org那里有一些关于方法论的非常好的论文。

我工作的公司创建了一个执行建模的工具。实际创建模型的工作率对于新手和专家来说约为5个要求，即每小时13个要求。方法论的一个很酷的事情是你不需要知道关于编写规范的域的任何信息。仅使用名词和动词等用户文本，建模者将在很短的时间内找到模型中的空白。

我希望这会有所帮助

迈克尔拉森

Answer 5

评估模型元素相对于通用/整体模型（如

）的生命周期

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，并始终将用户设为第一列）。这有助于确定需要用户界面进行数据输入和报告的位置。

目标是检查规范的完整性;上述技术有助于检查实体的生命周期是否与所识别的实体和应用程序“关闭”

Answer 6

如何制作原型？

Answer 7

在阅读大量关于软件需求的文献时，我发现了这两本有趣的书：

迈克尔杰克逊的

• Problem Frames: Analysing & Structuring Software Development Problems（不是歌手！:-)。

Bendjamen Kovitz的

• Practical Software Requirements: A Manual of Content and Style。

这两位作者真的从群众中脱颖而出，因为在我看来，他们正在努力将需求的发展转变为一个非常系统化的过程 - 更像工程而不是艺术或黑魔法。特别是迈克尔杰克逊对什么要求的定义 - 我认为这是我见过的最干净，最精确的。

我不会为这些作者提供一个很好的服务，试图在这里简短的帖子描述他们的方法。所以我不打算这样做。但我会尝试解释，为什么他们的方法似乎与你的问题非常相关：它允许你将大多数（不是全部，但大多数！）的需求开发工作归结为处理一堆检查清单*告诉您必须定义哪些要求以涵盖整个客户问题的所有重要方面。换句话说，这种方法应该最大限度地降低错过重要要求的风险（包括那些经常隐含的要求）。

我知道这听起来像是魔术，但事实并非如此。进入那些“神奇”的检查清单仍然需要花费大量精力：你必须首先阐明客户的问题，然后彻底分析，最后将其解剖成所谓的“问题框架”（这些都带有魔力）仅当检查列表与作者定义的几个典型问题框架紧密匹配时才检查列表。就像我说的，这种方法并不能保证一切都变得简单。但它绝对有望使需求开发过程尽可能系统化。

如果您当前项目中的需求开发距离一开始已经很远，那么此时尝试应用问题框架方法可能是不可行的（尽管这在很大程度上取决于您当前需求的组织方式）。不过，我强烈建议您阅读这两本书 - 它们包含了很多智慧，您仍然可以应用于当前的项目。

关于这些书的最后重要说明：

• 据我所知，杰克逊先生是“问题框架”概念的原作者。他的书很有学术性和理论性，但它非常，非常可读，甚至是有趣的。

• 先生。科维茨的书试图证明杰克逊先生的想法如何应用于实践中。它还包含大量有关编写和组织实际要求和要求文档的有用信息。

你可以从Kovitz的书中开始（只有在你真的需要深入研究理论方面时才能参考杰克逊先生的书）。但我相信，在一天结束时，你应该阅读这两本书，你不会后悔的。 ： - ）

... HTH

Answer 8

我同意Galwegian。所描述的技术远比“等待客户对我们大喊大叫”的方法更有效。