03 第03章 需求工程.pptx

第1页：软件工程第3章需求工程

软件工程第3章需求工程

第2页：软件工程第3章需求工程（续）

需求:成功的软件开发的前提软件质量=系统所实现的需求/客户所期望的需求

• 软件项目投标及签订合同的基础
• 软件系统实现的基础
• 系统确认移交的基础

第3页：需求的定义

需求的定义

• IEEE Standard Glossary of SoftwareEngineering Terminology
  • 用户解决一个问题或达到一个目标所需要的一种状况或能力
  • 系统为了满足一种约定、标准、规格说明或其它正式文件而必须满足或拥有的一种状况或能力
  • 以上两种状态或能力的文档化表示主观需求客观需求需求文档

第4页：功能性需求和非功能性需求

功能性需求和非功能性需求

• 功能性需求
  • 系统需要提供的服务或功能：如图书检索
  • 系统对特定输入的处理方式：如对非法输入的提示
  • 系统在特定环境下的行为：如长时间无操作时的屏保
• 非功能性需求
  • 对系统功能或服务附加的质量约束，例如响应时间、容错性、安全性等
  • 客户所关心的(外部质量)
  • 从系统开发和维护角度出发的质量属性，例如可理解性、可扩展性、可配置性等
  • 软件开发或维护者所关心的(内部质量、软件所特有)

第5页：内容摘要

内容摘要

• 需求工程概述
• 需求获取
• 需求分析、协商与建模
• 需求规约与验证
• 需求管理

第6页：内容摘要（续）

内容摘要

• 需求工程概述
• 需求获取
• 需求分析、协商与建模
• 需求规约与验证
• 需求管理

第7页：把需求工程定义为“直

• Alan Davis把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”(强调做什么)
• Herb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理
• Matthias Jarke和Klaus Pohl提出了三阶段周期的说法：获取、表示和验证
• ……

第8页：需求获取

• 需求获取：资料收集
• 需求分析与协商：理解分析整理
• 系统建模：用模型描述(写下来)
• 需求规约：完善需求文档并定稿
• 需求验证：验证确认
• 需求管理：整体规划及变更管理需求工程的六个阶段

第9页：需求获取（续）

需求获取

• 系统分析人员通过与用户的交流，了解业务现状以及对待开发系统的期望
  • 确定系统或产品范围的限制性描述
  • 与系统或产品有关的人员及特征列表
  • 系统的技术环境的描述
  • 系统功能的列表及应用于每个需求的领域限制
  • 一组描述不同运行条件下的应用场景以及为更好地定义需求而开发的系统原型
• 需求获取收集的“原始材料”为进行需求分析提供了基础

第10页：需求分析与协商

需求分析与协商

• 对需求进行分类组织，分析需求之间的关系
• 检查需求的一致性、重叠和遗漏的情况
• 根据用户的需要对需求进行排序。
• 在需求获取阶段，经常出现以下问题：
  • 提出的要求超出软件系统可以实现的范围或实现能力
  • 不同的用户提出了相互冲突的需求

第11页：系统建模

系统建模

• 建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁
• 系统分析人员借助建模技术对获取的需求信息进行分析和表达，排除错误和弥补不足，确保需求文档正确反映用户真实意图
• 常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法

第12页：需求规约

需求规约(Specification)

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

第13页：需求验证

需求验证

• 需求开发阶段工作的复查手段
• 对功能的正确性、完整性和清晰性，以及其它需求给予评价
• 为保证软件需求定义的质量，评审应以专门指定的人员负责(应该是需求分析人员之外的其他人员)，并按规程严格进行

第14页：需求确认与需求分析

需求确认与需求分析

• 二者密切相关
  • 都需要对系统需求中的遗漏和冲突进行识别和分析
  • 区别
• 需求分析处理的是未整理的原始需求，此时发现的问题是客户的问题
• 需求确认的对象是经分析后形成的需求规格说明，此时发现的问题是需求分析人员的问题，此外还需要考虑需求文档是否满足相应的质量标准

第15页：

