软件需求工程答案.ppt

软件开发的悲惨世界 需求定义 A condition or capability needed by a user to solve a problem or achieve an objective; 为用户解决问题或者达到目标所需要的条件或能力 ——CMMI-DEV&IEEE 从系统外部能发现系统所具有的满足于用户的特点、功能及属性等” ——Alan Davis 软件需求层次结构 需求组成部分 各层次需求描述样例 非功能需求 性能需求 易用性需求 可维护性需求 可测试性需求 可移植性需求 可扩展性需求 …… 接口需求 用户接口（界面）需求 软件接口需求 硬件接口需求 通讯接口需求 …… 实现约束 行业标准的约束 企业标准的约束 技术、方法的约束 供应商的约束 相关组的约束 …… 需求的重要性 需求对系统的影响比其他任何一个部分的失误都大 ——《人月神话》 提升产品质量最经济方式 缺陷分布统计 每个阶段缺陷引入的比例 Requirements 56% Design 27% Coding 10% Others 7% 重要性… 修正活动的成本 缺陷成长模型 Standish: 软件项目调查数据 使项目走向成功十个要素 2/3级过程域 需求的难度 开发软件系统的过程中，最困难的部分是确切地决定搭建什么样的系统。没有其他任何工作比确定详细的技术需求更加困难… 软件开发人员为客户所承担的最重要的职能是不断重复地抽取和细化产品的需求。事实上，客户不知道他们自己需要什么，他们通常不知道哪些问题是必须回答的，必须确定的问题细节常常根本不予考虑，甚至只是简单地回答——“开发一个类似于我们已有的手工处理过程的新软件系统”… ——《人月神话》 小例子 需求的难度 需求工程 需求开发和管理过程中的典型问题 项目开始的时候： 需求还没有，开发就开始了 想当然的以为问题已经得到了充分的理解 项目进展当中： 设计/解决方案与需求混杂在一起 在编码过程构思需求和设计方案 需求不断变化，缺乏有效控制机制，相关人员得不到变更通知 项目交付时： 并不与当初的期望相匹配 需求仍有不断地变更 造成问题的典型原因 缺乏合适的计划 需求开发过程不合适 与用户的沟通交流不充分 忽略了部分干系人 不清楚需求客户的问题 需求没有文档化或质量不高 缺乏或没有有效执行需求控制制度 需求获取的两个层面 项目层面的需求获取 关注特定产品的需求 关注短期需求，为项目开发提供输入 一次性的，参与人员有限 组织层面的需求获取 关注客户的需求，没有产品的限定 不仅关注短期需求，更关注中长期需求，为产品规划提供输入 持续不断的，全员参与 产品需求管理与产品规划、开发关系 产品需求的获取途径 识别干系人 理解干系人的needs，是需求分析的关键 非用户的needs必须被识别 通过提问的方法识别干系人 谁使用该系统（user）？ 谁买这个系统（customer）？ 这个系统的输出会影响谁？ 谁来评价和批准该系统发布？ 谁生产/维护该系统? 还有其它人关心这个系统吗？ 从干系人中获得信息 包括: Needs Wants Priorities Constraints 注意: 不要漏掉非功能需求 Needs和Wants的区别 不要漏掉priorities和constraints 识别非功能需求 在某些情况下，非功能需求是一个项目的主要目的，非功能需求往往决定了产品的成败 优先级 优先级可以用不同的方式 标签 (必须的，重要的，最好有的，可有可无的） 分级(priority 1, priority 2, priority n) 设定优先级考虑的因素 客户价值 商业价值 实现成本 实现时间 技术难易 需求分类模型－Kano模型 Kano模型是由日本的狩野纪昭博士（Dr. Noriaki Kano）在上世纪80年代提出的 把需求/品质分为5类： 基本需求(must-be) 期望需求(one-dimension) 魅力需求(attractive) 无关性需求(indifferent) 反面需求(reverse) 模型分两个维度 纵轴表示满意度 横轴表示实现程度 为什么要设立需求优先级 组织层面—产品路标规划 项目层面—项目策划 根据需求优先级缩小项目范围 根据需求优先级采用增量式开发、分期交付 根据需求优先级制定测试策略和计划 …… 实现约束 行业、企业等规范、标准约束 开发环境约束 编程语言约束 算法约束 …… 需求来源 访问并与有潜力的用户探讨 竞争产品和相关资料 当前系统的问题报告和增强要求 系统需求规格说明 内部的产品相关