第三章-需求分析

第三章-需求分析

• 了解需求分析的概念、基本任务。
• 熟悉需求分析的开发方法（结构化分析方法和面向对象的分析方法）和各自特点。
• 掌握结构化分析方法、结构化分析步骤，掌握面向数据流的分析方法；掌握数据流图、数据字典等结构化分析工具。

1、需求分析的任务

需求分析的任务不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

软件需求规格说明书

需求分析遵循准则

• 必须理解并描述问题的信息域 → 数据模型
• 必须定义软件应完成的功能 → 功能模型
• 必须描述作为外部事件结果的软件行为 → 行为模型
• 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。

确定对系统的综合要求

• 功能需求
  指定系统必须提供的服务，划分出系统必须完成的所有功能。
• 性能需求
  指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
• 可靠性和可用性需求
  可靠性定量地指定系统的可靠性。
  可用性与可靠性密切相关，它量化了用户可以使用系统的程度。
• 出错处理需求
  说明系统对环境错误应该怎样响应。
• 接口需求
  描述应用系统与它的环境通信的格式，例如用户接口需求、硬件接口需求、软件接口需求、通信接口需求。
• 约束
  描述在设计或实现应用系统时应遵守的限制条件，例如精度、工具和语言约束、设计约束、应使用的准则、应使用的硬件平台。
• 逆向需求
  说明软件系统不应该做什么。理论上有无限多个逆向需求，应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
• 将来可能提出的要求
  应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。
  这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。

分析系统的数据要求

分析系统的数据要求通常采用建立数据模型的方法。
为了提高可理解性，常常利用图形工具辅助描绘数据结构。

• 层次方框图
• Warnier图

导出系统的逻辑模型

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

修正系统的开发计划

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

2、需求分析的开发方法

（1）访谈

• 正式访谈：系统分析员将提出一些事先准备好的具体问题。
• 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。

（2）面向数据流自顶向下求精

信息处理系统的基本功能都是把输入数据转变成需要的输出数据。

数据决定了需要的处理和算法。
在可行性研究阶段许多实际的数据元素被忽略了，需求分析阶段是定义这些数据元素的时候了。

通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流图和数据存储定义到元素级。
为此，通常从数据流图的输出端着手分析。

可行性研究阶段产生的数据流图，许多具体的细节没有包括在里面，因此沿数据流图回溯时常常遇到下述问题: 为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出这个数据元素需要用的算法尚不完全清楚。

为此，往往需要向用户和其他有关人员请教与讨论，他们的回答使分析员对目标系统的认识更深入更具体了，系统中更多的数据元素被划分出来了，更多的算法被搞清楚了。

通常把分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO图中。通过分析而补充的数据流、数据存储和处理，应该添加到数据流图的适当位置上。

随着分析过程的进展，经过问题和解答的反复循环，分析员越来越深入具体地定义了目标系统，最终得到对系统数据和功能要求的满意了解。

（3）简易的应用规格说明技术

提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。

• 首先进行初步的访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案。
• 然后开发者和用户分别写出“产品需求”。选定会议的时间和地点，并选举一个负责主持会议的协调人。邀请开发者和用户双方组织的代表出席会议，并在开会前预先把写好的产品需求分发给每位与会者。

面向团队的需求收集方法的优点:
开发者与用户不分彼此，齐心协力，密切合作;即时讨论并求精;有能导出规格说明的具体步骤。

（4）快速建立软件模型

快速建立软件原型是最准确、最有效、最强大的需求分析技术。

构建原型的要点是，它应该实现用户看得见的功能，省略目标系统的“隐含”功能。

快速原型应该具备的第一个特性是“快速”。
快速原型的目的是使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。因此，原型的某些缺陷是可以忽略的，只要这些缺陷不严重地损害原型的功能，不会使用户对产品的行为产生误解。

快速原型应该具备的第二个特性是“容易修改”。
如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版。

3、分析建模

所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。

通常，模型由一组图形符号和组织这些符号的规则组成。

为了开发出复杂的软件系统，系统分析员从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。

• 实体-联系图，描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。
• 数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，因此，数据流图是建立功能模型的基础。
• 状态转换图，指明了作为外部事件结果的系统行为，描绘了系统的各种行为模式和在不同状态间转换的方式，是行为建模的基础。

4、需求规格说明

自然语言的规格说明具有容易书写、容易理解的优点，为大多数人所欢迎和采用。

为了消除用自然语言书写的软件需求规格说明书中可能存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题，人们主张用形式化方法描述用户对软件系统的需求。