第2章 软件项目管理之需求管理【荐】.ppt

如何练就需求分析的火眼金晴？ 5W + 1H + 8C 5W就是 Who、When、Where、What、Why Why是关键 1H就是 How – 需求本身的流程 8C指的是8个约束和限制，即8个Constraints： 包括性能Performance、成本Cost、时间Time、可靠性Reliability、安全性Security、合规性Compliance、技术性Technology、兼容性Compatibility 合同项目立项过程 1.甲方过程 招标书定义、乙方选择、合同签署 2.乙方过程 项目分析、竞标、合同签署 3.相关文档 《立项报告》、《可行性分析报告》、《标书》 需求评审做不好的后果： ? 需求变更 ? 需求不明确 ? 需求不可测 ? 需求不可实现 ? 导致后续工作难于开展或经常出现变更 由于需求未能得到有效管理， 在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，项目延期。 如何进行需求评审 ? 参与需求分析和评审的人员的管理 ? 软件需求文档的管理 ? 需求分析过程的管理 ? 需求变更的管理 需求规格评审实例 例1：“产品应在不少于每秒的正常周期内提供状态信息。” 分析：这个需求是不完整的： 状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。 需求规格评审实例 例1需求： 后台任务管理器因以误差上下不超过10秒的秒间隔，在用户界面的指定位置显示状态信息； 如果后台进程处理正常，那么应该显示任务已完成的百分数/比； 任务完成时，应显示相关的信息； 后台任务出错应该显示错误信息； 为了测试和追踪，将需求分解多个子需求。使在构造和测试时，被易于分别执行。 需求规格评审实例 例2：“产品应瞬间在文本中的显示和隐藏不可打印字符间切换” 　　计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些什么动作？而且，在文档中改变显示的范围是多大：选中的文本？整个的文档，或其他的？这也是个模模糊的问题。不可打印字符和隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。 需求规格评审实例 例2需求： 用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换。 现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。 需求规格评审实例 例3：“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。 单词“快速”使其模糊，没有加进错误报告的定义也是不完整的。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？ 需求规格评审实例 例3需求： “HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。 现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。 需求规格评审实例 练习：以下描述哪些属于不精确的用户需求描述？如果不精确，应如何改正？ 1）系统应表现出良好的响应速度。 不精确，应指出具体项目和响应时间。 2）系统必须用菜单驱动。 “必须”不精确，因系统还可以用其他方式驱动。 3）在数据录入界面，应该有10个按钮。 不精确，因过于细致，限制了设计的自由度。 4）系统运行时占用的内存不得超过200M。 仅是一个约束条件。 5）电梯应平稳运行。 不精确，应指出加速、减速、运行速度的大小。 6）即使系统崩溃，也不能损坏用户数据。 不精确，因这是一个难以保证的“用户需求”。 为什么要设定需求的优先级 软件开发受时间、成本、质量等多种资源的限制，同时软件开发的高不确定性，导致 需求在项目结束时往往难以被全部实现。