第3章 需求分析
一、需求分析的相关概念
1．定义
需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答"系统必须做什么"这个问题，即对目标系统提出完整、准确、清晰、具体的要求。在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。
2．必要性
为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件，不论人们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发者带来烦恼。
3．准则
需求分析和规格说明是一项十分艰巨复杂的工作。用户与分析员之间需要沟通的内容非常多，在双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性。因此，不仅在整个需求分析过程中应该采用行之有效的通信技术，集中精力细致工作，而且必须严格审查验证需求分析的结果。进行需求分析必须遵循以下4条准则。
（1）必须理解并描述问题的信息域，根据这条准则应该建立数据模型。
（2）必须定义软件应完成的功能，这条准则要求建立功能模型。
（3）必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。
（4）必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。
二、需求分析的任务
1．确定对系统的综合要求
虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求。通常对软件系统有下述几方面的综合要求。
（1）功能需求
功能需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。
（2）性能需求
性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
（3）可靠性和可用性需求
可靠性需求定量地指定系统的可靠性；可用性与可靠性密切相关，它量化了用户可以使用系统的程度。
（4）出错处理需求
出错处理需求说明系统对环境错误应该怎样响应。在某些情况下，"出错处理"指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。人们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少。
注意：上述错误不是由该应用系统本身造成的。
（5）接口需求
接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。
（6）约束
设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。
（7）逆向需求
逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，应选取能澄清真实需求且可消除发生误解的逆向需求。
（8）将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴，但是将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。
2．分析系统的数据要求
（1）意义
任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌。因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。
（2）工具
分析系统的数据要求通常采用建立数据模型的方法。复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够形象直观。为了提高可理解性，常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和Warnier图。
（3）规范
软件系统经常使用各种长期保存的信息，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。
3．导出系统的逻辑模型
综合分析结果可以导出系统的详细的逻辑模型，通常用数据流图、实体联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
4．修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。
三、与用户沟通获取需求的方法
1．访谈
访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。
（1）基本形式
①正式访谈
系统分析员将提出一些事先准备好的具体问题。
②非正式访谈
分析员将提出一些用户可以自由回答的开放性问题，鼓励被访问人员说出自己的想法。
（2）技术方法
①调查表技术
当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。
②情景分析技术
a．概念
情景分析是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。系统分析员利用情景分析技术，往往能够获知用户的具体需求。
b．作用
第一，能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。
第二，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的唯一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。
2．面向数据流自顶向下求精
（1）定义
结构化分析方法是面向数据流自顶向下逐步求精进行需求分析的方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。
（2）原理
①通常从数据流图的输出端着手分析。输出数据是由哪些元素组成的呢？通过调查访问不难搞清这个问题。每个输出数据元素又是从哪里来的呢？沿数据流图从输出端往输入端回溯，应该能够确定每个数据元素的来源，与此同时也就初步定义了有关的算法。
②为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出这个数据元素需要用的算法，往往需要向用户和其他有关人员请教，他们的回答使分析员对目标系统的认识更深入更具体了，系统中更多的数据元素被划分出来了，更多的算法被搞清楚了。
③通常把分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO图中。通过分析而补充的数据流、数据存储和处理，应该添加到数据流图的适当位置上。
④请用户对分析过程中得出的结果仔细地复查，数据流图是帮助复查的极好工具。复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。
⑤对经过细化后得到的新数据流图的分析追踪可能产生新的问题，这些问题的答案可能又在数据字典中增加一些新条目，并且可能导致新的或精化的算法描述。随着分析过程的进展，经过提问和解答的反复循环，最终得到对系统数据和功能要求的满意了解。图3-1概括了上述分析过程。
图3-1 面向数据流自顶向下求精过程
3．简易的应用规格说明技术
（1）定义
简易的应用规格说明技术是一种面向团队的需求收集法。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。是信息系统领域使用的主流技术。
（2）应用过程
①进行初步的访谈并确定会议方案。
通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案。开发者和用户分别写出"产品需求"。选定会议的时间和地点，并选举一个负责主持会议的协调人。邀请开发者和用户双方组织的代表出席会议，并预先把写好的产品需求分发给每位与会者。
②进行会议准备
要求每位与会者提前认真审查产品需求，并且列出作为系统环境组成部分的对象、系统将产生的对象以及系统为了完成自己的功能将使用的对象。还要求每位与会者列出操作这些对象或与这些对象交互的服务。最后还应该列出约束条件和性能标准。
③开会讨论
a．讨论的第一个问题是，是否需要这个新产品，一旦确实需要这个新产品，每位与会者就应该把他们在会前准备好的列表展示出来供大家讨论。这个阶段严格禁止批评与争论。
b．共同创建一张组合列表。在组合列表中消去了冗余项，加入了在展示过程中产生的新想法，但并不删除任何实质性内容。由协调人主持讨论这些列表。组合列表将被缩短，加长或重新措辞。讨论的目标是，针对每个议题都创建出一张意见一致的列表。
c．一旦得出了意见一致的列表，就把与会者分成更小的小组，每个小组的工作目标是为每张列表中的项目制定小型规格说明。
d．每个小组都向全体与会者展示他们制定的小型规格说明。通过讨论可能会增加或删除一些内容，也可能进一步做些精化工作。
④会后总结并起草需求规格说明书
在完成了小型规格说明之后，每个与会者都制定出产品的一整套确认标准，并把自己制定的标准提交会议讨论，以创建出意见一致的确认标准。最后，由一名或多名与会者根据会议成果起草完整的软件需求规格说明书。
（3）优点
①开发者与用户不分彼此，齐心协力，密切合作；
②即时讨论并求精；有能导出规格说明的具体步骤。
4．快速建立软件原型
（1）定义
快速原型是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是，它应该实现用户看得见的功能，省略目标系统的"隐含"功能。快速建立软件原型是最准确、最有效、最强大的的需求分析技术。
（2）特性
①快速
快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该"做什么"这个问题上尽可能快地达成共识。因此，原型的某些缺陷是可以忽略的，只要这些缺陷不严重地损害原型的功能，不会使用户对产品的行为产生误解，就不必管它们。
②容易修改
如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户需求。在实际开发软件产品时，原型的"修改试用反馈"过程可能重复多遍，如果修改耗时过多，势必延误软件开发时间。
（3）使用的方法和工具。
①第四代技术
第四代技术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。第四代技术使得软件工程师能够快速地生成可执行的代码，因此，它们是较理想的快速原型工具。
②可重用的软件构件
使用一组已有的软件构件（组件）来装配原型。软件构件可以是数据结构（或数据库），或软件体系结构构件（程序），或过程构件（模块）。必须把软件构件设计成能在不知其内部工作细节的条件下重用。
注意：现有的软件可以被用作"新的或改进的"产品的原型。
③形式化规格说明和原型环境
在过去的20多年中，人们已经研究出许多形式化规格说明语言和工具，用于替代自然语言规格说明技术。交互式环境可以调用自动工具把基于形式语言的规格说明翻译成可执行的程序代码，用户能够使用可执行的原型代码去进一步精化形式化的规格说明。
四、分析建模与规格说明
1．分析建模
（1）模型
模型是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。模型由一组图形符号和组织这些符号的规则组成。
（2）建模过程
结构化分析实质上是一种创建模型的活动。为了开发出复杂的软件系统，系统分析员应该从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。
2．软件需求规格说明
软件需求规格说明书是需求分析阶段得出的最主要的文档。通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。自然语言的规格说明具有容易书写、容易理解的优点。
五、实体-联系图
1．数据模型的定义
为了把用户的数据要求清楚、准确地描述出来，通常建立一个概念性的数据模型（信息模型）。概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现方法无关。
2．数据模型的构成
数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。
（1）数据对象
①定义
数据对象是对软件必须理解的复合信息的抽象。复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物不是数据对象。
②特点
a．可以由一组属性来定义的实体都可以被认为是数据对象。
b．数据对象彼此间是有关联的。
c．数据对象只封装了数据而没有对施加于数据上的操作的引用，这也是数据对象与面向对象范型中的"类"或"对象"的显著区别。
（2）属性
属性定义了数据对象的性质。必须把一个或多个属性定义为"标识符"，即当希望找到数据对象的一个实例时，用标识符属性作为"关键字"（"键"）。应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。
（3）联系
数据对象彼此之间相互连接的方式称为联系，也称为关系。联系也可能有属性。联系可分为以下3种类型。
①一对一联系（1：1）
一个数据对象只能对应一个数据对象，例如，一个部门有一个经理，而每个经理只在一个部门任职。
②一对多联系（1：N）
一个数据对象可以同时对应多个数据对象，例如，某校教师与课程之间存在一对多的联系"教"，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。
③多对多联系（M：N）
两个数据对象之间的联系是多对多的。例如，学生与课程问的联系（"学"）是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。
3．实体---联系图的符号
（1）定义
使用实体联系图来建立数据模型。可以把实体---联系图简称为E---R图，把用E---R图描绘的数据模型称为E---R模型。
E---R图中包含了实体（数据对象）、关系和属性3种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体（或关系）的属性，并用直线把实体（或关系）与其属性连接起来。例如，图3-2是某学校教学管理的E---R图。
图3-2 某校教学管理E---R图
（2）优点
①E---R模型比较接近人的习惯思维方式；
②E---R模型使用简单的图形符号表达，便于用户理解。
六、数据规范化
（1）必要性
软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。
（2）范式特点
①通常用"范式"定义消除数据冗余的程度。第一范式数据冗余程度最大，第五范式数据冗余程度最小。
②范式级别越高，存储同样数据就要分解成更多张表，"存储自身"的过程也就越复杂。
③随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，故在需求变化时数据的稳定性较差。
④范式级别提高则需要访问的表增多，因此性能将下降。一般选用第三范式都比较恰当。
（3）各范式的定义。
①第一范式每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
②第二范式满足第一范式条件，而且每个非关键字属性都由整个关键字决定。
③第三范式符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述，即一个非关键字属性值不依赖于另一个非关键字属性值。
七、状态转换图
1．定义
状态转换图（状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图还提供了行为建模机制，指明了作为特定事件的结果系统将做哪些动作。
2．状态
（1）定义
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个（或一系列）动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。
（2）分类
状态主要有：初态（初始状态）、终态（最终状态）和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。
（3）表示
状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。
①描绘循环运行过程：通常并不关心循环是怎样启动的。
②描绘单程生命期：需要标明初始状态和最终状态。
3．事件
事件是在某个特定时刻发生的事情，它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统做动作或（和）转换状态的控制信息。
4．状态图的符号
（1）符号的表示方法
①初态：用实心圆表示。
②终态：用一对同心圆（内圆为实心圆）表示。
③中间状态：用圆角矩形表示。可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，下面部分是活动表。
（2）组成部分
图3-3给出了状态图中使用的主要组成部分和符号表示。
图3-3 状态图中使用的主要符号
①活动表
活动表的语法格式如下：
事件名（参数表）／动作表达式
其中，"事件名"可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry，exit和do。entry事件指定进入该状态的动作；exit事件指定退出该状态的动作；do事件则指定在该状态下的动作。需要时可以为事件指定参数表，活动表中的动作表达式描述应做的具体动作。
②状态转换
状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
③事件表达式
事件表达式的语法如下：
事件说明[守卫条件]／动作表达式
其中，事件说明的语法为：事件名（参数表）。守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。动作表达式是一个过程表达式，当状态转换开始时执行该表达式。
5．实例分析
图3-4是电话系统的状态图。图中表明，没有人打电话时电话处于闲置状态；有人拿起听筒则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；这时如果拿起听筒的人改变主意不想扣了，他把听筒放下（挂断），电话重又回到闲置状态；如果拿起听筒很长时间不拨号（超时），则进入超时状态。
图3-4 电话系统的状态图
八、其他图形工具
1．层次方框图
（1）定义
层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素。
（2）实例分析
例如，描绘一家计算机公司全部产品的数据结构可以用图3-5中的层次方框图表示。这家公司的产品由硬件、软件和服务3类产品组成，软件产品又分为系统软件和应用软件，系统软件又进一步分为操作系统、编译程序和软件工具等。
图3-5 层次方框图的一个例子
（3）特点
随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，这种模式非常适合于需求分析阶段的需要。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。
2.Warnier图
（1）定义
Warnier图是法国计算机科学家Warnier提出的表示信息层次结构的另外一种图像工具，它用树形结构描绘信息，可以表明信息的逻辑组织，即可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的，它比层次方框图提供了更丰富的描绘手段。
（2）实例分析
图3-6是用Warnier图描绘一类软件产品的例子。图中花括号用来区分数据结构的层次，在一个花括号内的所有名字都属于同一类信息；异或符号（+）表明一类信息或一个数据元素在一定条件下才出现，而且在这个符号上、下方的两个名字所代表的数据只能出现一个；在一个名字下面（或右边）的圆括号中的数字指明了这个名字代表的信息类（或元素）在这个数据结构中重复出现的次数。
图中表示了一种软件产品要么是系统软件要么是应用软件。系统软件中有P1种操作系统，P2种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，图中标出了每种软件工具的数量。
图3-6 Warnier图的一个例子
3.IPO图
（1）定义
IPO图是输入、处理、输出图的简称，它是由美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。
（2）用法
IPO图的基本形式是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。处理框中列出处理的次序暗示了执行的顺序。在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。图3-7是一个主文件更新的例子。
图3-7 IPO图的一个例子
（3）改进的IPO图
改进的IPO图（IPO表）中包含某些附加的信息。如图3-8所示，改进的IPO图中包含的附加信息主要有系统名称、图的作者，完成的日期，本图描述的模块的名字，模块在层次图中的编号，调用本模块的模块清单，本模块调用的模块的清单，注释，以及本模块使用的局部数据元素等。在需求分析阶段可以使用IPO图简略地描述系统的主要算法。
图3-8 改进的IPO图的形式
（4）优点
①IPO图使用的基本符号既少又简单，易于掌握。
②可以在软件设计阶段修正IPO图。
九、验证软件需求
1．验证软件需求的正确性
（1）验证需求正确性的目的
需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15％的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。
（2）进行验证的四个方面
①一致性
所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
②完整性
需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
③现实性
指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
④有效性
必须证明需求是正确有效的，确实能解决用户面对的问题。
2．验证软件需求的方法
（1）验证需求的一致性
当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性，从而能有效地保证软件需求的一致性。
（2）验证需求的现实性
为了验证需求的现实性，应该参照以往开发类似系统的经验，分折用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。
（3）验证需求的完整性和有效性
只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要，即需求的有效性，只有在用户的密切合作下才能完成。采用原型系统的方法来进行验证。用户通过试用原型系统，也能获得许多宝贵的经验，从而可以提出更符合实际的要求。在快速建立原型系统时，可以适当降低对接口、可靠性和程序质量的要求，以及省掉许多文档资料方面的工作，从而可以大大降低原型系统的开发成本。
3．用于需求分析的软件工具
（1）要求
为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。这类软件工具应该满足下列要求。
①必须有形式化的语法（或表），因此可以用计算机自动处理使用这种语法说明的内容。
②使用这个软件工具能够导出详细的文档。
③必须提供分析（测试）规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果。
④使用这个软件工具之后，应该能够改进通信状况。
（2）PSL/PSA系统
①定义
PSL是用来描述系统的形式语言，PSA是处理PSL描述的分析程序。用PSL描述的系统属性放在一个数据库中。一旦建立起数据库之后即可增加信息、删除信息或修改信息，并且保持信息的一致性。PSA对数据库进行处理以产生各种报告，测试不一致性或遗漏，并且生成文档资料。
②功能
a．描述任何应用领域的信息系统；
b．创建一个数据库保存对该信息系统的描述符；
c．对描述符施加增加、删除和更改等操作；
d．产生格式化的文档和关于规格说明书的各种分析报告。
③优点
a．改进了文档质量，能保证文档具有完整性、一致性和无二义性，从而可以减少管理和维护的费用；
b．数据存放在数据库中，便于增加、删除和更改。