《软件需求最佳实践》学习总结第1部分原型模型与误区.doc

第1部分　原型、模型与误区 　需求实践现状分析 软件项目失败的根源 导致成本超支、进度超期的十大因素：缺乏用户参与（12.8%）、不完整的需求（12.3%）、需求变更频繁（11.8%）、缺乏执行层的支持（7.5%）、技术能力缺乏（7.0%）、资源不足（6.4%）、不切实际的用户期望（5.9%）、没有清晰的愿景和目标（5.3%）、不切实际的时间限制（4.3%）、新技术风险（3.7%）、其他（23.0%） 需求相关败因简要分析： 不完整的需求 需求规格说明书应该采用业务导向的树型层次结构来组织 缺乏用户参与 事不关己，高高挂起；逃离无趣区；被你赶走 对于需求分析员而言，真正的专业主义是基于业务利益（解决问题、创造机会、提高管控力等）的沟通 不切实际的用户期望 原因：软件的无形和成本的不透明 做不到是无效的，要说明为什么做不到 需求变更频繁 对变更进行分类、统计 让用户意识到变更对软件项目的负面影响，统一变更处理渠道 提供了不再需要的 在最开始有效地划分优先级 一幅漫画带来的思考（需求“迷途”） 沟通失真 文档、Review(再看一遍)：用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真 客户的需求放大 客户希望支付的成本尽可能少，获得的效益尽可能多：一方面需要提升软件估算实践的有效性，另一方面则需要产业成熟度的提高 解决方案的选择权交给了不熟悉技术的客户：在需求捕获的过程中多问“为什么”。 项目经理的需求控制 应该以业务为线索来组织需求，基于“Why”的层面对需求建立高层次的认识。 分析人员的技术加工 需求分析的本质在于业务分析，而非技术分析 编码人员的断章取义 业务场景是需求之魂 透过表象，分析本质 1、需求变更频繁 重视对需求变更的分析和管理 针对不同类型的变更进行分类，对于频繁类的变更在调研的时候重点提问 2、上线阻力大 利益冲突（主要发生在管理层） 在需求捕获的过程中细心地发现和总结潜在的行政因素，然后在系统实施之前将这些因素整理成文，直接提交给客户方的高层。 工作量增大（主要针对基层，即操作层） 在需求阶段就着手解决：提高易用性、工作量价值化、将数据迁移、准备工作独立出来 运行效果差 从问题或机会入手，提高管理人员的推动力：针对不同管理人员的内动力分析 从障碍和困难出发，解决操作人员的积极性 完全崩溃 一般是忽略了某方面的非功能需求。“定性”的方法描述非功能需求，是一种无效信息的传递，采用“定量”的方法描述 　不同软件项目的需求视图 1、信息系统的需求视图 信息系统是人、数据、过程和接口的组合，它们之间相互作用，支持并改进企业的日常运作，并支持管理人员和用户解决问题和做出决策。其本质就是数据信息化 支持企业日常运作：对企业流程进行电子化，并且将其固化下来。 支持解决问题：解决企业运作中存在的问题 支持决策：通过有效地获取、加工、处理数据，为管理人员提供决策的支持。 分类 联机事务处理系统（OLTP）——数据的生产者，流程电子化 管理信息系统（MIS）——数据的消费者 主管信息系统（EIS）——数据的高级消费者 决策支持系统（DSS）——数据的高级消费者 专家系统——个人知识的沉淀，同时也是数据的消费者 办公自动化系统（OA）——对沟通与协作的直接支持 联机事务处理系统——流程电子化 电子化的流程更利于流程的固化 电子化的流程会对业务产生一定的约束 管理信息系统——数据信息化 报表需求的分析（主要是对数据的消费），从管理的场景入手，从理解报表的目的着手来与用户沟通，而不是从报表的格式上入手。 报表分析要点：Why（目的）：报表的目的，使用的部门/职位，相关的场景 What（怎样获得）：关联的实体，关键指标及计算规则 How（如何展现）：展现形式，输入输出需要 2、嵌入式系统的需求视图 面向直接用户 在对面向用户的嵌入式系统在需求梳理时首先是找到具体的使用场景，然后再对重要功能域中的重要使用场景进行行为分析。 面向特定设备 梳理对外接口，重点在于找到与该系统相关联的外部系统，然后明确外部系统与其的功能交互点。 整理完外部接口之后，接着就是对其内部功能进行分析与描述。分析内部功能时以事件作为线索。 3、软件产品的需求视图 信息系统类产品 首先对目标市场进行分析（目标客户分析、竞争对手分析、商业模式分析），然后再进行产品体系设计。 需求重点：针对不同目标客户群体的不同商业模式分离变化点;经常需要减出通用性，再通过插接解决扩展性。 工具类软件产品 在整理需求时先对不同用户进行分析，标识出具体的使用场景，然后针对不同的使用场景进行分析，确定所需的功能点。在确定用户类型的时候还可以考虑根据不同人群的特点进行细分。 人机交互也是很重要的一部分，可以采用用户界面原型驱动的方式进行描述。 　软件需