需求工程概述

– 快速了解主题和范围
• 非正式方式：以非正式的段落方式覆盖 用例中的不同场景，例如《处理退货》
– 进一步细化用户需求并与用户进行确认
• 详述方式：在需求分析阶段还将进一步 细化
34/63
• 需求工程概述 • 需求获取 • 需求分析、协商与建模 • 需求规约与验证 • 需求管理
35/63
• 必须能够表示和理解问题的信息域(数据) • 必须能够定义软件将完成的功能 • 必须能够表示软件的行为(作为外部事件
26/63
• 原型系统
– 由开发小组快速开发一个近似的功能原型(往往以操 作界面为主)，分析人员与客户围绕着原型系统的演 示进行需求讨论
– 适用于客户仅有一些宏观的设想而自身需求还不明 确的情况下
– 特点：能够帮助客户将自己的设想落实为具体需求， 能够有效激发客户的思维，但需要额外的原型开发 开销
1) 确定谁会直接使用该系统，即参与者（Actor） 2)选取其中一个参与者 3)定义该参与者希望系统做什么，参与者希望系统作的每件
事将成为一个用况 4)对每件事来说，何时参与者会使用系统，通常会发生什么，
这就是用况的基本过程 5)描述该用况的基本过程
33/63
• 摘要方式：简洁的一段式概要，通常用 于主成功场景，例如《处理销售》
• 系统补不 足，确保需求文档正确反映用户真实意图
• 常用的分析和建模方法有面向数据流方法、 面向数据结构方法和面向对象的方法
11/63
• 通过建立完整的信息描述、详细的功能和 行为描述、性能需求和设计约束的说明、 合适的验收标准，给出对目标软件的各种 需求
29/63
• 客户与用户的区别
– 如：选课系统的客户可能是学校教务处，但用户包 括学生、教务员、管理人员、教务领导等
• 到用户的实际工作环境中对用户的工 作流程进行观察，了解用户实际的操 作环境、操作过程和操作要求，对照 用户提交的问题陈述，对用户需求可 以有更全面、更细致的认识
30/63
• 突出客户在需求分析乃至项目开发 中的作用
37/63
– 信息流表示了数据和控制在系统中流动时的 变化方式，输入对象被变换为中间信息(数 据和/或控制)，然后进一步被变换为输出
• 例如用数据流图表示的数据加工处理的全过程
– 信息结构表示了各种数据和控制项的内部组 织(数据之间的关系)
• 数据或控制项将被组织为n维表还是树形结构？ • 在结构的语境内，什么信息是和其他信息相关的？ • 信息包含在单个结构中，还是使用不同的结构？ • 在某信息结构中的信息如何和在另一个结构中的
21/63
• 建立分析所需要的通信途径，以 保证能顺利地对问题进行分析
22/63
• 访谈/调查计划：从初步的需求了解 出发，制订需要了解或讨论的问题 的顺序和范围等
– 有利于保证访谈的效率和全面性，但灵活性不足
• 在具体的实践中，通常采用折衷的 方法，即适当地计划好面谈，但不 要过于详细，允许有一定的灵活性
– 要求分析人员自身对需要有较强的认识，基本能够 把握客户的潜在想法或者开发方有类似的成品软件
27/63
• 第一阶段：了解基本情况
– 请教务处老师介绍背景，如学生总数、课程数量、 选课相关的基本制度等
• 第二阶段：制订访谈计划，深入讨论 相关需求
– 除了学生还有哪些相关用户? – 选课规则(学分、课程人数限制等)、退课规则 – 了解客户对系统的期望：准确、访问速度快… – ……
的结果) • 必须划分描述数据、功能和行为的模型
(分离描述)，从而可以分层次地揭示细节 • 分析过程应该在基本信息基础上不断细化
36/63
• 信息域：包括信息内容、信息 流、以及信息结构
– 信息内容表示了单个数据和控制对 象，目标软件所有处理的信息集合 由它们构成
• 例如，数据对象“工资”是一组重要 数据体的组合：领款人的姓名、净付 款数、付款总额、扣除额等等
5/63
• 需求工程概述 • 需求获取 • 需求分析、协商与建模 • 需求规约与验证 • 需求管理
6/63
• Alan Davis 把需求工程定义为“直到 （但不包括）把软件分解为实际架构构 件之前的所有活动” (强调做什么)
• Herb Krasner定义了需求工程的五阶段 生命周期：需求定义和分析、需求决策、 形成需求规格、需求实现与验证、需求 演进管理
软件工程
第3章 需求工程
软件质量=
系统所实现的需求/客户所期望的需求
• 软件项目投标及签订合同的基础 • 软件系统实现的基础 • 系统确认移交的基础
2/63
• IEEE Standard Glossary of Software Engineering Terminology
– 用户解决一个问题或达到一个目标所需要的
• 需求文档
– 自然语言描述 – UML图等图形表示 – 业务规则表格
18/63
• 需求工程概述 • 需求获取 • 需求分析、协商与建模 • 需求规约与验证 • 需求管理
19/63
• 缺少用户参与是项目失败的主要原因之一 • 良好的开端是成功的一半 • 需求获取：通过客户调研等手段对需求进
行收集、分析、细化、核实和组织 • 两种项目(相对)的需求获取过程：
• 系统分析人员通过与用户的交流，了解业 务现状以及对待开发系统的期望
– 确定系统或产品范围的限制性描述 – 与系统或产品有关的人员及特征列表 – 系统的技术环境的描述 – 系统功能的列表及应用于每个需求的领域限制 – 一组描述不同运行条件下的应用场景以及为更好地定
义需求而开发的系统原型
• 需求获取收集的“原始材料”为进行需求 分析提供了基础
– 适用于需求调研的中后期，往往用于对前期发现的 一些不明确或不一致的地方进行确认
– 特点：信息量较小，但能够引导客户对某些关键问 题进行思考，给出明确、严谨的回答和判断
– 需要分析人员在前期需求调研基础上敏锐地发现需 进一步确认的不明确或不一致需求，例如：
• 客户要求高安全性，而开发组反馈推荐解决方案是使用 USB Key这样的硬件证书进行身份验证和加密传输，但可 能会到来额外的运营开销，需要客户确认是否能够接受
28/63
• 第三阶段：基本了解需求后就一些关键细 节通过问卷进行明确
– 在已经了解总体选课人数之后，需要进一步了解通 常情况下的选课持续时间、是否按院系逐步开放选 科、选课人数的一般分布等—与性能设计密切相关
– 推荐关键管理人员使用USB Key设备，经济上是否 可以接受
– ……
• 原型：如该企业有类似成熟系统可结合系 统演示进行需求调研
– 产品项目：一般是根据公司战略和市场需求研发，旨在进 行批量出售或推广的项目
– 工程项目：一般是根据与用户签定的合同研发，旨在满足 特定用户需求的项目
20/63
• 建立顺畅的通信途径 • 深入客户方进行访谈与调查 • 观察用户操作流程 • 组成各方联合小组 • 使用基于用况(Use Case)的方法
• Matthias Jarke和Klaus Pohl提出了三 阶段周期的说法：获取、表示和验证
•……
7/63
• 需求获取：资料收集 • 需求分析与协商：理解分析整理 • 系统建模：用模型描述(写下来) • 需求规约：完善需求文档并定稿 • 需求验证：验证确认 • 需求管理：整体规划及变更管理
8/63
• 非功能性需求
– 对系统功能或服务附加的质量约束，例如响应时间、 容错性、安全性等——客户所关心的(外部质量)
– 从系统开发和维护角度出发的质量属性，例如可理解 性、可扩展性、可配置性等——软件开发或维护者所关 心的(内部质量、软件所特有)
4/63
• 需求工程概述 • 需求获取 • 需求分析、协商与建模 • 需求规约与验证 • 需求管理
• 需求变更管理：一个使用户与项目团 队对不断变更的系统需求达成并保持 一致的过程(变更的记录、分析、变 更过程管理、追踪等)
17/63
• 从高度抽象的系统服务或系统目标到对某 一系统功能的精确约束
• 原始需求
– 客户对软件系统及新的工作方式的期望目标 – 客户单位已经存在的日常工作方式和业务规则 – 系统所属领域固有的法规、标准或惯例等 – 一般目标：更快、更好、更安全
来控制会议； ⑤ 使用一种“定义机制”(它可以是工作表、图表、墙上
胶黏纸或墙板)； ⑥ 目标是标识问题、提出解决方案的要素、商议不同的
方法、以及在有利于完成目标的氛围中刻画出初步的 需求。
32/63
• 分析员可以根据所获取的需求创建一组标 识一串待建造系统的使用场景
• 创建用况模型的主要步骤如下：
• Facilitated Application Specification Techniques (FAST)
– 打破用户和开发者的界限，共同组成一个联合小组 – 发挥各自的长处，共同负责项目的推进 – 有助于发挥各自优势并增进解和协调
31/63
① 在中立的地点举行由开发者和用户出席的会议； ② 建立准备和参与会议的规则； ③ 建议一个足够正式的议程以便可以进行自由的交流； ④ 一个“协调者”(他可以是用户、开发者或其他外人)
信息相关？
38/63
• 问题抽象分析方法：要求分析人员在分 析过程中捕捉用户描述或问题本身固有 的一般-特殊关系
– 首先关注一般问题的解决途径，进而指导特殊问题 的解决方法
– 过程抽象：例如超市收银的总体过程包括启动销售、 依次输入商品ID/数量、汇总/付款、票据打印
• 商品ID输入：扫描或手动输入；支付：信用卡或现金…
一种状况或能力 主观需求
– 系统为了满足一种约定、标准、规格说明或
其它正式文件而必须满足或拥有的一种状况
或能力
客观需求
– 以上两种状态或能力的文档化表示