Project management 在审查需求规范时，什么是；“死罪”；需要解决的问题？
当审查需求规范（包括功能性、非功能性需求、约束等）时，无论其大小，作者犯下的“死罪”是什么Project management 在审查需求规范时，什么是；“死罪”；需要解决的问题？,project-management,qa,specifications,review,Project Management,Qa,Specifications,Review,当审查需求规范（包括功能性、非功能性需求、约束等）时，无论其大小，作者犯下的“死罪”是什么 请列出需求规范中对软件产品质量有不利影响的最基本的事情（按严重性降低的顺序）不超过7件。小于7是完全可以的。对于所需的内容，要求必须具体明确，但在如何满足要求方面应该少一些。做出假设-仔细检查任何看起来像假设的东西是否已经得到了验证。我的建议和我在新项目之前总是做的是仔细检查 第42,43页，共包含多个要求的措辞拙劣的句子。将它们分开，使它们更清晰，更容易在完成时勾选。不容易验证是否满足的要求-更改为一个
请列出需求规范中对软件产品质量有不利影响的最基本的事情（按严重性降低的顺序）不超过7件。小于7是完全可以的。对于所需的内容，要求必须具体明确，但在如何满足要求方面应该少一些。做出假设-仔细检查任何看起来像假设的东西是否已经得到了验证。我的建议和我在新项目之前总是做的是仔细检查
第42,43页，共包含多个要求的措辞拙劣的句子。将它们分开，使它们更清晰，更容易在完成时勾选。不容易验证是否满足的要求-更改为一个表格，以便在审查时更容易标记为满足或不满足。缺少的要求-更难捕捉。将需求划分为清晰的部分（例如安全、性能、样式等）可以更容易发现。功能、时间、质量-选择任意两个。确保这些要求不会对您的团队施加所有这三个方面的压力 对试图控制流程的需求进行回击 从一开始就要求明确的优先顺序
坚持每项要求都有一个明确的验收标准。该要求没有具体说明谁/做了什么
"The invoice is reconciled to the purchase order."
这是指系统做了什么，还是用户做了什么？我在为其编写代码的项目中看到的最糟糕的一个：-
The system shall interface to SAP as required.
首先，一个包含“as required”的需求是愚蠢的。那条线肯定花了40万美元。客户不停地指着它，说你要在那里胡说八道。过于严格-如果可能，请指定相关公差。含糊不清的要求是不好的
无法验证和无法量化的需求双倍增加。无所不知的WikMedia有一个很好的需求概要-。我想说，在这些要点中，缺乏可核查性是最常见的。理解大局在生活中是很重要的，但是，你需要在你的需求中明确地说明一些事情，例如，系统应该能够快速响应。相反，系统应在不到2秒钟内响应所有请求。当然，所有这些都取决于您得到的需求类型。我习惯于典型的Gui或Web应用程序、批处理过程和
- 首先提出标准，这些标准不必在每个规范中定义，请参考它们
- 尽可能小一些——很少有人能够阅读一份200页的文档并记住所有的事情
- 具体、可测量、具体
- Do示例（图纸、会计书写）
- 在描述功能之前，先解释目的
- 包括性能标准、恢复力标准、部署说明、所需操作文档
- 功能、架构、接口和非功能需求的分离
- 使用明确一致的符号来描述实体
- 明确用例的进入和退出标准
- 拥有流程图（思维导图与UML的用途相同，并且更容易绘制）
- 明确定义范围，包括哪些内容，哪些内容不包括，以及在哪里可以找到那些未标注的内容
- 有一个可追溯性矩阵
- 独特的。还有别的吗 相似的需求
- 可识别的，是否可以 需求是否唯一标识？是否可以在整个开发过程中进行跟踪
- 完成。有什么东西不见了吗 被遗忘的？彻底吗？是吗 包括制作所需的一切 它是独立的吗
- 准确。对吗？它是否正确定义了 目标？有什么错误吗
- 明确的。是 描述准确而不含糊？ 有单一的解释吗？是 它容易阅读和理解吗
- 一致的。描述是什么 这篇专题文章写得很好 与中的其他项目不冲突 规格
- 相关。这个声明有必要吗 你喜欢这个功能吗？是额外的吗 应该忽略的信息？ 它可以追溯到一个 原始客户需求
- 可行。会吗 使用可用的 人员、工具和资源 在指定的预算和 时间表
- 无代码。规格是否符合要求 坚持定义产品和服务 而不是底层的软件设计， 架构和代码
- 可测试的。可以测试吗？够了 测试人员提供的信息 是否可以创建测试来验证是否满足要求
- 优先排序。是更多还是更多 不如其他要求重要
- 使用主动语音。是吗 s