软件工程课件:3%-第03章 需求工程.ppt

上传人(卖家):罗嗣辉 文档编号:2046196 上传时间:2022-01-21 格式:PPT 页数:63 大小:201KB
下载 相关 举报
软件工程课件:3%-第03章 需求工程.ppt_第1页
第1页 / 共63页
软件工程课件:3%-第03章 需求工程.ppt_第2页
第2页 / 共63页
软件工程课件:3%-第03章 需求工程.ppt_第3页
第3页 / 共63页
软件工程课件:3%-第03章 需求工程.ppt_第4页
第4页 / 共63页
软件工程课件:3%-第03章 需求工程.ppt_第5页
第5页 / 共63页
点击查看更多>>
资源描述

1、复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程2/63软件质量软件质量=系统所实现的需求系统所实现的需求/客户所期望的需求客户所期望的需求 软件项目投标及签订合同的基础软件项目投标及签订合同的基础 软件系统实现的基础软件系统实现的基础 系统确认移交的基础系统确认移交的基础复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程3/63 IEEE Standard Glossary of Software Engineering Terminology 用户解决一个问题或达到一个目标所需要的一种状况或能力 系统为了满足一种约定、标准、规格说明

2、或其它正式文件而必须满足或拥有的一种状况或能力 以上两种状态或能力的文档化表示主观需求主观需求客观需求客观需求需求文档需求文档复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程4/63 功能性需求功能性需求 系统需要提供的服务或功能:如图书检索 系统对特定输入的处理方式:如对非法输入的提示 系统在特定环境下的行为:如长时间无操作时的屏保 非功能性需求非功能性需求 对系统功能或服务附加的质量约束,例如响应时间、容错性、安全性等客户所关心的(外部质量) 从系统开发和维护角度出发的质量属性,例如可理解性、可扩展性、可配置性等软件开发或维护者所关心的(内部质量、软件所特有)

3、复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程5/63需求工程概述需求工程概述需求获取需求获取需求分析、协商与建模需求分析、协商与建模需求规约与验证需求规约与验证需求管理需求管理复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程6/63需求获取需求获取需求分析、协商与建模需求分析、协商与建模需求规约与验证需求规约与验证需求管理需求管理复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程7/63 Alan Davis 把需求工程定义为把需求工程定义为“直到直到(但不包括)把软件分解为实际架构构(但不包括)把软件

4、分解为实际架构构件之前的所有活动件之前的所有活动” (强调强调做什么做什么) Herb Krasner定义了需求工程的五阶段定义了需求工程的五阶段生命周期:生命周期:需求定义和分析需求定义和分析、需求决策需求决策、形成需求规格形成需求规格、需求实现与验证需求实现与验证、需求需求演进管理演进管理 Matthias Jarke和和Klaus Pohl提出了三提出了三阶段周期的说法:阶段周期的说法:获取获取、表示表示和和验证验证 复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程8/63 需求获取:资料收集需求获取:资料收集 需求分析与协商:理解分析整理需求分析与协商:理

5、解分析整理 系统建模:用模型描述系统建模:用模型描述(写下来写下来) 需求规约:完善需求文档并定稿需求规约:完善需求文档并定稿 需求验证:验证确认需求验证:验证确认 需求管理:整体规划及变更管理需求管理:整体规划及变更管理复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程9/63 系统分析人员通过与用户的交流,了解业系统分析人员通过与用户的交流,了解业务现状以及对待开发系统的期望务现状以及对待开发系统的期望 确定系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下的应用场

6、景以及为更好地定义需求而开发的系统原型 需求获取收集的需求获取收集的“原始材料原始材料”为进行需求为进行需求分析提供了基础分析提供了基础复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程10/63 对需求进行分类组织,分析需求之间的对需求进行分类组织,分析需求之间的关系关系 检查需求的一致性、重叠和遗漏的情况检查需求的一致性、重叠和遗漏的情况 根据用户的需要对需求进行排序。根据用户的需要对需求进行排序。 在需求获取阶段,经常出现以下问题:在需求获取阶段,经常出现以下问题: 提出的要求超出软件系统可以实现的范围或实现能力 不同的用户提出了相互冲突的需求 复旦大学计算机

