下载掌阅APP，畅读海量书库
立即打开
需求分析方法由对软件的信息域和功能域的系统分析过程及其表示方法组成。它提供了分解问题的方法，定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，就是说，这些方法提供了一种表示信息域的机制，分析人员根据这种表示，确定软件功能及其他特性，最终建立一个待开发软件的抽象模型，即目标系统的逻辑模型。信息域具有数据流、数据内容和数据结构3种属性。通常，一种需求分析方法总要利用其中的一种或几种属性。
目前存在许多需求分析方法，每种分析方法都引入了不同的记号和分析策略，但是它们仍具有以下共性。
1.支持信息域分析的机制
所有的方法都直接或间接地涉及数据流、数据内容或数据结构等信息域属性。
在多数情况下，数据流特征是用将输入转换成输出的变换（功能）过程来描述的，数据内容可以用数据词典机制明确表示，或者通过描述数据的层次结构隐含地表示。
2.功能表示的方法
功能一般用数据变换或加工来表示，每项功能可用规定的记号（圆圈或方框）标识。功能的说明可以用自然语言文本来表达，也可以用形式化的规格说明语言来表达，还可以用上述两种方式的混合方式——结构化语言来描述。
3.接口
接口的说明通常是数据表示和功能表示的直接产物，某个具体功能的流进和流出数据流应是其他相关功能的流出或流入数据流。因此，通过数据流分析可以确定功能间的接口。
4.问题分解的机制及对抽象的支持
问题分解和抽象主要依靠分析人员在不同抽象层次上表示数据域和功能域，以逐层细化的手段建立分层结构来实现。例如，不论使用何种分析方法，分析人员都能表示诸如“计算员工9月份工资”之类的功能，可以在这个抽象层次上操纵这个功能。另外，所有的分析方法都提供一种逐层分解的机制，把“计算员工9月份工资”功能划分成一些子功能，如计算房租、计算电费、计算水费、计算工会费、计算有线电视费、计算养老保险费，等等。其中，每项子功能还可以利用功能说明表示法在更低的一级抽象层次上表示。
5.逻辑视图和物理视图
大多数方法允许分析人员在着手问题的逻辑解决方案之前先分析物理视图。通常，同一种表示法既可用来表示逻辑视图，也可用来表示物理视图。
6.系统抽象模型
为了能够比较精确地定义软件需求，可以建立待开发软件的一个抽象模型，用基于抽象模型的术语来描述软件系统的功能和性能，形成软件需求规格说明。这种抽象的模型是从外部现实世界的问题领域抽象而来的，是在高级层次上描述和定义系统的服务。
对于比较简单的问题，不必建立抽象系统模型。或者说，系统模型已经在分析人员头脑中形成，直接由分析人员写成规格说明。但对于比较复杂的问题，问题领域中各种关系比较复杂，仅有在头脑中想象的模型是不够的，必须建立适当的比较形式化的抽象系统模型，才能准确而全面地反映问题领域中各种复杂的要求。
不同类型的问题有不同的需要解决的中心问题，因而要建立不同类型的系统模型。对于数学软件，设计的中心问题是算法，软件人员的主要力量要花在对数学模型算法的考虑上。对于数据通信软件，设计的中心问题是数据传送和过程控制，实现算法简单，采用数据流模型比较合适。对于涉及大量数据的数据处理软件，设计的中心问题是数据处理，包括数据的采集、传送、存储、变换、输出等，一旦数据结构明确，与它相关的算法就很简单了，因此可以采用实体—关系模型。如果系统要求有数据库支持（通过数据库获取和存放信息），还需要考虑数据在数据库中的组织方式和存取方法，建立数据库模型。因此，在分析过程中，数据模型是首先要集中精力考虑的问题。
系统模型的建立是对现实世界中存在的有关实体和活动的抽象和细化，其建立过程包括观察分析、模型表示和模型检查3个阶段，如图2.5所示。
图2.5 系统模型的建立过程
首先，分析人员和用户合作，从各方面观察现实世界中的有关实体和活动，建立理解的共同基准，分清哪些概念与系统相关，必须纳入系统模型，哪些是系统模型不必关心的。分析人员和用户在共同理解的基础上，建立系统模型，包括系统提供的各种系统服务，模型表示的细节应有系统输入、系统输出、系统数据处理、系统控制等。
系统模型建立起来以后，还要进行检查。除静态检查之外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界系统观察得到的系统跟踪信息进行对照，检查模型是否符合要求。