第16页：在实际的开发过程

• 在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。

第17页：需求管理

需求管理

• 一种获取、组织并记录系统需求的系统化方案：对所有需求工程相关活动的规划和总体控制
• 需求变更管理：一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程(变更的记录、分析、变更过程管理、追踪等)

第18页：需求管理（续）

回顾：需求的各种形式

• 从高度抽象的系统服务或系统目标到对某一系统功能的精确约束
• 原始需求
  • 客户对软件系统及新的工作方式的期望目标
  • 客户单位已经存在的日常工作方式和业务规则
  • 系统所属领域固有的法规、标准或惯例等
  • 一般目标：更快、更好、更安全
• 需求文档
  • 自然语言描述
  • UML图等图形表示
  • 业务规则表格

第19页：内容摘要

内容摘要

• 需求工程概述
• 需求获取
• 需求分析、协商与建模
• 需求规约与验证
• 需求管理

第20页：需求获取

需求获取

• 缺少用户参与是项目失败的主要原因之一
• 良好的开端是成功的一半
• 需求获取：通过客户调研等手段对需求进行收集、分析、细化、核实和组织
• 两种项目(相对)的需求获取过程：
  • 产品项目：一般是根据公司战略和市场需求研发，旨在进行批量出售或推广的项目
  • 工程项目：一般是根据与用户签定的合同研发，旨在满足特定用户需求的项目

第21页：需求获取方法与策略

需求获取方法与策略

• 建立顺畅的通信途径
• 深入客户方进行访谈与调查
• 观察用户操作流程
• 组成各方联合小组
• 使用基于用况(Use Case)的方法

第22页：建立顺畅的通信途径

建立顺畅的通信途径

• 建立分析所需要的通信途径，以保证能顺利地对问题进行分析

第23页：访谈与调查

访谈与调查

• 访谈/调查计划：从初步的需求了解出发，制订需要了解或讨论的问题的顺序和范围等
  • 有利于保证访谈的效率和全面性，但灵活性不足
• 在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性

第24页：访谈与调查的原则

访谈与调查的原则

• 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化
• 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题
• 提问和回答在汇总后应能够反映用户需求的全貌
  • 不断汇总-反馈-汇总

第25页：访谈与调查的具体形式

访谈与调查的具体形式-1

• 会议讨论法
  • 适用于需求调研早期
  • 特点：需求获取的信息量大，但有时全面性和深入性不足
  • 做好调研计划，同时掌握好计划与灵活性的平衡
• 一般由客户方的基本情况介绍开始
• 随着情况了解的深入，分析人员逐渐成为主导：要求分析人员有较强的理解和交流能力、思维敏锐，能够有效地引导并把握讨论的议题和方向

第26页：访谈与调查的具体形式（续）

访谈与调查的具体形式-2

• 调查问卷
  • 由分析人员拟定问卷(选择、判断居多)请客户方代表回答
  • 适用于需求调研的中后期，往往用于对前期发现的一些不明确或不一致的地方进行确认
  • 特点：信息量较小，但能够引导客户对某些关键问题进行思考，给出明确、严谨的回答和判断
  • 需要分析人员在前期需求调研基础上敏锐地发现需进一步确认的不明确或不一致需求，例如：
• 客户要求高安全性，而开发组反馈推荐解决方案是使用USB Key这样的硬件证书进行身份验证和加密传输，但可能会到来额外的运营开销，需要客户确认是否能够接受

第27页：访谈与调查的具体形式

访谈与调查的具体形式-3

• 原型系统
  • 由开发小组快速开发一个近似的功能原型(往往以操作界面为主)，分析人员与客户围绕着原型系统的演示进行需求讨论
  • 适用于客户仅有一些宏观的设想而自身需求还不明确的情况下
  • 特点：能够帮助客户将自己的设想落实为具体需求，能够有效激发客户的思维，但需要额外的原型开发开销
  • 要求分析人员自身对需要有较强的认识，基本能够把握客户的潜在想法或者开发方有类似的成品软件