7、科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程11/63 建模工具的使用在用户和系统分析人员之建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁间建立了统一的语言和理解的桥梁 系统分析人员借助建模技术对获取的需求系统分析人员借助建模技术对获取的需求信息进行分析和表达,排除错误和弥补不信息进行分析和表达,排除错误和弥补不足,确保需求文档正确反映用户真实意图足,确保需求文档正确反映用户真实意图 常用的分析和建模方法有面向数据流方法、常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法面向数据结构方法和面向对象的方法复旦大学计算机科学与工程系复旦大

8、学计算机科学与工程系 软件工程课程软件工程课程12/63 通过建立完整的信息描述、详细的功能和通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、行为描述、性能需求和设计约束的说明、合适的验收标准,给出对目标软件的各种合适的验收标准,给出对目标软件的各种需求需求 软件需求规约软件需求规约是分析任务的最终产物是分析任务的最终产物 需求规约作为用户和开发者之间的一个协需求规约作为用户和开发者之间的一个协议,在之后的软件工程各个阶段发挥重要议,在之后的软件工程各个阶段发挥重要作用作用复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程13/63 需求开发

9、阶段工作的复查手段需求开发阶段工作的复查手段 对功能的正确性、完整性和清晰性,对功能的正确性、完整性和清晰性,以及其它需求给予评价以及其它需求给予评价 为保证软件需求定义的质量,评审应为保证软件需求定义的质量,评审应以专门指定的人员负责以专门指定的人员负责(应该是需求应该是需求分析人员之外的其他人员分析人员之外的其他人员),并按规,并按规程严格进行程严格进行 复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程14/63 二者密切相关二者密切相关 都需要对系统需求中的遗漏和冲突进行识别和分析 区别 需求分析处理的是未整理的原始需求,此时需求分析处理的是未整理的原始需求

10、,此时发现的问题是客户的问题发现的问题是客户的问题 需求确认的对象是经分析后形成的需求规格需求确认的对象是经分析后形成的需求规格说明,此时发现的问题是需求分析人员的问说明,此时发现的问题是需求分析人员的问题,此外还需要考虑需求文档是否满足相应题,此外还需要考虑需求文档是否满足相应的质量标准的质量标准复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程15/63复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程16/63 在实际的开发过程中,获取、分析、建在实际的开发过程中,获取、分析、建模、编写规约和验证这些需求开发活动模、编写规约和验证这

11、些需求开发活动不会是线性地、顺序地完成。实际上,不会是线性地、顺序地完成。实际上,这些活动是交叉的、递增的和反复的。这些活动是交叉的、递增的和反复的。复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程17/63 一种获取、组织并记录系统需求的系一种获取、组织并记录系统需求的系统化方案:对所有需求工程相关活动统化方案:对所有需求工程相关活动的规划和总体控制的规划和总体控制 需求变更管理:一个使用户与项目团需求变更管理:一个使用户与项目团队对不断变更的系统需求达成并保持队对不断变更的系统需求达成并保持一致的过程一致的过程(变更的记录、分析、变变更的记录、分析、变更过程管

12、理、追踪等更过程管理、追踪等)复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程18/63 从高度抽象的系统服务或系统目标到对某从高度抽象的系统服务或系统目标到对某一系统功能的精确约束一系统功能的精确约束 原始需求原始需求 客户对软件系统及新的工作方式的期望目标 客户单位已经存在的日常工作方式和业务规则 系统所属领域固有的法规、标准或惯例等 一般目标:更快、更好、更安全 需求文档需求文档 自然语言描述 UML图等图形表示 业务规则表格复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程19/63需求工程概述需求工程概述需求分析、协商与建模需

13、求分析、协商与建模需求规约与验证需求规约与验证需求管理需求管理复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程20/63 缺少用户参与是项目失败的主要原因之一缺少用户参与是项目失败的主要原因之一 良好的开端是成功的一半良好的开端是成功的一半 需求获取:通过客户调研等手段对需求进需求获取:通过客户调研等手段对需求进行收集、分析、细化、核实和组织行收集、分析、细化、核实和组织 两种项目两种项目(相对相对)的需求获取过程:的需求获取过程: 产品项目:一般是根据公司战略和市场需求研发,旨在进行批量出售或推广的项目 工程项目:一般是根据与用户签定的合同研发,旨在满足特定用户

