软件工程：需求分析

虽然可行性研究阶段已经粗略地了解了用户的需求，甚至还提出了一些可行的方案。但是，可行性研究的基本目的是作用于较小成本在较短时间内确定是否存在可行的解法，因此许多细节被忽略。

需求分析的任务还不确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪样工作，也就是对目标系统提出完整，准确，清晰，具体的要求。需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面的形式准确地描述软件需求。

需求规格说明书模板：链接

基本准则：

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

1，需求分析的任务

1.1，确定系统的综合要求

需求	描述
功能需求	系统必须提供的服务
性能需求	系统必须满足的定时约束或容量约束，通常包括速度，速率，主存容量，磁盘容量等
可靠性和可用性需求	可靠性需求定量地指出系统的可靠性 可用性与可靠性密切相关，它量化了用户可以使用系统的程度
出错处理需求	说明系统对环境错误应该怎样响应
接口需求	接口需求描述应用系统与它的环境通信的格式
约束	设计约束或实现约束在设计或实现应用系统时应遵守的限制条件，精度，工具，语言，设计约束等
逆向需求	说明软件系统不应该做什么，理论上有无限个逆向需求
将来可能提出的要求	应该明确列出那些虽然不属于当前系统开发范畴，但根据分析很可能会提出来的要求

1.2，分析系统的数据要求

（1）任何一个系统软件本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求的一个重要任务。

（2）复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够形象直观，为了提高可理解性，常常利用图形工具辅助描绘数据结构。

（3）软件系统经常使用各种长期保存的信息，这些信息通畅以一定方式组织并存储在数据库或者文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。

1.3，导出系统的逻辑模型

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

1.4，修正系统开发计划

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

2，获取需求的方法

2.1，访谈

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

在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。

情景分析的用处：

• 它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。
• 由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。

2.2，面向数据流自顶向下求精

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

为了达到这个目标，通常从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。

数据流图是帮助复查的极好工具，从输入端开始，分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。这些解释集中反映了通过前面的分析工作分析员所获得的对目标系统的认识。

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

2.3，简易的应用规格说明技术

简易的应用规格说明技术是为了解决使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想的。

2.4，快速建立软件模型

特性：

• 快速原型应该具备的第一个特性是“快速”。
• 快速原型应该具备的第二个特性是“容易修改”。

方法工具：

• 第四代技术：数据库查询和 表语言，程序和应用系统生成器以及其他非常高级的非过程语言。
• 可重用的软件构件：用已有的软件构建来装配原型。
• 形式化规格说明和原型环境：将形式化语言翻译成可执行的程序代码。

3，分析建模与规格说明

3.1，分析建模

• 实体联系图，描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。
• 数据流图是建立功能模型的基础。
• 状态转换图描绘了系统的各种行为模式和在不同状态间转换的方式。

3.2，软件需求规格说明

需求分析除了分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。

软件需求规格说明书：通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。

4，实体关系图（ER图）

数据对象	数据对象是对软件必须理解的符合信息的抽象
	数据对象可以是外部实体、事物、行为、事件、角色、单位、地点或结构等。 总之，可以由一组属性来定义的实体都可以被认为是数据对象。
	数据对象彼此间是有关联的
	数据对象只封装了数据而没有对施加于数据上的操作的引用
属性	属性定义了数据对象的性质
	必须把一个或多个属性定义为“标识符”，也就是说，当人们希望找到数据对象的一个实例时， 用标识符属性作为“关键字”(通常简称为“键”)。
联系	一对一：一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。
	一对多：某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教
	多对多：学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。
实体-联系符	矩形框代表实体，用连接相关实体的菱形框表示关系， 用椭圆形或圆角矩形表示实体(或关系)的属性，用直线把实体(或关系)与其属性连接起来。 联系也存在属性

5，数据规范化

第一范式	每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
第二范式	满足第一范式，而且每个非关键字属性都由整个关键字决定。
第三范式	满足第二范式，一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述。

6，状态转换图

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

状态	状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。
	在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态)和中间状态。 在一张状态图中只能有一个初态，而终态则可以有0至多个。
	状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。
事件	事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。
	事件就是引起系统做动作或(和)转换状态的控制信息。
符	在状态图中，初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。
	中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。 上面部分为状态的名称，这部分是必须有的； 中间部分为状态变量的名字和值，这部分是可选的； 下面部分是活动表，1这部分也是可选的。
	3种标准事件：entry, exit和do。 entry事件指定进入该状态的动作， exit事件指定退出该状态的动作， 而do事件则指定在该状态下的动作。

7，其他图形工具

7.1，层次方框图

层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。

7.2，Warnier图

和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。用Warnier图可以表明信息的逻辑组织，也就是说，它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。

7.3，IPO图

IPO图是输入、处理、输出图的简称，它是由美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。

8，验证软件需求

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

需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。

为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述4个方面进行验证：

一致性	所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
完整性	需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
现实性	指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
有效性	必须证明需求是正确有效的，确实能解决用户面对的问题。

8.2，验证软件需求的方法

验证一致性	人工技术审查验证软件系统规格说明书的正确性 形式化的描述软件需求的方法
验证现实性	分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。 必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。
验证完整性和有效性	在用户的密切合作下完成，主要依靠原型系统。

8.3，用于需求分析的软件工具

软件工具应该满足以下要求：

• 必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容。
• 使用这个软件工具能够导出详细的文档。
• 必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组 告指明对完整性分析的结果。
• 使用这个软件工具之后，应该能够改进通信状况。

PSL/PSA系统：PSL/PSA系统是CADSAT（计算机辅助设计和规格说明分析工具）的一部分。其中PSL是用来描述系统的形式语言，PSA是处理PSL描述的分析程序。

PSL/PSA功能：

• 描述任何应用领域的信息系统。
• 创建一个数据库保存对该信息系统的描述符。
• 对描述符施加增加、删除和更改等操作。
• 产生格式化的文档和关于规格说明书的各种分析 告。