第28页：需求调研例—学生选课系统

需求调研例—学生选课系统-1

• 第一阶段：了解基本情况
  • 请教务处老师介绍背景，如学生总数、课程数量、选课相关的基本制度等
• 第二阶段：制订访谈计划，深入讨论相关需求
  • 除了学生还有哪些相关用户?
  • 选课规则(学分、课程人数限制等)、退课规则
  • 了解客户对系统的期望：准确、访问速度快…
  • ……

第29页：需求调研例—学生选课系统（续）

需求调研例—学生选课系统-2

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

第30页：观察用户操作流程

观察用户操作流程

• 客户与用户的区别
  • 如：选课系统的客户可能是学校教务处，但用户包括学生、教务员、管理人员、教务领导等
• 到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识

第31页：组成联合小组

组成联合小组

• 突出客户在需求分析乃至项目开发中的作用
• Facilitated ApplicationSpecification Techniques (FAST)
  • 打破用户和开发者的界限，共同组成一个联合小组
  • 发挥各自的长处，共同负责项目的推进
  • 有助于发挥各自优势并增进解和协调

第32页：基本原则①在中立的地点举行由

FAST基本原则①在中立的地点举行由开发者和用户出席的会议；②建立准备和参与会议的规则；③建议一个足够正式的议程以便可以进行自由的交流；④一个“协调者”(他可以是用户、开发者或其他外人)来控制会议；⑤使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)；⑥目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。

第33页：基本原则①在中立的地点举行由（续）

用况(Use Case)

• 分析员可以根据所获取的需求创建一组标识一串待建造系统的使用场景
• 创建用况模型的主要步骤如下：1)确定谁会直接使用该系统，即参与者（Actor）2)选取其中一个参与者3)定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况4)对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程5)描述该用况的基本过程

第34页：用况的描述方法

用况的描述方法

• 摘要方式：简洁的一段式概要，通常用于主成功场景，例如《处理销售》
  • 快速了解主题和范围
• 非正式方式：以非正式的段落方式覆盖用例中的不同场景，例如《处理退货》
  • 进一步细化用户需求并与用户进行确认
• 详述方式：在需求分析阶段还将进一步细化处理销售：顾客携带所购商品到达收银台。收银员用POS系统记录每件商品。系统逐行显示细目并显示总价。顾客输入支付信息。系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统得到购物收据并携带商品离开。处理退货：主成功场景：顾客携带商品到收银台退货。收银员使用POS系统记录并处理每件退货商品。替换场景：如果顾客使用信用卡付款，而其信用卡账户退款交易被拒绝，则告知客户并使用现金退款。如果……

第35页：内容摘要

内容摘要

• 需求工程概述
• 需求获取
• 需求分析、协商与建模
• 需求规约与验证
• 需求管理

第36页：需求分析原则

需求分析原则

• 必须能够表示和理解问题的信息域(数据)
• 必须能够定义软件将完成的功能
• 必须能够表示软件的行为(作为外部事件的结果)
• 必须划分描述数据、功能和行为的模型(分离描述)，从而可以分层次地揭示细节
• 分析过程应该在基本信息基础上不断细化

第37页：信息域

信息域

• 信息域：包括信息内容、信息流、以及信息结构
  • 信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成
• 例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等

第38页：–信息流表示了数据和控制在系

–信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出

• 例如用数据流图表示的数据加工处理的全过程
  • 信息结构表示了各种数据和控制项的内部组织(数据之间的关系)
• 数据或控制项将被组织为n维表还是树形结构？
• 在结构的语境内，什么信息是和其他信息相关的？
• 信息包含在单个结构中，还是使用不同的结构？
• 在某信息结构中的信息如何和在另一个结构中的信息相关？

第39页：–信息流表示了数据和控制在系（续）

抽象、分解与多视点分析

• 问题抽象分析方法：要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特殊关系
  • 首先关注一般问题的解决途径，进而指导特殊问题的解决方法
  • 过程抽象：例如超市收银的总体过程包括启动销售、依次输入商品ID/数量、汇总/付款、票据打印