14、需求的项目复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程21/63 建立顺畅的通信途径建立顺畅的通信途径 深入客户方进行访谈与调查深入客户方进行访谈与调查 观察用户操作流程观察用户操作流程 组成各方联合小组组成各方联合小组 使用基于用况使用基于用况(Use Case)的方法的方法复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程22/63 建立分析所需要的通信途径,以建立分析所需要的通信途径,以保证能顺利地对问题进行分析保证能顺利地对问题进行分析复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程23/63

15、访谈访谈/调查计划:从初步的需求了解调查计划:从初步的需求了解出发,制订需要了解或讨论的问题出发,制订需要了解或讨论的问题的顺序和范围等的顺序和范围等 有利于保证访谈的效率和全面性,但灵活性不足 在具体的实践中,通常采用折衷的在具体的实践中,通常采用折衷的方法,即适当地计划好面谈,但不方法,即适当地计划好面谈,但不要过于详细,允许有一定的灵活性要过于详细,允许有一定的灵活性复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程24/63 所提问的问题应该所提问的问题应该循序渐进循序渐进,从整体,从整体的方面开始提问,接下来的问题应有的方面开始提问,接下来的问题应有助于对

16、前面的问题更好的理解和细化助于对前面的问题更好的理解和细化 不要限制用户对问题的回答不要限制用户对问题的回答,这有可,这有可能会引出原先没有注意的问题能会引出原先没有注意的问题 提问和回答在汇总后应能够反映用户提问和回答在汇总后应能够反映用户需求的全貌需求的全貌不断汇总不断汇总-反馈反馈-汇总汇总复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程25/63 会议讨论法会议讨论法 适用于需求调研早期 特点:需求获取的信息量大,但有时全面性和深入性不足 做好调研计划,同时掌握好计划与灵活性的平衡 一般由客户方的基本情况介绍开始一般由客户方的基本情况介绍开始 随着情况了解

17、的深入,分析人员逐渐成为主导:随着情况了解的深入,分析人员逐渐成为主导:要求分析人员有较强的理解和交流能力、思维敏要求分析人员有较强的理解和交流能力、思维敏锐,能够有效地引导并把握讨论的议题和方向锐,能够有效地引导并把握讨论的议题和方向复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程26/63 调查问卷调查问卷 由分析人员拟定问卷(选择、判断居多)请客户方代表回答 适用于需求调研的中后期,往往用于对前期发现的一些不明确或不一致的地方进行确认 特点:信息量较小,但能够引导客户对某些关键问题进行思考,给出明确、严谨的回答和判断 需要分析人员在前期需求调研基础上敏锐地发

18、现需进一步确认的不明确或不一致需求,例如: 客户要求高安全性,而开发组反馈推荐解决方案是使用客户要求高安全性,而开发组反馈推荐解决方案是使用USB Key这样的硬件证书进行身份验证和加密传输,但可这样的硬件证书进行身份验证和加密传输,但可能会到来额外的运营开销,需要客户确认是否能够接受能会到来额外的运营开销,需要客户确认是否能够接受复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程27/63 原型系统原型系统 由开发小组快速开发一个近似的功能原型(往往以操作界面为主),分析人员与客户围绕着原型系统的演示进行需求讨论 适用于客户仅有一些宏观的设想而自身需求还不明确的情

19、况下 特点:能够帮助客户将自己的设想落实为具体需求,能够有效激发客户的思维,但需要额外的原型开发开销 要求分析人员自身对需要有较强的认识,基本能够把握客户的潜在想法或者开发方有类似的成品软件复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程28/63 第一阶段:了解基本情况第一阶段:了解基本情况 请教务处老师介绍背景,如学生总数、课程数量、选课相关的基本制度等 第二阶段:制订访谈计划,深入讨论第二阶段:制订访谈计划,深入讨论相关需求相关需求 除了学生还有哪些相关用户? 选课规则(学分、课程人数限制等)、退课规则 了解客户对系统的期望:准确、访问速度快 复旦大学计算机

