1、1 2 目的n更深刻的理解需求以及它的价值n更深入的理解需求的层次和类型n为良好的需求管理建立坚实的方法论基础n为更有效的管理需求给出实践和建议3 大纲n需求管理介绍n需求管理的重要概念n需求跟踪n深入管理需求n编写好的需求n需求变更管理4 需求管理介绍n什么是需求？什么是需求管理？n常见问题n需求管理的重要性和益处5 项目成功因素源于: “Chaos Chronicles, III, 2003”. 清晰的商业目标清晰的商业目标17% 用户积极用户积极参与程度参与程度7%最小化范围最小化范围12%敏捷的需求过程敏捷的需求过程管理层的管理层的 支持支持14%15%14%6%5%5%5%有经验的有
2、经验的 项目经理项目经理标准的标准的 组织结构组织结构可靠的可靠的 估算估算规范的规范的 方法方法熟练的员工熟练的员工n 28%的项目按时并在预算内完成n 49%的项目超出原先估算n 时间平均延迟了63%n 成本超出了45%n 23%的项目在完成之前被取消6 项目规模是关键成功率(%)Standish Group, 99 ()项目规模（$）7 什么是“需求”？n 任何影响产品或系统设计制造方式的信息n 功能n 性能n 安全性n 可用性n n 复杂的产品/项目有数以千计的需求n 飞机、汽车、火车、手机n 同义词n 目标，规则，规约，约束，要求，特性，标准8 需求无处不在需求需求目的目标目标法规条
3、件条件需求特性特性功能功能规则风险风险9 什么是“需求管理”？进行需求管理的目的是在客户和 .项目 .之间建立统一的认识。 这种与客户一致的认识是规划和管理 项目的基础。”卡内基梅隆大学软件工程学院软件能力成熟度模型（CMM）。 www.sei.cmu.edu/cmm突然，国王和护城河承包商发生了激烈争执，然后，需求管理诞生了。10 为什么要进行需求管理?n “分析报告指出多达71的项目失败是因为差劲的需求管理，这个是项目失败的最主要的原因，比落后的技术，进度失控或者混乱的变更管理还要关键” CIO Magazine, 2005/1111 n 错误的需求会对项目的整个生命周期造成多米诺骨牌效应
4、n 遗漏用户需求将导致遗漏系统功能点,又将导致遗漏设计模块,最终导致功能失效UserSystemFailureDesign多米诺骨牌效应12 常见问题1. 需求只存在组织中那些“专家”的脑子里，没有被记录下来2. 有时客户的需求会被忽略3. 而有时候开发的功能却不被客户使用4. 客户签字确认了需求却一直提出修改要求5. 需求变更对项目影响很大，难以确定变更的影响范围和成本6. 市场部门、开发部门、测试部门跨部门的沟通存在问题，例如需求变化时不能迅速通知到测试部门去调整测试计划和案例。7. 需求规格说明书的要求都实现了，客户却不满意8. 需求的研发状态，需求变更的状态难以掌握如果您的项目中有3项
5、类似的问题，那就说明参加这门培训是值得的13 电信业和银行业15个项目统计n Hofmann and Lehner 2001n 最成功的项目在需求工程上投入了28%的资源：需求获取，需求建模，需求确认和验证等n 平均每个项目在需求活动上投入了15.7%的工作量和占了 38.6%的时间14 需求管理的作用 I 提高质量n 关于质量，Crosby的定义很简单与需求一致。n 正确的需求：正确的功能的前提n 一致性n 与需求保持一致并不仅仅在项目的后期用测试来验证，更强调的是在项目的每一个阶段都紧紧围绕需求这个主线来开展工作。n 需求跟踪正是保证需求演化的整个过程都是与需求保持一致，以此保证项目和产品
6、的最终质量 Phil Crosby15 需求管理的作用 II 成本控制n 目标正确是第一位的需求的正确捕获和表达n在项目后期才发现需求的缺陷，修复需要非常高的成本n 需求分析n分析得出带来最大价值的需求n同时得出所需的成本n我们的目标：n合理成本下的效益最佳n 需求变化时如何控制成本n洞察变更影响n影响分析:迅速定位需要进行修改的模块16 工作量时间典型较好整体成本低整体成本低缩短了缩短了开发时间开发时间第一时间采取措施能降低成本和缩短时间第一时间采取措施能降低成本和缩短时间17 需求管理的作用 III 支持项目进度的管理n 真实项目进度的反映n 例如，多少需求已经被实现，它们的状态如何？n
7、又如哪些需求已经有对应的测试案例，哪些需求已经测试通过？n 需求驱动开发n 需求活动在项目正式立项之前就展开n 需求分解后的功能点/模块成为项目管理中的需要实现的任务18 课程大纲n 需求管理介绍n 需求管理的重要概念n 需求的“沙漏”我们工作的全景视图n 涉众的概念n 需求的层次n 需求捕获n 需求跟踪n 深入管理需求n 编写好的需求n 需求变更管理19 需求的 “沙漏”20 需求的 “沙漏”系统边界的确定需求的筛选需求开发标识涉众收集需求需求管理需求的演化问题陈述高度分散、凌乱的非结构的信息正式的结构化的需求解决方案设计21 一些的需求专家人许多相关人员.工 程工程问题陈述定义问题.定义解
8、决方案需求的 “沙漏”22 需求的 “沙漏”系统边界的确定需求的筛选标识涉众收集需求.需求的演化问题陈述高度分散、凌乱的非结构的信息访谈，调查问卷观测用户现有系统改进建议，问题报告，创新研究正式的需求陈述:单独的, 唯一的,清晰的, 准确的,抽象的,良好的, 可测试的可追踪的正式的结构化的需求解决方案设计23 孙子兵法24 选择做正确的事情“追求胜利”“作战”将事情做对需求的 “沙漏”25 需求管理的困难n 需求：n 不明确n 众多来源n 难以用文字表达n 关联内容太多n 变更n 数量巨大26 需求文档的文档反映需求的演变层次n 某个银行研发中心的需求演进的层次n 业务规格说明书 软件规格说明
9、书 概要设计详细设计n 某个电信制造厂商的需求演进的层次n 市场需求 产品包需求 设计需求n 某个芯片提供商的需求演进的层次n 市场需求产品需求 系统功能n 不同的产品/系统，不同的公司，对自己的需求体系有自己的定义27 典型的需求层次n 业务需求 n 定义一个机构达到的目标和目的。n 用户需求(涉众需求) n 说明用户需要系统提供什么能力帮助其完成任务。n 系统需求 n 说明系统必需完成什么功能才能提供用户所需的。28 业务需求n 我们为什么要进行这个项目？n 组织的业务目标n 提高公司的运营效率内部信息管理信息系统n 提高产品的市场竞争力对商业软件n 通常来自n 投资方n 管理层n 市场部
10、n 产品部n 常见文档记录方式n 工作说明书n 前景和范围文档n 市场需求文档n 项目计划书（可行性报告）29 业务需求n 若对项目预期的范围和目标有不同的理解，就无法对下列获得一致意见n 对哪些用户应该被访谈获取需求n 哪些功能应该被纳入n 现象n 某些特性先被添加，又被删除，又被加入n 分布式开发团队尤为重要n 决策基础n 目标版本n 应用的广度和深度n 需求变更30 用户需求（涉众需求）n 用户的目标，用户希望完成的任务n 影响系统的需求信息类型：n 业务目标n 使用场景n 外部约束n用户界面需求n接口需求n环境的约束n 业务规则n 数据定义n 用户需求 - 涉众需求的通俗解释31 系统
11、需求n 产品中实现的功能性需求n 用户以此完成工作n 进而满足业务需求n 描述包含多组件的系统的顶级需求32 如果世界就这么简单业务需求业务需求用户需求用户需求系统需求系统需求33 设计测试质量/ 标准法律/规章维护 市场培训支持 实现部署业务系统需求客户用户项目中各种信息交织在一起34 课程大纲n 需求管理介绍n 需求管理的重要概念n 需求的“沙漏”我们工作的全景视图n 涉众的概念n 需求的层次n 需求捕获n 需求跟踪n 深入管理需求n 编写好的需求n 需求变更管理35 捕获需求n 我们必须知道哪些信息是从来的需求的来源n 我们必须知道哪些信息是我们需要的需求的分类n 我们必须善于发现需求捕
12、获需求的技巧36 捕获需求活动:n 标识涉众n 与涉众交流n 收集需求n 给需求的重要程度排序n 选择需求n 记录需求37 r572最终用户最终用户培训和支持培训和支持业务业务客户客户考虑所有可能的用户考虑所有可能的用户. 遗漏了他们的任何需求都会导致系统问题的出现遗漏了他们的任何需求都会导致系统问题的出现或系统失败或系统失败技术支持技术支持安装和维护安装和维护销售员销售员管理者，经理管理者，经理运输和装卸运输和装卸每个涉众都有各自的需求集38 标识涉众n Stakeholder: 涉众n 涉众是对于系统有利益关系或关注的个人，团队或组织。IEEE 1471有哪些涉众角色？n 投资方（系统的投
13、资方）n 主管方（批准/管理系统的）n 最终用户（用户/系统受益方）n 操作方（操作/维护系统的）n 监管方（认证系统的）n 测试方（负责系统验收）n 其它（受系统影响的）39 涉众角色举例XXX 系统：系统：投资方投资方计划部计划部主管方主管方信息化部信息化部用户代表用户代表市场部市场部最终用户最终用户营业员营业员监管方监管方审计部审计部测试方测试方信息化部信息化部操作方操作方信息化部信息化部概念：涉众角色40 捕获需求n 我们必须知道哪些信息是从来的需求的来源n 我们必须知道哪些信息是我们需要的需求的分类n 引出系统功能的需求信息n 非功能性需求的信息类型n 我们必须善于发现需求捕获需求的
14、技巧41 用户提供给我们的足够的信息吗？n 没有？不知道？n 我们知道要收集哪些信息吗？42 客户不会给你一个清晰全面的需求列表n 业务目标n 使用场景n 业务规则n 功能性需求n 质量属性n 接口需求n 约束n 数据的要求n 等等43 需求分类n 功能需求n 系统必须实现的能力. n 某些系统必须完成的工作. n “系统能够为运输和装卸工作人员提供打印运输标记功能.” n 能够作为一个逻辑时序组织和实现的功能是功能需求.n 非功能需求n 必须被系统满足的潜在的条件. n “约束补充了系统的质量但不会作为一个功能存在.” 对于系统而言，约束不增加任何特殊的工作, 但它起到保证系统满足所需的功能
15、,保证系统更可靠,更易使用. n “音乐点歌系统能够储存15,000,000个在线账号.”n 非功能需求能够作为一个重要规则或条件组织和实现.44 影响系统功能的需求信息类型n 业务目标n 使用场景n 外部约束n用户界面需求n接口需求n环境的约束n 业务规则n 数据定义45 非功能性需求的信息类型n “真实的现实系统中，在决定系统的成功或者失败的因素中，满足非功能性需求往往比满足功能性需求更为重要。”n 性能n 软件质量属性n 对产品的功能作出了补充，从不同方面描述了产品的特性n 如可用性，可移植性，健壮性等等。46 影响系统功能的需求信息类型n 业务目标 业务需求n 使用场景 用例n 外部约
16、束n 用户界面需求n 接口需求n 环境的约束n 业务规则n 数据定义47 场景和用例用于以下目的的技术：用于以下目的的技术：n 详细描述涉众需求n 研究揭示涉众需求的情形n 按照每个目标或状态生成需求n 改善与涉众的沟通n 用涉众语言表达应用情况n 确保需求的完整性n 覆盖全部情况的多种应用n 结构化编写需求文档n 用主场景作为标题结构n 导出验收测试n 设计覆盖所有应用情况的测试48 最终目标最终目标水平水平 1水平水平 2 操操 作作 顺顺 序序实现最终目标实现最终目标的步骤的步骤子目标子目标子目标子目标子目标子目标子目标子目标 子目标子目标子目标子目标子目标子目标用户场景作为不同层次的目
17、标子目标子目标子目标子目标子目标子目标49 应用情况举例（一件行李）应用情况举例（一件行李）行李拥有人在目的地提行李卸机装机就绪装机飞行登机由飞机卸货装机飞行再次装机装入集装箱运至登机口安全检查贴标签登记受控由集装箱卸货交行李卸机装机乘客入座测量称重50 多个场景图n 一个场景图也许不够n 把类似的情况组成一组场景n 场景将包含共同的元素n 指出共同的子场景n 首先设计整个结构n 然后加入特例Sd jer isadDfj fdidfUahfi dfDf dfuy fdasdfF sad fddkgfhuvjdSada fAsdf Klrt fdsFdd ffdSdf dfufAsdfjj oi
18、jfJha dfOiasdf fuDffd dfOrj dsId asd dsDfids adfPrtid yffd场景场景 A场景场景 B共同的子场景共同的子场景51 场景和用例n 使用场景(Usage Scenario)n 多年来需求分析人员一直使用n 用例(Use Case) 以场景为中心的方法n Ivar Jacobson及其同事 (1992)n Larry Constatnine和Lucy Lockwood(1999)n Alistair Cockburn (2001)n 用例不适合n 批处理，主要用于计算的系统，数据仓库n 应用的复杂在于执行的运算或者生成的报表n 关于Use Ca
19、se，请参加UML的资料52 用例n 在讨论用例时会引出包含其他需求信息n 优先级n 使用频率n 业务规则n 所操作的数据n 接口信息53 用例和功能性需求n 开发人员实现的不是业务需求或者用例n 而是功能需求n 用例从actor的角度来表述系统行为，省略了很多细节n 系统外部可见的行为n ATM机和银行的计算机如何通讯n 对于实现用例时需要的详细的功能性需求，需求分析人员应给出明确的描述(Arlow 1998)n 有些功能需求比较容易从用例中理解和导出n 另一些则没有在用例描述中出现n 需求分析员应该对用例和系统的操作环境的理解导出该类功能性的需求54 场景举例（一件行李）行李拥有人在目的地
20、提行李卸机装机就绪装机飞行登机由飞机卸货装机飞行再次装机装箱运至登机口安全检查贴标签登记受控由箱子卸货交行李卸机装机值机人员应该能够记录托运行李物品的旅客信息行李处理机器应该能够把行李放到规定尺寸的箱子中55 记录与用例相关的功能性需求n 用例文档？n 软件需求规格说明书？n 第一种只使用用例文档n 把功能性需求包含在每个用例描述n 还需要单独记录非功能性需求，以及不与特定用例相关的需求n 第二种用例与软件需求规格说明n 相当简单的用例描述n 用例中推导出的功能性需求记录在SRS中n 可追踪关系n 第三种只使用软件需求规格说明书n 利用用例或者特性来组织n 把用例和功能性需求都记录在SRS中5
21、6 用例使用时的问题n 用例过多n 用例过于复杂n 用例中包含用户界面设计n 用例中包含数据定义n 用户无法理解57 影响系统功能的需求信息类型n 业务目标 业务需求n 使用场景 用例n 外部约束n 用户界面需求n 接口需求n 环境的约束n 业务规则n 数据定义58 外部系统的约束外部系统n 存在或预定义的未来系统n 竞争或合作的系统n 被替换的系统n 相关的系统,例如,在其它终端的行李系统外部约束n 接口 (通常是标准的)59 操作环境操作环境我们的系统我们的系统竞争系统竞争系统 F竞争系统竞争系统 E合作系统合作系统 D合作系统合作系统 C竞争系统竞争系统 B合作系统合作系统 A环境的约束
22、n环境的作用:n 环境对系统的作用是什么n引入的环境:n 系统对环境的作用是什么 对其自身的作用 (例如,振动)60 环境约束的例子环境的作用:n 必须能够在水下发送信息n 必须能够在失重的条件下做记录n 必须能够在有暴风雨的条件下发现来进攻的导弹引入的环境:n 不允许制造太大的噪音或振动n 不能干扰邻近的电子设备61 影响系统功能的需求信息类型n 业务目标 业务需求n 使用场景 用例n 外部约束n 用户界面需求n 接口需求n 环境的约束n 业务规则n 数据定义62 业务规则n 软件功能性需求的一个主要来源n 指定了系统为符合这种规则必须具备的功能n 业务规则是公司的重要资产n 你明白了，他明
23、白了吗？n 构建规则集能够帮助需求分析人员，帮助开发者理解需求63 业务规则的种类n 事实n 关于数据实体及其属性的陈述n 例，每个订单都包含运费n 例，如果购买的是不可退的票，如改变行程，就要另外付费n 约束n 限制了系统或用户可以执行哪些操作n 词汇，必须，不可以，可以不或者只有n 例，图书馆的借阅者最多可以同时借阅10本书例例: ATM跨行取款要收费跨行取款要收费1RMB我们会要求这个吗我们会要求这个吗?64 业务规则的种类(续)n 动作/状态触发规则n 特定条件下触发某个动作n 如，机票到了失效日期的前一个礼拜，则应通知客户n 计算n 定义了算法n 如，机场建设费65 业务规则和需求n
24、 业务规则会影响到多个应用n 企业级的资源进行管理n Ask Whyn 客户会告诉你需求相关的业务规则n 记录需求和规则之间的关系n 利用属性n 利用追踪关系66 练习和讨论n 针对每种业务规则，给出您的项目中的例子n 找出需求背后的来源，从而发现业务规则67 数据定义n 独立的数据定义n 方便信息的查询n 避免冗余和不一致性n 数据字典n 定义应用中使用的数据元素或属性的含义、数据类型、长度、格式需要的精度以及允许的取值n 作为项目术语表的补充n 可作为SRS的附录，或者单独的文档n 如何定义n 符号标识法n 利用CASE工具68 符号表示法n 被定义的数据项在等号的左边，其定义在等号的右边
25、n 基本数据元素n 确定其数据类型，大小，允许的取值范围和其他属性n 订单标识号=*系统生成的6位顺序整数，以1开头，并能唯一标识每个订单*n 组合结构n 一个数据结构包含多个数据项 ()：表示可选n 订单中的产品 = 产品编号名称数据数量单位(供应商名称)n 重复项n 用大括号表示可出现一个数据结构中的一个数据项的多个实例n 订单订单标识号订单日期帐户号1:10订单中的产品n 可选项n 数量单位=“克”|“千克”|“个”|“打”|69 非功能性需求的信息类型n “真实的现实系统中，在决定系统的成功或者失败的因素中，满足非功能性需求往往比满足功能性需求更为重要。”n 性能n 软件质量属性n 对
26、产品的功能作出了补充，从不同方面描述了产品的特性n 如可用性，可移植性，健壮性等等。70 性能需求n 定义了系统多快好省的完成专门的功能n 速度，如响应时间n 吞吐量，如每秒处理的事务n 处理能力，如并发使用的负载n 定时，如严格的实时要求n 确认需求n 使需求可以被测试n 定义妥协空间n 通过定义谈判的范围71 性能需求和功能需求n 总是与功能相关而非与约束相关n 但是有时限制的值可以作为约束n 文档中应用专门的部分记录系统的性能需求n 尽可能量化n 不同的功能型需求有不同的性能需求n 为相应的功能指定其性能目标72 软件质量属性n 除了完成任务，还要使客户满意n 技术角度，质量属性影响重要
27、的架构和设计策略n 一般说来客户不能明确提出他们对产品质量的期望n 不同项目考虑的重点不同n 嵌入式系统 有效性和可靠性n Internet应用可用性、完整性和可维护性n 桌面系统互操作性和易用性n 产品的不同部分需求不同的质量属性组合73 对用户比较重要的软件质量属性n 可用性 (Availability)n 有效性 (Efficiency)n 可扩充性(Extensibility)n 完整性 (Integrity)n 互操作性(Interoperability)n 可靠性(Reliability)n 健壮性(Robustness)n 易用性(Usability)74 对开发人员比较重要的软
28、件质量属性n 可维护性(Maintainability)n 可移植性(Portability)n 可重用性(Reusability)75 可用性和有效性n 可用性n 系统的平均无故障时间(MTTF)/(平均无故障时间+故障发生后所用的故障修复时间(MTTR)n Web站点或者用户遍及全球的应用n AV1：工作日，系统的至少可用性达到99.5%;休息日，系统的可用性至少95%n 如果要求可用性为100？n 有效性n 衡量系统在利用处理器能力、磁盘空间、内存和通信带宽等方面的表现n 例，在预计的峰值负载条件下，至少25%的处理器能力和内存备用76 可扩充性和完整性n 可扩充性n 用来测量向产品中添
29、加新功能的难易程度n 设计方案的选择n 例，一个至少具有6个月产品支持经验的程序员，可以在8小时内为系统添加一个新的输出设备n 完整性n 主要处理防止非法访问系统功能、防止数据丢失、防护病毒入侵以及保护数据的保密性和安全性n Internetn 使用含义明确的术语，如用户身份验证、用户权限级别等等77 互操作性、可靠性和健壮性n 互操作性n 系统与其他系统交互数据的服务的难易程度n 外部接口需求n 可靠性n 健壮性n “制造得象坦克一样”n 当系统遇到非法数据和操作，相连的系统发生故障时，能够继续正常运行的可能性n 健壮的软件可以从问题的环境中自然的恢复过来78 易用性n 易于使用n 人机工程
30、 Human Engineeringn 问题n 快速简单做某事的重要程度如何？n 完成某个工作应该花多长时间？n 界面习惯？n 学习曲线？79 可维护性、可移植性和可重用性n 可维护性表明了纠正缺陷或修改软件的简单程度n 频繁修订的产品n 可引出设计目标n 例，程序维护人员应该在20小时或更短的时间内，对报告格式进行更改，以遵循官方修订的报告格式n 可移植性n 度量将软件从一种运行环境移至到另一个运行环境所需的工作量n 可重用性n 度量一个软件组件应用到其他应用程序所需的工作量80 捕获需求n 我们必须知道哪些信息是从来的需求的来源n 我们必须知道哪些信息是我们需要的需求的分类n 引出系统功能
31、的需求信息n 非功能性需求的信息类型n 我们必须善于发现需求捕获需求的技巧81 轻松一刻n 联合利华新换了一批自动香皂包装机以后，经常出现香皂盒子是空的没有香皂的情况，而在装配线一头用人工检查因为效率问题不太可能而且不保险？n 这不，一个由自动化，机械，机电一体化等专业的博士组成的Solution队伍来解决这个问题，没多久他们在装配线的头上开发了全自动的X光透射检查线，透射检查所有的装配线尽头等待装箱的香皂盒，如果由空的就用机械臂取走。n 中国一乡镇企业生产香皂也遇到类似问题，老板吩咐线上小工务必想出对策解决之，小工拿了一个电风扇放在装配线的头上，对着最后的成品吹之，空盒子被吹走问题解决之82
32、 需求/系统工程最应关注问题领域问题域问题域“定义要做什么定义要做什么”解决方案域解决方案域“定义系统如何实现定义系统如何实现”83 在写出好的需求之前n 我们必须知道哪些信息是从来的需求的来源：涉众n 需求的发展层次n我们是在谈论同一层次的需求吗？84 概念：问题和解决方案验收测试 验收产品验收产品 涉众需求 需求陈述 操作应用 满足满足组件需求 组件测试 测试需求测试需求 子系统需求 子系统测试 集成子系统集成子系统 满足满足 系统需求 系统测试 评估系统评估系统 满足满足 表达问题定义解决方案85 涉众需求涉众需求描述问题和其背景涉众希望从系统得到的结果不定义解决方案，除了环境结果的质量
33、拥有方为涉众或其代表（例如市场部）系统需求系统需求抽象地表达解决方案系统的功能不定义设计系统行为的效果拥有方为系统工程师“用户应能用户应能 .”“系统应系统应 。”问题和解决方案的不同问题问题解决方法解决方法概念：问题和解决方案86 混淆问题和解决方案的结果n 不能很好理解问题n 无法决定功能n 开发人员将自行决定n 用户和系统约束条件混淆 n 拥有方不清概念：问题和解决方案87 四个关键问题能帮助我们在适当层次表达需求1.目的是什么？专注于问题，而不是解决方案识别在何处将需求陈述为解决方案表达需求不要限制解决方案2.是否隐含一个解决方案？理解为什么需要特定的解决方案收集导致所建议解决方案的约
34、束条件3.潜在目标是什么？帮助表达和量化需求是最大、最小还是优化的？4.如何知道目标已得到满足？量化需求和使需求可测88 举例客户希望在交叉路口设置一组控制交通的红绿灯。1. 目的是什么？2. 是否隐含一个解决方案？3. 什么是潜在目标？4. 如何确定需求已得到满足？89 需求跟踪n 需求管理介绍n 需求管理的重要概念n 需求捕获n 需求跟踪n 深入管理需求n 编写好的需求n 需求变更管理90 需求跟踪n 正确定义需求后的跟踪管理n 过程改进(如CMMI)需要进行双向的需求跟踪n 理解高层信息如何转换到低层n 理解如何满足和验证需求n 具体体现在：n 理解需求如何被满足n 理解需求变更的影响n
35、 理解需求如何被测试n 理解测试失败的影响91 整个生命周期的可追溯性整个生命周期的可追溯性验收测试 验收产品验收产品 用户需求需求陈述操作应用 满足满足组件需求 组件测试测试需求测试需求 子系统需求 子系统测试 集成子系统集成子系统 满足满足 系统需求 系统测试 验证系统验证系统 满足满足 概念：需求跟踪92 影响分析影响分析验收测试 验收产品验收产品 用户需求 需求陈述操作应用 满足满足组件需求 组件测试测试需求测试需求 子系统需求 子系统测试 集成子系统集成子系统 满足满足 系统需求 系统测试 验证系统验证系统 满足满足 概念：需求跟踪93 覆盖率分析覆盖率分析完成了多少完成了多少 ?验
36、收测试 验收产品验收产品 用户需求 需求陈述操作应用 满足满足组件需求 组件测试测试需求测试需求 子系统需求 子系统测试 集成子系统集成子系统 满足满足 系统需求 系统测试 验证系统验证系统 满足满足 ?概念：需求跟踪94 来源分析来源分析为什么？为什么？验收测试 验收产品验收产品 用户需求 需求陈述操作应用 满足满足组件需求 组件测试测试需求测试需求 子系统需求 子系统测试 集成子系统集成子系统 满足满足 系统需求 系统测试 验证系统验证系统 满足满足 概念：需求跟踪95 来源覆盖率分析来源覆盖率分析验收测试 验收产品验收产品 用户需求 需求陈述操作应用 满足满足组件需求 组件测试测试需求测
37、试需求 子系统需求 子系统测试 集成子系统集成子系统 满足满足 系统需求 系统测试 验证系统验证系统 满足满足 ?概念：需求跟踪96 跟踪需求示例n 在需求条目上建立链接n 要求：区分、标识和管理各个需求条目客户需求客户需求系统需求系统需求软件设计软件设计满满足足满满足足97 审查追踪关系的两大标准n 充分性: 底层的需求是不是能够充分满足高层的要求？n 必要性: 所有的底层的需求/功能都必要存在来满足高层的需求？n 一定的工具支持：能够容易地浏览相关需求98 高效的需求跟踪n 实战中要求n 方便地创建需求关联n 方便地查看需求关联n 方便地维护需求关联n 方便地建立需求跟踪的分析报告99 大
38、纲n 需求管理介绍n 需求管理的重要概念n 需求跟踪n 深入管理需求n 编写好的需求n 需求变更管理100 进一步管理需求n 我需要管理需求的状态.n 我能看到只包含通过测试的需求集合吗?n 我需求对需求的优先级进行排序n 我们需要将开发力量集中在客户最迫切的需求上。n 我们想大家基于统一的信息进行工作n 我们能提供对每个用户自己感兴趣的数据吗？101 需求条目管理1 前言前言 本文档是关于新乘用车的需求信息。 1.1 范围范围 本车将销向欧洲、美国和亚洲。 它属中档家用轿车。 1.2 背景背景 面包黄油等传统的英国和维多利亚废话。 这段还会继续延续下去直到看上去很丰富为止。 2 能力需求能力
39、需求 2.1 承重能力承重能力 该车应能乘坐 5 人。 应具有 12 立方米的行李箱，且不会对成员仓造成任何影响。 2.2 速度速度 文档其它属性可接受性可接受性可接受可接受需检查需检查优先级优先级强制项强制项希望项希望项IDID号号UR 1UR 2标识分类控制102 n 属性是额外定义的需求特性, 能够对需求项描述提供实质的额外说明n来源谁提出的这条需求?n优先级这条需求的优先级?n评论任何关于需求的评论用来澄清需求的涵义.n问题任何需要澄清的关于Source的问题n状态需求的状态n负责人相关人员n 你可以定义你的属性来支持你们的需求管理过程,并且提高数据 的生产效率属性刻画您的需求103
40、使用属性需求不只是一个文本描述。它还有其它属性，例如234 用户将各类业务定单根据业务规则分解为各类面向服务开通的工单。n 简述简述： 定单分解n 优先级优先级： 高n 版本版本：1.0.5n 状态状态：已规划n 统一管理程度统一管理程度:统一需求n 104 需求状态的跟踪和控制n 把需求展示的观看限定在某些特别的信息上, 如:n高风险的需求项n已规划的需求项n分配给某个人的需求项n没有通过测试的需求项n给某些需求项的属性设定一个值n你也许想给所有文本含有 “安全”单词的需求项的优先级属性赋值为“高”105 为什么要设定需求优先级？n现实约束的需要n迭代开发的需要n变更管理的需要106 我们可
41、能遇到的困难n 如果将决定权完全交给客户n 分步式优先级n 威胁式优先级n 不同的用户，不同的优先级n 请我们和客户都要理解好钢用到刀刃上！107 问正确的问题n 是否有其他方式可以满足这一需求？n 如果忽略或推迟实现这一需求，其后果是什么？n 如果不立即实现这一需求，那么对项目的业务目标有什么影响？n 如果将这一需求推迟到下一版本中实现，您为什么不满意呢？108 设置优先级n 最简单和直观的方式n高n中n低n 从重要性和紧迫性两个方面考虑重要不重要紧迫高？不紧迫？低109 复杂的优先级判断n 很多因素会影响到需求的优先级n 竞争对手分析n 客户需求n 创新想法n 公司战略n 所有开发约束条件
42、等n 优先级的判断常常兼有定性（价值，风险）的判断和定量（例如特性的估计成本）的比较 110 层次分析法 n 70 年代由美国运筹学家TLSatty提出的，是一种定性与定量分析相结合的多目标决策分析方法论。n 吸收利用行为科学的特点，是将决策者的经验判断给予量化，对目标（因素）结构复杂而且缺乏必要的数据情况下，采用此方法较为实用，n 常用的一种系统分析方法111 课程大纲n 需求管理介绍n 需求管理的重要概念n 需求跟踪n 深入管理需求n 编写好的需求n 好的需求表达的准则n 好的需求文档的准则n 需求变更管理112 需求书写的标准n 一个需求一句话。n 每个需求包含主语和谓语，主语是用户或系
43、统，谓语是条件、动作和期望的结果。 n 注意助动词的使用:n“将要,” “将,”或 “必须” 等词表示强制特征n“也许” 或 “可能” 等词表示可选特征n 这个需求标识预期的目标和结果。n 包含一个需求是否被满足的判断标准或其它可度量质量的指标。 113 n访谈n问卷n需求讨论会n在用户环境中工作n类似的或现有产品n变更建议和问题报告n 现有产品、环境及工作流模式的观察报告n 市场调查n 中期项目评审n 用户小组会议n 新技术n 用户修改需求来源114 r572“网络用户将能够在网络用户将能够在5秒钟之秒钟之内内访问当前账号中的信息访问当前账号中的信息.”定义用户类型定义用户类型定义结果定义结
44、果性能标准性能标准动词动词这句需求标识了用户类型和最终结果这句需求标识了用户类型和最终结果并且说明了预期的时间并且说明了预期的时间验证质量的团队可以依据定义的判断标准检查需求是否成功实现验证质量的团队可以依据定义的判断标准检查需求是否成功实现- “访问访问 . 账号信息账号信息” “少于少于5秒钟秒钟.” 挑战：在每条需求定义中找出用户类型，实现结果和度量标挑战：在每条需求定义中找出用户类型，实现结果和度量标准准. 一个合格需求的剖析115 每个单独的需求应该:1.1. 单一单一：单一的可追溯元素2.2. 唯一唯一：每个陈述都是唯一标识的3.3. 清晰清晰：每个陈述都是清晰易理解的4.4. 精
45、确精确：每个陈述都是准确和简明的5.5. 抽象抽象：不对下层解决方案施加影响6.6. 量化量化：每个陈述都有验收条件7.7. 可测试可测试：每个陈述都可以被确认/验证合格需求具备的特征116 需求文档的七大标准各需求组应：1.完整 / 充分：全部需求都存在2.一致：任意两个需求都没有冲突3.无冗余：每个需求仅表达一次4.模块化：相关的需求陈述的聚集在一起5.结构化：需求信息文档结构应清晰6.满足：应实现适当粒度的设计可跟踪性7.验证：应实现适当粒度的测试可跟踪性定义最外层轮廓结构，之后逐步改善117 写好的需求不可能一蹴而就n 让大家从一开始就明白标准是什么n 先写下来您听得的，或者收集的信息
46、，尽管不那么完美n 使用最初的版本去获得最快的反馈n 逐步地完善需求，去掉模糊的陈述，不必要的设计等等。n 涉众的始终参与和需求专家的介入是一样重要的118 1.1. 避免凌乱：避免凌乱：简洁为美2.2. 非约束条件：非约束条件：例如，“如果它应当是必须的”；这对需求来说毫无意义3.3. 多项需求：多项需求：经常使用的词有，“和”、“或”、“但是”、“然而”4.4. 含糊术语：含糊术语：通常、一般、经常、正常情况下、典型情况是、用户友好、通用的、灵活的5.5. 理想化的想法：理想化的想法：“100%可靠”、“使所有用户满意”、“在所有平台上运行”、“处理所有意外故障”、“可针对未来所有情况升级
47、”6.6. 推测：推测：局限于你所知道的六大应避免事项119 n 一句中有多个需求n 保持一个需求一个句子.n 包含连接词（将多个句子连接在一起）的需求是非常危险的. n 危险的连接词包括“和”, “或”, “并且”, “还有”.“当电池电压低于3.6伏时电量警示灯亮起通知使用者并且系统将当前工作空间中的数据保存起来.”更好1)将通知用户电池电量不够的需求作为一个独立的“用户需求”分离出来. 2) 一个系统需求是“系统将保存当前工作空间中的数据当电压电量低于3.6伏”3) 当不能清晰刻划一个的描述和提及需求时，创建跟踪，归属，分配和验证关系是非常困难的避免问题120 n 避免模糊n 书写尽可能
48、清晰和明确n 导致模糊的几种原因:n “或” 容易导致混合的需求出现n 缺乏力度的定义(仅仅给出一些简单的描述和用例)n 松散的定义(用“等等”) “呼叫方将听到音乐，通知和/或忙音当呼叫方等待、延迟或碰到占线等等更好1) 定义每种呼叫类型将听到什么和多久.例如，呼叫方延迟（当被叫方正在通话时等候）等候时收到音乐.2) “和/或” 和 “等等”的使用表明需求描述的贫乏和松散. 避免问题121 n 构造严谨的需求条款n 不严谨的需求条款是非常危险的n 造成显而易见的疏漏,不是推翻原需求内容就是增加需求内容 n 问题出现在测试n 不严谨的词包括: 如果, 但是, 当, 除.外, 除非, 虽然. “
49、除假日或特殊销售通知或诸如此类事情外，除非事先确定，服务人员将判断是播放音乐还是新闻”.n 更好1) 尽量完成细节描述，完成细节业务规则的描述，以完成需求的判断.2) 小心使用不严谨的词. “除非预先确定”, “除外”, “或诸如此类.”避免问题122 n 使用含糊或不确定的术语n 很多非正式的词句会造成系统质量因太过模糊而不能验证.n 含糊的词包括: 用户友好的, 通用的, 灵活的, 近似地,. “将为用户提供一个界面友好的前端.”n 更好1) 系统能够通过辅助菜单和对话框引导用户使用.2) 向导功能指导用户进行下一步操作.避免问题123 n 避免太过理想化 n 理想化的意思是不可能实现.
50、n 理想化的词包括: 100%实现. 满足所有条件. 处理所有异常. 无条件的修改. 无修改情况下满足所有平台.“网络系统可以彻底地处理全部异常错误并且全兼容所有硬件特征.”更好1) 网络系统将处理2版本用户手册附录A-错误列表中的错误2) 平均两周内解决网络系统的硬件特征兼容问题.避免问题124 大纲n 需求管理介绍n 需求管理的重要概念n 需求跟踪n 深入管理需求n 编写好的需求n 需求变更管理n 变更的影响分析n 变更的记录n 变更的及时发现和通知125 管理变更n 理解变更的影响n 要求：理解需求之间的关系，并且深入到文档内部跟踪需求条目满足满足满满足足客户需求客户需求系统需求系统需求
