惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

第三章 需求分析

一、需求分析的任务

1、概述： 软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。需求分析就是通过对应用问题及其环境的分析与理解，采用一系列的分析方法和技术，将用户的需求逐步精确化、完全化、一致化，最终形成需求规格说明文档的过程。在此，准确回答软件系统“必须做什么”。在需求分析的过程中，用户和系统分析员起着同样重要的作用。P3~4

2、结构化的系统分析方法应遵守的准则：P56，P6

3、什么是需求

需求就是以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的一个集合。通常对软件系统的需求是以下几方面的综合：P56~57，P7~11

(1) 功能需求；(2) 性能需求；(3) 可靠性和可用性需求；(4) 出错处理需求；(5) 接口需求；(6) 约束；(7) 逆向需求；(8) 将来可能提出的要求

4、需求的另一种提法

功能需求

(1) 系统做什么？

(2) 系统何时做什么？

(3) 系统何时及如何修改或升级？

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

软件开发的各项技术性指标，例如：存储容量限制、执行速度、响应时间、吞吐量等。

环境需求

(1) 硬件设备：

机型、外设、接口、地点、分布、温度、湿度、磁场干扰等

(2) 软件：

操作系统、网络、数据库

界面需求

(1) 有来自其它系统的输入吗？

(2) 有到向其它系统的输出吗？

(3) 对数据格式有规定吗？

(4) 对数据存储介质有规定吗？

用户或人的因素

(1) 用户类型？

(2) 各种用户熟练程度？

(3) 需受何种训练？

(4) 用户理解、使用系统的难度？

(5) 用户错误操作系统的可能性？

文档需求

(1) 需哪些文档？

(2) 文档针对哪些读者？

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

(1) 输入、输出数据的格式？

(2) 接收、发送数据的频率？

(3) 数据的准确性和精度？

(4) 数据流量？

(5) 数据需保持的时间？

资源需求

(1) 软件运行时所需的数据、软件、内存空间等等资源。

(2) 软件开发、维护所需的人力、

(3) 支撑软件、开发设备等。

安全保密要求

(1) 需对访问系统或系统信息加以控制吗？

(2) 如何隔离用户之间的数据？

(3) 用户程序如何与其它程序和操作系统隔离？

(4) 系统备份要求？

软件成本消耗与开发进度需求

(1) 开发有规定的时间表吗？

(2) 软硬件投资有无限制？

质量保证

(1) 系统的可靠性要求？

(2) 系统必须监测和隔离错误吗？

(3) 规定系统平均出错时间？

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

(4) 出错后，重启系统允许的时间？

(5) 系统变化如何反映到设计中？

(6) 维护是否包括对系统的改进？

(7) 系统的可移植性？

5、需求分析的主要任务

(1)、确定需求----确定对系统的综合要求；

(2)、建立数据模型----利用图形工具描述系统的数据结构，并将数据结构规范化，建立数据模型；

(3)、导出系统的逻辑模型----通常用数据流图、实体--联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。

(4)、修正系统开发计划

(5)、编写需求规格说明

6、需求分析的过程：

应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述出目标系统及其行为特征和相关约束。它通常是一些过程的组合：

需求获取(需求引出

)

需求建模

编写软件需求规格说明书

(SRS)

验证需求(包括鉴定和证实)。

二、获取需求的方法

0、需求的来源

客户或用户

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

领域标准

相关领域的专家

系统或过程文档

相关政策或法律

1、初步需求获取技术

(1) 访谈与会议----分析人员采用个别访谈或小组会议的形式与用户进行初步交流。在访谈和会议之前，分析人员根据对问题的初步描述精心准备一系列问题，通过用户对问题的回答或互相商讨来逐步理解用户的需求。

(2) 问卷调查----当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。

(3) 观察用户工作流程----提取系统的初步用户需求，分析用户提出的需求的合理性，补充用户没有意识到的需求，并能够从软件的角度改进操作流程和操作规范，从而可获得用户满意的结果。

(4) 用户和开发人员共同组成联合小组

(5) 情景分析技术 P58~59，P17~18

在这里，通常用户扮演未来的用户，分析人员扮演软件系统。

2、面向数据流，自顶向下求精

软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息。数据决定了需要的处理和算法，数据显然是需求分析的出发点。

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