20、科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程29/63 第三阶段:基本了解需求后就一些关键细第三阶段:基本了解需求后就一些关键细节通过问卷进行明确节通过问卷进行明确 在已经了解总体选课人数之后,需要进一步了解通常情况下的选课持续时间、是否按院系逐步开放选科、选课人数的一般分布等与性能设计密切相关 推荐关键管理人员使用USB Key设备,经济上是否可以接受 原型:如该企业有类似成熟系统可结合系原型:如该企业有类似成熟系统可结合系统演示进行需求调研统演示进行需求调研复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程30/63 客户与用户的区别客户与用

21、户的区别 如:选课系统的客户可能是学校教务处,但用户包括学生、教务员、管理人员、教务领导等 到用户的实际工作环境中对用户的工到用户的实际工作环境中对用户的工作流程进行观察,了解用户实际的操作流程进行观察,了解用户实际的操作环境、操作过程和操作要求,对照作环境、操作过程和操作要求,对照用户提交的问题陈述,对用户需求可用户提交的问题陈述,对用户需求可以有更全面、更细致的认识以有更全面、更细致的认识复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程31/63 突出客户在需求分析乃至项目开发突出客户在需求分析乃至项目开发中的作用中的作用 Facilitated Applic

22、ation Specification Techniques (FAST) 打破用户和开发者的界限,共同组成一个联合小组 发挥各自的长处,共同负责项目的推进 有助于发挥各自优势并增进解和协调 复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程32/63在中立的地点举行由开发者和用户出席的会议;在中立的地点举行由开发者和用户出席的会议;建立准备和参与会议的规则;建立准备和参与会议的规则;建议一个足够正式的议程以便可以进行自由的交流;建议一个足够正式的议程以便可以进行自由的交流;一个一个“协调者协调者”(他可以是用户、开发者或其他外人他可以是用户、开发者或其他外人)来控

23、制会议;来控制会议;使用一种使用一种“定义机制定义机制”(它可以是工作表、图表、墙它可以是工作表、图表、墙上胶黏纸或墙板上胶黏纸或墙板);目标是标识问题、提出解决方案的要素、商议不同的目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的方法、以及在有利于完成目标的氛围中刻画出初步的需求。需求。复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程33/63 分析员可以根据所获取的需求创建一组标分析员可以根据所获取的需求创建一组标识一串待建造系统的使用场景识一串待建造系统的使用场景 创建用况模型的主要步骤如下:创建用况模型的主要步骤

24、如下:1) 确定谁会直接使用该系统,即参与者(Actor) 2)选取其中一个参与者 3)定义该参与者希望系统做什么,参与者希望系统作的每件事将成为一个用况 4)对每件事来说,何时参与者会使用系统,通常会发生什么,这就是用况的基本过程 5)描述该用况的基本过程复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程34/63 摘要方式:简洁的一段式概要,通常用摘要方式:简洁的一段式概要,通常用于主成功场景,例如于主成功场景,例如处理销售处理销售 快速了解主题和范围 非正式方式:以非正式的段落方式覆盖非正式方式:以非正式的段落方式覆盖用例中的不同场景,例如用例中的不同场景,例

25、如处理退货处理退货 进一步细化用户需求并与用户进行确认 详述方式:在需求分析阶段还将进一步详述方式:在需求分析阶段还将进一步细化细化处理销售:处理销售:顾客携带所购商品到达收银顾客携带所购商品到达收银台。收银员用台。收银员用POSPOS系统记录每件商品。系系统记录每件商品。系统逐行显示细目并显示总价。顾客输入统逐行显示细目并显示总价。顾客输入支付信息。系统对支付信息进行验证和支付信息。系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统记录。系统更新库存信息。顾客从系统得到购物收据并携带商品离开。得到购物收据并携带商品离开。处理退货:处理退货: 主成功场景主成功场景: 顾客携带商品到收银

26、台退货。收银员顾客携带商品到收银台退货。收银员使用使用POSPOS系统记录并处理每件退货商品。系统记录并处理每件退货商品。 替换场景替换场景: 如果顾客使用信用卡付款,而其信用如果顾客使用信用卡付款,而其信用卡账户退款交易被拒绝,则告知客户并使卡账户退款交易被拒绝,则告知客户并使用现金退款。用现金退款。 如果如果复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程35/63需求工程概述需求工程概述需求获取需求获取需求规约与验证需求规约与验证需求管理需求管理复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程36/63 必须能够表示和理解问题的

