需求开发过程ppt课件.ppt

第二章软件需求工程过程 1 课程提纲 软件需求基本理论和概念软件需求工程过程软件需求获取软件需求分析软件需求规格说明软件需求验证软件需求管理软件需求实现软件需求工程新进展软件需求开发与需求管理工具 2 内容提要 Agenda 软件需求工程定义客户的需求观需求知识技能获取定义项目业务需求 视图及范围需求开发过程包括需求获取 需求分析 撰写需求规格说明和需求验证需求管理过程包括需求变更和风险管理 配置与版本控制 需求跟踪链与需求状态跟踪需求管理与项目管理CMMI需求工程过程模型 3 一 软件需求工程 需求工程是指应用已证实有效的技术 方法进行需求分析 确定客户需求 帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科 它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束 形成需求文档 并对用户不断变化的需求演进给予支持 注意 和所有工程学科一样 需求工程并不是以零星偶发的 随机的或无计划的方式进行 而是代之以已证明方法的系统化应用 4 软件需求工程组成 需求工程 需求管理 需求开发 编写规格说明 分析 问题获取 验证 包括软件类产品中需求收集 评价 编写文档等所有活动 建立并维护在软件工程中同客户达成的契约 软件需求工程划分为需求开发和需求管理 5 需求开发过程 需求开发可进一步分为需求获取 Elicitation 需求分析 Analysis 规格说明 Specification 和需求验证 Validation 这些子学科涵盖了为软件和软件相关产品收集 评估 和记录需求相关的所有活动 6 1 需求管理活动 需求管理过程 7 基准需求说明 分析编写文档评审 商议 需求变更过程 市场 需求 客户 管理 市场客户管理 项目环境 当前基线 需求开发 需求管理 修正后基线 需求变更 项目变更 需求开发与需求管理之间的界限 需求开发与管理之间的界线 8 二 客户的需求观BrainStorming Whoarethepotentialstakeholders 风险承担者 ofasoftwareproject Showyourthinking Users maybeclassifiedintodifferentusers CustomersDevelopersTestersMarketingteamSeniormanagementteamProductmanagement 9 KeyStakeholders 10 对一个软件项目最关注的人员 用户 Users 考虑的重点是产品的易使用性 功能客户 Customers 考虑的重点是产品的功能以及由此能产生的效益开发人员 Engineers 考虑的重点是产品的可开发性 技术细节 11 用户的特征 从产品可操作性出发思考问题不一定是受到良好训练的工程师了解产品操作环境对产品技术 商务背景 限制不感兴趣 12 客户的特征 是用户的代理人 客户可能是同一组织内的系统工程组 市场组 其他职能部门 多数情况下可能是一个外部客户 如中国移动 CMCC 中国联通 Unicom ServicesProvider ISP 对产品的性能 功能有本能的感觉集中于产品的商务方面关心产品合同与合法性等细节客户不一定是受到良好训练的工程师对产品的可操作性的知识并不全面 13 开发人员的特征 是受到良好训练的工程师日常交流更善于使用专业术语对产品的可操作性的知识并不全面可能过分服从 也可能过于坚持己见钟爱于技术完美性 疏忽商务上的作用 14 项目相关人员对项目的影响 15 通过协商获得合理的期望 用户 派生原始需求 扩展可选择性 了解开发人员和客户的问题 客户 开发人员 充足的人员 技术和资本配置 扩展可选择性了解用户和客户的问题 成本 时间表的合理分派 了解开发人员和用户的问题 通过团队合作协商 解决冲突 达成共识 16 用户对系统的期望 如何同用户一起构思系统的功能 17 三 需求知识技能获取 需求过程是必不可少的 所有项目的涉众都应该理解需求工程的概念和方法 这样有利于各方之间的沟通 将各涉众方召集起来利用一天的时间进行软件需求培训 这是打造团队的一种有效方法 18 三 知识技能获取 需求工程的知识技能是系统需求分析人员的基础 本门课程的学习实际上就是奠定这一基础的最好方式 如果缺少了这一领域的知识 唯一的方式通过培训来在一定程度上提高分析员的能力和水平 各位学员完全有可能担当小组培训师的任务 培训需求分析人员培训软件需求的用户代表和管理人员让开发人员了解问题域 应用领域 的基本概念编写项目术语汇编 19 三 知识技能获取 培训需求分析人员所有的开发人员都应接受一个基本的需求工程培训 但那些负责收集 编写文档和分析用户需求的人员应当进行更长时间 更加针对性的培训 把高水平的需求人员组织起来 通过良好的信息交流 了解应用领域并有效地应用需求工程中的成熟技术 20 三 需求知识技能获取 培训需求分析员 需要几天时间的培训熟练的需求分析员应具备以下特点 耐心思维条理性强有良好的交际和沟通能力理解产品应用领域掌握丰富的需求工程技术 21 三 知识技能获取 培训软件需求的用户代表和管理人员参与软件开发的用户代表应接受为期一天左右的需求工程培训 开发管理者和客户管理者也应参加 这样的培训将使他们理解强调需求的重要性 以及忽略需求带来的风险 22 三 需求知识技能获取 对用户代表和管理者进行软件需求培训 一到两天的培训明白重视需求的意义需求工作包括哪些活动要提交什么样的结果忽略需求过程会导致的风险更加体谅软件开发人员 23 三 知识技能获取 让开发人员了解问题域 应用领域 的基本概念组织一些简短的关于客户业务活动 术语 目标等方面的讨论会帮助开发人员对应用领域有个基本的了解 这能减少误解及工程中的返工 可能的情况下为每位人员或项目小组安排一个用户伙伴以便在项目过程中解释业务术语和概念 产品代表就应该扮演这样的角色 24 三 需求知识技能获取 对开发人员进行应用领域的相关培训 安排研讨课程减少在开发过程中的混淆 误解和返工在项目开发过程中为每位开发人员配备一位用户伙伴 负责解释行话和业务概念 25 三 知识技能获取 编写项目术语汇编为减少沟通方面的问题 编一部术语汇编将项目应用领域的专用词汇给予定义说明 既要包括那些有多种含义与用法的术语 也要包括那些在专用领域的术语解释 术语表中包括同义词 有多种含义的术语 以及既有特定领域的含义又有日常含义的术语 26 四 建立项目视图和范围 项目视图在高层上描述了产品涉及的各个方面 在期望的环境中所具有的功能 范围是对产品应该包含的部分的界定业务机遇的描述项目的目标产品范围和局限性客户及用户的特点优先级项目成功的标准 27 业务需求 业务需求 BusinessRequirement 表示组织或客户层次的目标 业务需求通常来自项目的投资人 购买产品的客户 实际用户的管理者 市场营销部门或产品策划部门 业务需求描述了组织为什么要开发一个系统 即组织希望达到的目标 28 业务需求 业务需求位于需求链中的最高层 这种需求定义了软件系统的视图 productvision 与范围 projectscope 用户需求和软件功能需求都必须符合业务需求设定的前景和目标 业务需求定义不充分的一个迹象是 某些特性先是被添加 然后被删除 之后又被加入 29 业务需求与用例 业务需求决定了应用的广度与深度 广度 breadth 指应用能完成哪些业务工作 即用例 深度 depth 说明将各项用例实现到何种程度业务需求会影响到用例及相关功能需求的实现优先级 业务需求对于需求的实现方式也有很大的影响 30 产品视图和项目范围 产品视图 productvision 将所有涉众统一到一个方向上 视图描述了产品用来干什么 它最终会是什么样子 项目范围 projectscope 确定当前的项目要解决产品长远规划中的哪一部分 范围同时定义了项目的限制 31 产品视图和项目范围 视图关系到整个产品 当产品的战略定位或信息系统的业务目标随时间发生改变时 视图也会随之变化 但这种变化相对缓慢 范围则只与一个特定的项目或实现产品功能下一增量的某次迭代有关 图2产品视图包括了每一个计划产品的版本的范围 32 视图与范围文档 视图与范围文档用于将业务需求收集整理到一个文档中 为后续的开发工作打好基础 视图与范围文档的所有者是项目的执行主管 投资负责人或其他类似的角色 需求分析员与他们合作编写视图和范围文档 33 视图与范围文档 视图与范围文档的模板模板为组织中项目团队要编写的文档提供了标准结构 可以对该模板进行修改以适应项目的特定要求 34 五 需求开发过程 需求获取需求分析撰写需求规格说明需求验证 35 需求开发过程 需求开发是一个迭代的过程 迭代 iteration 是需求开发成功的关键 36 需求开发过程 该过程的相关活动 确定产品将要面对的各类用户 从各类用户的代表处收集需求 了解用户的任务和目标 以及这些任务要实现的业务目标 分析从用户处得到的信息 将用户的任务目标与功能需求 非功能需求 业务需求 业务规则 解决方案及其他无关信息区分开来 37 需求开发过程 将顶层的需求分配到系统构架内定义好的软件组件中 了解各质量需求的相对重要性 协商需求的实现优先级 将收集的用户需求表述为书面的需求规格说明和模型 审阅需求文档 以确保在认识上与用户声明的需求一致 应在开发小组接受需求之前解决所有分歧 38 需求开发过程 需求获取 需求获取 Elicitation 是需求工程的核心任务 即确定软件系统涉众的需要及限制条件的过程 需求获取着重于发现用户需求 用户需求包括用户要求系统完成什么任务和用户对性能 易用性和其他质量属性的期望 39 需求开发过程 需求获取 需求获取 acquisition 发生在需求工程过程早期阶段 有时也称为需求收集 gathering 需求捕获 capture 主要关注以下几个方面 应当收集什么信息了解问题域的特性 渐进地刻画需求的方向有哪些信息来源信息来源是多方面的 包括所有项目风险承担者 Stakeholders 相似系统的类同分析等可能通过什么机制或技术收集 40 需求开发过程 需求获取 确定需求开发过程编写项目视图和范围文档将用户群分类并归纳各自特点选择每类用户的产品代表建立起典型用户的核心队伍让用户代表确定用户使用实例召开应用程序开发联系会议 JAD 分析用户工作流程确定质量属性和其它非功能需求通过检查当前系统的问题报告来进一步完善需求跨项目重用需求 41 需求开发过程 需求获取 确定需求开发过程确定如何组织需求的收集 分析 细化 核实的步骤并编写成文档 这里也包括该活动的安排和进度计划 42 需求开发过程 需求获取 编写项目视图和范围文档项目视图和范围文档应该包括高层的产品业务目标 所有的使用实例和功能需求都必须遵从能达到的业务需求 项目视图说明使所有项目参与者对项目的目标能达成共识 而范围则是作为评估需求或潜在特性的参考 43 需求开发过程 需求获取 将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况 要将可能使用产品的客户分成不同组 他们可能在使用频率 使用特性 优先等级或熟练程度等方面都有所差异 详细描述他们的个性特点及任务状况将有助于产品设计 44 需求开发过程 需求获取 选择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策 这对于内部信息系统的开发是最易实现的 因为用户就是身边的职员 而对于商业系统开发 就得在主要客户或测试者中建立起良好的合作关系 并确定合适的产品代表 他们必须一直参与项目的开发而且有权作出决策 45 需求开发过程 需求获取 建立起典型用户的核心队伍把同类产品或其先前版本用户代表召集起来 从他们那里收集目前产品需求 这一团队对商业开发很有实际意义 因为你拥有庞大且多样的客户基础 与产品代表的区别在于 核心队伍成员通常不做决策 46 需求开发过程 需求获取 让用户代表确定用户使用实例从用户代表处收集他们使用软件完成所需任务的描述 使用实例 讨论用户与系统间的交互方式和对话要求 在编写使用实例的文档时可使用标准模板 在使用实例基础上导出功能需求 47 需求开发过程 需求获取 召开应用程序开发联系会议 JAD JAD会议是范围广的 简便灵活的专题讨论会 workshop 也是分析人员与客户代表之间一种很好的合作办法 并能由此拟出需求文档的底稿 该会议通过紧密而集中的讨论将客户与开发人员间的合作关系付诸实践 48 需求开发过程 需求获取 分析用户工作流程观察用户执行业务任务的过程 画一张简单的示意图 如数据流图 来描绘出用户什么时候获得什么数据 并怎样使用这些数据 编制业务过程流程文档将有助于明确产品的使用实例和功能需求 你甚至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标 49 需求开发过程 需求获取 确定质量属性和其它非功能需求在功能需求之外再考虑非功能的质量特点 这才会使你的产品最终满足客户的期望 这些质量特点包括 性能 有效性 可靠性 可用性等 而规范这些质量属性很大程度上决定于客户提供的信息 50 需求开发过程 需求获取 通过检查当前系统的问题报告来进一步完善需求客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加新特性的想法 负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息 51 需求开发过程 需求获取 跨项目重用需求如果客户要求的功能与已有的产品很相似 则可以查看需求是否有足够的灵活性以允许重用一些已有的软件组件 52 需求开发过程 需求分析 需求分析 Analysis 是对需求进行分类并将它们组织为相关的子集 根据其他需求的关系来考察每个需求 检查需求的一致性 疏忽和二义性 以及根据客户 用户的需要对需求进行排序 53 需求开发过程 需求分析 需求分析包括提炼 分析和仔细审查已收集到的需求信息 确保所有的风险承担者都明白其含义并找出错误和遗漏 分析的目的在于开发出高质量的具体的需求 为项目估算 结构设计和测试提供定量信息 54 需求开发过程 需求分析 绘制系统关联图创建用户接口原型分析需求可行性确定需求优先级别为需求建立模型创建数据字典使用质量功能部署 55 需求开发过程 需求分析 绘制系统关联图这种关联图是用于定义系统与外部系统实体间的界限和接口的简单模型 通过关联图可以明确定义通过接口的信息流和物质流 56 需求开发过程 需求分析 57 需求开发过程 需求分析 创建用户接口原型当开发人员和用户都不能确定需求时 开发一个用户接口原型即一个可能的局部实现 用户通过评价原型将使项目参与者能更好地理解所要解决的问题 借此找出需求中的问题或者通过增加新需求完善对问题的规范 58 需求开发过程 需求分析 分析需求可行性在允许的成本 性能要求下 分析每项需求实施的可行性 明确与每项需求实现相联系的风险 包括是否与其它需求相冲突 对外界因素的依赖和技术障碍等 59 需求开发过程 需求分析 确定需求优先级别应用分析方法确定使用实例 产品特性和单项需求实现的优先级别 以优先级为基础确定产品版本将包括哪些需求或特性 60 需求开发过程 需求分析 为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明 它们能提供不同的信息与关系有助于找到不正确的 不一致的 遗漏的和冗余的需求 这样的模型包括数据流图 实体关系图 状态变换图 对话框图 对象类及交互作用图 61 需求开发过程 需求分析 创建数据字典数据字典是对系统用到的所有数据项和结构的定义 以确保开发人员使用统一的数据定义 在需求阶段 数据字典至少应定义客户数据项以确保客户与开发小组使用一致的定义和术语 分析和设计工具通常包括数据字典组件 62 需求开发过程 需求分析 使用质量功能部署质量功能部署 QFD 是一种高级系统技术 它将产品特性 属性与对客户的重要性联系起来 该技术提供了一种分析方法以明确哪些是客户最关注的特性 QFD将需求分为三类 期望需求 即客户或许并未提及 但若缺少会让他们感到不满意 普通需求 兴奋需求 即实现了会给客户带去惊喜 但若未实现也不会受到责备 63 需求开发过程 规格说明 需求规格说明书 SRS 中包含详细的软件的功能需求和非功能需求 规格说明是系统和需求工程师生产的最终工作产品 它将作为硬件工程 软件工程 数据库工程以及人力工程的基础 64 需求开发过程 规格说明 采用SRS模板指明需求的来源为项目需求注上标号记录业务规范创建需求跟踪能力矩阵 65 需求开发过程 规格说明 采用SRS模板通常每个软件开发组织都要为编写软件需求文档定义一种标准模板 为记录需求及相关信息提供统一的结构 模板类型很多 这就需要选择适合其软件项目特性的模板 达到此目的有时还需要作些改动以适合项目的特点 一个通用模板是IEEE标准830 1998SRS模板 66 需求开发过程 规格说明 指明需求的来源为了让所有项目风险承担者明白SRS中为何提供这些功能需求 需要追溯每项需求的来源 这可能是一种使用实例或其它客户要求 也可能是某项更高层系统需求 业务规范 政府法规 国际规范或标准等 67 需求开发过程 规格说明 为项目需求注上标号制定一种规则为SRS中每项需求提供一个独立的可识别的标号 这种规则应当很健全 允许增加 删除和修改 被赋予标号的需求会被容易地跟踪 记录需求变更并为需求状态和变更活动建立度量 68 需求开发过程 规格说明 记录业务规范业务规范是指产品的操作或使用原则和流程等 这部分内容将是SRS中的独立部分或章节 有时会形成一个独立文档 部分业务规范将引出相应的功能需求 69 需求开发过程 规格说明 创建需求跟踪能力矩阵建立一个矩阵 matrix 把每项需求与实现 测试规范和代码部分联系起来 同时也和更高层需求以及任何与其相关的其它需求联系起来以便需求的跟踪和管理 职业的做法是在开发过程建立这个矩阵 而不是最后去补建 70 需求开发过程 需求验证 需求验证 Validation 将检查规格说明以保证所有系统需求已被无歧义地陈述 不一致性 疏忽和错误已被检查出并纠正 并且工作产品符合为过程 项目和产品建立的标准 71 需求开发过程 需求验证 审查需求文档以需求为依据编写测试用例编写用户手册确定合格的标准 72 需求开发过程 需求验证 审查需求文档对需求文档的进行正式审查是保证软件质量的很有效也是很常用的方法 组织一个由不同代表 如分析人员 客户代表 设计人员 测试人员等 组成的小组 对SRS及相关模型进行仔细的审查 另外 需求开发其间非正式评审也是发现错误 增强需求质量的常用和有效的方法 73 需求开发过程 需求验证 以需求为依据编写测试用例根据用户需求所要求的产品特性写出黑盒功能测试用例 以此检验是否达到了客户期望的要求 是否有被疏忽的需求 需求模型 对话框和原型等是否正确 74 需求开发过程 需求验证 编写用户手册在需求开发早期可起草一份用户手册 用它作为需求规格的参考并辅助需求分析 优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能 而辅助需求如质量属性 性能需求及对用户不可见的功能则在SRS中予以说明 75 需求开发过程 需求验证 确定合格的标准让用户描述什么样的产品才算满足他们的使用要求 将合格的测试建立在使用情景描述 scenario 或使用实例 usecase 的基础之上 76 六 需求管理过程 需求管理是一组用于帮助项目组在项目进展中的任何时候去标识 控制和跟踪需求的活动 需求管理过程包括变更控制 ChangeControl 版本控制 VersionControl 需求跟踪 RequirementsTracing 与需求状态跟踪 RequirementsStatusTracking 77 需求管理过程 主要的需求管理活动 78 需求管理过程 该过程包括以下活动 定义需求基线 某一时刻 对特定版本中已达成一致的需求内容的描述 审查需求变更请求 评估其可能产生的影响以决定是否批准 以可控的方式将准的需求变更融入项目中 79 需求管理过程 续 保持项目计划与需求的同步 估计需求变更的影响 在此基础上协商新的需求约定 跟踪每项需求 找到与其对应的计划 源代码和测试用例 testcase 在项目开发过程中 始终跟踪需求的状态和变更 80 需求开发与需求管理 需求开发与需求管理的分界 81 六 需求管理过程 确定需求变更控制过程建立变更控制委员会进行需求变更影响分析跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性使用需求管理工具 82 六 需求管理过程 确定需求变更控制过程确定一个选择 分析和决策需求变更的过程 所有需求变更都要遵循此过程 商业化问题跟踪工具都能支持变更控制过程 83 六 需求管理过程 建立变更控制委员会组织一个由项目风险承担者组成的小组作为变更控制委员会 由他们来确定进行哪些需求变更 此变更是否在项目范围内 估计它们的价值并对此评估设置实现优先级 制定目标版本 84 六 需求管理过程 进行需求变更影响分析应评估每项选择的需求变更 以确定它对项目计划安排和其它需求的影响 明确与变更相关的任务并评估完成这些任务所需的工作量 通过这些分析将有助于变更委员会作出更好的决策 85 六 需求管理过程 跟踪所有受需求变更影响的工作产品当进行某项需求变更时 参照需求跟踪能力矩阵找到相关的其它需求 设计模板 源代码和测试用例 这些相关部分可能也需要修改 从而减少因疏忽而不得不变更产品的机会 在需求发生变化的情况下 这种变更是必须进行的 86 六 需求管理过程 建立需求基准版本和需求控制版本文档确定一个基准需求 之后的需求变更将以此为基准遵循变更控制过程 每个版本的需求规格说明都必须是独立说明以避免新旧版本混淆 成熟的做法是使用合适的配置管理工具在版本控制下进行 87 六 需求管理过程 维护需求变更的历史记录记录变更需求文档版本的日期 变更原因 版本号 变更责任人 版本控制工具能够自动完成这些任务 88 六 需求管理过程 跟踪每项需求的状态建立一个数据库 其中每一条记录保存一项功能需求 需求属性 需求状态 如已推荐的 以通过的或称为已通过评审的 已实施的 已验证的 未来实现的等 这样可以通过工具检索每类需求的数量 89 六 需求管理过程 衡量需求稳定性记录基准需求的数量和每周或每月的变更 添加 修改 删除 量 过多的需求变更是一个 报警信号 意味着问题并未真正定义清楚 项目范围并未很好地确定下来 或者政策变化较大等 通常这需要递交给项目管理委员会商讨解决方案 90 六 需求管理过程 使用需求管理工具商业化的需求管理工具能帮助你在数据库中存储不同类型的需求 为每项需求确定属性 可跟踪其状态 并在需求与其它开发工作产品间建立跟踪能力联系链 91 七 需求管理与项目管理 选择一种合适的软件开发生存周期基于需求的项目计划发生需求变更时协商项目约定编写文档 管理与需求相关的风险跟踪需求工程所耗的工作量 92 七 需求管理与项目管理 选择一种合适的软件开发生存周期经典的瀑布模型只适用于需求说明在项目早期即可全部完成的情况 通常需根据所开发项目的性质选择适合的一种或几种开发方法 例如 如果需求说明在项目早期无法全部确定 则从最为清晰易懂的部分开始 93 七 需求管理与项目管理 基于需求的项目计划随着需求细节不断变得清晰 完善 项目开发计划的进度安排将会不断改变 一开始可以根据项目视图和范围对工作量 成本 进度等作一估算 其估计当然很不可靠 但随着需求说明的完善 其估计也会越来越准确 94 七 需求管理与项目管理 发生需求变更时协商项目约定当在项目中添加新的需求 或需求发生变化时 需要估计能否在目前安排下利用现有资源保质保量按时完成 如果不可能 需要协商新的可行的约定和计划 如果协商不成功 则需要将可能的后果和更新项目风险管理计划联系起来 以反映出对项目成功新的不利因素 95 七 需求管理与项目管理 编写文档 管理与需求相关的风险采用自由讨论的方法并将与需求相关的项目风险编写成文档 利用各种方法来减轻 阻止和跟踪这些风险 需求风险管理与控制在很多组织都会在每月或每周项目例会必讨论的议题 其中会包括前述的需求分类与变更相关的数据图表 96 七 需求管理与项目管理 跟踪需求工程所耗的工作量记录需求开发和管理工作量 利用这些数据可以评估计划的需求活动是否已达到所期望的要求 并可以为将来项目的需求工程提供更好的资源计划 97 八 CMMI中需求管理的流程图 98 八 CMMI需求工程过程模型 CMMI CapabilityMaturityModelIntegration 即能力成熟度模型集成 CMMI是CMM模型的最新版本 早期的CMMI CMMI SE SW IPPD 1 02版本是应用于软件业项目的管理方法 SEI在部分国家和地区开始推广和试用 随着应用的推广与模型本身的发展 演绎成为一种被广泛应用的综合性模型