需求管理方法论ppt课件

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