- 需求分析的任务就是准确地回答“系统必须做什么”。
- 概要设计（也称为总体设计）的基本目的是“概括地说系统应该如何实现”。
- 详细设计，就是把概要设计中的内容进行具体的实现。
3.1 需求分析任务
需求分析的任务就是准确地回答“系统必须做什么”。是通过系统分析员与用户一起商定，清晰、准确、具体地描述软件产品必须具有的功能、性能、运行环境等要求。
用户：知道做什么，不知道怎么做。
开发人员：知道怎么做，不知道做什么。
因此，系统分析员必须和用户密切配合、充分交流信息，得出经过用户认可的系统需求。
需求分析的目的是澄清用户的需求，并把双方共同的理解明确地表达成一份书面文档——需求规格说明书。
需求分析的具体任务
- 确定软件系统的综合需求（功能、性能、接口、运行环境等）；
- 分析系统的数据需求；
- 导出软件系统的逻辑模型；
- 修正系统开发计划；
- 开发原型系统；
- 编写需求规格说明书；
- 需求评审，验证需求分析的正确性。
3.2 需求分析过程
需求分析是一项软件工程活动，它包括：需求获取、需求建模、需求规格说明、需求评审。
3.2.1 需求获取
- 刻画出软件的功能和性能；
- 指明软件与其他系统元素的接口；
- 建立软件必须满足的约束。
3.2.2 需求建模
需求分析模型是准确地描述需求的图形化工具，主要有实体关系图、数据流图、状态转换图。需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据结构、体系结构、接口和处理过程设计的模型。
如上图所示，目标系统模型的建立过程分 4 步完成：
-
获得当前系统的物理模型
了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，分析理解当前系统的运行过程（也即理解当前系统“怎么做”），并用一个具体的能反映现实的模型（系统流程图）来表示。
-
抽象出当前系统的逻辑模型
从上述步骤的“怎么做”抽取系统“做什么”的本质，舍弃非本质的东西，即可抽象出当前系统的逻辑模型（数据流图）。
-
建立目标系统的逻辑模型
明确目标系统做什么，一般先比较目标系统和当前系统的差异，对当前系统的数据流图变化的部分做相应的调整（增加或删除部分功能，拆分或合并处理），获得目标系统的逻辑模型。
-
转换为目标系统的物理模型
根据目标系统逻辑模型建造物理模型（系统结构图），导出新的物理系统。
货物采购需求分析实例
- 获得当前系统的物理模型
- 抽象出当前系统的逻辑模型
- 分析目标系统与当前系统的差别，建立目标系统的逻辑模型
3.2.3 需求规格说明
把分析的结果用正式的文档记录下来，作为最终软件配置的一个组成成分。需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。
3.2.4 需求评审
作为需求分析阶段的复审手段，在需求分析的最后一步应该对功能的正确性、完整性和清晰性以及其他需求给予评价。
需求分析研究的对象是用户的要求。必须全面理解用户的各项要求，准确表达用户的要求。只有经过确切描述的软件需求才能成为软件设计的基础。
评审应由专人负责，评审组由软件开发成员、软件专家、领域专家和用户构成。
需求分析是一个不断的迭代过程。只有需求全面，准确无误，才能开发出用户满意的系统。
3.3 需求分析原则
- 正确理解和表达问题的信息域和功能域。
-
对问题进行分解和不断细化，建立问题的层次结构。
- 捕获问题空间的多维视图。
- 给出系统的逻辑视图和物理视图。
3.4 需求获取方法
需求获取是软件开发工作中最重要的环节之一，其工作质量对整个软件系统开发的成败具有决定性影响。需求获取工作量大，所涉及的过程、人员、数据、信息非常多，因此要想获得真实、全面的需求必须要有正确的方法。常规的需求获取的方法有以下几种：
- 收集资料。收集资料就是将用户日常业务中所用的计划、原始凭据、单据和报表等原始资料收集起来，以便对它们进行分类研究。
- 开调查会。召开调查会是一种集中征询意见的方法，适合于对系统的定性调查。
- 个别访谈。开调查会有助于大家的见解互相补充，以便形成较为完整的印象。但是由于时间限制等其他因素，不能完全反映出每个与会者的意见，因此，往往需要在会后根据具体需要再进行个别访问。
- 书面调查。根据系统特点设计调查表（需求问卷调查表），用调查表向有关单位和个人征求意见和收集数据。该方法适用于比较复杂的系统。
- 参加业务实践。如果条件允许，亲自参加业务实践是了解现行系统的最好方法。通过实践还加深了开发人员和用户的思想交流和沟通，这将有利于下一步的系统开发工作。
- 收发电子邮件。通过互联网和局域网发电子邮件进行调查，这可大大节省时间、人力、物力和费用。
- 召开电视电话会议。如果有条件还可以利用打电话和召开电视会议进行调查，但只能作为补充手段，因为许多资料需要亲自收集和整理。
3.5 需求分析模型
需求分析模型是准确地描述系统需求的图形化工具。它可以使人们更好地理解将要建造的系统，它有助于系统分析员理解系统的信息、功能和行为，成为确定需求规格说明完整性、一致性和精确性的重要依据，奠定软件设计基础。
需求分析建模的方法有结构化分析建模和面向对象分析建模。
结构化分析导出的分析模型包括数据模型、功能模型和行为模型。
需求分析模型以“数据字典”为核心，描述了软件使用的所有数据对象，围绕这个核心的是“实体关系图”、“数据流图”和“状态转换图”。
具体形式如下图所示：
3.5.1 实体关系图
实体关系图（ER，Entity-Relationship Diagram）：是一种数据模型，是以实体、关系、属性三个基本概念概括数据的基本结构，从而描述静态数据结构的概念模型。
ER 包括三种基本元素：
- 实体：表示具有不同属性的事物，用带实体名称的矩形框表示。
- 属性：指实体某一方面的特征，用带属性名称的椭圆表示。
- 关系：关系表示实体之间的相互连接，用直线连接相关联的实体，并在直线上用带关系名称的菱形来表示
关联的重数定义了在关联的一端可以存在的数据实体实例的数量。 关联重数可以具有下列值之一：
- (1)：表明在关联端存在且只存在一个数据实体实例。
- (0..1)：表明在关联端不存在实体实例或存在一个实体实例。
- (*或N)：表明在关联端不存在实体实例，或者存在一个或多个实体实例。
两个数据对象之间按关联的重数有以下三种关联：
- 一对一（1:1）关联：对象 A 的一个实例只能关联到对象 B 的一个实例，对象 B 的一个实例也只能关联到对象 A 的一个实例。
一对一关系图 - 一对多（1:N）关联：对象 A 的一个实例可以关联到对象 B 的一个或多个实例，而对象 B 的一个实例只能关联到对象 A 的一个实例，如一个母亲可以有多个孩子，而一个孩子只能有一个母亲。
一对多关系图 - 多对多（M:N）关联：对象 A 的一个实例可以关联到对象 B 的一个或多个实例，同时对象 B 的一个实例也可以关联到对象 A 的一个或多个实例，如一个叔叔可以有多个侄子，一个侄子也可以有多个叔叔。
多对多关系图
示例一：教学管理系统 ER 图
以下实体关系图描述的是教师、课程、学生三者之间的关系。
示例二：工资计算系统 ER 图
以下实体关系图描述的是出勤、职工、奖金、扣款之间的关系。
3.5.2 数据流图
3.5.2.1 数据流图的概念
数据流图（DFD，Data flow diagram），是描述数据流和数据转换的图形工具，它是进行结构化分析的基本工具，也是进行软件体系结构设计的基础。
3.5.2.2 数据流图中的要素
DFD 有四种元素，其基本符号如图所示：
- 外部实体：与系统进行交互，但系统不对其进行加工和处理的实体（人或事物），用带实体名称的矩形方框表示。
- 加工（处理）：对数据进行的变换和处理，用带加工（处理）名称的圆圈表示。
- 数据流：在数据加工之间或数据存储和数据加工之间进行流动的数据，用带数据流名称的箭头表示。
- 数据存储：在系统中需要存储的数据（文件），用带存储文件名称的双实线表示。
示例，工资计算系统的顶层（0层）数据流图：
在数据流图中有时也使用附加符号：*、+、⊕，分别表示与、或、互斥关系。
3.5.2.3 分层数据流图
数据流图可分为不同层次，顶层（0层）DFD 称为基本系统模型，可以将整个软件系统表示为一个具有输入和输出的黑匣子，其加工处理是软件项目的名称，用一个圆圈表示。
DFD 中的每一个加工可以进一步扩展成一个独立的数据流图，以揭示系统中加工的细节。这种循序渐进的细化过程可以继续进行，直到最底层的 DFD 图仅描述加工的原子过程为止。每一层数据流图必须与它上一层数据流图的输入输出保持平衡和一致。
3.5.2.4 绘制数据流图的基本步骤
数据流图是在需求陈述的基础上绘制的。
- 首先画系统的输入/输出，确定系统从外界接收什么数据，系统向外界输出什么数据，确定系统的范围和边界。
- 其次画系统内部，将系统的输入和输出流用一连串加工连接起来。可以从输入端画到输出端，也可反过来画。在数据流的组成或值发生变化的地方添加一个“加工”，在需要存放数据的地方加上一个“文件”。
- 最后画加工的内部，对加工进行分解，一个复杂的加工可用几个子加工代替。
示例：商店业务处理系统的数据流图
- 首先确定系统的输入和输出（顾客和供应商）；
这个数据流图只是一个高层的系统逻辑模型，它反映了目标系统要实现的功能。
- 其次，根据商店业务，画出顶层数据流图，以反映最主要业务处理流程。经过分析，商店业务处理的主要功能有销售、采购、会计三大项。主要数据流输入的源点和输出终点是顾客和供应商。然后从输入端开始，根据商店业务工作流程，画出数据流流经的各加工框，逐步画到输出端，得到第一层数据流图。
- 最后，对每个加工（主要是销售和采购）细化，得出第二层数据流图。
第二层数据流图——销售细化：
第二层数据流图——采购细化：
3.5.2.5 绘制数据流图应注意的问题
-
给数据流命名的方法：
- 数据流名字用名词或名词词组；
- 命名时，尽量使用现实系统中已有的名字；
- 避免使用空洞的名词，如“数据”、“信息”等。
如果在为某个数据流（或数据存储）命名时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该尝试重新分解，看是否能解决这个问题。
-
给加工命名的原则：
- 顶层加工是软件项目的名称。
- 加工的名字最好使用动宾词组，如“生成成绩单”、“打印报表”等。
- 加工的命名同样避免使用空洞的词组，如“计算”、“处理”等。
不要把数据流图画成控制流图，应尽量避免数据流图中夹带控制流，以免与详细设计阶段的程序流程图相混淆。
-
应保持子图与父图输入/输出流的平衡。
子图与父图的平衡 提高数据流图的清晰性。应做到分解自然，概念合理、清晰，在不影响易理解性的基础上适当地多分解，以减少数据流图的层数。分解时要注意子加工的独立性，还应注意均衡性。
反复修改，不断完善。人的思考过程是一个不断的迭代过程，不可能一次成功，需要不断完善，直到满意为止。对于复杂的系统，很难保证一次就能将数据流图绘制成功。因此应随时准备改进数据流图而用更好的版本来代替。
3.5.3 状态转换图
当软件系统涉及时序关系时需要进行行为建模，由于数据流图不描述时序关系，系统的控制和事件流需要通过行为模型来描述。
在描述系统或各个数据对象的行为时，采用状态转换图。通过描述系统或对象的状态，以及引起系统或对象状态转换的事件来表示系统或对象的行为。
状态转换图（STD，Status Transition Diagram），是描述系统状态如何响应外部事件进行转移的一种图形表示。
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。在状态图中定义的状态主要有：初始状态、中间状态和最终状态。
事件是在某个特定时刻发生的事情，它是对引起系统从一个状态转换到另一个状态的外界事件的抽象。
在状态转换图中，圆圈“○”表示可得到的系统状态，箭头“→”表示从一种状态向另一种状态的转移。箭头旁标上事件名。
示例一：有关处理器（CPU）分配的进程状态转移图
示例二：电话系统的状态转换图
3.6 数据字典
数据字典（DD，Data Dictionary） 用来描述数据流图中的数据存储、数据加工和数据流。数据字典与数据流图配合，能够准确、清晰地表达数据处理的要求。
3.6.1 词条描述
对于在数据流图中每一个被命名的图形元素均加以定义，其内容有: 名字、别名或编号、分类、描述、定义、位置、其它。
在数据字典中，数据元素的定义可以是基本元素及其组合，数据进行自顶向下地分解，直到不需要进一步解释且参与人员都清楚其含义为止。
3.6.1.1 数据流词条描述
- 数据流名称及编号；
- 说明：简要介绍它产生的原因和结果；
- 数据流来源：来自何方；
- 数据流去向：去向何处；
- 数据流组成：数据结构；
- 数据量流通量：数据量，流通量；
数据流定义实例：航班订票单的数据定义
数据流编号：DF001
数据流名称：订票单
简述：订票时填写的订票单
数据流来源：外部实体“乘客”
数据流去处：处理逻辑“预订机票”
数据流组成：订单编号
日期
乘客号
航班号
状态
订单失效日期
流通量：每天300份
高峰值流通量：每天早上9：00，约160份
3.6.1.2 数据元素词条描述
- 数据元素名称及编号；
- 类型：数字（离散值，连续值），文字（编码类型）；
- 长度；
- 取值范围；
- 相关的数据元素及数据结构；
数据元素定义实例：考试成绩的数据定义
数据元素编号：DC001
数据元素名称：考试成绩
别名：成绩、分数
简述：学生考试成绩，分五个等级
类型/长度：两个字节，字符类型
取值/含义：优 [90-100]
良 [80-89]
中 [70-79]
及格 [60-69]
不及格 [0-59]
有关数据项或结构：学生成绩档案
有关处理逻辑：计算成绩
3.6.1.3 数据文件词条描述
- 数据文件名称及编号；
- 简述：存放的是什么数据；
- 输入数据；
- 输出数据；
- 数据文件组成：数据结构；
- 存储方式：顺序，直接，关键码；
- 存取频率；
数据文件定义实例：图书库存的数据定义
数据文件编号：DB002
数据文件名称：图书库存
组成：图书编号+图书详情+目前库存量
组织方式：按图书编号从小到大排列
3.6.1.4 加工逻辑（数据处理）词条描述
- 加工名称及编号；
- 加工编号：反映该加工的层次；
- 简要描述：加工逻辑及功能简述；
- 输入数据流；
- 输出数据流；
- 加工逻辑：简述加工程序，加工顺序；
数据处理定义实例：编辑订票的数据定义
数据处理编号：DP001
数据处理名称：编辑订票
简述：接收从终端录入的订票单，检验是否正确
输入：乘客订单，来源：外部实体“乘客”
输出：1.合格订单，去处：处理逻辑“确定订票”
2.不合格订单，去处：外部实体“乘客”
功能描述：……（略）
3.6.1.5 外部实体词条描述
- 外部实体名称及编号；
- 简要描述；
- 有关数据流；
- 数目；
外部实体定义实例：教师的数据定义
编号：DT001
名称：教师
简述：向教师图书室提供图书的教师
从外部输入：报销申请
向外部输出：入库证明
3.6.2 数据字典中的符号
示例：存折的数据字典描述
存折＝户名＋所号＋帐号＋开户日＋性质＋(印密)＋1{存取行}50
户名＝2{字母}24
所号＝“001”..“999”
帐号＝“00000001”..“99999999”
开户日＝年＋月＋日
性质＝“1”..“6” 注：“1”表示普通户，“5”表示工资户等
印密＝“0” 注：印密在存折上不显示
存取行＝日期＋（摘要）＋支出＋存入＋余额＋操作＋复核
3.7 需求规格说明书
需求规格说明书（SRS，Software Requirement Specification），是系统分析人员在需求分析阶段完成的文档，是软件需求分析的最终结果。
它的作用主要是：作为软件人员与用户之间事实上的技术合同；作为软件人员下一步进行设计和编码的基础；作为测试和验收的依据。
SRS 必须用统一格式的文档进行描述。为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，如中国国家标准推荐的SRS模板，也可以根据项目特点和软件开发小组的特点对标准进行适当的改动，形成自己的模板。
3.7.1 需求规格说明主要内容
- 引言
- 编写目的：阐明编写需求说明书的目的，指出预期的读者。
- 项目范围：待开发的项目名称及项目的开发目的；与项目应用相关的利益人及最终目标；项目的委托方、开发单位和主管部门；该软件系统与其他系统的关系。
- 定义：列出文档中所用到专门术语的定义和缩写词的原义。
- 参考资料：包括项目经核准的计划任务书、合同或上级机关的批文；项目开发计划；文档所引用的资料、标准和规范。列出这些资料的作者、编号、发表日期、出自单位或资料来源。
- 任务概述
- 产品概述：描述开发意图、应用目标、作用范围、应向读者说明的有关该项目的开发背景。
- 用户特点：列出本软件最终用户的特点，说明操作人员、维护人员的教育水平和技术水平。
- 条件与限制：对设计系统时对开发者的条件与限制。
- 需求规定
- 对功能的规定：包括内部及外部功能的规定。
- 对性能的规定：包括对精度、时间要求、灵活性、适应性等的规定。
- 对输入输出的规定：包括所有输入输出数据、引用接口及接口控制文件、操作员控制的详细描述。
- 数据管理的规定：包括静态数据、动态数据、数据库、数据字典、数据采集的详细描述。
- 其他专门要求：如安全保密性、可使用性、可维护性、可移植性等。
- 运行环境规定
- 用户界面：如屏幕格式、报表格式、菜单格式、输入输出时间等。
- 设备：对系统硬件的要求描述。
- 软件接口：包括外部（软硬件）接口、内部（模块之间）接口和用户界面的描述。
- 故障处理。