3.1 需求分析的任务
需求分析的意义
软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。
需求分析定义
需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。即：确地回答“系统必须做什么?”。
在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。
软件需求的组成
业务需求：反映组织机构和客户对系统、产品高层次的业务目标要求。
用户需求：从用户使用的角度给出需求的描述。
例子：一个小型超市需要一个商品的查询系统。
业务需求：进货人员需要查询商品库存以便保证及时进货；收款员需要查询商品的销售价格以便结账；经理需要查询商品的销售及盈利情况。
用户需求: 这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。
系统需求：从系统的角度描述要提供的服务以及所受到的约束。
功能性需求：描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。
非功能性需求：产品必须具备的属性或品质。
设计约束：设计与实现必须遵循的标准、约束条件。如运行平台、协议、选择的技术、编程语言和工具等。
软件需求的描述
- 结构化、面向对象、PDL
- 图形化表示
- 数学描述（形式化语言描述）
需求分析的具体任务
（1） 确定对系统的综合要求
功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求★、约束、 逆向需求、将来可能提出的要求。
（2） 分析系统的数据要求
（3） 构建系统的逻辑模型
（4） 修正系统开发计划
接口需求 ★
常见的接口需求有：
- 用户接口需求
- 硬件接口需求
- 软件接口需求
- 通信接口需求
软件需求过程
需求获取是开发人员与客户或用户一起对应用领域进行调查研究，收集系统需求的过程。
需求分析是将获取到的需求准确的理解、求精，并将其转化为完整的需求定义（包括建模），进而生成需求规约的过程。
需求获取和分析有一定的难度，因为：
- 1）项目相关人员通常并不真正知道希望计算机做什么，让他们清晰的表达出需要系统做什么是件困难的事，他们或许提出不切实际的要求。
- 2） 项目相关人员用自己的语言表达需求，这些语言包含很多工作中的专业术语和专业知识。系统分析员没有这些知识和经验，而他们又必须了解这些需求。
- 3）不同的项目相关人员有不同的需求，可能以不同的方式表达，分析人员必须发现所有潜在的需求资源，而且能发现这些需求的相容或冲突之处。
- 4）经济和业务环境决定了分析是动态的，需求在分析过程中会发生变更。个别需求的重要程度会改变，新的需求会从新的项目相关人员那里得到。
需求分析建模之结构化方法 ★
- （1） 信息域，数据模型（ER图）
- （2） 软件功能，功能模型（数据流图）
- （3） 软件行为，行为模型（状态/活动图）
- （4） 分层细化
3.2 与用户沟通获取需求的方法 ○
- 访谈（情景分析）
- 面向数据流自顶向下求精
- 简易的应用规格说明
- 快速建立软件原型
面向数据流自顶向下求精
简易的应用规格说明技术
提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。
- 进行初步的访谈
- 开发者和用户双方组织的代表出席会议
- 每个小组为每张列表中的项目制定小型规格说明
- 根据会议成果起草完整的软件需求规格说明书
3.3 分析建模与规格说明
分析建模
模型：为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，由一组图形符号和组织这些符号的规则组成。
建模方法：
- 结构化分析 (Structured Analysis，SA)，70年代末由DeMarco等人提出。该方法不是被所有的使用者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发展了超过30年的一个混合物。
- 面向对象分析
软件需求规格说明(SRS)
软件需求规格说明 (Software Requirement Specification, SRS) 通常用自然语言+模型，完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
软件需求规格说明书，是需求分析阶段得出的最主要的文档。
3.4 实体-联系图 (ER图) ★
实体-联系图 (ER图)：是用来建立数据模型的工具。
数据模型：是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，反映了用户的现实环境，而且与在软件系统中的实现方法无关。
数据模型中包含3种相互关联的信息：数据对象（实体）、数据对象的属性及数据对象彼此间相互连接的关系。
(1) 数据对象
数据对象：是对软件必须理解的复合信息的抽象。
复合信息：是指具有一系列不同性质或属性的事物，仅有单个值的事物(例如，宽度)不是数据对象。
可以由一组属性来定义的实体都可以被认为是数据对象。如：外部实体、事物、行为、事件、角色、单位、地点或结构等。
数据对象彼此间是有关联的。
(2) 属性
属性定义了数据对象的性质。
必须把一个或多个属性定义为“标识符”，也就是说，当我们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)。
应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。
如：学生具有学号、姓名、性别、年龄、专业（其它略）等属性；
课程具有课程号、课程名、学分、学时数等属性；
教师具有职工号、姓名、年龄、职称等属性。
(3) 联系
数据对象彼此之间相互连接的方式称为联系，也称为关系。
联系可分为以下3种类型：
一对一联系(1∶1)
如：一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。
一对多联系(1∶N)
如：某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。
多对多联系(M∶N)
如：学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。
联系也可能有属性。
如：学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性。
3.5 数据规范化
规范化的目的
- 消除数据冗余，即消除表格中数据的重复；
- 消除多义性，使关系中的属性含义清楚、单一；
- 使关系的“概念”单一化，让每个数据项只是一个简单的数或字符串，而不是一个组项或重复组；
- 方便操作。使数据的插入、删除与修改操作可行并方便；
- 使关系模式更灵活，易于实现接近自然语言的查询方式。
如何规范化
规范化将数据的逻辑结构归结为满足一定条件的二维表（关系）。即：
- 表格中每个信息项必须是一个不可分割的数据项，不可是组项。
- 表格中每一列 (列表示属性)中所有信息项必须是同一类型，各列的名字 (属性名) 互异，列的次序任意。
- 表格中各行 (行表示元组) 互不相同，行的次序任意。
教工号 姓名 性别 职称 职务 001 张毅坤 男 教授 院长 002 李 林 女 讲师 用教学管理例说明如何规范化：
有三个实体型，即课程、学生和教师，用三个关系保存它们的信息：
- 学生(学号，姓名，性别，年龄，年级，专业，籍贯)
- 教师(职工号，姓名，年龄，职称，职务，工资级别，工资)
- 课程(课程号，课程名，学分，学时，课程类型)
为表示实体型之间的联系，又建立两个关系：
- 选课 (学号，课程号，听课出勤率，作业完成率，分数)
- 教课 (职工号，课程号，授课学期,……)
这五个实体及关系，组成了数据库的模型。
在每个关系中，属性名下加（下划线）指明关键字。并规定关键字能唯一地标识一个元组。
范式
通常用“范式(Normal Forms)”定义消除数据冗余的程度。第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数据冗余程度最小。
但是：
- 范式级别越高，存储同样数据就需要分解成更多张表，因此，“存储自身”的过程也就越复杂。
- 随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。
- 范式级别提高则需要访问的表增多，因此性能(速度)将下降。
从实用角度看来，在大多数场合选用第三范式都比较恰当。
第一范式
每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
如：
学生(学号，姓名，性别，年龄，年级，专业，籍贯)
教师(职工号，姓名，年龄，职称，职务，工资级别，工资)
课程(课程号，课程名，学分，学时，课程类型)
第二范式
满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。
如：
选课 ( 学号，课程号，听课出勤率，作业完成率，分数 )
教课 ( 职工号，课程号，授课学期，…… )
第三范式
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，不符合第三范式的例子：
学号, 姓名, 年龄, 所在学院, 学院联系电话，关键字为单一关键字“学号”;
存在依赖传递: (学号) → (所在学院) → (学院地点, 学院电话)
3.6 状态转换图 ★
状态转换图(简称为状态图)：通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。
1) 状态
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。
一张状态图中只能有一个初态，而终态则可以有0至多个。
2) 事件
事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。
例如，用户移动或点击鼠标等都是事件。
简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。
3) 符号
初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。
中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。
活动表的语法格式：事件名(参数表) / 动作表达式
- 其中，“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry，exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。
状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。
状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
事件表达式的语法：事件说明[守卫条件] / 动作表达式
- 事件说明的语法为：事件名(参数表)。
- 守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。
- 动作表达式是一个过程表达式，当状态转换开始时执行该表达式。
案例：电话系统的状态图
案例：复印机状态图
复印机的工作过程大致如下：未接到复印命令时处于闲置状态，一旦接到复印命令则进入复印状态，完成一个复印命令规定的工作后又回到闲置状态，等待下一个复印命令；如果执行复印命令时发现没纸，则进入缺纸状态，发出警告，等待装纸，装满纸后进入闲置状态，准备接收复印命令；如果复印时发生卡纸故障，则进入卡纸状态，发出警告等待维修人员来排除故障，故障排除后回到闲置状态。
请用状态转换图描绘复印机的行为。
从问题陈述可知，复印机的状态主要有“闲置”、“复印”、“缺纸”和“卡纸”。引起状态转换的事件主要是“复印命令”、“完成复印命令”、“发现缺纸”、“装满纸”、“发生卡纸故障”和“排除了卡纸故障”。
3.7 其他图形工具
层次方框图
层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。
树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。
随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，这种模式非常适合于需求分析阶段的需要。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。
举例：
Warnier图
Warnier图是法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。
Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。
用Warnier图可以表明信息的逻辑组织。它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。
举例：
图中表示一种软件产品要么是系统软件要么是应用软件。系统软件中有P1种操作系统，P2种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，图中标出了每种软件工具的数量。
- “( )”的数字表示重复的次数
- “⊕”表示互斥的选择关系
IPO图
左边的框中列出有关的输入数据。
中间的框内列出主要的处理，处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。
在右边的框内列出产生的输出数据。
在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。
一种改进的IPO图 (也称为IPO表)
在需求分析阶段可以使用IPO表简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。
需求分析阶段，IPO表中的许多附加信息暂时还不具备，但在设计阶段可以进一步补充修正这些图，作为设计阶段的文档。
这正是在需求分析阶段用IPO表作为描述算法的工具的重要优点。
3.8 验证软件需求
验证软件需求的正确性，一般应从4个方面进行：
- (1) 一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
- (2) 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
- (3) 现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
- (4) 有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。
小结
需求分析的任务: what functions + other requirements
获取需求的方法: visit, prototyping, refinement
分析建模与规格说明: 数据、功能和行为模型
实体-联系图 & 数据规范化
状态转换图+有穷状态机
数据字典&其他图形工具
验证软件需求:一致性、完整性、现实性和有效性
重点
需求分析建模的结构化方法
接口需求
需求分析阶段所涉及的建模工具图形