以用户体验为中心的需求分析.pdfVIP

第5章 以用户体验为中心的需求分析 现在 PACS 项目团队沿着前进的道路来到一座大山前，在旁边的石碑上赫然篆刻着“定 义”两个大字。 在概念阶段不是已经明确技术方案与初步 范围了吗？为什么还要经过定义的过程？ 这个问题往往是许多项目实施中业务部门都会提出的问题。需求的定义过程就是要让 业务需求通过分析手段转化为可以指导开发的系统需求。现在我们需要好好坐下来，进行 需求分析，而你的角色从这个阶段开始已经转变为业务需求分析师（BA ）。我们需要进一 步细化原始需求，将模糊、不清晰的业务原始需求变为明确的定义，使需求提出者和需求 实现者双方都能明白未实现的系统将会是什么样子。 表5-1 业务需求因素分析 成功因素 权 重 失败因素 权 重 用户的参与 15.9% 不完整的需求 13.1% 执行层的支持 13.9% 缺乏用户参与 12.4% 清晰的需求描述 13.0% 资源不足 10.6% 合适的规划 9.6% 不切实际的用户期望 9.9% 现实的客户期望 8.2% 缺乏执行层的支持 9.3% 较小的里程碑 7.7% 需求变更频繁 8.7% 有才能的员工 7.2% 规划不足 8.1% 主权 5.3% 提供了不再需要的 7.5% 清晰的愿景和目标 2.9% 缺乏 IT 管理 6.2% 第5 章 以用户体验为中心的需求分析 努力的工作和稳定的员工 2.4% 技术能力缺乏 4.3% 其他 13.9% 其他 9.9% 需求定义阶段对于项目成败具有非常关键的作用！表5- 1 是美国专门从事跟踪 IT 项目 成功或失败的权威机构Standish Group 在其CHAOS Report 报告中指出的影响软件项目成 功和失败的十大关键因素。其中在成功因素中有三个与需求定义有关，差不多占到40%左 右，这是一个相当大的比例。而在失败因素中直接和需求有关的更是超过了 50%。在企业 级应用开发的经验也表明，在需求定义中出现的问题对项目的影响是非常巨大的，常常导 致项目成本大幅超支或者进度延误，甚至还会导致项目完全失败。需求定义的错误在后期 会被放大，图 5- 1 就是经验总结出的一个单位人时代价图例（注意：本图中的数字代表一 个错误在需求时修正需要消耗 1 个单位人时，而在设计时发现并修正就需要消耗 5 个单位 人时，依此类推）。 图5-1 一个单位人时代价图例 需求定义过程的传统方法一直以来都存在各种困境，作者认为对产出物的具体规格的 认识差异一直以来都不能得到很好的解决，下面我们就来看一下在 Silverlight 项目案例中 是如何走出这一泥潭的。 5.1 走出需求定义的泥潭 那我们应该怎么来定义系统的样子呢？我 现在都不知道我们要建的系统会是一个什么样 子，难道又要像以前一样费劲地写出一本需求规 格说明书，画出用例与时序图吗？ 现在的需求定义的成熟度差异相