需求分析的目标之一就是把数据流和数据存储定义到元素级，之二就是通过功能分解的方法对数据流图分层细化，最终得到对系统数据和功能要求的满意了解。

结构化分析方法是一种面向数据流自顶向下逐步求精进行需求分析的方法：

(1) 分析的起点是系统的输出数据。要分析数据的组成(通过调查)、数据的来源和数据经历的处理(通过回溯数据流图)。 P21

(2) 在分析过程中，对数据流图中缺少的数据要进行补充、对处理要明确其算法、对增加的功能要补充处理模块。

(3) 更新系统逻辑模型：把分析过程中得到的有关数据元素的信息记录在数据字典中、把对算法的简明描述记录在IPO图中、通过分析而补充的处理、数据流和数据存储添加到数据流图的适当位置上。

(4) 与用户交流，进行复查确认----对更新过的系统逻辑模型，从输入开始，走一遍。 P23

(5) 分解处理模块，细化数据流图。(可能出现新的数据流和数据存储)

(6) 对于分解得到的新数据流图，进行(1)~(5)步，最终得到对系统数据和功能要求的满意的解(基本不需再细化)。

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

3、简易的应用规格说明技术

是一种面向团队的需求收集技术。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。目前，该技术已经成为信息系统领域使用的主流技术。 典型过程：

(1) 根据问题的定义，用户、开发者分别写需求；(个人)

(2)用户、开发者交叉审查需求；并根据需求，描述系统及其开发的约束；(个人) P28

(3) 确认系统的必要性；(全体)

(4) 展示个人对系统的描述，编辑这些描述；(全体) P29

(5) 综合个人描述，形成组合表格；去除冗余项，加入了在展示过程中产生的新想法；(全体) P30

(6) 为每个议题(对象、服务、性能和约束)创建出一张意见一致的目标列表；(全体)

(7) 为每张列表中的项目制定小型规格说明，它是对列表中包含的单词或短语的准确说明；(分组)

(8) 展示每一份小型规格说明，讨论修改之；(全体)

(9) 分别制定出产品的一整套确认标准；(个人)

(10) 综合个人制定的标准，形成完整的软件需求规格说明书；(全体)

4、快速建立软件原型

所谓原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是，它应该实现用户看得见的功能(例如，

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如，修改文件)。快速原型的特性是：快速、容易修改。 P33~

34

构造快速原型的工具： P34~36

(1) 第四代技术

(2) 可重用的软件构件

(3) 形式化规格说明和原型环境

三、分析建模

1、模型与建模

模型----事物的模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。

建模----构建模型，描述事物。

2、结构化分析实质上是一种创建模型的活动。

为了开发出复杂的软件系统，系统分析员应该从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。

模型的核心是数据字典，它描述了所有的在目标系统中使用的和生成的数据对象。围绕着这个核心的有三种图：实体--关系图(ERD)描述数据对象及数据对象之间的关系--数据模型；数据流图(DFD)描述数据在系统中如何被传送或变换，以及描述如何实现对数据流进行变换的功能(或子功能)--功能模型；状态--迁移图(STD)描述系统对外部事

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

件如何响应，如何动作--行为模型。因此，ERD用于数据建模，DFD用于功能建模，STD用于行为建模。

四、分析建模工具

1、ER图

ER图，即实体--联系图，是表示数据对象及其之间关系的图形语言机制，是建立数据模型的图形工具。实例：P47

系统分析员通常建立一个概念性的数据模型(也称为信息模型)，将用户的数据要求清楚、准确地描述出来。概念性数据模型是按照用户的观点对数据建立的模型，它描述了从用户角度看到的数据，反映了用户的现实环境，而且它与在软件系统中的实现方法无关。

ER图的基本成份和使用的符号

实体(即数据对象)----矩形框

关系----菱形框

属性----椭圆形或圆角矩形

数据对象

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

(1) 数据对象：是软件必须理解的复合信息的抽象，是具有一系列不同性质或属性的事物，仅有单个值的事物(例如，宽度)不是数据对象。

(2) 可以由一组属性来定义的实体都可以被认为是数据对象。

如：外部实体、事物、行为、事件、角色、单位、地点或结构等。

(3) 数据对象只封装了数据而没有对施加于数据上的操作的引用，这是数据对象与面向对象范型(参见本书第9章)中的“类”或“对象”的显著区别。

(4) 数据对象彼此间是有关联的。

