需求分析看书小结.docVIP

1.软件需求定义 需求是指系统必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束 2.需求工程的本质 需求工程可以看作把一个定义不足的问题转换为一个定义充分的问题以便找出解决方案 3.问题域与解系统 问题域:被开发系统的应用领域 解系统:指可以在问题域内产生某种效果的系统 4.软件需求分类 功能需求 性能需求 (非功能需求) 设计约束 商业约束 5.客户/用户/开发者的需求观 6.不合格的需求派生的问题 无足够用户参与 用户需求的不断增加 模棱两可的需求说明 不必要的特性 过分精简的规格说明 忽略用户分类 不准确的计划 7.高质量的需求带来的好处 8.优秀需求所具有的特征 完整性(Complete) 正确性(Correct) 可行性(Feasible) 必要性(Necessary) 与实现无关性(Implementation Independent) 划分优先级 (Prioritized, Future and trade-offs) 无二义性(Unique) 可验证性(Verifiable) 正确的详细层次(Right level of details) 需求规格说明的特征 完整性(Complete) 一致性(Consistent) 简洁明了(Concise) 可修改性(Modifiable) 可跟踪性(Traceable) 软件需求工程定义 需求获取 应当收集什么信息 问题域的描述 要求解决的问题列表(需求) 用户对解系统的行为或结构施加的任何约束 有哪些信息来源 高层系统需求 System Requirements 客户(实际的和潜在的) Customers 客户的“规格说明书” CRS 原有解系统(即运行在问题域中，执行与预期的新的解系统相似功能的系统)及其文档 原有系统的用户 竞争对手的产品 应用领域专家 定义了任何接口系统的特征和行为的文档 相关的技术标准和法规 可能通过什么机制或技术收集 面谈 准备 询问正确的问题 直接问题 原始的和派生的问题 总结性问题 集中精力倾听 重复关键问题 记录收集的信息 调查表 用例或场景分析 对客户进行分类 业务需求 使用实例 功能需求 质量属性 外部接口 限制 数据定义 解决思路 头脑风暴 需求剪裁 确定需求开发过程 编写项目视图和范围文档 业务需求 背景 业务机遇 业务目标 客户需求 业务风险 项目视图解决方案 范围和局限性 业务环境 产品成功的因素 基于项目视图和范围的管理 将用户群分类并归纳各自特点 选择每类用户的产品代表 建立起典型用户的核心队伍 让用户代表确定用户使用实例 召开应用程序开发联系会议(JAD) 分析用户工作流程 确定质量属性和其它非功能需求 通过检查当前系统的问题报告来进一步完善需求 跨项目重用需求 需求分析 绘制系统关联图 创建用户接口原型 分析需求可行性 确定需求优先级别 为需求建立模型 创建数据字典 使用质量功能部署 结构化分析工具 DFD数据流图、DD数据字典和PSPEC CFD、CSPEC和STD E-R图 面向对象分析工具 用例图，类图，对象图 对象-关系图 对象-行为图 建模工具 数据流图 实体关系图 状态转换图 对话图 类图 需求规格书 采用SRS模板 指明需求的来源 为项目需求注上标号 记录业务规范 创建需求跟踪能力矩阵 需求验证 审查需求文档 以需求为依据编写测试用例 编写用户手册 确定合格的标准 确定需求变更控制过程 建立变更控制委员会 进行需求变更影响分析 跟踪所有受需求变更影响的工作产品 建立需求基准版本和需求控制版本文档 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性 使用需求管理工具 客户的需求观 成功的目标 构成阻碍的因素 用户 产品易于使用，具有所有期望的功能和操作能力 不合理的期望 客户 在规定时间和投资下向用户递交产品，最大可能满足用户需要 不切实际的时间表和预算 频繁的需求变更 不确定的质量目标 开发人员 开发满足客户、用户需求的产品。收回投资 人员能力不足 个人表现欠佳 缺乏风险意识 接受客户不切实际的要求 需求知识技能获取 耐心 思维条理性强 有良好的交际和沟通能力 理解产品应用领域 掌握丰富的需求工程技术 培训软件需求的用户代表和管理人员 明白重视需求的意义 需求工作包括哪些活动 要提交什么样的结果 忽略需求过程会导致的风险 更加体谅软件开发人员 让开发人员了解问题域(应用领域)的基本概念 编写项目术语汇编 CMMI需求工程过程模型 需求分析的六个原则（一）永远不要显得比客户更聪明 总结一下需求分析第一个原则的中心思想： 1、需求分析第一个原则：永远不要显得比客户更聪明。 聪明反被聪明误，这样的事情太多了，我们产品经理都是有智慧的人，而不是耍小聪明