在审查需求规范时，什么是“致命的罪过"?需要解决吗? [英] When reviewing requirements specification what "deadly sins" need to be addressed?

问题描述

在审查需求规范(包括功能性、非功能性需求、约束等)时，无论大小，作者所犯的致命罪"是什么?

When reviewing requirements specification (that includes functional, non-functional requirements, constraints etc) however small or large it is what are the "deadly sins" committed by authors to look out for?

请列出不超过 7 件在需求规范中已完成(或未完成)对软件产品质量产生不利影响的最重要的事情(按严重性降序排列).小于 7 完全可以.

Please list not more than 7 most essential things (in order of decreasing severity) that being done (or not done) in requirements specification have adverse effect on the quality of software product. Less than 7 is perfectly OK.

推荐答案

OK，这7个以上，但是好的需求有以下几个属性:

OK, this is more than 7, but good requirements have the following attributes:

• 独特.有没有其他要求相似?
• 可识别，可以要求被唯一标识?能否在您的整个开发过程中进行追踪?
• 完成.有什么遗漏或忘记了?是否彻底?可以包括制作所需的一切它是独立的吗?
• 准确.这是正确的吗?它是否正确定义了目标?有错误吗?
• 明确.是描述准确而不含糊?有单一的解释吗?是易于阅读和理解?
• 一致.是描述编写的功能使其不与中的其他项目冲突规范?
• 相关.声明是否必要到功能?是额外的吗应该忽略的信息?是否可以追溯到最初的客户需求?
• 可行.是真的吗使用可用的人员、工具和资源在规定的预算内和时间表?
• 无代码.是否规范坚持定义产品和不是底层的软件设计，架构和代码?
• 可测试.可以测试吗?足够的提供的信息是测试人员是否可以创建测试来验证需求是否得到满足?
• 优先.是更多还是不如其他要求重要?
• 使用主动语态.是否规范使用主动语态?被动语态并不总是指定谁或什么执行操作.
• 分类.是否要求逻辑上与相似的分组要求?可能的类别是:行为、表现、接口，数据结构/元素，实施、合规性/质量、操作性(可靠性、安全性、安全)，派生/工程.

• Unique. Are there any other requirements that are similar?
• Identifiable, Can the requirement be uniquely identified? Can it be traced throughout your development process?
• Complete. Is anything missing or forgotten? Is it thorough? Does it include everything necessary to make it stand alone?
• Accurate. Is it correct? Does it properly define the goal? Are there any errors?
• Unambiguous. Is the description exact and not vague? Is there a single-interpretation? Is it easy to read and understand?
• Consistent. Is the description of the feature written so that it doesn't conflict with other items in the specification?
• Relevant. Is the statement necessary to the feature? Is it extra information that should be left out? Is it traceable to an original customer need?
• Feasible. Can it be implemented with the available personnel, tools, and resources within the specified budget and schedule?
• Code-free. Does the specification stick with defining the product and not the underlying software design, architecture, and code?
• Testable. Can it be tested? Is enough information provided that a tester could create tests to verify the requirement is satisfied?
• Prioritized. Is it more or less important than other requirements?
• Uses Active Voice. Does the specification use the active voice? Passive voice doesn't always specify who or what performs the action.
• Categorized. Is the requirement logically grouped with similar requirements? Possible categories are: Behavioral, Performance, Interface, Data Structures/Elements, Implementation, Compliance/Quality, Operational (Reliability, Safety, Security), Derived/Engineered.

一个体面的需求跟踪工具可以自动化/强制执行上述一些，如可识别、优先排序、分类，但只有团队的审查才能检查其余部分.关键是在这些属性上培训您的团队，通过阅读需求的好坏示例来让他们练习，并建立一个有效的审查流程，在您的生命周期中尽早检查需求，以便对下游活动产生影响.

A decent requirements tracking tool can automate/enforce some of the above, like Identifiable, Prioritized, Categorized, but only a review by the team can check the rest. The key is in training your team on these attributes, getting them practice by reading both good and bad examples of requirements, and establishing an efficient review process that checks requirements early enough in your life cycle as to have an impact on the downstream activities.

这篇关于在审查需求规范时，什么是“致命的罪过"?需要解决吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！