• 商品ID输入：扫描或手动输入；支付：信用卡或现金…
  • 数据抽象：收银单包括客户ID、商品明细、总金额
• 超市活动期间有折扣优惠，收银条上可能需要折扣情况

第40页：问题分解分析方法

• 问题分解分析方法：以层次化的方式对问题进行分解和不断细化
  • 较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析
  • 分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分
  • 典型例子：分层数据流图…
  • 例如横向分解纵向分解

第41页：多视点分析

• 多视点分析：尽量全面地考虑系统中不同干系人的需求和期望
  • 例如围绕着超市收银系统
• 顾客希望计价过程透明、快捷
• 收银员希望手工输入少，减少失误
• 经理希望得到全面的统计分析支持
• 系统管理员希望提供日志功能、保障安全
  • 最终的软件系统是相关方的综合体，各种期望可能存在冲突，需要进一步分析权衡

第42页：需求协商

需求协商

• 协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案
• 协商不是简单的逻辑或技术上的争论
• 要注意组织和行政方面的因素
  • 不一致的目标
  • 责任的丧失或转移
  • 组织文化
  • 组织管理态度和士气
  • 部门差异

第43页：通常会议是解决冲突最快的方式

• 通常会议是解决冲突最快的方式
• 参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员
• 会议应该讨论那些非正式讨论不能解决的问题
• 通常会议分为三个阶段：
  • 叙述阶段
  • 讨论阶段
  • 决策阶段

第44页：需求建模

需求建模

• 在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做
• 目标软件的模型不应涉及软件实现细节
• 常用的分析方法：
  • 面向数据流的结构化分析方法(SA)
  • 面向数据结构的分析方法
  • 面向对象的分析方法(OOA)

第45页：详细用况说明的结构注释用例的

详细用况说明的结构注释用例的组成部分以动词开始用例名称要设计的系统范围“用户目标”(基本流程)或“子功能”级别调用系统以提供服务的参与者主要参与者关注该用例的人，以及他们各自的需要涉众及其关注点用例启动前必须成立的条件前置条件用例结束后必须成立的条件后置条件典型的、理想的成功场景主成功场景其它可能的场景（成功或失败）替换场景相关的非功能需求特殊需求不同的I/O方法及数据格式技术和数据变元表当前用例的发生频率，可能影响调查、测试和实现的时间安排发生频率仍待解决或确认的问题其它问题

第46页：系统收银用况详细说明-1范围

POS系统收银用况详细说明-1范围：下一代POS系统级别：用户目标主要参与者：收银员涉众及其关注点：收银员：准确、快速地完成收银操作…顾客：快速完成付款并获得购物凭证以方便退货………前置条件：收银员经过认证、顾客是超市会员后置条件：正确更新库存、正确计算税金……

第47页：系统收银用况详细说明-2主成功场景

POS系统收银用况详细说明-2主成功场景：1.顾客携带商品到收银台付款2.收银员启动一次销售过程……n.顾客付款系统打印票据完成整个销售过程替换场景：a.……顾客信用卡额度不足要求退货……b.……条码无法刷出使用键盘输入唯一码…………特殊需求：1.90%情况下信用卡刷卡响应时间小于30秒2.顾客能在1米范围内清楚看到单价和累计金额显示……

第48页：系统收银用况详细说明-3技术与数据变元

POS系统收银用况详细说明-3技术与数据变元：1.商品ID获取可以通过扫描和键盘输入两种方式2.商品ID支持中国、欧洲及日本三中编码标准……发生频率：可能在16小时内不间断发生其它问题：1.收银员下班后是否需要清理现金并进行结帐处理2.该超市是否可能在未来实行24小时营业……

第49页：内容摘要

内容摘要

• 需求工程概述
• 需求获取
• 需求分析、协商与建模
• 需求规约与验证
• 需求管理

第50页：需求规约的原则

需求规约的原则-1

• 从现实中分离功能，即描述要“做什么”而不是“怎样实现”
  • 规约必须是一个认识模型，而不是设计或实现的模型
  • 使用面向处理的规约语言(或称系统定义语言)，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约

