第四章需求分析过程

第四章需求分析过程 需求分析基础需求分析建模

4.1 需求分析基础  • 软件需求用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。 • 需求分析阶段的任务通过对问题及环境的理解、分析，将用户需求精确化、完全化，最终形成需求规格说明，描述系统信息、功能和行为。 • 技术和方法初步需求获取技术需求建模技术快速原型技术问题抽象、问题分解与多视点分析

软件需求分析产品 • 用户需求（系统分析的产品） • 系统需求 • 软件需求规格说明（软件设计描述）需求规格说明是软件设计、实现、测试、维护的基础。

用户需求、系统需求和软件设计描述 用户需求用自然语言和图表描述说明系统必须提供哪些服务、系统运行要受哪些约束系统需求详细说明系统将要提供的服务以及系统受到的约束精确的描述软件的功能系统买方和软件开发者签订合同的重要内容软件设计描述在系统需求的基础上，加入更详细的内容，构成软件设计活动的概要描述，是软件设计和实现的基础

4.1.1 需求分析三个主要阶段 • 问题分析 • 需求描述 • 需求评审 

1 问题分析 • 建立问题分析系统模型。从不同的角度、不同的抽象级别精确地说明对问题的理解、对目标软件的需求。 • 模型应帮助用户和分析人员发现、排除用户需求不一致，不合理的部分，挖掘潜在的用户需求。 • 模型是分析人员根据问题创建的软件系统结构，包括与问题和环境相关的信息流、处理功能、用户界面、行为及设计约束。 • 模型是形成需求规格说明、进行软件设计的基础。

2 需求描述 • 以需求模型为基础，考虑软件问题的可解性，生成需求规格说明和初步的用户手册。 • 需求规格说明包含对目标软件系统的外部行为的完整描述、需求验证标准以及用户在性能、质量、可维护性等方面的要求。 • 用户手册包括用户界面描述以及有关目标软件使用方法的初步构想。

3 需求评审 • 对需求规格说明和初步的用户手册进行评审，确保软件需求的完全性、精确性和一致性，并使用户和软件设计人员对需求规格说明及用户手册的理解达成一致。 • 确认后的需求规格说明应成为用户方与软件开发方合同的一部分。

4.1.2 初步需求获取技术 1 访谈与会议分析人员应精心准备问题，通过用户对问题的回答，逐步理解用户对目标软件的要求。 (1) 循序渐进首先关心一般性、整体性问题，然后再讨论细节问题。 (2)客观、公正不应限制用户在回答问题过程中自由发挥。 (3) 总结问题汇总后应能反映软件或其子系统的全貌，能覆盖用户对目标软件或其子系统在功能、行为、性能诸方面的要求。细节问题留待以后解决。

2 考察用户软件或其子系统业务流程 学习用户的有关业务知识，在用户帮助下了解用户的软件或子系统业务流程，结合软件开发和应用的经验提出新的用户需求。 3 联合小组 建立软件开发方和用户方共同组成的联合小组，小组成员对分析负有相同的责任。联合小组要制定自己的工作制度和计划，确定专门的记录员，另设专人负责会议的议程和资料的综合、整理。选择易于理解、比较简洁、精确的表示机制作为描述语言，如辅以文字说明的流程图。

实例分析家庭保安系统  问题描述：家庭保安市场正以每年40%的速度增长。希望建立一种基于微处理器的家庭保安系统，它能够识别异常事件并采取相应的防护措施。这些异常事件包括：非法侵入、火灾、水淹等。一旦异常情况被传感器探测出来，系统应自动通过电话向监控中心报警。此外，应允许户主对系统行为进行程序控制。

分析初期联合小组的工作程序 • 联合小组首先制定工作制度,明确议程。 • 经过会议讨论，明确问题的范围、问题与环境的关系，并就开发软件产品的必要性达成共识。 • 列出问题及环境中的有关对象，操作以及对象间的相互作用。对象: 控制面板、电话机、监控中心、烟雾传感器、门窗监视器、警报器等操作:接收传感器事件、用户编程控制、电话拔号、报警等。 

对接收传感器事件、用户编程控制、电话报警等操作进行详细的描述，可用流程图表示。对接收传感器事件、用户编程控制、电话报警等操作进行详细的描述，可用流程图表示。 • 提出约束，比如：造价不能超过3，000元，对传感器事件必须在1秒内作出响应，事件必须按优先级进行处理等。会后小组负责人对这些信息进行综合、整理，形成文档，该文档应能反映“家庭保安系统”的全貌。

