项目管理 – 在审查需求规范时,需要解决哪些“致命罪”?

在审查需求规范(包括功能性,非功能性要求,约束等)时,无论规模大小,都是作者提出的“致命罪”是什么?

请列出不超过7个最基本的东西(按严重程度降低的顺序),在要求规范中完成(或未完成)会对软件产品的质量产生不利影响.少于7是完全可以的.

好的,这超过7,但良好的要求具有以下属性:

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

一个不错的需求跟踪工具可以自动执行/执行上述某些功能,例如可识别,优先级,分类,但只有团队的审核才能检查其余部分.关键在于培训您的团队了解这些属性,通过阅读需求的好的和坏的示例来实践他们,并建立一个有效的审核流程,在生命周期中尽早检查需求,从而对下游活动产生影响.

相关文章
相关标签/搜索