27、必须能够表示和理解问题的信息域信息域(数据数据) 必须能够定义软件将完成的必须能够定义软件将完成的功能功能 必须能够表示软件的必须能够表示软件的行为行为(作为外部事件作为外部事件的结果的结果) 必须必须划分描述数据、功能和行为的模型划分描述数据、功能和行为的模型(分离描述分离描述),从而可以分层次地揭示细节,从而可以分层次地揭示细节 分析过程应该在基本信息基础上不断分析过程应该在基本信息基础上不断细化细化复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程37/63 信息域信息域:包括信息内容、信息包括信息内容、信息流、以及信息结构流、以及信息结构信息内容信息内容表示

28、了单个数据和控制对象,目标软件所有处理的信息集合由它们构成例如,数据对象例如,数据对象“工资工资”是一组重要是一组重要数据体的组合:领款人的姓名、净付数据体的组合:领款人的姓名、净付款数、付款总额、扣除额等等款数、付款总额、扣除额等等 复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程38/63 信息流信息流表示了数据和控制在系统中流动时的变化方式,输入对象被变换为中间信息(数据和/或控制),然后进一步被变换为输出 例如用数据流图表示的数据加工处理的全过程例如用数据流图表示的数据加工处理的全过程 信息结构信息结构表示了各种数据和控制项的内部组织(数据之间的关系) 数

29、据或控制项将被组织为数据或控制项将被组织为n维表还是树形结构?维表还是树形结构? 在结构的语境内,什么信息是和其他信息相关的?在结构的语境内,什么信息是和其他信息相关的? 信息包含在单个结构中,还是使用不同的结构?信息包含在单个结构中,还是使用不同的结构? 在某信息结构中的信息如何和在另一个结构中的在某信息结构中的信息如何和在另一个结构中的信息相关?信息相关? 复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程39/63 问题抽象问题抽象分析方法:要求分析人员在分分析方法:要求分析人员在分析过程中捕捉用户描述或问题本身固有析过程中捕捉用户描述或问题本身固有的的一般一

30、般-特殊关系特殊关系 首先关注一般问题的解决途径,进而指导特殊问题的解决方法 过程抽象:例如超市收银的总体过程包括启动销售、依次输入商品ID/数量、汇总/付款、票据打印 商品商品ID输入:扫描或手动输入;支付:信用卡或现金输入:扫描或手动输入;支付:信用卡或现金 数据抽象:收银单包括客户ID、商品明细、总金额 超市活动期间有折扣优惠,收银条上可能需要折扣情况超市活动期间有折扣优惠,收银条上可能需要折扣情况复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程40/63 问题分解问题分解分析方法:以层次化的方分析方法:以层次化的方式对问题进行分解和不断细化式对问题进行分解

31、和不断细化 较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析 分解可以逐级进行,直至子问题被分解为一个容易分析理解的部分 典型例子:分层数据流图 例如横向分解横向分解纵向分解纵向分解复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程41/63 多视点多视点分析:尽量全面地考虑系统分析:尽量全面地考虑系统中不同干系人的需求和期望中不同干系人的需求和期望 例如围绕着超市收银系统 顾客希望计价过程透明、快捷顾客希望计价过程透明、快捷 收银员希望手工输入少,减少失误收银员希望手工输入少,减少失误 经理希望得到全面的统计分析支持经理希望得到全面的统计分析支持 系统

32、管理员希望提供日志功能、保障安全系统管理员希望提供日志功能、保障安全 最终的软件系统是相关方的综合体,各种期望可能存在冲突,需要进一步分析权衡复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程42/63 协商的过程就是讨论需求冲突,找出每协商的过程就是讨论需求冲突,找出每个人都满意的折衷方案个人都满意的折衷方案 协商不是简单的逻辑或技术上的争论协商不是简单的逻辑或技术上的争论 要注意组织和行政方面的因素要注意组织和行政方面的因素 不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异 复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程