划分小组完成需求 • 划分小组，分别处理用户编程控制和传感器监测两个子系统。目的是对子系统的软件需求进行细化。对出现的新对象、新操作、新约束应及时添加到相应的子系统。 • 确定子系统需求并形成文档 • 讨论子系统的集成及需求验证标准。初步分析活动应形成结论性文档，该文档将作为后续分析活动的基础。

初步分析生成的“家庭保安系统”部分需求文档初步分析生成的“家庭保安系统”部分需求文档  • “家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。 • 配置操作 (1)指定每一传感器的种类和编号； (2)设置开、关机密码； (3)指定报警电话号码； (4)指定报警延迟和电话重拔延迟时间(以秒为单位)。

当软件系统接收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拔报警电话号码，拔号操作将按照重拔延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。当软件系统接收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拔报警电话号码，拔号操作将按照重拔延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。 • 开机后软件系统负责显示当前工作状态，接收并处理用户指令。

4.1.3 需求建模 建立软件模型是分析活动的关键。 • 目标软件系统的模型用来刻划系统所涉及的信息、处理功能及系统运行时的外部行为。 • 模型不应涉及软件实现细节。 • 选择图形符号表示信息流、处理功能及系统行为，以此来描述软件需求模型。

4.1.4 分析问题的方法 抽象 • 关注一般问题的解决途径，以此指导特殊问题的求解。注意用户描述的抽象级别，统一规划系统行为。 • 避免不一致性，减少分析的工作量。分解 • 根据问题的规模和复杂性进行分解，并对子问题展开进一步的分析。 • 逐级分解，直至子问题的规模降至合适程度。 • 在问题分解过程中，要建立子问题之间的相互联系。 • 必须遵循子问题内部紧藕合，子问题之间松藕合的原则。

视点分解法 在分析的初期，整体地把握一个大型问题的软件需求是困难的。需要从各个角度分别对问题进行理解和分析，然后再综合，达到全面理解的目需求分析视点系统观点用户观点信息观点功能观点行为观点等。整理、综合用户描述，应注意用户视点的变化，避免遗漏。

4 .1.5 支持需求分析的快速原型技术 • 软件开发早期，快速建立目标软件系统原型，让用户对原型进行评估并提出意见。原型几经改进最终确定，设计和编码人员遵循原型确立的外部特征实现软件产品。 • 如果软件产品含有大量人机交互、可视输出、或者涉及复杂的算法，应采用快速原型技术。 • 对于复杂问题,可对某些子问题，尤其是用户界面，使用快速原型技术。

4.1.6 需求规格说明与评审 • 产生需求规格说明并进行评审。 • 需求规格说明应成为开发过程必须遵循的指导原则。

1 引言 1.1需求规格说明的目的 1.2软件产品的作用范围 1.3定义、同义词与缩写 1.4参考文献 1.5需求规格说明概览 2 一般性描述 2.1产品与其环境之间的关系 2.2产品功能 2.3用户特征 2.4限制与约束 2.5假设与前提条件 3 特殊需求 附录 索引 需求规格说明

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软件界面 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工作场地需求需求规格说明-- 特殊需求描述

需求评审 • 需求规格说明进入设计阶段之前，必须进行评审。如果发现错误或缺陷，应及时纠正或更改需求分析、模型，需求规格说明，并重新评审。 • 衡量需求规格说明的标准正确性无歧义性完全性可验证性一致性可理解性可修改性可追踪性

4.2 需求分析建模 需求分析方法 • 结构化分析方法 • 面向对象的分析方法需求分析模型 • 数据建模 • 功能建模 • 行为建模

4.2.1 需求分析方法 结构化分析方法 • 六十年代未、七十年代初结构化设计盛行，结构化分析以结构化设计附产品的身份出现。 • 七十年代未期Douglas Ross提出结构化分析的术语 • DeMarco[DEM79] 进行推广，给出分析员可以创建信息流模型的主要图形记号，建议将“数据字典”和“处理说明”作为信息流模型的补充，並提供方法应用的实例；

结构化分析方法 • 八十年代初期Page-Jones[PAG80],Gane[GAN82]等人提出结构化分析方法的一些变种，用于信息系统的开发； • 八十年代中期Ward、Mellor[WAR85]、Hatiy和Pirbhai[HAT87]对结构化分析进行扩充支持实时、控制和嵌入式系统的开发; • Harel ＆ Pnueli研制了面向复杂实时反应式系统(Complex Real-time Reactive System)的开发环境 STATEMATE。