第51页：需求规约的原则（续）

需求规约的原则-2

• 系统工程：如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中
• 规约必须包括系统运行环境
• 规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约

第52页：需求规约的原则

需求规约的原则-3

• 规约必须允许不完备性并允许扩充
• 规约必须局部化和松散耦合
  • 它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落(理想情况)
  • 规约应被松散地构造(即松耦合)，以便能够很容易地加入和删去一些段落

第53页：需求规约A

需求规约A.系统参考文献Ⅰ.引言B.整体描述C.软件项目约束A.信息内容表示Ⅱ.信息描述B.信息流表示：ⅰ数据流ⅱ控制流A.功能划分Ⅲ.功能描述B.功能描述：ⅰ处理说明ⅱ限制∕局限ⅲ性能需求ⅳ设计约束ⅴ支撑图C.控制描述ⅰ控制规约ⅱ设计约束A.系统状态Ⅳ.行为描述B.事件和响应A.性能范围Ⅴ.检验标准B.测试种类C.期望的软件响应D.特殊的考虑Ⅵ.参考书目Ⅶ.附录

第54页：需求规约A（续）

• 引言：陈述软件目标，在基于计算机的系统语境内进行描述。
• 信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。
• 功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。
• 行为描述：描述作为外部事件和内部产生的控制特征的软件操作。
• 检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。
• 参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。
• 附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。

第55页：需求验证

需求验证

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

第56页：内容摘要

内容摘要

• 需求工程概述
• 需求获取
• 需求分析、协商与建模
• 需求规约与验证
• 需求管理

第57页：需求管理

需求管理

• 需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动
• 需求跟踪有两种方式，正向跟踪与逆向跟踪
  • 正向跟踪：以用户需求为切入点，检查《需求规约》中的每个需求是否都能在后继工作产品中找到对应点
  • 逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在《需求规约》中找到出处

第58页：需求变更的原因

需求变更的原因

• 初期的认识不足导致错误或不完整的需求
• 需求本身存在不一致
• 业务变化导致的刚性需求变更
• 外部经济、市场环境的变化
• 客户和项目组对已确认的需求理解不一致
• 技术制约或多目标权衡带来的需求变更

第59页：关键实践

关键实践

• 唯一标识每项需求并进行的系统管理
• 分级的需求管理
• 需求变更管理过程支持
• 需求生命周期及依赖性管理
• 变更影响分析及需求变更决策

第60页：唯一地标识每一项需求

唯一地标识每一项需求

• 为每一项需求分配一个唯一的标识符
  • 自动编号：如word中的章节编号
  • 有意义的标识符：如pos-1,store-1,ETF-1….
• 使得需求文档的其它部分或者在其它系统文档中可以明确引用该项需求
• 使用一套基于数据库的系统管理需求
  • 系统地记录每项需求及其追踪关系
  • 方便查询和统计
  • 需求版本管理的基础

第61页：分级的用户需求管理

分级的用户需求管理

• 五个需求等级
  • Urgent:必须立刻优先实现
  • Necessary:必须实现，但不一定马上进行
  • Needed:需要的，不过没有也还凑合
  • Better:现在似乎也可以，但可以更好一点
  • Useful:总会有用的
• 正常情况下用户需求应该相对平均地分布在这五个等级上
• 分级管理策略：满足核心的用户需求同时说服用户将其它需求搁置或纳入下一版本

第62页：分级需求管理的好处

分级需求管理的好处

• 软件产品不是一个闭门造车、精益求精的艺术品(实验室产品)
• 尽早取得阶段性成果有助于鼓舞项目团队和客户的信心和士气
• 尽早让事实去验证：系统经历的实践越多需求的精确性越高
• 严谨的需求变更管理策略将促使客户更加理性地看待需求变更

第63页：需求变更管理过程支持变更申请

需求变更管理过程支持变更申请需求方开发方忽略选择变更方式SCCB评估项目经理自行决定根据评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划