需求笔记.docVIP

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