属性

属性定义了数据对象的性质，数据对象是由其属性来刻画的。

一个实体可能有许多属性，分析应根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。

必须把其中的一个或多个属性的联合定义为“标识符”，也就是说，当我们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)。

联系

是数据对象彼此之间相互连接的方式。关系可分为以下3种类型：

(1) 一对一联系(1∶1)

(2) 一对多联系(1∶N)

(3) 多对多联系(M∶N)

(4) 联系也可能有属性

对联系的说明 P46，48

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

2、数据的规范化

为什么要进行数据规范化：

为----减少数据冗余，确保数据一致性；避免出现插入或删除异常，简化数据的修改过程----而进行的数据结构规范化。

如何进行数据规范化

(1) 将数据的逻辑结构归结为满足一定条件的二维表（关系）。即： a. 表格中每个信息项必须是一个不可分割的数据项，不可以是组项； b. 表格中每一列(表示属性)中所有信息项必须是同一类型，各列的名字(属性名)互异，列的次序任意；

c. 表格中各行(表示一个元组)互不相同，行的次序任意。

举例：

在教学管理系统中，有三个实体型，即课程、学生和教师，用三个关系保存它们的信息：

表1：学生(学号，姓名，性别，年龄，年级，专业，籍贯)

表2：教师(职工号，姓名，年龄，职称，职务，工资级别，工资) 表3：课程(课程号，课程名，学分，学时，课程类型)

为表示实体型之间的联系，又建立两个关系：

表4：选课(学号，课程号，听课出勤率，作业完成率，成绩)

表5：授课(职工号，课程号，授课效果)

这五个关系，组成了数据库的模型。在每个关系中，属性名下加下划线的是关键字，规定关键字能唯一地标识一个元组。

(2) 通常用“范式(normal forms)”定义消除数据冗余的程度。

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

a. 第一范式：每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。例如：表1、表2、表3；

b. 第二范式：满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。例如：表4、表5；(表1、2、3是吗？)

c. 第三范式：符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。

例如：表2中，“工资级别”是“职务”或“职称”决定的；而“工资”是对“工资级别”的进一步描述。因此，表2没有达到第三范式。

P52

3、状态转换图

状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作。因此，利用状态转换图可以建立系统的行为模型。

状态转换图中的成份

(1) 状态 P56~57

(2) 事件 事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象，也就是引起系统做动作或(和)转换状态的控制信息。

(3) 状态转换 从一个状态到另一个状态，变迁的方向。

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

状态转换图中使用的符号

P59

举例

4、数据加工的描述工具

(1) IPO图(是数据字典的内容之一，描述处理) P69~70，P71~72

(2) 结构化描述语言

对于数据流图中的每个模块都要进行数据加工描述，像数据字典中的条目一样记录在卡片上。

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

(3) 类程序流程图

5、其他图形工具

(1) 层次方框图 P68，P64~66

(2) Warnier图 P68~69，P67~69

(3) 关于UML

UML----Unified Modeling Language

UML是一种语言，提供了用于交流的词汇表和在词汇表中组合词汇的规则。词汇表和规则注重于对系统进行概念上和物理上的描述。UML这样的建模语言是适用于软件蓝图的标准语言。贯穿于软件开发生命期，并能表达系统体系结构的各种不同视图。对软件密集型系统的制品进行：可视化、详细描述、构造、文档化。

a. 可视化：UML只是一组图形符号。确切地讲，UML表示法中的每一

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

个符号都有明确语义。这样，一个开发者可以用UML绘制一个模型，而另外一个开发者可以无歧义的理解这个模型

b. 详细描述：详细描述意味着用它所建的模型是精确的、无歧义的和完整的。

c. 构造性：UML不是一种可视化的编程语言，但用UML描述的模型可以与各种编程语言直接相连，可以进行正向工程和逆向工程两种工程。 d. UML的文档化语言特性：一个健壮的软件组织除了生产可执行的代码之外，还要给出各种制品。这些制品的产出是度量和理解软件系统的关键。

五、软件需求规格说明(SRS)

用自然语言 + 模型，完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。 P40

软件需求规格说明书，是需求分析阶段得出的最主要的文档。 主要内容提示：

1 引言

1.1 简介(对整个SRS作综述)

1.2 编写目的(本SRS的编写目的与阅读对象)

1.3 背景(项目背景)

