本文内容来自于对《软件工程导论》（第6版，张海潘 牟永敏 编著），仅为个人学习记录。如涉及版权问题请版权方联系我。
需求分析是软件定义时期的最后一个阶段。
需求分析的基本任务：准确地回答“系统必须做什么”这个问题。
需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求 。
在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。
尽管目前有许多不同的用语需求分析的结构化分析方法，但是，所有这些分析方法都遵守下述准则：
（1）必须理解并描述问题的信息域，根据这条准则应该建立数据模型。
（2）必须定义软件应完成的功能，这条准则要求建立功能模型。
（3）必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。
（4）必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。
3.1需求分析的任务
3.1.1确定对系统的综合要求
虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求。通常对软件系统有下述几方面的综合要求：
1.功能需求
这方面的需求制定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。
2.性能需求
性能需求制定系统必须满足的定时约束或容量约束。
3.可靠性和可用性需求
可靠性需求定量地制定系统的可靠性。
可用性与可靠性密切相关，它量化了用户可以使用系统的程度。
4.出错处理需求
这类需求说明系统对环境错误应该怎样响应。
5.接口需求
接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。
6.约束
设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。
7.逆向需求
逆向需求说明软件系统不应该做什么。
8.将来可能提出的需求
应该明确地列出那些虽然不属于当前系统开发范畴，但是根据分析将来很可能会提出来的需求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改项做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。
3.1.2分析系统的数据要求
分析系统的数据要求通常采用建立数据模型的方法。
3.1.3导出系统的逻辑模型
综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体联系图（ER图）、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
3.1.4修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。
3.2与用户沟通获取需求的方法
3.2.1访谈
访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。
访谈有两种基本形式，分别是正式的和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题。在非正式访谈中，分析员将提出一些用户可以*回答的开放性问题，以鼓励被访问人员说出自己的想法。
情景分析技术
情景分析技术的用处主要体现在下述两个方面：
（1）他能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。
（2）由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的唯一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。
3.2.3简易的应用规格说明技术
这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。
使用简易的应用规格说明技术分析需求的典型过程如下：
①进行初步的访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案。
②开发者和用户分别写出“产品需求”。
3.3分析建模与规格说明
3.3.1分析建模
为了更好地理解复杂事物，人们常常采用建立事物模型的方法。所谓模型，就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。
需求分析过程中应该建立3种模型，它们分别是数据模型、功能模型、行为模型。
3.3.2软件需求规格说明
通过需求分析出了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。
通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求。可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的需求。
3.4实体-联系图
为了把用弧度数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型（也称为信息模型）。概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现方法无关。
数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。
3.4.1数据对象
数据对象是对软件必须理解的附和信息的抽象。所谓复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物（例如宽度）不是数据对象。
数据对象可以是外部实体。总之，可以由一组属性来定义ID实体都可以被认为是数据对象。
数据对象彼此间是有关联的。
数据对象之封装了数据而没有对施加于数据上的操作的引用，这是对数据对象与面向对象范型中的“类”或“对象”的显著区别。
3.4.2属性
属性定义了数据对象的性质。
应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。
3.4.3联系
客观世界中的事物彼此间往往是有联系的。
数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下3中类型：
（1）一对一联系（1：1）
（2）一对多联系（1：N）
（3）多对多联系（M：N）
联系也可能有属性。
3.4.4实体-联系图的符号
通常，使用实体-联系图（entity-relationship diagram）来建立数据模型。可以把实体-联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。
ER图中包含了实体（即数据对象）、关系和属性3中基本成分，通常用矩形框代表实体，用连接相关实体的菱形框标识关系，用椭圆型或圆角矩形标识实体（或关系）的属性，并用直线把实体（或关系）与其属性连接起来。
3.5数据规范化
软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。
通常用“范式（normal forms）”定义消除数据冗余的程度。第一范式（1NF）数据冗余程度最大，第五范式（5NF）数据冗余程度最小。但是，第一，范式级别越高，存储同样数据就需要分解成更多张表，因此，“存储自身”的过程也就越复杂。第二，随着范式级别的提高，数据的存储结构与机遇问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。第三，范式级别提高则需要访问的表增多，因此性能（速度）将下降。从实用角度看来，在大多数场合选用第三范式都比较恰当。
通常按照属性间的依赖情况区分范式化的程度。下面给出第一、第二和第三范式的定义：
（1）第一范式 每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
（2）第二范式 满足第一范式条件，而且每个非关键字属性都由整个关键字决定（而不是由关键字的一部分来决定）
（3）第三范式 符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述（即一个非关键字属性值不依赖于另一个非关键字属性值）。
3.6状态转换图
状态转换图（简称为状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。
3.6.1状态
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
在状态图中定义的状态主要有：初态（即初始状态）、状态（即最终状态）和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。
状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。
3.6.2事件
事件是在某个特定时刻发生的事情，它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统做动作或（和）转换状态的控制信息。
3.6.3符号
在状态图中，初态用实心圆表示，终态用一对同心圆（内圆为实心圆）表示。
中间状态用圆角矩形表示，可以用两条水平横线把它划分成上、中、下3个部分。上部分为状态的名称，这部分是必须的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。
3.8验证软件需求
软件需求的验证从以下4个方面：
（1）一致性
所有需求必须是一直的，任何一条需求不能和其他需求互相矛盾。
（2）完整性
需求必须是完整的，规格说明书应该包含用户需求的每一个功能或性能。
（3）现实性
指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
（4）有效性
必须证明需求是正确有效的，确实能解决用户面对的问题。
本文内容来自于对《软件工程导论》（第6版，张海潘 牟永敏 编著），仅为个人学习记录。如涉及版权问题请版权方联系我。