在审查需求规范（包括功能性、非功能性需求、约束等）时，无论大小，作者所犯的“致命罪”是什么？
请列出不超过 7 件最重要的事情（按严重性递减顺序）在需求规范中完成（或未完成）会对软件产品的质量产生不利影响。小于 7 完全没问题。
Totophil
问问题
2583 次
17 回答
12
OK，这已经不止7个了，不过好的需求有以下属性：
- 独一无二的。还有其他类似的要求吗？
- Identifiable , 能否唯一标识需求？它可以在您的整个开发过程中被追踪吗？
- 完成。有什么遗漏或遗忘吗？是否彻底？它是否包括使其独立所需的一切？
- 准确。这是正确的吗？它是否正确定义了目标？有没有错误？
- 毫不含糊。描述是否准确而不含糊？有单一解释吗？是否易于阅读和理解？
- 一致的。特性描述是否写得不与规范中的其他项目冲突？
- 相关。该声明是该功能所必需的吗？是否应该省略额外的信息？它是否可以追溯到最初的客户需求？
- 可行。是否可以在指定的预算和时间表内使用可用的人员、工具和资源来实施？
- 无代码。规范是否坚持定义产品而不是底层软件设计、架构和代码？
- 可测试。可以测试吗？是否提供了足够的信息，测试人员可以创建测试来验证需求是否得到满足？
- 优先。它比其他要求更重要还是更不重要？
- 使用主动语音。规范是否使用主动语态？被动语态并不总是指定谁或什么执行动作。
- 分类。需求是否在逻辑上与相似的需求分组？可能的类别有：行为、性能、接口、数据结构/元素、实施、合规/质量、操作（可靠性、安全性、安保）、衍生/工程。
一个体面的需求跟踪工具可以自动化/强制执行上述一些，如可识别、优先级、分类，但只有团队审查才能检查其余部分。关键是在这些属性方面对您的团队进行培训，通过阅读需求的好坏示例来让他们练习，并建立一个有效的审查流程，在您的生命周期中尽早检查需求，以便对下游活动产生影响。
于 2008-10-09T11:33:32.590 回答
2
缺少要求 - 更难捕捉。将需求分成清晰的部分（例如安全性、性能、样式等）可以使这一点更容易被发现。
于 2008-10-09T11:03:56.207 回答
2
功能、时间、质量 - 选择任何两个。确保要求不会将这三个要求都强加给您的团队。
推回试图控制您的流程的要求。
从一开始就要求明确的优先级。
坚持为每个要求制定明确的验收标准。
于 2008-10-09T11:04:27.283 回答
1
需求必须具体且明确地说明需要什么，但在如何满足需求方面不应该如此。
于 2008-10-09T10:50:20.337 回答
1
做出假设 - 仔细检查任何看起来像假设的东西实际上已经得到验证。
于 2008-10-09T10:56:20.857 回答
1
包含多个要求的措辞不佳的句子。将它们分开在某个地方，使它们更清晰，更容易在完成后打勾。
于 2008-10-09T10:58:21.523 回答
1
不容易验证是否满足的要求 - 更改为在审核时更容易标记为满足或未满足的表单。
于 2008-10-09T11:00:38.617 回答
1
该要求没有具体说明谁/做什么。
"The invoice is reconciled to the purchase order."
这是否意味着系统做某事，或用户？
于 2008-10-09T11:05:08.153 回答
1
我在一个我为之编码的项目中见过的最糟糕的一个：-
The system shall interface to SAP as required.
首先，带有“根据需要”的要求是愚蠢的。那一条线一定要花费 40 万美元。顾客不停地指着它说它说你要在那里做废话，废话，废话。
于 2008-10-09T11:06:23.317 回答
1
过于严格 - 如果可能，请指定相关公差。
于 2008-10-09T11:07:25.763 回答
1
模棱两可的要求是不好的。
无法验证和无法量化的需求加倍。
于 2008-10-09T11:09:07.430 回答
1
当然，这一切都取决于你得到什么样的要求。我习惯于典型的 Gui 或 Web 应用程序、批处理和
- 首先提出标准，不必在每个规范中定义，参考它们
- 让它尽可能小——很少有人可以阅读 200 页的文档并牢记一切
- 具体、可衡量、具体
- 做例子（图纸，会计著作）
- 在描述功能之前先说明目的
- 包括性能标准、弹性标准、部署说明、所需操作的文档
我还给审稿人一个建议：了解你的主题
您必须非常详细地了解需求的上下文、特定客户的需求、技术环境，或许还有最重要的需求将针对谁，以及他们对全球的了解程度如何。
我在项目中获得了非常糟糕的经验，因为他们的个人知识非常浅薄，很多人都在审查规范。您会在同一水平上获得反馈，主要是正式的更正，但规范的严重缺乏只会在项目中最近才被发现。
于 2008-10-09T11:13:59.337 回答
1
避免使用“狡猾的词”——任何可以从上下文中分离出来并且听起来很糟糕的语言都是糟糕的。
确保一切都非常清楚：模糊 == 坏事（tm）
于 2008-10-09T11:38:08.273 回答
0
我的建议以及在新项目之前我总是做的事情是仔细检查史蒂夫麦康奈尔代码完成第 42,43 页上的检查清单
于 2008-10-09T10:57:53.347 回答
0
无所不知的维基百科有一个很好的需求概要 - http://en.wikipedia.org/wiki/Requirement#Good_requirements。我想说的是，在这些方面，缺乏可验证性是最常见的。了解大局在生活中很重要，但是，您需要在需求中明确说明，例如。系统应快速响应。相反，系统应在 2 秒内响应所有请求。
于 2008-10-09T11:09:16.350 回答
0
- 功能、架构、接口、非功能需求的分离。
- 使用明确和一致的符号来描述实体
- 明确用例的进入和退出标准
- 有流程图（思维导图与 UML 的目的相同，并且更容易绘制）
- 明确定义范围，涵盖哪些内容和未涵盖的内容以及在哪里可以找到那些未知的内容
- 有一个可追溯性矩阵
于 2008-10-09T11:22:24.937 回答
0
于 2008-10-09T11:40:28.503 回答