一、需求分析的目的
需求分析是一项软件工程的活动，其目的包括以下几点：
完整地获取用户要求，清楚地理解索要解决的问题；
描述清楚软件的功能和性能；
指明软件与其他系统元素的接口；
建立软件必须满足的约束（如运行环境等）。
二、需求分析的任务
需求分析是研究用户要求，以得到目标系统的需求定义的过程。需求分析的基本任务是软件开发人员和用户一起完全弄清用户对系统的确切要求。具体步骤包括下面几点。
1. 需求获取
调查研究的方法有访谈、分发调查表或开会等。
（1）访谈 ：正式访谈和非正式访谈 。
（2）分发调查表：调查表中列出需要的内容，让用户书面回答问题。
（3）开会 ：可采用开会-讨论-确认的方法进行调查。
2. 需求建模
需求分析建立起来的模型为日后的软件设计提供了可被翻译成数据、体系结构、接口和处理过程设计的模型。
2.1软件需求的层次
1)．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
2)．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。
3)．功能需求(functional requirement) 定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求
1引言 2
1.1编写目的 2
1.2背景 2
1.3定义 2
1.4参考资料 2
2任务概述 2
2.1目标 2
2.2用户的特点 3
2.3假定和约束 3
3需求规定 3
3.1对功能的规定 3
3.2对性能的规定 3
3.2.1精度 3
3.2.2时间特性要求 3
3.2.3灵活性 4
3.3输人输出要求 4
3.4数据管理能力要求 4
3.5故障处理要求 4
3.6其他专门要求 5
4运行环境规定 5
4.1设备 5
4.2支持软件 5
4.3接口 5
4.4控制 5
软件需求说明书的编写提示
1引言
1.1编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。
1.2背景
说明：
a． 待开发的软件系统的名称；
b． 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c． 该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出用得着的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2任务概述
2.1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
2.2用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束
2.3假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
3需求规定
3.1对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
3.2对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.2.2时间特性要求
说明对于该软件的时间特性要求，如对：
a． 响应时间；
b． 更新处理时间；
c． 数据的转换和传送时间；
d． 解题时间；等的要求。
3.2.3灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a． 操作方式上的变化；
b． 运行环境的变化；
c． 同其他软件的接口的变化；
d． 精度和有效时限的变化；
e． 计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
3.5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.6其他专门要求
如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4运行环境规定
4.1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a． 处理器型号及内存容量；
b． 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c． 输入及输出设备的型号和数量，联机或脱机；
d． 数据通信设备的型号和数量；
e． 功能键及其他专用硬件
4.2支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
4.3接口
说明该软件同其他软件之间的接口、数据通信协议等。
4.4控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
需求分析的任务就是准确地回答“ 系统必须做什么 ”。是通过系统分析员与用户一起商定，清晰、准确、具体地描述软件产品必须具有的 功能 、 性能 、 运行环境 等要求。
用户：知道做什么，不知道怎么做。 开发人员：知道怎么做，不知道做什么。
因此，系统分析员必须和用户密切配合、充分交流信息，得出经过用户认可的系统需求。 需求分析的目的是澄清用户的需求，并把双方共同的理解明确地表达成一份书面文档—— 需求规格说明书 。
需求分析是一项软件工程活动，它包括： 需求获取 、 需求建模 、 需求规格说明 、 需求评审 。
需求分析模型 是准确地描述需求的图形化工具，主要有 实体关系图 、 数据流图 、 状态转换图 。需求分析建立起来的模型为日后软件设计人员提供了可被翻译成 数据结构 、 体系结构 、 接口 和 处理过程 设计的模型。
如上图所示，目标系统模型的建立过程分 4 步完成：
把分析的结果用正式的文档记录下来，作为最终软件配置的一个组成成分。需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。
作为需求分析阶段的复审手段，在需求分析的最后一步应该对功能的正确性、完整性和清晰性以及其他需求给予评价。
需求分析研究的对象是 用户的要求 。必须 全面理解 用户的各项要求， 准确表达 用户的要求。只有经过确切描述的软件需求才能成为软件设计的基础。
评审应由专人负责，评审组由软件开发成员、软件专家、领域专家和用户构成。
需求分析是一个不断的迭代过程。只有需求全面，准确无误，才能开发出用户满意的系统。
需求获取是软件开发工作中最重要的环节之一，其工作质量对整个软件系统开发的成败具有决定性影响。需求获取工作量大，所涉及的过程、人员、数据、信息非常多，因此要想获得真实、全面的需求必须要有正确的方法。常规的需求获取的方法有以下几种：
需求分析模型 是准确地描述系统需求的图形化工具。它可以使人们更好地理解将要建造的系统，它有助于系统分析员理解系统的信息、功能和行为，成为确定需求规格说明完整性、一致性和精确性的重要依据，奠定软件设计基础。
需求分析建模的方法有 结构化分析建模 和 面向对象分析建模 。
结构化分析导出的分析模型包括 数据模型 、 功能模型 和 行为模型 。
需求分析模型以“ 数据字典 ”为核心，描述了软件使用的所有数据对象，围绕这个核心的是“ 实体关系图 ”、“ 数据流图 ”和“ 状态转换图 ”。
具体形式如下图所示：
实体关系图（ER，Entity-Relationship Diagram） ：是一种数据模型，是以实体、关系、属性三个基本概念概括数据的基本结构，从而描述 静态数据结构 的概念模型。
ER 包括三种基本元素：
关联的重数 定义了在关联的一端可以存在的数据实体实例的数量。 关联重数可以具有下列值之一：
两个数据对象之间按关联的重数有以下三种关联：
以下实体关系图描述的是教师、课程、学生三者之间的关系。
以下实体关系图描述的是出勤、职工、奖金、扣款之间的关系。
数据流图（DFD，Data flow diagram） ，是描述数据流和数据转换的图形工具，它是进行结构化分析的基本工具，也是进行软件体系结构设计的基础。
DFD 有四种元素，其基本符号如图所示：
示例，工资计算系统的顶层（0层）数据流图：
在数据流图中有时也使用 附加符号 ： * 、 + 、 ⊕ ，分别表示与、或、互斥关系。
数据流图可分为不同层次，顶层（0层）DFD 称为 基本系统模型 ，可以将整个软件系统表示为一个具有输入和输出的黑匣子，其加工处理是 软件项目的名称 ，用一个圆圈表示。
DFD 中的每一个加工可以进一步扩展成一个独立的数据流图，以揭示系统中加工的细节。这种循序渐进的细化过程可以继续进行，直到最底层的 DFD 图仅描述加工的 原子过程 为止。每一层数据流图必须与它上一层数据流图的输入输出保持平衡和一致。
数据流图是在需求陈述的基础上绘制的。
这个数据流图只是一个高层的系统逻辑模型，它反映了目标系统要实现的功能。
第二层数据流图——销售细化：
第二层数据流图——采购细化：
当软件系统涉及 时序关系 时需要进行 行为建模 ，由于数据流图不描述时序关系，系统的控制和事件流需要通过行为模型来描述。
在描述系统或各个数据对象的行为时，采用 状态转换图 。通过描述系统或对象的 状态 ，以及引起系统或对象状态转换的 事件 来表示系统或对象的行为。
状态转换图（STD，Status Transition Diagram） ，是描述系统状态如何响应外部事件进行转移的一种图形表示。
状态 是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。在状态图中定义的状态主要有： 初始状态 、 中间状态 和 最终状态 。
事件 是在某个特定时刻发生的事情，它是对引起系统从一个状态转换到另一个状态的外界事件的抽象。
在状态转换图中，圆圈“○”表示可得到的 系统状态 ，箭头“→”表示从一种状态向另一种 状态的转移 。箭头旁标上 事件名 。
数据字典（DD，Data Dictionary） 用来描述数据流图中的数据存储、数据加工和数据流。 数据字典与数据流图配合，能够准确、清晰地表达数据处理的要求。
对于在数据流图中每一个被命名的图形元素均加以定义 ，其内容有: 名字、别名或编号、分类、描述、定义、位置、其它。
在数据字典中，数据元素的定义可以是基本元素及其组合，数据进行自顶向下地分解，直到不需要进一步解释且参与人员都清楚其含义为止。
数据流定义实例：航班订票单的数据定义
数据元素定义实例：考试成绩的数据定义
数据文件定义实例：图书库存的数据定义
数据处理定义实例：编辑订票的数据定义
外部实体定义实例：教师的数据定义
存折＝户名＋所号＋帐号＋开户日＋性质＋(印密)＋1{存取行}50 户名＝2{字母}24 所号＝“001”..“999” 帐号＝“00000001”..“99999999” 开户日＝年＋月＋日 性质＝“1”..“6” 注：“1”表示普通户，“5”表示工资户等 印密＝“0” 注：印密在存折上不显示 存取行＝日期＋（摘要）＋支出＋存入＋余额＋操作＋复核
需求规格说明书（SRS，Software Requirement Specification） ，是系统分析人员在需求分析阶段完成的文档，是软件需求分析的最终结果。
它的 作用 主要是： 作为软件人员与用户之间事实上的技术合同；作为软件人员下一步进行设计和编码的基础；作为测试和验收的依据 。
SRS 必须用统一格式的文档进行描述。为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，如中国国家标准推荐的SRS模板，也可以根据项目特点和软件开发小组的特点对标准进行适当的改动，形成自己的模板。
