第02章 需求工程.pptVIP

软件需求工程 内容 瀑布模型 2.1 软件需求分析的基本概念 2.1.1 软件需求分析的任务 　　需求分析阶段的任务： 　　在可行性分析的基础上，进一步了解确定用户需求。准确地回答 “系统必须做什么？” 的问题。获得需求规格说明书。 　Boehm对软件需求的定义： 　　研究一种无二义性的表达工具，它能为用户和软件人员双方都接受并能够把“需求”严格地、形式地表达出来。 需求的类型 业务需求（business requirement） 客户对系统的高层次的目标要求。在项目视图与范围文档中予以说明 用户需求（user requirement） 用户使用产品必须要完成的任务 功能需求（functional requirement） 开发人员必须实现的软件功能，使得用户能完成他们的任务，满足业务需求 非功能需求（non-functional requirement ） 对系统提供的服务或者功能提出的约束，包括时间、开发过程、软件质量、标准等约束 一个例子 从不同的角度来看，需求具有不同的层次，即业务需求、用户需求、功能需求和非功能需求等 例子：字处理程序 之 “ 拼写检查器” 业务需求：“用户能有效地纠正文档中的拼写错误” 用户需求：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词” 功能需求：“找到并高亮度提示错词的操作”；“显示提供替换词的对话框”；“实现整个文档范围的替换” 非功能需求：“替换操作执行速度快”；“异常出现概率小” 需求获取 系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定： 系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下系统或产品使用状况的应用场景 为更好地定义需求而开发的任意原型。 需求获取的工作产品为进行需求分析提供了基础 需求获取方法与策略 建立顺畅的通信途径 访谈与调查 观察用户操作流程 组成联合小组 用况（Use Case） 建立顺畅的通信途径 建立分析所需要的通信途径，以保证能顺利地对问题进行分析。 访谈与调查 在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备： 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化； 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题； 提问和回答在汇总后应能够反映用户需求的全貌。 例子：“赛艇比赛成绩计算系统”的第一次面谈的准备计划 观察用户操作流程 到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。 组成联合小组 便利的应用规约技术(Facilitated Application Specification Techniques , FAST) ： 打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调 FAST基本原则 在中立的地点举行由开发者和用户出席的会议； 建立准备和参与会议的规则； 建议一个足够正式的议程以便可以进行自由的交流； 一个“协调者”(可以是用户、开发者或其他外人)来控制会议； 使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)； 目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。 需求分析与协商 需求获取结束后，分析活动需要： 对需求进行分类组织 分析每个需求与其它需求的关系，检查需求的一致性、重叠和遗漏的情况 根据用户的需要对需求进行排序 在需求获取阶段，经常出现以下问题： 用户提出的要求超出软件系统可以实现的范围或实现能力； 不同的用户提出了相互冲突的需求 需求协商 协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案 协商不是简单的逻辑或技术上的争论 要注意组织和行政方面的因素 ①不一致的目标 ②责任的丧失或转移 ③组织文化 ④组织管理态度和士气 ⑤部门差异 通常会议是解决冲突最快的方式 参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员 会议应该讨论那些非正式讨论不能解决的问题 通常会议分为三个阶段： 叙述阶段 讨论阶段 决策阶段 系统建模 建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图 在软件需求分