需求管理和需求分析.PPT

什么是好的需求规格说明书 1 正确 需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。 2 清楚 清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚： 文档的结构、段落是否乱七八糟？上下文是否不连贯？ 文档的语句是否含糊其词、罗里罗嗦？ 看了半天是否还不明白需求究竟是什么？ 3 无二义性 “无二义性” 是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。 什么是好的需求规格说明书 4 一致 “一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。 5 必要 《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。 可以把“必要”比喻为“雪中送炭”。但要把握好度，“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。 6 完备 “完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求。 人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。 不完备的《产品需求规格说明书》将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。 什么是好的需求规格说明书 7 可实现 《产品需求规格说明书》中的各项需求对我们而言应当都是可实现的（Attainable）。 “可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。 营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。 所以，一般经过双方确认的《产品需求规格说明书》会作为商业合同附件，所以我们要把握好《产品需求规格说明书》中的内容，尽量在合同范围内满足客户得需求，但一定要在时间、费用、质量，技术内能实现得，不能实现一定要和客户进行接受说明，实在不行的可以进行业务裁决，由公司营销人员人员搞定。 对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处理意见，避免将来发生商业纠纷。 8 可验证 《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。 例如，摩天大楼的一项需求是“抗十二级台风”， 什么是好的需求规格说明书 9 确定优先级 为什么要确定需求的“优先级”？ 理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了。 人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。 需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。 10 阐述“做什么”而不是“怎么做” 《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。 我们经常把系统设计甚至编程的变量声明等写到 《产品需求规格说明书》中，让用户看不明白，也就无法签字确认。 形成需求规格说明书 1 规程 第一步：细化并分析用户需求 需求分析员首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如采用Rational 的Rose工具进行需求的建模分析，建模分析产生的文档可以作为《产品需求规格说明书》的附件。补充说明：建模分析的技术难度比较高，需求分析员应当根据自身水平进行取舍。 第二步：撰写产品需求规格说明书 需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当撰写《软件需求规格说明书》和《硬件需求规格说明书》。 第三步：进行需求确认 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。 需求评审之后，开发方和客户方的责任人对《产品需求规格说明书》作书面承诺。 2 软件需求规格说明书的参考模板 什么是好的需求规格说明书 需求管理：确认、跟踪、变更控