33、软件工程课程43/63 通常会议是解决冲突最快的方式通常会议是解决冲突最快的方式 参加者应该包括发现冲突、遗漏或重叠参加者应该包括发现冲突、遗漏或重叠的分析员,以及可以解决发现的问题的的分析员,以及可以解决发现的问题的项目相关人员项目相关人员 会议应该讨论那些非正式讨论不能解决会议应该讨论那些非正式讨论不能解决的问题的问题 通常会议分为三个阶段:通常会议分为三个阶段: 叙述阶段 讨论阶段 决策阶段 复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程44/63 在软件需求分析阶段,所创建的模型,在软件需求分析阶段,所创建的模型,要着重于描述系统要要着重于描述系统要做什

34、么做什么,而不是,而不是如如何去做何去做 目标软件的模型不应涉及软件实现细节目标软件的模型不应涉及软件实现细节 常用的分析方法:常用的分析方法: 面向数据流的结构化分析方法 (SA) 面向数据结构的分析方法 面向对象的分析方法 (OOA)复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程45/63用例的组成部分用例的组成部分注注 释释用例名称用例名称以动词开始以动词开始范围范围要设计的系统要设计的系统级别级别“用户目标用户目标”(基本流程基本流程)或或“子功能子功能”主要参与者主要参与者调用系统以提供服务的参与者调用系统以提供服务的参与者涉众及其关注点涉众及其关注点

35、关注该用例的人,以及他们各自的需要关注该用例的人,以及他们各自的需要前置条件前置条件用例启动前必须成立的条件用例启动前必须成立的条件后置条件后置条件用例结束后必须成立的条件用例结束后必须成立的条件主成功场景主成功场景典型的、理想的成功场景典型的、理想的成功场景替换场景替换场景其它可能的场景(成功或失败)其它可能的场景(成功或失败)特殊需求特殊需求相关的非功能需求相关的非功能需求技术和数据变元表技术和数据变元表不同的不同的I/O方法及数据格式方法及数据格式发生频率发生频率当前用例的发生频率,可能影响调查、测当前用例的发生频率,可能影响调查、测试和实现的时间安排试和实现的时间安排其它问题其它问题仍

36、待解决或确认的问题仍待解决或确认的问题复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程46/63范围:范围:下一代下一代POSPOS系统系统级别:级别:用户目标用户目标主要参与者:主要参与者:收银员收银员涉众及其关注点:涉众及其关注点:收银员:准确、快速地完成收银操作收银员:准确、快速地完成收银操作顾客:快速完成付款并获得购物凭证以方便退货顾客:快速完成付款并获得购物凭证以方便退货前置条件:前置条件:收银员经过认证、顾客是超市会员收银员经过认证、顾客是超市会员后置条件:后置条件:正确更新库存、正确计算税金正确更新库存、正确计算税金复旦大学计算机科学与工程系复旦大学

37、计算机科学与工程系 软件工程课程软件工程课程47/63主成功场景:主成功场景:1.1.顾客携带商品到收银台付款顾客携带商品到收银台付款2.2.收银员启动一次销售过程收银员启动一次销售过程n.n.顾客付款系统打印票据完成整个销售过程顾客付款系统打印票据完成整个销售过程替换场景:替换场景:a.a.顾客信用卡额度不足要求退货顾客信用卡额度不足要求退货b.b.条码无法刷出使用键盘输入唯一码条码无法刷出使用键盘输入唯一码特殊需求:特殊需求:1.90%1.90%情况下信用卡刷卡响应时间小于情况下信用卡刷卡响应时间小于3030秒秒2.2.顾客能在顾客能在1 1米范围内清楚看到单价和累计金额显示米范围内清楚看

38、到单价和累计金额显示复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程48/63技术与数据变元:技术与数据变元:1.1.商品商品IDID获取可以通过扫描和键盘输入两种方式获取可以通过扫描和键盘输入两种方式2.2.商品商品IDID支持中国、欧洲及日本三中编码标准支持中国、欧洲及日本三中编码标准发生频率:发生频率:可能在可能在1616小时内不间断发生小时内不间断发生其它问题:其它问题:1.1.收银员下班后是否需要清理现金并进行结帐处理收银员下班后是否需要清理现金并进行结帐处理2.2.该超市是否可能在未来实行该超市是否可能在未来实行2424小时营业小时营业复旦大学计算机科

