第三章：需求分析

第三章：需求分析

需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答"系统必须做什么"这个问题。 对目标系统提出完整、准确、清晰、具体的要求。 在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。 尽管目前有许多不同的用于需求分析的结构化分析方法，但是，所有这些分析方法都 遵守下述准则。
(1)必须理解并描述问题的信息域，根据这条准则应该建立数据模型。
(2)必须定义软件应完成的功能，这条准则要求建立功能模型。
(3)必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。
(4)必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。

3.1 需求分析的任务

3.1.1 确定对系统的综合要求

• 1.功能需求

  • 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。

• 2.性能需求

  • 性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。

• 3.可靠性和可用性需求

  • 可靠性需求定量地指定系统的可靠性，可用性与可靠性密切相关，它量化了用户可以使用系统的程度。

• 4.出错处理需求

  • 这类需求说明系统对环境错误应该怎样响应。

• 5.接口需求

  • 接口需求描述应用系统与它的环境通信的格式。

• 6.约束

  • 设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计(或实现)过程，只是说明用户或环境强加给项目的限制条件。

• 7.逆向需求

  • 逆向需求说明软件系统不应该做什么。

• 8.将来可能提出的要求

  • 应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。

3.1.2 分析系统的数据要求

• 任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。分析系统的数据要求通常采用建立数据模型的方法(见3.4节)。

3.1.3 导出系统的逻辑模型

• 综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。

3.1.4修正系统开发计划

• 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。

3.2与用户沟通获取需求的方法

3.2.1 访谈

• 在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。
  情景分析技术的用处主要体现在下述两个方面：
  (1)它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。
  (2)由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的唯一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。

3.2.2 面向数据流自顶向下求精

• 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。

3.2.3 简易的应用规格说明技术

• 人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。今天，简易的应用规格说明技术已经成为信息系统领域使用
  的主流技术。

3.2.4 快速建立软件原型

• 快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。

3.3 分析建模与规格说明

3.3.1 分析建模

• 需求分析过程应该建立3种模型，它们分别是
  数据模型（实体-联系图）、功能模型（数据流图）和行为模型（状态转换图）。

3.3.2 软件需求规格说明

• 通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。自然语言的规格说明具有容易书写、容易理解的优点，为大多数人所欢迎和采用。

3.4实体-联系图

为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数 据模型(也称为信息模型)。概念性数据模型是一种面向问题的数据模型，是按照用户的 观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而 且与在软件系统中的实现方法无关。数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。

3.4.1 数据对象

• 数据对象是对软件必须理解的复合信息的抽象。所谓复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物(例如宽度)不是数据对象。可以由一组属性来定义的实体都可以被认为是数据对象。

3.4.2 属性

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

3.4.3 联系

• 一对一、一对多、多对多

3.4.4 实体-联系图的符号

• ER图中包含了实体(即数据对象)、关系和属性3种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性连接起来

  • 图3.2某校教学管理ER图
    

3.5 数据规范化

(1)第一范式 每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。

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

3.6 状态转换图

状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的 事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作 (例如处理数据)。

3.6.1 状态

• 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态)和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。

3.6.2 事件

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

3.6.3 符号

• 在状态图中，初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。
  中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。
  上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。
  活动表的语法格式如下：
  事件名(参数表)/动作表达式
  其中，“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry,exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。
  状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
  事件表达式的语法如下：
  事件说明[守卫条件]/动作表达式
  其中，事件说明的语法为：事件名(参数表)。
  守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真，状态转换就发生。
  动作表达式是一个过程表达式，当状态转换开始时执行该表达式。

  • 图3.3 状态图中使用的主要符号
    

3.6.4 例子

• 图3.4 电话系统的状态图
  

3.7其他图形工具

3.7.1 层次方框图

3.7.2 Warnier图

3.7.3 IPO图

3.8 验证软件需求

3.8.1 从哪些方面验证软件需求的正确性

• 一般说来，应该从下述4个方面进行验证。
  (1)一致性 所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
  (2)完整性 需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
  (3)现实性 指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。
  (4)有效性 必须证明需求是正确有效的，确实能解决用户面对的问题。

3.8.2 验证软件需求的方法

• 1.验证需求的一致性

  • 人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性(见3.8.3节),从而能有效地保证软件需求的一致性。

• 2.验证需求的现实性

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

• 3.验证需求的完整性和有效性

  • 使用原型系统是一个比较现实的替代方法，开发原型系统所需要的成本和时间可以大大少于开发实际系统所需要的。用户通过试用原型系统，也能获得许多宝贵的经验，从而可以提出更符合实际的要求。

3.8.3 用于需求分析的软件工具

• 为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。这类软件工具应该满足下列要求。
  (1)必须有形式化的语法(或表),因此可以用计算机自动处理使用这种语法说明的内容。
  (2)使用这个软件工具能够导出详细的文档。
  (3)必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果。
  (4)使用这个软件工具之后，应该能够改进通信状况。

3.9小 结

（1） 需求分析的目标和任务
（2） 软件系统的可行性分析
（3） 需求获取
（4） 需求规格说明书
（5） 数据流建模（数据流图）
（6） 实体-关系建模（E-R 图）
（7） 系统行为建模
（8） 用例建模（用例图）
（9） 面向对象建模

思维导图

百度网盘地址