4.2.2 需求分析模型 结构化分析模型

4.2.2.1 结构化分析模型 核心数据字典描述软件工程项目的所有数据对象中间层实体-关系图、数据流图、状态-变迁图实体-关系图描述数据对象之间的关系数据流图功能建模的基础系统或子系统对数据实施的变换、变换的功能提供信息分析的信息状态-变迁图行为建模的基础系统的行为模式（称“状态”）以及状态变迁的方式

结构化的分析模型 最外层数据对象描述、加工规格说明PSPEC、控制规格说明CSPEC 数据对象表示实体-关系图中每个数据对象的属性加工规格说明PSPEC 描述数据流图的每个功能。控制规格说明CSPEC 描述软件控制的附加信息

4.2.2.2 数据建模 • 数据对象、属性和关系 • 实体一关系图 • 实体—关系图是数据模型的基础，它描述数据对象、属性、及其关系。

1 数据对象、属性与关系 • 数据对象 • 数据属性 • 数据关系 • 数据对象、属性与关系

数据对象 现实世界具有不同特征和属性的实体或事务的标识，计算机软件描述并处理的一组信息。如，事件、行为、角色、组织、地点、结构等。 • 数据对象只封装数据，包括：数据流、数据源、外部实体的数据部分，不封装操作。 • 数据对象是相互关联的。

属性用“标识符、符号串和值”标识，描述数据对象的性质。包括：（1）命名标识数据对象（2）描述描述数据对象的性质 （3）引用建立数据对象之间的联系 • 数据对象的属性是原子数据项，不包含内部数据结构。 • 数据对象的任何属性有且仅有一个属性值。 • 现实世界的实体具有许多属性，分析人员只能考虑与应用问题有关的属性。

数据对象描述 例汽车销售管理问题的数据对象描述表. 汽车属性制造商型号标识码车体类型颜色买主

关系 • 数据对象按照某种关系相互连接 • 用对象－关系偶描述数据对象 • 关系的命名及内涵应反映描述的问题 • 删除与问题无关的关系

数据对象、属性与关系 例汽车销售问题的数据对象、属性与关系  数据对象属性数据对象关系制造商汽车生产购车用户汽车购买

2 实体—关系图（E-R方法，Entity-Relationship Approach）描述系统所有数据对象的组成和属性，描述数据对象之间关系的图形语言。 • “一对一”（1：1）一个对象A关联一个对象B,反之，一个对象B关联一个对象A。如，夫妻。 • “一对多”（1：N）一个对象A关联多个对象B,反之，一个对象B关联一个对象A。如，父子。 • “多对多”（N：M）一个对象A关联多个对象B,反之，一个对象B关联多个对象A。如，叔侄。

职称性别性别职务姓名系教工号年级姓名学号教师学生 N 1 教学成绩 N M 课程课程号课名学时学分教师-学生-课程E-R 图

年龄 ID号地址制造模型实体类型驾驶证号颜色姓名制造商人车拥有 N M 拥有者人与车关系E-R 图

汽车业务销售的E-R图 ID号 N 合同货主 M 模型 ID 运输 N 1 实体类型 1 类型制造 N 制造商车型 N N 1 引擎许可证货栈传输 N M 销售关系

汽车的部分—整体关系 用实体—关系图表示数据对象的层次结构及部分—整体关系

汽车的层次表示

4.2.2.3 功能建模 • 数据流图与数据字典 • 数据流图的实时系统扩充 • (1). Ward & Mellor扩充 • (2). Hatley & Pirhai扩充

1 数据流图与数据字典 • 基于计算机的信息处理系统由数据流和一系列的加工构成，这些加工将输入数据流加工为输出数据流 • 数据流图描述数据流和加工 • 数据流图用图形符号表示数据流、加工、数据源及外部实体 • 数据流图具有层次结构，支持问题分解、逐步求精的分析方法 • 它是数据驱动的数据流图既可以表示基于计算机的系统，也可以表示软件

数据流图标记

顶层数据流图 随着需求分析活动的深入，较高抽象级别的复杂加工逐步精化为一系列相互关联的数据流和子加工。

数据流图的精化与平衡 • 逐层精化必须保持数据流图的平衡 • 数据流与加工精化必须保持一致 • 需求分析活动只求对问题全面、清晰的理解，不考虑软件设计细节

例子:商店业务处理系统

第一层数据流图

第四章 需求分析过程