1.4 定义(提供正确理解本SRS所必须的术语、缩写词和简写的定义)

1.5 参考资料(列举编写本SRS时所参考的资料或其它资源)

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

2 任务概述

2.1 目标(概述该产品应具有的主要功能，这些功能应该按照一种有效的方式进行组织，使客户或第一次阅读该文档的所有人都易于理解。介绍该产品与其他产品或项目的联系，诸如该产品是否是产品系列中的下一成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个新型的产品，等等。)

2.2 用户的特点(描述可能使用该产品的不同用户类及其相关特征，诸如用户、操作人员以及维护人员等，他们的某些特征[如教育程度、经验以及技术专长等]将对系统的操作环境产生重要的约束。)

2.3 假定和约束(描述将限制开发人员进行设计选择的一些项目，可能的限制包括如下内容：

必须使用或者避免的特定技术、工具、编程语言和数据库

所要求的开发规范或标准

企业策略、政府法规或工业标准

硬件限制，例如定时需求或存储器限制

数据转换格式标准

硬、软件运行环境等)

3 详细的需求

3.1 功能需求(该产品的详细功能需求，指出每一个功能的输入、处理操作和输出。这些是必须提交给用户的软件功能)

3.2 性能需求(阐述不同的应用领域对产品性能的需求，并解释其原理以帮助开发人员选择合理的设计。诸如确定所支持的客户端数、

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

并发用户数、文件或记录规模、时间特性要求[如操作响应时间]、数据精度等。)

3.3 外部接口需求(描述可以保证该产品与外部组件正确连接的需求，包括用户界面、硬件接口、软件接口和通信接口等。)

3.4 故障处理需求

3.5 与软件质量相关的需求(软件属性需求)

正确性：能达到用户预期的目标，运行基本无错误

可靠性：程序的精度范围、系统无故障执行时间概率、故障恢

复要求等

可用性：系统可以使用并且完全操作的时间

可扩展性：软件中增加新功能的所需时间

安全性：控制软件被未经授权者访问的范围

互操作性：该系统与其他系统交换数据和服务的要求

可维护性：在操作过程中查找和修复一个错误所需的工作量 可移植性：从一个硬件或软件环境转移到另外一个硬件或软件

环境中所需的工作量

可重用性：程序能够在另外一个应用环境中重复使用的范围 可测试性：测试组件或系统以查找缺陷的简单程度

易用性：用户学习、操作、为程序准备输入以及解释程序的输

出所需的工作量。

等等(需要的列出，不需要的略去。)

3.6 其他专门需求

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

4 分析建模

以数据字典为核心，建立软件的数据、功能、行为三大模型。对于行为模型可以只为系统的人机交互部分建立。画E-R图，应该是先用关系表组织数据对象，再规范到三范式，最后出E-R图。

5 待定问题列表

编辑一张在软件产品需求分析报告中待确定问题时的列表，把每一个表项都编上号，以便跟踪调查。

六、验证软件需求(需求规格说明评审)

所谓验证软件需求，就是在需求分析之后，从一致性、完整性、现实性、有效性等方面验证这些需求是否正确。

验证方法：

1、验证“一致性”----所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。

用自然语言书写的软件系统规格说明，靠人工技术审查验证；用形式化需求陈述语言书写的软件需求规格说明，可以用软件工具验证。

2、验证“现实性”----指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。

参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。

3、验证“完整性”----需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。

惠州学院 软件工程导论 第三章__需求分析 刘宇芳老师

4、“有效性”----必须证明需求是正确有效的，确实能解决用户面对的问题。

有效性和完整性应该由用户来验证。其主要方法是建立快速原型。

5、PSL/PSA(问题陈述语言/问题陈述分析程序)系统

是一种帮助软件需求分析的软件工具。----了解 PP71-72

七、本阶段工作总结

1、使用需求获取技术，充分获取需求

2、建立模型：(1)分层细化数据流图、(2)扩充数据字典、(3)从需求中(包括前面的数据流图和数据字典)抽取实体，建立对应的数据对象，规范到3范式、(4)从需求中抽取实体间的关系，画E-R图、(5)对于交互性较强的系统或系统的交互部分画状态转换图

3、写需求规格说明书

4、验证需求

本章作业 P73 1、2、6

对自选项目进行需求分析

本文来源：https://www.bwwdw.com/article/9h11.html