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

EN

好吧，这比7还多，但良好的需求具有以下属性：

• Unique.还有没有其他需求是similar?
• Identifiable，的?这些需求可以被唯一地识别吗？它可以在整个开发process?
• Complete.中被跟踪吗？有什么东西丢了或忘了吗？是彻底的吗？它是否包括使其站得住脚所需的一切? alone?
• Accurate.这是正确的吗？它是否正确地定义了目标？有没有errors?
• Unambiguous.描述是否准确而不含糊？有单一的解释吗？它是否易于阅读和understand?
• Consistent.是否编写了功能描述，使其不与specification?
• Relevant.中的其他项冲突该语句对于该功能是必需的吗？这是不是应该省略的额外信息？是否可追溯到原始客户need?
• Feasible.是否可以在指定的预算和schedule?
• Code-free.范围内使用可用的人员、工具和资源来实施该规范是否坚持定义产品，而不是底层软件设计、体系结构和code?
• Testable.它能被测试吗？如果测试人员可以创建测试来验证需求是否为satisfied?
• Prioritized.，那么信息是否足够它比其他requirements?
• Uses活动语音更重要还是更不重要。规范中是否使用了主动语音？被动语态并不总是指定谁或什么人执行action.
• Categorized.需求是否在逻辑上与类似的需求进行了分组？可能的类别包括:行为、性能、接口、数据结构/元素、实现、合规性/质量、可操作性(可靠性、安全性、安全性)、Derived/Engineered.

一个像样的需求跟踪工具可以自动化/强制执行上面的一些内容，比如可识别的、优先排序的、分类的，但只有团队的审查才能检查其余的。关键是在这些属性上训练你的团队，让他们通过阅读需求的好的和坏的例子来实践，并建立一个有效的审查过程，在生命周期中足够早地检查需求，以便对下游活动产生影响。

缺少需求--更难捕捉。将需求划分为清晰的部分(例如安全性、性能、样式等)可以更容易地发现这一点。

功能、时间、质量--随便选两个。确保需求不会将所有这三项都强加给您的团队。

回击那些试图控制你的过程的需求。

从一开始就要求有清晰的优先顺序。

坚持每个需求都有一个明确的验收标准。