39、学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程49/63需求工程概述需求工程概述需求获取需求获取需求分析、协商与建模需求分析、协商与建模需求管理需求管理复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程50/63 从现实中分离功能,即描述要从现实中分离功能,即描述要“做什么做什么”而不是而不是“怎样实现怎样实现” 规约必须是一个认识模型,而不是设计或实现的模型 使用面向处理的规约语言(或称系统定义语言),讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应,来定义一个行为模型,从而得到“做什么”的规约复旦大学计算机科学与工程系复旦大学计算机科学与

40、工程系 软件工程课程软件工程课程51/63 系统工程:如果被开发软件只是一个基系统工程:如果被开发软件只是一个基于计算机的系统中的一个元素,那么整于计算机的系统中的一个元素,那么整个大系统也包括在规格说明的描述之中个大系统也包括在规格说明的描述之中 规约必须包括系统运行环境规约必须包括系统运行环境 规约必须是可操作的,以便能够利用它规约必须是可操作的,以便能够利用它决定对于任意给定的测试用例,已提出决定对于任意给定的测试用例,已提出的解决方案是否都能满足规约的解决方案是否都能满足规约复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程52/63 规约必须允许不完备性并

41、允许扩充规约必须允许不完备性并允许扩充 规约必须局部化和松散耦合规约必须局部化和松散耦合 它所包括的信息必须局部化,这样当信息被修改时,只要修改某个单个的段落(理想情况) 规约应被松散地构造(即松耦合),以便能够很容易地加入和删去一些段落复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程53/63. 引言引言 A.系统参考文献系统参考文献B.整体描述整体描述C.软件项目约束软件项目约束. 信息描述信息描述 A.信息内容表示信息内容表示B.信息流表示:信息流表示: 数据流数据流 控制流控制流. 功能描述功能描述 A.功能划分功能划分 B.功能描述:功能描述: 处理说明

42、处理说明 限制限制局限局限 性能需求性能需求 设计约束设计约束 支撑图支撑图 C.控制描述控制描述 控制规约控制规约 设计约设计约束束. 行为描述行为描述 A.系统状态系统状态 B.事件和响应事件和响应. 检验标准检验标准 A.性能范围性能范围B.测试种类测试种类C.期望的软件响应期望的软件响应D.特殊的考虑特殊的考虑. 参考书目参考书目. 附录附录复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程54/63引言:陈述软件目标,在基于计算机的系统语境内:陈述软件目标,在基于计算机的系统语境内进行描述。进行描述。信息描述:给出软件必须解决问题的详细描述,记:给出软件必

43、须解决问题的详细描述,记录信息内容和关系、流和结构。录信息内容和关系、流和结构。功能描述:描述解决问题所需的每个功能。其中包:描述解决问题所需的每个功能。其中包括,为每个功能说明一个处理过程;叙述设计约束;括,为每个功能说明一个处理过程;叙述设计约束;叙述性能特征;用一个或多个图形来形象地表示软叙述性能特征;用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互件的整体结构和软件功能与其他系统元素间的相互影响。影响。行为描述:描述作为外部事件和内部产生的控制特:描述作为外部事件和内部产生的控制特征的软件操作。征的软件操作。检验标准:描述检验系统成功的标志。即对系统进:描述检

44、验系统成功的标志。即对系统进行什么样的测试,得到什么样的结果,就表示系统行什么样的测试,得到什么样的结果,就表示系统已经成功实现了。它是已经成功实现了。它是“确认测试确认测试”的基础。的基础。参考书目:包含了对所有和该软件相关的文档的引:包含了对所有和该软件相关的文档的引用,其中包括其他的软件工程文档、技术参考文献、用,其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。厂商文献以及标准。附录:包含了规约的补充信息,表格数据、算法的:包含了规约的补充信息,表格数据、算法的详细描述、图表以及其他材料。详细描述、图表以及其他材料。复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工

45、程课程软件工程课程55/63 需求验证目的是要检验需求是否能够反映用户的意愿需求验证目的是要检验需求是否能够反映用户的意愿 评审人员评审时往往需要检查以下内容:评审人员评审时往往需要检查以下内容:1. 系统定义的目标是否与用户的要求一致;2. 系统需求分析阶段提供的文档资料是否齐全;文档中的描述是否完整、清晰、准确地反映了用户要求;3. 被开发项目的数据流与数据结构是否确定且充足;4. 主要功能是否已包括在规定的软件范围之内,是否都已充分说明;5. 设计的约束条件或限制条件是否符合实际;6. 开发的技术风险是什么;7. 是否详细制定了检验标准,它们能否对系统定义是否成功进行确认。 复旦大学计算

