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

好的,这不止7个,但是好的需求具有以下属性:

• 唯一的 相似的需求?
• 需求是否唯一标识?是否可以在整个开发过程中进行跟踪?
• 完成 . 有什么东西不见了吗 被遗忘的?彻底吗?是吗 包括制作所需的一切 它是独立的吗?
• 球门有什么错误吗?
• 毫不含糊的 . 是 它容易阅读和理解吗?
• 一致的 与中的其他项目不冲突 规格?
• 相关的 . 这个声明有必要吗 你喜欢这个功能吗?是额外的吗 它可以追溯到一个 原始客户需求?
• 可行的 . 会吗 使用可用的 人员、工具和资源
• 无代码 而不是底层的软件设计, 架构和代码?
• 可测试 是否可以创建测试来验证是否满足要求?
• 优先考虑 不如其他要求重要?
• 使用主动语态 . 是吗 如何使用主动语音? 被动语态并不总是指定 谁或什么执行该操作。
• 分类 以相似的方式逻辑地分组 要求?可能类别 实施、合规/质量, 操作(可靠性、安全性、,

一个像样的需求跟踪工具可以自动/强制执行上面的一些功能,如可识别、优先排序、分类,但只有团队的审查才能检查其余的功能。关键在于对您的团队进行这些属性的培训,通过阅读需求的好例子和坏例子来进行实践,并建立一个有效的审查流程,在您的生命周期中尽早检查需求,从而对下游活动产生影响。

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

功能、时间、质量-选择任意两个。确保这些要求不会对您的团队施加所有这三个方面的压力。

对试图控制流程的需求进行回击。

坚持每个要求的明确验收标准。

对于所需的内容,需求必须是具体的、明确的,但在如何满足需求方面,应该少一些。

包含多个要求的措辞糟糕的句子。在某个地方将它们分开,使它们更清晰,更容易勾选。

不容易验证是否满足的要求-更改为在评审时更容易标记为满足或不满足的表格。

该要求没有规定谁/做什么。

"The invoice is reconciled to the purchase order."

在我为之编写代码的项目中,我见过的最糟糕的一个:-

The system shall interface to SAP as required.

首先,一个包含“as required”的需求是愚蠢的。那条线肯定花了40万美元。客户不停地指着它,说它说你要在那里胡说八道。

过于严格-如果可能,指定相关公差。

模棱两可的要求是不好的。

当然,所有这些都取决于你得到什么样的需求。我习惯于典型的Gui或Web应用程序、批处理过程和

• 尽可能小一些——很少有人能够阅读一份200页的文档并记住所有的事情
• Do示例(图纸、会计书写)
• 包括性能标准、恢复力标准、部署说明、所需操作文档

我还有一个建议给评审员: 了解你的主题

我在项目中有过非常糟糕的经历,因为很多人都在审查规范,因为他们的个人知识非常浅薄。您会得到相同级别的反馈,大部分是正式的更正,但是规范的严重不足只会在项目中最近才发现。

避免使用“黄鼠狼语”——任何可以脱离上下文、听起来不好的语言都是不好的。

确保一切都绝对清楚:模糊==坏事(tm)

我的建议和我在开始一个新项目之前经常做的事情是仔细检查 第42,43页,共页 Steve McConnell's Code Complete

无所不知的WikMedia有一个很好的需求概要- http://en.wikipedia.org/wiki/Requirement#Good_requirements

• 功能、架构、接口和非功能需求的分离。
• 使用明确一致的符号来描述实体
• 拥有流程图(思维导图与UML的用途相同,并且更容易绘制)
• 有一个可追溯性矩阵

Requirement management 和 CMMI 文件。

也访问 Requirement Checklist 谷歌的“良好需求标准”。