Question

在审查需求规范（包括功能性，非功能性要求，约束等）时，无论规模大小，都是作者提出的“致命罪”是什么？

请列出不超过7个最重要的事项（按严重程度降低的顺序），在要求规范中完成（或未完成）会对软件产品的质量产生不利影响。少于7是完全可以的。

Answer 1

好的，这超过7，但是好的要求具有以下属性：

唯一即可。还有别的吗？要求是否相似？
可识别，可以要求是唯一标识？可以在整个开发过程中跟踪它吗？
的完成即可。有什么遗失或忘记了？它彻底吗？可以包括制作所需的一切它独自一人？
的精确即可。这是对的吗？它是否正确定义了目标？有没有错误？
的无歧义的即可。是描述准确而不含糊？有单一解释吗？是它易于阅读和理解吗？
的一致即可。是描述编写的功能使它成为可能与...中的其他项目不冲突规范？
的相关即可。声明是否必要这个功能？这是额外的吗？应该遗漏的信息？是否可追溯到原始客户需求？
的可行即可。是真的吗用可用的方式实现人员，工具和资源在指定的预算范围内日程？
的 无代码。是规范吗？坚持定义产品和不是底层软件设计，架构和代码？

的可测试即可。可以测试吗？足够信息提供了一个测试人员可以创建测试来验证满足要求吗？

的优先即可。是更多还是不如其他要求重要吗？

使用活动语音。是吗？规范使用主动语音？被动语态并不总是指定谁或什么执行行动。

的分类的即可。是要求逻辑上与类似的分组要求？可能的类别是：行为，表现，接口，数据结构/元素，实施，合规/质量，操作（可靠性，安全性，安全），派生/工程。

一个不错的需求跟踪工具可以自动执行/执行上述某些功能，例如可识别，优先级，分类，但只有团队的审核才能检查其余部分。关键在于培训您的团队这些属性，通过阅读需求的好的和坏的示例来实践他们，并建立一个有效的审核流程，在生命周期中尽早检查需求，从而对下游活动产生影响。< / p>

Answer 2

缺少要求 - 更难捕捉。将需求分成清晰的部分（例如安全性，性能，样式等）可以使这更容易被发现。

Answer 3

特点，时间，质量 - 挑选任何两个。确保要求不会对你的团队施加所有这三项要求。

推迟尝试控制流程的要求。

从一开始就要求明确优先顺序。

坚持每项要求的明确验收标准。

Answer 4

做出假设 - 仔细检查看起来像假设的任何事情是否已经实际验证过。

Answer 5

避免使用“狡猾的词语” - 任何可以从其语境中获取并且听起来很糟糕的语言都是不好的。

确保一切都绝对清晰：模糊==坏事（tm）

Answer 6

当然，这一切都取决于你得到什么样的要求。我习惯于典型的Gui或Web应用程序，批处理和

首先提出标准，不必在每个规范中定义，参考它们
尽量减少 - 很少有人可以阅读200页文档并牢记一切
具体，可疑，具体
做例子（图纸，会计文字）
在描述咒语之前解释目的
包括性能标准，弹性标准，部署说明，所需操作文档

我还为评论者提供了一条建议：了解您的主题

您必须非常详细地了解需求的背景，特定客户的需求，技术环境以及可能最重要的需求，以及他们对全球的理解程度。

由于他们的个人知识非常浅薄，我在项目中的经验非常糟糕，很多人都在审查这些规范。您可以在相同的级别上获得反馈，主要是正式的更正，但严格缺乏规范只会在项目中最近发现。

Answer 7

模棱两可的要求很糟糕。

无法核实和无法量化的要求加倍。

Answer 8

过于严格 - 如果可能，请指定相关公差。

Answer 9

我在编码的项目中见过最糟糕的一个： -

The system shall interface to SAP as required.

首先，其中“按要求”的要求是愚蠢的。这一行必须花费40万美元。客户一直指着它，说它说你要做，等等，等等。

Answer 10

要求没有说明事情是谁/是什么。

"The invoice is reconciled to the purchase order."

这是否意味着系统做某事或用户？

Answer 11

要求不易验证的要求 - 更改为在审核时可以更轻松地标记为满足的表单。

Answer 12

<包含多个要求的措辞不佳的句子。将它们分开，使其更加清晰，更容易勾选。

Answer 13

要求必须具体且明确，无论如何需要，但应该更少关于如何满足要求。

Answer 14

所有知识维基百科都有一个很好的要求概要 - http://en.wikipedia.org/wiki/Requirement#Good_requirements。我想说的是，缺乏可验证性是最常见的。了解大局在生活中很重要，但是，你需要在你的要求中明确地说出来，例如。系统应迅速作出反应。相反，系统应在不到2秒的时间内响应所有请求。

Answer 15

功能，架构，接口，非功能要求的分离。
使用明确且一致的符号来描述实体
明确用例的进入和退出条件
拥有流程图（思维导图与UML具有相同的用途，并且更容易绘制）
以明确的术语定义范围，涵盖的内容和不适用的内容以及在哪里找到未知的内容
具有可追溯性矩阵

Answer 16

我的建议和我在新项目之前经常做的事情是仔细检查核对清单 Steve McConnell's Code Complete

的第42,43页

Answer 17

您可以考虑阅读一些Requirement management和CMMI文档。

另请访问Requirement Checklist并谷歌查看“有效要求标准”。

这些专门用于创建有助于软件开发的流程。

在审查需求规范时，需要解决哪些“致命罪”？

17 个答案: