需求分析过程

实例分析 家庭保安系统
问题描述： 家庭保安市场正以每年40%的速度增长。希望
建立一种基于微处理器的家庭保安系统，它能够 识别异常事件并采取相应的防护措施。这些异常 事件包括：非法侵入、火灾、水淹等。一旦异常 情况被传感器探测出来，系统应自动通过电话向 监控中心报警。此外，应允许户主对系统行为进 行程序控制。
人与车关系E-R 图
地址 年龄
姓名 人
驾驶证号
制造模型 ID号
制造商
车
N
拥有
M
实体类型 颜色
拥有者
汽车业务销售的E-R图
N
合同
货主 M
ID
1
运输 N
类型
1
制造商
制造
N 车型
1
N
N
许可证
N
销售关系
货栈
M
ID号 模型 实体类型 引擎 传输
汽车的部分—整体关系
用实体— 关系图表示 数据对象的 层次结构及 部分—整体 关系
2.5
1.3定义、
3
1.4
1.5需求规格说明概览
2
2.1产品与其环境之间的关系
2.2
需求规格说明-- 特殊需求描述
3 3.1 3.1.1功能或行为需求1 3.1.1.1 3.1.1.2 3.1.1.3 3.1.1.4输出 3.1.2功能或行为需求2 … 3.1.n功能或行为需求n 3.2 3.2.1 3.2.2 3.2.3
数据对象只封装数据，包括：数据流、数据源、 外部实体的数据部分，不封装操作。
数据对象是相互关联的。
属性
用“标识符、符号串和值”标识，描述数据对象的性质。 包括：
（1）命名
标识数据对象
（2）描述
（3）引用
建立数据对象之间的联系
数据对象的属性是原子数据项，不包含内部数据结构。 数据对象的任何属性有且仅有一个属性值。 现实世界的实体具有许多属性，分析人员只能考虑与应用
八十年代中期 Ward、Mellor[WAR85]、Hatiy和 Pirbhai[HAT87] 对 结 构 化 分 析 进 行 扩 充 支 持 实 时 、 控制和嵌入式系统的开发;
Harel ＆ Pnueli研制了面向复杂实时反应式系统 (Complex Real-time Reactive System)的开发环 境 STATEMATE。
模型是形成需求规格说明、进行软件设计的基础。
2 需求描述
以需求模型为基础，考虑软件问题的可解性，生 成需求规格说明和初步的用户手册。
需求规格说明包含对目标软件系统的外部行为的 完整描述、需求验证标准以及用户在性能、质量、 可维护性等方面的要求。
用户手册包括用户界面描述以及有关目标软件使 用方法的初步构想。
对接收传感器事件、用户编程控制、电话报警等 操作进行详细的描述，可用流程图表示。
提出约束，比如：造价不能超过3，000元，对传 感器事件必须在1秒内作出响应，事件必须按优先 级进行处理等。
会后小组负责人对这些信息进行综合、整理，形成 文档，该文档应能反映“家庭保安系统”的全貌。
划分小组完成需求
活动的概要描述，是软件设计和实现的基础
4.1.1 需求分析三个主要阶段
问题分析
需求描述
需求评审
1 问题分析
建立问题分析系统模型。从不同的角度、不同的 抽象级别精确地说明对问题的理解、对目标软件 的需求。
模型应帮助用户和分析人员发现、排除用户需求 不一致，不合理的部分，挖掘潜在的用户需求。
模型是分析人员根据问题创建的软件系统结构， 包括与问题和环境相关的信息流、处理功能、用 户界面、行为及设计约束。
学习用户的有关业务知识，在用户帮助下了解用户的软件 或子系统业务流程，结合软件开发和应用的经验提出新的 用户需求。
3
建立软件开发方和用户方共同组成的联合小组，小组成员 对分析负有相同的责任。 联合小组要制定自己的工作制度和计划，确定专门的记录 员，另设专人负责会议的议程和资料的综合、整理。 选择易于理解、比较简洁、精确的表示机制作为描述语言， 如辅以文字说明的流程图。
(1) 循序渐进 首先关心一般性、整体性问题，然后再讨论细
节问题。 (2)客观、公正
不应限制用户在回答问题过程中自由发挥。 (3) 总结
问题汇总后应能反映软件或其子系统的全貌， 能覆盖用户对目标软件或其子系统在功能、行为、性 能诸方面的要求。
细节问题留待以后解决。
2 考察用户软件或其子系统业务流程
软件需求分析产品
用户需求 （系统分析的产品） 系统需求 软件需求规格说明（软件设计描述）
需求规格说明是软件设计、实现、测试、维护的基 础。
用户需求、系统需求和软件设计描述
用户需求 用自然语言和图表描述 说明系统必须提供哪些服务、系统运行要受哪些约束 系统需求 详细说明系统将要提供的服务以及系统受到的约束 精确的描述软件的功能 系统买方和软件开发者签订合同的重要内容 软件设计描述 在系统需求的基础上，加入更详细的内容，构成软件设计
3.3
3.4 3.4.1 3.4.2硬件约束
… 3.5 3.5.1 3.5.2 3.5.3 3.5.4可移植性
… 3.6 3.6.1 3.6.2 3.6.3工作场地需求
需求规格说明进入设计阶段之前，必须进行评审。如果 发现错误或缺陷，应及时纠正或更改需求分析、模型， 需求规格说明，并重新评审。
衡量需求规格说明的标准
功能建模的基础
系统或子系统对数据实施的变换、变换的功能
提供信息分析的信息
状态-变迁图 行为建模的基础
系统的行为模式（称“状态”）以及状态变迁的方 式
结构化的分析模型
最外层 数据对象描述、加工规格说明PSPEC、控制规格说
明CSPEC 数据对象
表示实体-关系图中每个数据对象的属性 加工规格说明PSPEC
3 需求评审
对需求规格说明和初步的用户手册进行评 审，确保软件需求的完全性、精确性和一 致性，并使用户和软件设计人员对需求规 格说明及用户手册的理解达成一致。
确认后的需求规格说明应成为用户方与软 件开发方合同的一部分。
4.1.2
1 访谈与会议
分析人员应精心准备问题，通过用户对问题的回答，逐步
第四章 需求分析过程
需求分析基础 需求分析建模
4.1 需求分析基础
软件需求 用户对目标软件系统在功能、行为、性能、设计约
束等方面的期望。
需求分析阶段的任务 通过对问题及环境的理解、分析，将用户需求精确
化、完全化，最终形成需求规格说明，描述系统信息、 功能和行为。 技术和方法 初步需求获取技术 需求建模技术 快速原型技术 问题抽象、问题分解与多视点分析
分析初期联合小组的工作程序
联合小组首先制定工作制度,明确议程。 经过会议讨论，明确问题的范围、问题与环境的关系，并
就开发软件产品的必要性达成共识。 列出问题及环境中的有关对象，操作以及对象间的相互作
用。
对象: 控制面板、电话机、监控中心、烟雾传感器、门窗监 视器、警报器等
操作:接收传感器事件、用户编程控制、电话拔号、报警等。
数据对象属性 制造商 购车用户
数据对象 汽车 汽车
关系 生产 购买
2 实体— Approach）
E-R方法，Entity-Relationship
描述系统所有数据对象的组成和属性，描述数据对
象之间关系的图形语言。
“一对一”（1：1） 一个对象A关联一个对象B,反之，一个对象B关联一个对
象A。如，夫妻。
如果软件产品含有大量人机交互、可视输出、 或者涉及复杂的算法，应采用快速原型技术。
对于复杂问题,可对某些子问题，尤其是用户 界面，使用快速原型技术。
4.1.6 需求规格说明与评审
Fra Baidu bibliotek生需求规格说明并进行评审。
需求规格说明应成为开发过程必须遵循的指导原 则。
需求规格说明
1
2.3
1.1
2.4
1.2
问题有关的属性。
数据对象描述
例 汽车销售管理问题
的数据对象描述表. 汽车属性
制造商 型号 标识码 车体类型 颜色
关系 数据对象按照某种关系相互连接 用对象－关系偶描述数据对象 关系的命名及内涵应反映描述的问题 删除与问题无关的关系
数据对象、属性与关系
例 汽车销售问题的数据对象、属性与关系
汽车的层次表示
4.2.2.3
数据流图与数据字典 数据流图的实时系统扩充
(1). Ward & Mellor扩充 (2). Hatley & Pirhai扩充
划分小组，分别处理用户编程控制和传感器监测 两个子系统。目的是对子系统的软件需求进行细 化。对出现的新对象、新操作、新约束应及时添 加到相应的子系统。
确定子系统需求并形成文档
讨论子系统的集成及需求验证标准。初步分析活 动应形成结论性文档，该文档将作为后续分析活 动的基础。
初步分析生成的“家庭保安系统”部分需求文档
七十年代未期 Douglas Ross提出结构化分析 的术语
DeMarco[DEM79] 进行推广，给出分析员可 以创建信息流模型的主要图形记号，建议将 “数据字典”和“处理说明”作为信息流模 型的补充，並提供方法应用的实例；
结构化分析方法
八十年代初期Page-Jones[PAG80],Gane[GAN82]等 人提出结构化分析方法的一些变种，用于信息系 统的开发；
“一对多”（1：N） 一个对象A关联多个对象B,反之，一个对象B关联一个对
象A。如，父子。
“多对多”（N：M） 一个对象A关联多个对象B,反之，一个对象B关联多个对
象A。如，叔侄。
教师-学生-课程E-R 图
性别 职称 职务
姓名
教工号
教师
1
教
N
姓名 性别
系
学号
年级
学生
M
课程
N
学
成绩
课程号 课名 学时 学分
视点分解法
在分析的初期，整体地把握一个大型问题的软 件需求是困难的。需要从各个角度分别对问题进 行理解和分析，然后再综合，达到全面理解的目
需求分析视点
系统观点 用户观点 信息观点
功能观点 行为观点等。
整理、综合用户描述，应注意用户视点的变化， 避免遗漏。
4 .1.5
软件开发早期，快速建立目标软件系统原型， 让用户对原型进行评估并提出意见。原型几 经改进最终确定，设计和编码人员遵循原型 确立的外部特征实现软件产品。
正确性
无歧义性
可验证性 一致性
可修改性 可追踪性
完全性 可理解性
4.2 需求分析建模
需求分析方法 结构化分析方法 面向对象的分析方法 需求分析模型 数据建模 功能建模 行为建模
4.2.1 需求分析方法
结构化分析方法
六十年代未、七十年代初结构化设计盛行， 结构化分析以结构化设计附产品的身份出现。
抽象 关注一般问题的解决途径，以此指导特殊问题的
求解。注意用户描述的抽象级别，统一规划系统 行为。 避免不一致性，减少分析的工作量。 分解 根据问题的规模和复杂性进行分解，并对子问题 展开进一步的分析。 逐级分解，直至子问题的规模降至合适程度。 在问题分解过程中，要建立子问题之间的相互联 系。 必须遵循子问题内部紧藕合，子问题之间松藕合 的原则。
“家庭保安系统”的软件允许用户在安装时进行系 统配置，实施对传感器的监控并通过控制面板与用 户进行信息交互。
配置操作 (1)指定每一传感器的种类和编号； (2)设置开、关机密码； (3)指定报警电话号码； (4)指定报警延迟和电话重拔延迟时间(以秒为单位)。
当软件系统接收到传感器发出的数据后，判别是 否出现异常事件。如果是，则在指定的延迟时间 内拔报警电话号码，拔号操作将按照重拔延迟反 复进行，直至电话接通。然后软件系统负责报告 时间、地点和异常事件的性质。
描述数据流图的每个功能。 控制规格说明CSPEC
描述软件控制的附加信息
4.2.2.2
数据对象、属性和关系 实体一关系图 实体—关系图是数据模型的基础，它描述数据对 象、属性、及其关系。
1
数据对象 数据属性 数据关系 数据对象、
数据对象 现实世界具有不同特征和属性的实体或事务
的标识，计算机软件描述并处理的一组信息。如， 事件、行为、角色、组织、地点、结构等。
开机后软件系统负责显示当前工作状态，接收并 处理用户指令。
4.1.3
建立软件模型是分析活动的关键。 目标软件系统的模型用来刻划系统所涉及
的信息、处理功能及系统运行时的外部行 为。 模型不应涉及软件实现细节。 选择图形符号表示信息流、处理功能及系 统行为，以此来描述软件需求模型。
4.1.4 分析问题的方法
4.2.2 需求分析模型
数据对象描述
加工規约PSPEC
结
构
实体-关系图
数据流图
化
分
数据字典 实体关系图
析
模
型
状态-变迁图
控制規约CSPEC
4.2.2.1 结构化分析模型
核心
数据字典 描述软件工程项目的所有数据对象
中间层 实体-关系图、数据流图、状态-变迁图
实体-关系图 描述数据对象之间的关系
数据流图