需求工程

11/63
需求规约(Specification)
• 通过建立完整的信息描述、详细的功能和 行为描述、性能需求和设计约束的说明、 合适的验收标准，给出对目标软件的各种 需求 • 软件需求规约是分析任务的最终产物 • 需求规约作为用户和开发者之间的一个协 议，在之后的软件工程各个阶段发挥重要 作用
12/63
– – – – – 确定系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下的应用场景以及为更好地定 义需求而开发的系统原型
• 需求获取收集的“原始材料”为进行需求 分析提供了基础
9/63
需求分析与协商
17/63
回顾：需求的各种形式
• 从高度抽象的系统服务或系统目标到对某 一系统功能的精确约束 • 原始需求
– – – – 客户对软件系统及新的工作方式的期望目标 客户单位已经存在的日常工作方式和业务规则 系统所属领域固有的法规、标准或惯例等 一般目标：更快、更好、更安全
• 需求文档
– 自然语言描述 – UML图等图形表示 – 业务规则表格
30/63
组成联合小组
• 突出客户在需求分析乃至项目开发 中的作用 • Facilitated Application Specification Techniques (FAST)
– 打破用户和开发者的界限，共同组成一个联合小组 – 发挥各自的长处，共同负责项目的推进
– 有助于发挥各自优势并增进解和协调
28/63
需求调研例—学生选课系统-2
• 第三阶段：基本了解需求后就一些关键细 节通过问卷进行明确
– 在已经了解总体选课人数之后，需要进一步了解通 常情况下的选课持续时间、是否按院系逐步开放选 科、选课人数的一般分布等—与性能设计密切相关 – 推荐关键管理人员使用USB Key设备，经济上是否 可以接受 – ……
软件工程
第3章 需求工程
需求:成功的软件开发的前提
软件质量=
系统所实现的需求/客户所期望的需求
• 软件项目投标及签订合同的基础 • 软件系统实现的基础 • 系统确认移交的基础
2/63
需求的定义
• IEEE Standard Glossary of Software Engineering Terminology
– 产品项目：一般是根据公司战略和市场需求研发，旨在进 行批量出售或推广的项目 – 工程项目：一般是根据与用户签定的合同研发，旨在满足 特定用户需求的项目
20/63
需求获取方法与Biblioteka 略• • • • • 建立顺畅的通信途径 深入客户方进行访谈与调查 观察用户操作流程 组成各方联合小组 使用基于用况(Use Case)的方法
• 需求分析处理的是未整理的原始需求，此时 发现的问题是客户的问题 • 需求确认的对象是经分析后形成的需求规格 说明，此时发现的问题是需求分析人员的问 题，此外还需要考虑需求文档是否满足相应 的质量标准
14/63
15/63
• 在实际的开发过程中，获取、分析、建 模、编写规约和验证这些需求开发活动 不会是线性地、顺序地完成。实际上， 这些活动是交叉的、递增的和反复的。
⑤
⑥
32/63
用况(Use Case)
• 分析员可以根据所获取的需求创建一组标 识一串待建造系统的使用场景 • 创建用况模型的主要步骤如下：
1) 确定谁会直接使用该系统，即参与者（Actor） 2) 选取其中一个参与者 3) 定义该参与者希望系统做什么，参与者希望系统作的每件 事将成为一个用况 4) 对每件事来说，何时参与者会使用系统，通常会发生什么， 这就是用况的基本过程 5) 描述该用况的基本过程
21/63
建立顺畅的通信途径
• 建立分析所需要的通信途径，以 保证能顺利地对问题进行分析
22/63
访谈与调查
• 访谈/调查计划：从初步的需求了解 出发，制订需要了解或讨论的问题 的顺序和范围等
– 有利于保证访谈的效率和全面性，但灵活性不足
• 在具体的实践中，通常采用折衷的 方法，即适当地计划好面谈，但不 要过于详细，允许有一定的灵活性
• 对需求进行分类组织，分析需求之间的 关系 • 检查需求的一致性、重叠和遗漏的情况 • 根据用户的需要对需求进行排序。 • 在需求获取阶段，经常出现以下问题：
– 提出的要求超出软件系统可以实现的范围或实现能力 – 不同的用户提出了相互冲突的需求
10/63
系统建模
• 建模工具的使用在用户和系统分析人员之 间建立了统一的语言和理解的桥梁 • 系统分析人员借助建模技术对获取的需求 信息进行分析和表达，排除错误和弥补不 足，确保需求文档正确反映用户真实意图 • 常用的分析和建模方法有面向数据流方法、 面向数据结构方法和面向对象的方法
27/63
需求调研例—学生选课系统-1
• 第一阶段：了解基本情况
– 请教务处老师介绍背景，如学生总数、课程数量、 选课相关的基本制度等
• 第二阶段：制订访谈计划，深入讨论 相关需求
– – – – 除了学生还有哪些相关用户? 选课规则(学分、课程人数限制等)、退课规则 了解客户对系统的期望：准确、访问速度快… ……
23/63
访谈与调查的原则
• 所提问的问题应该循序渐进，从整体 的方面开始提问，接下来的问题应有 助于对前面的问题更好的理解和细化 • 不要限制用户对问题的回答，这有可 能会引出原先没有注意的问题 • 提问和回答在汇总后应能够反映用户 需求的全貌——不断汇总-反馈-汇总
24/63
访谈与调查的具体形式-1
5/63
内容摘要
• 需求工程概述 • 需求获取 • 需求分析、协商与建模 • 需求规约与验证 • 需求管理
6/63
• Alan Davis 把需求工程定义为“直到 （但不包括）把软件分解为实际架构构 件之前的所有活动” (强调做什么) • Herb Krasner定义了需求工程的五阶段 生命周期：需求定义和分析、需求决策、 形成需求规格、需求实现与验证、需求 演进管理 • Matthias Jarke和Klaus Pohl提出了三 阶段周期的说法：获取、表示和验证 • … …
– 用户解决一个问题或达到一个目标所需要的 一种状况或能力 主观需求 – 系统为了满足一种约定、标准、规格说明或 其它正式文件而必须满足或拥有的一种状况 或能力 客观需求 – 以上两种状态或能力的文档化表示
需求文档
3/63
功能性需求和非功能性需求
• 功能性需求
– 系统需要提供的服务或功能：如图书检索 – 系统对特定输入的处理方式：如对非法输入的提示 – 系统在特定环境下的行为：如长时间无操作时的屏保
7/63
需求工程的六个阶段
• • • • • • 需求获取：资料收集 需求分析与协商：理解分析整理 系统建模：用模型描述(写下来) 需求规约：完善需求文档并定稿 需求验证：验证确认 需求管理：整体规划及变更管理
8/63
需求获取
• 系统分析人员通过与用户的交流，了解业 务现状以及对待开发系统的期望
• 会议讨论法
– 适用于需求调研早期 – 特点：需求获取的信息量大，但有时全面性和深 入性不足 – 做好调研计划，同时掌握好计划与灵活性的平衡
• 一般由客户方的基本情况介绍开始 • 随着情况了解的深入，分析人员逐渐成为主导： 要求分析人员有较强的理解和交流能力、思维敏 锐，能够有效地引导并把握讨论的议题和方向
• 客户要求高安全性，而开发组反馈推荐解决方案是使用 USB Key这样的硬件证书进行身份验证和加密传输，但可 能会到来额外的运营开销，需要客户确认是否能够接受
26/63
访谈与调查的具体形式-3
• 原型系统
– 由开发小组快速开发一个近似的功能原型(往往以操 作界面为主)，分析人员与客户围绕着原型系统的演 示进行需求讨论 – 适用于客户仅有一些宏观的设想而自身需求还不明 确的情况下 – 特点：能够帮助客户将自己的设想落实为具体需求， 能够有效激发客户的思维，但需要额外的原型开发 开销 – 要求分析人员自身对需要有较强的认识，基本能够 把握客户的潜在想法或者开发方有类似的成品软件
33/63
用况的描述方法
•
处理销售：顾客携带所购商品到达收银 摘要方式：简洁的一段式概要，通常用 台。收银员用POS系统记录每件商品。系 处理退货： 于主成功场景，例如《处理销售》 统逐行显示细目并显示总价。顾客输入 主成功场景： 支付信息。系统对支付信息进行验证和 – 快速了解主题和范围 顾客携带商品到收银台退货。收银员 记录。系统更新库存信息。顾客从系统 使用 POS系统记录并处理每件退货商品。 非正式方式：以非正式的段落方式覆盖 得到购物收据并携带商品离开。 替换场景： 用例中的不同场景，例如《处理退货》 如果顾客使用信用卡付款，而其信用 – 进一步细化用户需求并与用户进行确认 卡账户退款交易被拒绝，则告知客户并使 详述方式：在需求分析阶段还将进一步 用现金退款。 细化 如果……
需求验证
• 需求开发阶段工作的复查手段 • 对功能的正确性、完整性和清晰性， 以及其它需求给予评价 • 为保证软件需求定义的质量，评审应 以专门指定的人员负责(应该是需求 分析人员之外的其他人员)，并按规 程严格进行
13/63
需求确认与需求分析
• 二者密切相关
– 都需要对系统需求中的遗漏和冲突进行识别 和分析 – 区别
34/63
•
•
内容摘要
• 需求工程概述 • 需求获取 • 需求分析、协商与建模 • 需求规约与验证 • 需求管理
35/63
需求分析原则
• 必须能够表示和理解问题的信息域(数据) • 必须能够定义软件将完成的功能 • 必须能够表示软件的行为(作为外部事件 的结果) • 必须划分描述数据、功能和行为的模型 (分离描述)，从而可以分层次地揭示细节 • 分析过程应该在基本信息基础上不断细化