46、机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程56/63需求工程概述需求工程概述需求获取需求获取需求分析、协商与建模需求分析、协商与建模需求规约与验证需求规约与验证复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程57/63 需求管理是一组用于帮助项目组在项目进需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求展中的任何时候去标识、控制和跟踪需求的活动的活动 需求跟踪有两种方式,正向跟踪与逆向跟需求跟踪有两种方式,正向跟踪与逆向跟踪踪 正向跟踪:以用户需求为切入点,检查需求规约中的每个需求是否都能在后继工作产品中找到对应点

47、逆向跟踪:检查设计文档、代码、测试用况等工作产品是否都能在需求规约中找到出处复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程58/63 初期的认识不足导致错误或不完整的需求初期的认识不足导致错误或不完整的需求 需求本身存在不一致需求本身存在不一致 业务变化导致的刚性需求变更业务变化导致的刚性需求变更 外部经济、市场环境的变化外部经济、市场环境的变化 客户和项目组对已确认的需求理解不一致客户和项目组对已确认的需求理解不一致 技术制约或多目标权衡带来的需求变更技术制约或多目标权衡带来的需求变更复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课

48、程59/63 唯一标识每项需求并进行的系统管理唯一标识每项需求并进行的系统管理 分级的需求管理分级的需求管理 需求变更管理过程支持需求变更管理过程支持 需求生命周期及依赖性管理需求生命周期及依赖性管理 变更影响分析及需求变更决策变更影响分析及需求变更决策复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程60/63 为每一项需求分配一个唯一的标识符为每一项需求分配一个唯一的标识符 自动编号:如word中的章节编号 有意义的标识符:如pos-1,store-1,ETF-1. 使得需求文档的其它部分或者在其它系统使得需求文档的其它部分或者在其它系统文档中可以明确引用该项需

49、求文档中可以明确引用该项需求 使用一套基于数据库的系统管理需求使用一套基于数据库的系统管理需求 系统地记录每项需求及其追踪关系 方便查询和统计 需求版本管理的基础复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程61/63 五个需求等级五个需求等级 Urgent:必须立刻优先实现 Necessary:必须实现,但不一定马上进行 Needed:需要的,不过没有也还凑合 Better:现在似乎也可以,但可以更好一点 Useful:总会有用的 正常情况下用户需求应该相对平均地分布在正常情况下用户需求应该相对平均地分布在这五个等级上这五个等级上 分级管理策略:满足核心的用户

50、需求同时说分级管理策略:满足核心的用户需求同时说服用户将其它需求搁置或纳入下一版本服用户将其它需求搁置或纳入下一版本复旦大学计算机科学与工程系复旦大学计算机科学与工程系 软件工程课程软件工程课程62/63 软件产品不是一个闭门造车、精益求精的软件产品不是一个闭门造车、精益求精的艺术品艺术品(实验室产品实验室产品) 尽早取得阶段性成果有助于鼓舞项目团队尽早取得阶段性成果有助于鼓舞项目团队和客户的信心和士气和客户的信心和士气 尽早让事实去验证:系统经历的实践越多尽早让事实去验证:系统经历的实践越多需求的精确性越高需求的精确性越高 严谨的需求变更管理策略将促使客户更加严谨的需求变更管理策略将促使客户

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 大学
版权提示 | 免责声明

1,本文(软件工程课件:3%-第03章 需求工程.ppt)为本站会员(罗嗣辉)主动上传,163文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。
2,用户下载本文档,所消耗的文币(积分)将全额增加到上传者的账号。
3, 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(发送邮件至3464097650@qq.com或直接QQ联系客服),我们立即给予删除!


侵权处理QQ:3464097650--上传资料QQ:3464097650

【声明】本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是网络空间服务平台,本站所有原创文档下载所得归上传人所有,如您发现上传作品侵犯了您的版权,请立刻联系我们并提供证据,我们将在3个工作日内予以改正。


163文库-Www.163Wenku.Com |网站地图|