project-management - 在查看需求规范时，需要解决哪些 "deadly sins"？

Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗？更新问题，以便editing this post用事实和引用来回答。

1年前关闭。



Improve this question




在审查需求规范说明(包括功能需求，非功能需求，约束等)时，无论大小，作者应注意的“致命罪”是什么？

请列出不超过7个最基本的事项(以降低严重性的顺序)，这些事项在需求规范说明中已完成(或未完成)会对软件产品的质量产生不利影响。小于7完全可以。

最佳答案

好的，这是7以上，但是好的要求具有以下属性:

唯一的。还有其他吗
相似的要求？

可识别的可以
要求被唯一标识？是否可以在您的整个开发过程中进行追溯？

完成。是否缺少任何东西或
忘记了？彻底吗？可以
包括一切必要的东西
它独立吗？

准确。这是正确的吗？是否正确定义了
目标？有没有错误？

明确。是
描述准确而又不模糊？
有单一的解释吗？是
容易阅读和理解吗？

一致。是描述
编写的功能使其
与中的其他项目不冲突
规范？

相关的。该声明是否必要
功能？额外吗
应该忽略的信息？
它可以追溯到
原始客户需求？

可行的。是真的吗
用可用的实现
人员，工具和资源
在指定的预算之内，并且
日程？

无代码。规范是否
坚持定义产品并
不是底层的软件设计，
体系结构和代码？

可测试的。可以测试吗？足够的
提供测试人员的信息
可以创建测试来验证是否满足要求？

优先。是更多还是
比其他要求重要吗？

使用事件语音。是否
规范使用主动语态？
被动语态并非总是如此
谁或什么执行操作。

归类。是要求
在逻辑上与相似分组
要求？可能的类别
是:行为，绩效，
接口(interface)，数据结构/元素，
实现，合规/质量，
操作性(可靠性，安全性，
安全性)，派生/工程化。

体面的需求跟踪工具可以自动执行/强制执行上述某些操作，例如可识别，优先，分类，但是只有团队审查才能检查其余内容。关键是对团队进行这些属性方面的培训，通过阅读需求的好坏示例让他们进行实践，并建立有效的审查流程，以在您的生命周期中尽早检查需求以对下游事件产生影响。

关于project-management - 在查看需求规范时，需要解决哪些 "deadly sins"？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/186716/