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

Question

在审查需求规格说明（包括功能性，非功能性需求，约束等）时，无论规模大小如此之大，作家为了寻找“致命罪孽”是什么？

请列出不超过7项最重要的事情（按严重程度递减），要求规范中完成（或未完成）对软件产品质量有不利影响。少于7是完全正确的。

Answer 1

OK，这是大于7，但良好的需求具有以下属性：

• 唯一。有没有其他 要求是相似的？
• 可识别， 要求可以唯一标识吗？它可以追溯到整个开发过程吗？
• Complete。有什么遗漏或 忘记？它彻底吗？ 是否包含使 独立的所有必要条件？
• 准确。这是对的吗？它是否正确定义了 目标？有没有错误？
• 毫不含糊。 的描述是否确切并且不含糊？ 是否有单一解释？ 很容易阅读和理解？
• 一致的。 的描述是否写入了这样的功能，使其 与 中的其他项不冲突？
• 相关。该声明是否需要 的功能？是否应额外提供 信息？ 是否可追溯至 原来的客户需求？
• 可行。可以使用 执行 人员，工具和资源 在指定的预算和 时间表内吗？
• 免密码。规范 是否坚持定义产品和 而不是底层软件设计， 体系结构和代码？
• 可测试。它可以被测试吗？是否有足够的 信息提供测试仪 可以创建测试来验证满足要求？
• 优先。它比其他要求更重要还是更不重要？
• 使用主动语音。 规范是否使用主动语音？ 被动语态并不总是指定 执行操作的人员或内容。
• 分类为。需求 在逻辑上与类似的 要求分组？可能的类别 是：行为，性能， 接口，数据结构/元素， 执行，符合性/质量， 操作性（可靠性，安全性， 安全性），派生/设计。

体面的需求跟踪工具可以自动化/强制执行以上某些操作，如可识别，优先级，分类，但只有团队的审查可以检查其余部分。关键在于培训团队的这些属性，让他们通过阅读需求的好坏示例来实践，并建立一个高效的审核流程，在您的生命周期中足够早地检查需求，以便对下游活动产生影响。

Answer 2

要求必须具体且明确地针对所需要的内容，但不应该如何满足要求。

Answer 3

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

Answer 4

我的建议和我总是做之前一个新的项目是双重检查 第42,43 Steve McConnell's Code Complete

Answer 5

包含不止一个要求措辞不佳的sentances检查清单。将它们分离出来，使它们更清晰，更容易勾选。

Answer 6

不易验证为满足的要求 - 更改为可在审阅时更容易标记为符合或不符合的形式。

Answer 7

缺失的要求 - 更难以捕捉。将要求分成明确的部分（例如安全，性能，造型等）可以使这一点更容易被发现。

Answer 8

功能，时间，质量 - 选择任意两个。确保这些要求不会强加给你的团队。

推回试图控制流程的要求。

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

坚持每个要求明确的接受标准。

Answer 9

该要求没有指定谁/是什么东西。

"The invoice is reconciled to the purchase order." 

这是否意味着系统执行某些操作或用户？

Answer 10

最差的一个我见过的一个项目，我编码： -

The system shall interface to SAP as required. 

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

Answer 11

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

Answer 12

含糊不清的要求是不好的。

无法验证和无法量化的要求加倍。

Answer 13

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

Answer 14

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

• 竖起执行标准第一，没有在各个规范的定义，是指他们
• 让它尽可能小 - 很少人能读200页文档，并永远铭记
• 要具体，mesurable，混凝土
• 做例子（图纸，占著作）
• 描述funtction
• inlcude第106页解释的目的erformance标准，弹性执行标准，部署指令，操作文档需要

我也有一个单一的忠告审稿：知道你的主题

你必须有需求的情况下的非常详细的了解，具体客户的需求，技术环境以及可能最重要的这项要求将被解决的问题以及他们对全球的了解程度。

由于他们的个人知识很浅，我在很多人回顾规格的项目中做了很糟糕的项目经验。您可以获得相同级别的反馈，大部分都是正式更正，但是规范的严重缺失只会在项目中最近才发现。

Answer 15

• 分离功能性，架构性，接口，非功能性需求。
• 使用明确和一致的符号来描述实体的使用情况
• 有流程图（思维导图服务于同一目的，UML，并更容易画出）
• 定义
• 清除进入和退出条件在明确的范围而言，什么是覆盖，什么是不和在哪里可以找到那些留在未知
• 有追溯矩阵

Answer 16

避免'黄鼠狼'字 - 任何语言都可以从它的上下文中获取并且听起来很糟糕。

确保一切都非常清楚：模糊==坏事（TM）

Answer 17

你可能会考虑读一些Requirement management和CMMI文件。

同时访问Requirement Checklist和谷歌的“标准的良好要求”。

这些专门设计用于创建帮助进行软件开发的流程。