《软件工程实践与项目管理》课件第4章

4.1需求分析的目标

4.2需求分析的任务

4.3需求分析的步骤4.4数据流图

4.5设计数据字典4.6“需求分析报告”的书写格式4.7高质量的“需求分析报告”应具备的特性4.8需求评审实例

4.9实例：“某省电信集团公司资金管理系统需求分析报告”本章小结

习题

第4章软件需求分析4.1需求分析的目标软件需求分析的基本目的是确定系统必须完成什么工作，也就是对目标系统提出完整、准确、清晰、具体的要求。软件需求分析建立在软件可行性报告基础上，项目分析员通过与用户密切合作、充分交流、完整准确地理解项目中用户信息及信息的处理过程，详细了解用户需求，最终写出用户认可的需求分析报告。为此，软件需求分析人员应该具备如下能力：

(1)具备系统的硬件和软件的应用能力；

(2)具备良好的书面和口头形式进行讨论和交换意见的沟通能力；

(3)具备“既能看到树木，又能看到森林”的洞察能力。4.2需求分析的任务软件需求分析阶段的任务包括：分析系统的信息和数据要求，确定系统的综合要求，使用数据流图和数据字典导出目标系统的逻辑模型，修正系统开发计划，开发原型系统。

1．分析系统的信息和数据要求

1)分析系统的信息要求系统的信息要求分析主要围绕以下几方面进行：

(1)信息内容和关系。信息内容包括单个数据和控制对象。

(2)信息流。信息流是系统中数据和控制的流向。

(3)信息结构。信息结构指不同的数据和控制项的内部结构。

2)分析数据要求任何一个软件系统本质上都是一个数据处理系统，都包括数据的输入、处理与输出过程，因此，软件需求分析阶段必须考虑数据和数据处理方面的有关问题，即弄清系统涉及哪些数据、数据间的联系、数据性质、数据结构，数据处理的类型、数据处理的逻辑功能等。

2.确定系统的综合要求系统的综合要求包括如下几个方面：

(1)系统功能要求。系统的功能要求是系统最主要的需求，它确定了系统必须完成的功能。

(2)系统性能要求。性能要求包括可靠性、联机系统的响应时间、存储容量、安全性等，应该根据具体系统而定。

(3)系统运行要求。运行要求指系统运行的环境要求，如系统软件、数据库管理系统软件、外存和数据通信接口等。

(4)系统扩充要求。对将来可能提出的系统扩充及修改要求作准备。

3．导出目标系统的逻辑模型在分析完系统的功能需求后，应该建立目标的逻辑模型。逻辑模型的主要任务是建立系统的数据字典、实体关系图(即E-R图)、状态转换图、数据流图。如图4-1所示。图4-1需求分析模型结构图具体分析如下：

(1)数据描述。数据描述主要利用实体关系图(E-R图)和数据字典来描述。

E-R图中的基本图形符号如表4-1所示。表4-1E-R图的基本图形符号及含义现以“课程管理系统”为例，来说明教师、课程、学生之间的实体关系。如图4-2所示。图4-2课程管理系统实体关系图关于数据字典的设计在本章节后面部分将作详细介绍。

(2)控制描述。控制描述主要使用状态转换图来表示。状态图是是用来说明事物的状态、事件和它们之间的关系的。状态图由状态组成，各状态由转移链接在一起。状态是对象执行某项活动或等待某个事件时的条件。关于状态图的设计详细介绍见第6章。

(3)处理描述。处理描述主要使用数据流图和数据字典来表示。关于数据流图的设计也将在本章节后面部分作详细介绍。

4.修正系统开发计划修正系统开发计划是根据分析过程中获得的对软件需求更深入、更具体的认识，对目标系统的成本及进度进行更准确的估算，从而对系统开发计划进一步进行修正。

5.开发原型系统一般地，在一种新产品投产之前，通常先制造一个“样机”，试机成功后再进行批量生产。原型化系统开发思想是从“样机”中借鉴过来的，即在目标系统开发之前，先构造一个原型系统，以便通过较少的投入和较短的时间，让用户尽快感受到目标系统的主要功能，用户也可以通过对原型系统的了解更准确地提出和确定对所开发的软件的要求。4.3需求分析的步骤软件需求分析阶段的工作可以分为以下五个部分：获取项目需求，分析与综合，编制需求分析文档，综合评审，管理需求变更。

1.获取项目需求项目需求包括下面几个方面的内容：

(1)功能需求。功能需求指所开发的目标系统应该完成什么功能，是最主要的需求。

(2)性能需求。性能需求给出目标系统的技术性能指标，包括存储容量限制、响应速度限制等。

(3)环境需求。目标系统运行时对运行环境的要求。例如在硬件方面，对机型、外部设备、数据通信接口等的要求。在软件方面，对支持目标系统运行的系统软件(操作系统、网络软件、数据库管理系统等)的要求。在使用方面，对使用部门的制度及其操作人员的技术水平的要求等。

(4)可靠性需求。不同软件运行时，失效的影响不同。在需求分析时应按实际的运行环境对目标系统运行时发生故障的概率提出要求。对于重要系统，或是运行失效会造成严重后果的系统，应提出较高的可靠性需求。

(5)安全保密需求。不同的用户对系统的安全、保密的要求也不尽相同。应当对用户这方面的需求恰当地作出规定，以便对待开发系统进行特殊的设计，使其满足用户对安全保密性方面的要求。

(6)用户界面需求。如果软件具有友好的用户界面，用户就能够方便、有效、愉快地使用该软件。从市场角度看，具有友好用户界面的软件系统具有较强的竞争力。因此，在需求分析时，必须对细致地规定用户界面应达到的标准。

(7)资源使用需求。这是指目标系统运行时对数据、软件、内存空间等各项资源的要求。另外，软件系统开发时所需要的人力、支撑软件、开发设备等都属于软件开发的资源，需要在需求分析时加以确定。

(8)软件成本消耗与开发进度需求。在软件项目立项后，要根据合同规定，对软件开发的进度和各步骤的费用提出要求，以作为开发管理的依据，并预先估计以后系统可能达到的目标。这样，在开发过程中，可以为系统将来的扩充与修改做好准备。一旦有扩充或修改需要时，就比较容易进行补充和修改。获取项目需求唯一和最好的方法是深入现场(带上录音笔和调研问题列表，见表4-2)，倾听用户对目标系统的要求。系统分析员绝不能坐在办公室凭空想象用户的需求而进行“闭门造车”。表4-2调研问题列表与用户沟通交流的方式有会议、电话、电子邮件、小组讨论、模拟演示(或场景表演)等。与用户的每一次交流都一定要有记录(或录音)，交流的结果还应该进行分类，以便后续的分析活动。例如，可以将需求细分为功能需求、非功能需求(如响应时间、平均无故障工作时间、自动恢复时间等)、环境限制、设计约束等类型。

2.分析与综合分析与综合是需求分析阶段的第二步工作，系统分析员需要从信息流和信息结构出发，逐步细化软件的所有功能，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求、是否合理，并依据功能、性能、运行环境等需求，最终制定出系统的解决方案和目标系统的详细逻辑模型。分析与综合工作要反复地进行，直到分析人员与用户双方对系统的解决方案和目标系统的详细逻辑模型都无异议为止。

3.编制需求分析文档对在分析与综合过程中已经确定了的需求应当用文字清晰准确地进行描述，形成需求分析文档。这些文档应作为软件文档存档，需求分析文档通常由以下四部分构成：

(1)软件需求规格说明书：主要描述目标系统的概貌、功能需求、性能需求、数据需求(主要包括数据字典、数据流图等)、运行需求和将来可能的扩充需求。

(2)初步的用户手册：主要包括系统的使用步骤和方法等。

(3)软件开发实施计划。

4.综合评审综合评审是需求分析阶段工作的复查手段，综合评审过程中，要对系统各项需求的正确性、完整性和清晰性给予评价。在需求评审中主要评审以下内容：

(1)设计方案的正确性、先进性和经济性；

(2)系统组成、系统要求及系统内部接口的合理性；

(3)系统外部接口的合理性；

(4)采用的设计准则、规范和标准的合理性；

(5)系统可靠性、可维护性、安全性等要求是否合理；

(6)关键技术的落实情况；

(7)编制的质量保证计划是否可行。

5.需求变更在开发的过程中，需求的变更是不可避免的，软件系统在设计、编码以及测试的任何阶段都可能发生需求变更。如何以可控的方式管理软件的需求变更，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着需求分析过程没有得到充分的执行。所以需求管理要保证需求分析的各个活动都得到了充分的执行，以求得到正确的需求。为了保证软件开发的顺利进行，对软件系统需求的变更要按照流程进行严格管理，如图4-3所示。图4-3需求变更流程首先进行变更发起。变更的发起者可以是用户，也可以是开发方。用户或者开发方在开发过程感到某些地方不满意时，都可以发起变更要求。在考虑是否提出需求变更时，建议遵循如下原则：

(1)减少频繁变更。不要轻易进行需求变更。

(2)处理过程规范化。如果确实需要变更，必须首先写出“变更申请书”书面申请，经过项目组讨论确定之后才可以实施变更。在用户向项目组递交“变更申请书”后，项目组要进行需求变更的影响分析和评价，评价的结果可能是批准，也可能是拒绝“变更申请书”的变更。如果批准变更，有可能要对项目的计划进度或人员等进行相应变更，所以要进行重新计划。最后，是执行相应的变更计划。4.4数据流图数据流图(DataFlowDiagram，DFD)是描述系统的逻辑模型的主要形式。它不涉及硬件、软件、数据结构与文件组织，与系统的物理描述无关，只是用一种图形及与此相关的注释来表示系统的逻辑功能，即所开发的系统在信息处理方面“要做什么”。由于图形描述简明、清晰，不涉及到技术细节，所描述的内容是面向用户的，即使完全不懂信息技术的用户单位的人员也容易理解，因此数据流图是系统分析人员与用户之间进行交流的有效手段，也是系统设计(即建立所开发的系统的物理模型)的主要依据之一。

1．数据流图使用的符号数据流图中有四种基本元素，其符号表示如图4-4所示。图4-4数据流图的基本符号

(1)描述一个源点或终点。其中注明源点或终点的名称。

(2)描述一个变换数据的处理。输入数据在此进行变换产生输出数据。其中注明处理的名称。

(3)描述一个数据存储。通常用于代表一个数据表，其中注明数据表的名称。

(4)描述一个数据流。被加工的数据及其流向。流线上注明数据名称，箭头代表数据流动方向。注意，数据流与程序流程图的画法不能混淆。在数据流图中只有“数据源(或称做外部项)、数据处理(或称做加工)、数据存储、数据流”这四种图形元素，不能随意创造任何其他图形符号。一个数据存储并不等同于一个文件，它可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等。数据流由一个或一组确定的数据组成。数据流的表示应该注意以下事项：

(1)数据流名应能直观地反映数据流的含义。

(2)数据流的流向。

(3)数据流可以同名，也可以有相同的数据结构，但不同的数据具有不同的含义。

(4)两个符号(加工、外部项、数据存储)之间可以有多个数据流存在。

(5)避免错误的数据流命名方法。

(6)当数据存储需要重复时，为了避免可能引起的误解，如果代表同一个事物的相同符号在图中出现在n个地方，则在这个符号的一个角上画n-1条短斜线做标记。加工又称处理(亦称变换)，它表示对数据流的操作。加工的符号分成上、下两部分，从上到下分别是标识部分和功能描述部分(见后面的图4-7所示)。标识部分用于标注加工编号，以“P”开头；功能描述部分用来写加工名。数据源点和终点(又称端点)是系统外的实体，称做外部项。它们存在于环境之中，与系统有信息交流，从源点到系统的信息叫系统的输入；从系统到终点的信息称系统的输出。同一个端点可以是人或其他系统。在数据流图中引入源点和终点是为了便于理解系统，所以不需要详细描述它们，但可以有编号。

如果数据源点和终点相同，可以只用一个符号代表数据的源点和终点，这样至少将有两个箭头和这个符号相连(一个进一个出)。另一种表示方法是再画一个同样的符号表示数据的终点(见后面的图4-7所示)。

2．绘制数据流图的步骤绘制数据流图过程示意如图4-5所示。

图4-5绘制数据流图过程示意图具体绘制步骤如下：

(1)确定所开发的系统的外部项(外部实体)，即系统的数据来源和去处。

(2)确定整个系统的输入数据流和输出数据流，把系统作为一个加工环节，画出关联图。

(3)确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节(子系统)确定每个加工的输入与输出数据流以及与这些加工有关的数据存储。

(4)根据自顶向下，逐层分解的原则，对上层图中全部或部分加工环节进行分解。

(5)重复步骤(4)，直到逐层分解结束。

(6)对图进行检查和合理布局，主要检查分解是否恰当、彻底，数据流图中各层是否有遗漏、重复、冲突之处，命名、编号是否确切和合理，对错误与不当之处进行修改。

(7)与用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。

3．数据流图举例下面以储户到银行取款的过程为例来分析绘制数据流图的步骤，其过程描述如下：首先储户填好取款单，然后把取款单和存折一起交给银行柜台人员。银行柜台人员做如下处理：

(1)审核存折是否合格，取款金额是否有效，如果不合格或无效，将储户的存折、取款单退回储户。

(2)如果上述两个条件都验证成功，则进行取款并修改账目，然后将存折及现金交给储户，同时将取款单存档。该业务过程的数据流图描述如下：

(1)画出顶层的数据流图—银行取款处理数据流图(如图4-6所示)。图4-6银行取款处理顶层数据流图

(2)逐层分解加工，画出下层数据流图，即取款的第2层数据流图(如图4-7所示)。图4-7取款的第2层数据流图

4.课堂练习绘出如下所述系统的数据流图。书店向顾客发放订单，顾客将所填订单交由系统处理。系统首先依据图书目录对订单进行检查并对合格订单进行处理，处理过程中根据顾客情况和订单数目将订单分为优先订单与正常订单两种：随时处理优先订单、定期处理正常订单。最后系统根据所处理的订单汇总，并按出版社要求发给出版社。4.5设计数据字典

1．数据字典的内容数据字典一般包括以下五类元素(或条目)。

1)数据流在一个数据流图中，数据以数据流为单位进行传输。其主要内容为：编号：数据流名称：说明(简要介绍作用及其产生的原因和结果)：数据流来源：数据流去向：数据流组成：2)数据元素(数据项)数据元素也称数据项，是数据的最小单位。其主要内容为：编号：数据元素名称：类型：长度：取值范围：数据结构：3)数据存储数据存储是数据保留或保存的地方。其主要内容为：编号：数据存储名称：简述(存放的是什么数据)：输入数据：输出数据：数据存储组成：存储方式(查询、更新、关键码)：4)处理(加工)处理就是一个处理过程，其主要内容为：编号：P1处理名称：简要描述(功能简述)：输入数据流：输出数据流：处理逻辑(处理算法、处理顺序)：5)外部实体(数据源和数据终点)外部实体是系统的“人—机”界面。数据流由外部实体流入，又从系统向外部实体流出。其主要内容为：编号：外部实体名称：简要描述：从外部实体输入：向外部实体输出：2.举例现以图4-7为例，来设计有关的数据字典。数据字典如下：1)数据流编号：F2数据流名称：存折和现金说明：本数据流是经“取款处理”后的结果数据流来源：取款处理数据流去向：储户数据流组成：存折 = 存折号 + 开户行名称 + 户名 + 交易金额 + 交易日期 + 余额 + 操作人 + 复核人

2)数据存储编号：D1数据存储名称：账目记录简述：主要存储有关账户信息。输入数据：客户取款后更新账务数据。输出数据：用于款项更新、打印和账务查询。数据存储组成：账目数据=操作日期+贷记方+借记方+余额+操作人+复核人3)处理编号：P1处理名称：取款审核简要描述：审核账户是否本行账户、取款金额是否小于存折余额。输入数据流：F1输出数据流：F1.1，F1.24)外部实体(数据源)编号：S1数据源名称：储户简要描述：拿存折和取款单取款。从数据源输入：客户提供取款金额等信息。

3.总结数据流图只描述了系统的“分解”，并没有表达图中的数据、处理等具体含义。对数据流图上各项目含义的不同理解将对以后的开发和维护工作造成不便。数据字典是对数据流图中的所有数据、处理等进行精确定义。数据流图和数据字典共同构成系统的逻辑模型。数据字典是需求分析阶段的工具，数据字典最重要的用途是用户通过它可以清楚地了解分析员对系统数据和处理的详细说明。不同的开发人员或不同的开发小组之间可以通过数据字典对数据的理解达成一致，从而避免定义混乱。数据字典对处理的描述也是很有价值的，如果改变了某个数据的定义，就会对处理产生相应影响。数据字典也是下一步设计的依据，如果所有开发人员都根据数据字典的定义去设计模块，则能避免许多麻烦的接口问题。

4.课堂练习在学生学籍管理系统中，学生首先拿录取通知书和身份证到校报到，登记并注册，然后进行体检。体检合格后，为学生分配宿舍；不合格则拒绝报到注册和登记。请完成如下任务：

(1)画出上述数据流图。

(2)写出数据字典。4.6“需求分析报告”的书写格式下面给出“需求分析报告”的书写格式以供参考。

1．目的和对象阐明编写需求说明书的目的，指明读者对象

2．项目背景描述

(1)项目的委托单位、开发单位和主管部门；

(2)该软件系统与其他系统的关系，描述本项目的适用场合及业务处理情况；

(3)项目名称：本项目的名称，包括项目的全名、简称、代号、版本号；

(4)名词定义：列出文档中用到的专门术语的定义和缩写词的原文，对重要的或是具有特殊意义的名词进行定义；

(5)调研情况介绍：描述主要的调研活动及对象。

3．用户情况

1)用户特点介绍本项目用户(或潜在用户)的情况，包括：

(1)用户的组织结构及职责；

(2)用户的技术水平。

2)业务工作流程

(1)业务工作流程图：画出用户业务流程图；

(2)业务情况描述：描述用户工作中每个业务情境；

(3)用户原有系统的情况：介绍用户现在使用的软件系统的主要功能。

4.任务概述

1)目标阐明本项目所需达到的目的。

2)作用范围以及其他应向读者说明的有关该软件开发的背景解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点即可。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。

5．运行环境

1)硬件环境详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其他特殊设备。

2)软件环境包括操作系统、网络软件、数据库系统以及其他特殊软件要求。

3)条件与限制说明本软件产品在实现时所必须满足的条件和所受的限制，以及相应的原因。必须满足的条件包括输入数据的范围以及格式，所受的限制包括软件环境、硬件环境等方面的内容。

4)主要特点说明本软件产品与同类产品相比的特点，如卖点(仅限于自主产品)。

6．功能需求与功能分析

1)功能划分从用户的角度将产品按功能划分成不同的部分，但这些部分并不对应于最终程序实现时的功能模块。

2)功能描述细化由功能划分所生成的各部分的内容，应包括下列内容：

(1)必须完成的功能以及对此功能的详细描述：按功能类型分类，逐条列出本软件所能完成的各项功能以及对此功能的详细描述；

(2)不支持的功能以及相应的原因：列出本软件所不支持的各项功能以及相应的原因。此部分内容务必详细准确、无二义性，以作为将来验收和测试的标准。用列表的方式逐项定量和定性地叙述对软件所提出的功能要求，说明软件可支持的终端数和可支持的并行操作的用户数。

7．需求分析

1)用户需求用例分析画出业务系统的UML用例图。给出业务的角色和用例对应关系。

2)业务系统的活动图描述业务系统的UML活动图。

3)功能分析从系统分析角度介绍采用什么新技术，采用哪种对策来解决将来出现或可能出现的问题。

(1)按照业务需求或功能特性画出系统结构图；

(2)采用逐步求精方法分解系统功能结构，画出各子系统的功能结构图，并进行文字描述。

8．数据描述

1)静态数据静态数据指长时间不发生改变或临时存储的数据。例如身份证号码等。

2)动态数据动态数据指经常发生改变的数据。

3)外部数据信号、文件、数据库等数据的处理和输入规定。

4)输入/输出数据说明输入/输出数据的类型及格式。

5)数据流图从数据传递和加工的角度描述系统的数据流图(此数据流图不包含任何有关实现的内容，只是从最上层对有关内容加以描述)。

6)数据词典对数据流图中出现所有被命名的图形元素(数据的源点/终点、数据流、数据存储、数据处理)在数据词典中加以定义，使得每一个图形元素的名字都有一个确切的解释。

9．性能需求

1)数据精确度根据实际情况，确定产品最终输出数据(包括传输中)的数据精确度。

2)时间特性说明产品(尤其是交互式产品)在响应时间、更新处理时间、数据转换与传输时间、运行时间等方面所需达到的时间特性。

3)适应性

(1)复用性。说明本产品是否可以复用已有软件或最终产品是否可为其他产品复用。

(2)灵活性。说明在运行环境、与其他软件的接口以及开发计划等发生变化时，具有的适应能力。如：操作方式上的变化，运行环境的变化，同其他软件的接口的变化，精度和有效时限的变化，计划的变化或改进。对于为了提供这些灵活性而进行专门设计的部分应该加以标明。

10．运行需求

1)用户界面说明本产品的人机界面风格。如屏幕格式、报表格式、菜单格式、输入/输出格式等。

2)硬件接口说明该产品与硬件之间各接口的逻辑特点及运行该软件的硬件设备特征。列出运行该软件所需要的硬件设备。说明其中的新型设备及其专门功能，包括：处理器型号及内存容量；外存容量；媒体及其存储格式；设备的型号及数量；输入及输出设备的型号和数量；数据通信设备的型号和数量；其他专用硬件。

3)软件接口列出系统的支撑软件(包括中间件)，列出用到的操作系统、开发环境、数据库和测试软件等。说明该产品与其他软件之间接口，对于涉及到的软件产品应指出规格说明、版本号等。

4)故障处理列出可能出现的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。说明本产品在健壮性方面所能达到的目标。

11．不确定的问题说明目前尚未确定的问题及处理的计划。

12．风险分析说明本项目面临的主要风险。例如：时间进度风险、人力资源风险等。

13．其他需求其他需求如易用性、安全保密性、可维护性、可移植性等。

14．同类产品简介(限自主产品)描述同类产品的特点，如工作流程、运行环境、限制条件等。

15．用户手册提交初步用户操作手册(或软件使用说明书)。

16．编写人员及编写日期列出参与编写的人员的名字及编写日期和版本号等，并标明项目负责人。

17．参考资料

(1)项目经核准的计划任务书、合同或上级机关的批文；

(2)文档所引用的资料、标准和规范等。列出这些资料的作者、标题、编号、发表日期、出版单位等。4.7高质量的“需求分析报告”应具备的特性编写一个高质量的“需求分析报告”应该具有以下五个特性：

1.正确性每个需求必须精确地描述要交付的功能。需求的正确性取决于是否反映了用户的真正意图。

2.可行性在已知的能力、有限的系统及其环境中，每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段必须有技术人员参与。

3.优先级对用户需求进行优先排队，并指出具体的产品版本中优先实现的需求。

4．明确性需求叙述对于多个读者应能达成共识。要避免使用一些对于读者不清楚的主观词汇或形容词，如用户友好性、轻易、简单、快速、有效、几个、艺术级、改善的、最大、最小等。每写一个需求都应简洁、直观，并采用用户熟知的术语，不要采用计算机术语。

5.可验证性可以使用测试手段验证产品中每个需求是否正确地实现。编写优秀的需求分析报告是没有公式可循的。这里给出编写高质量需求分析报告的建议：

(1)句子和段落要简短。采用主动语气。使用正确的语法、拼写和标点。使用术语要保持一致性，并在术语表或数据字典中定义。

(2)换位思考。要看需求是否被有效定义，要和用户进行换位思考。

(3)需求的细化和合并。努力正确地把握细化程度。可以考虑将多个比较小的需求合并为一个大的需求。

(4)需求中的定义要一致。需求分析报告的术语在定义上要保持一致。4.8需求评审实例

1.任务描述给出如下几个需求描述，请对这些描述进行评审：

(1)描述1：“软件系统应在不少于每60秒的正常周期内提供状态信息”。

(2)描述2：“软件系统应瞬间在显示和隐藏不可打印字符间切换”。

(3)描述3：“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。

(4)描述4：“假如可能，主管号码应该通过联机校验，而不是通过全体主管号码列表进行校验”。

2.任务分析

1)对于“描述1”的分析“描述1”描述的需求含义不明确，表现在以下四点：

(1)未给出状态信息定义；

(2)也未说明信息如何显示给用户；

(3)“软件系统”范围太大，没有具体指明产品的哪个部分；

(4)“不少于每60秒”是个不确定值。

【课堂练习】按照下面的提示重新编写描述1：

(1)明确系统状态信息；

(2)后台服务器以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息；

(3)假如后台进程处理正常，那么应该显示任务已完成的百分比；

(4)任务完成时应显示相关的信息；

(5)后台任务出错应该显示错误信息。

2)对于“描述2”的分析“描述2”描述的需求含义不明确，表现在以下三点：

(1)“瞬间”含义不明确；

(2)没有声明触发状态切换的条件；

(3)需求的不可证实性。对于“不可打印字符”和“隐藏字符”没有定义。我们可以这样更改一下“描述2”：“用户能够在一个特定触发条件下，对显示文档中所有Html标记与隐藏文档中所有Html标记进行切换”。现在很清楚，不可打印字符是HTML标记。

3)对于“描述3”的分析这个需求无法验证，表现在：

(1)单词“快速”是个(形容词)模糊词。

(2)错误报告所包含的内容不明确。我们可以这样更改一下“描述3”的描述：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。假如没有错误，就不会产生错误报告”。这样，出错报告包含的内容就清楚了。

4)对于“描述4”的分析这个需求描述不明确，表现在：

(1)“假如可能”很模糊。

(2)“应该”是一个不确切的词，没有指明用户是否需要这个功能。我们可以这样更改一下描述4：“系统必须通过联机的方法校验输入的主管号码而不能通过全体主管号码列表来效验输入的主管号码。”4.9实例：某省电信集团公司资金管理

系统需求分析报告

1.目的和对象(略)

2.用户特点

(1)本系统适用于大型集团企业和事业单位，用户具有较高的文化素质和计算机操作水平。

(2)集团公司有多个子公司，其子公司的财务管理是独立的，并建立了相应的财务管理系统。

3.任务概述国家对各企、事业单位的资金监控已成为整顿和规范市场经济秩序、有效防范和严惩经济犯罪的有效手段，而对于集团企业来说，对内部及下属单位实行资金监控更是尤为必要。实现集团资金监控是一个系统工程，它需要集团企业总部、子公司(或成员单位)和银行三者间的紧密联系。

(1)集团总部需要掌握子公司资金的使用情况，如现金、银行存款、应收应付账款、应收应付票据、其他货币资金等，通过各单位资金流入与流出情况，深入了解和掌握各子公司的生产经营活动是否正常、投入产出是否合理、经济效益是否显著、偿债能力是否足够、货币回笼是否正常等等。

(2)集团还需要与商业银行间建立一个外部的资金信息接口处理系统，通过银行信息及时反映出子公司的资金现状和流向，如收款单位名称、金额、付款时间等真实、详细资料,这样才能做到真正意义上的资金监控。此系统达到的目的如下：

(1)由于公司的资金大部分是由集团公司调拨的，子公司在月初需向集团公司汇报上个月的资金使用情况。

(2)对子公司的资金查询(实时余额和明细、历史余额和明细)。集团公司需要及时掌握子公司货币资金的使用情况，包括现金、银行存款、应收应付账款、其他应付款、应收应付票据、其他货币资金等；资金监控系统主要分成日记账查询、明细账查询、汇总信息查询、现金流量查询等。

(3)对子公司货币资金的使用情况进行全面监控，可按日、月、年查询，并提供报警功能，自动提示不合理的凭证和超出资金使用限额的公司。监控的范围包括现金、银行存款、应收应付账款、其他应付款、应收应付票据、其他货币资金、现金流量等。

(4)方便性。信息查询、打印和系统维护全部通过Web方式实现，不论系统使用者在本地还是在外地都可以及时掌握相关的信息。

(5)实时性。当日即可掌握子公司以前任一天的资金使用信息，而不用等到下个月月初。

(6)安全性。通过用户密码和数据加密的方式保证系统的安全，而且不同级别的用户看到的信息也不一样。

4.功能需求本系统建立在集团公司现有财务系统基础之上，可实时监控子公司货币资金的使用情况，避免资金的违规挪用，提高了资金的管理水平。系统功能如下：

(1)收入上划。把收款全部或者部分上划到总公司的收款账号。

(2)资金下拨。当子公司需要付款时，总公司拨款到子公司的支出账号。

(3)银企对账。实现银行和企业的实时对账。

(4)综合查询。对于收入上划、资金下拨提供综合查询，其条件有：时间段、分公司类别、分公司、银行、收入、支出、专款等。

(5)分公司银行账户明细库查询。

(6)分公司银行账户余额查询统计。

(7)分公司结算明细查询统计。

(8)银行数据的接收。

(9)数据(收入/支出)统计分析。

(10)与企业应收应付/其他账务系统的无缝对接。

(11)资金头寸调拨。

(12)定期存款到期的预警功能。因此，本系统设计为几个应用组成部分：

(1)资金监控查询系统：查询各银行账户的基本信息，当日明细、历史明细、当天余额、历史余额、上划款及下拨款等信息，可按地区、银行、账号性质、日期等组合查询各公司在银行的资金使用状况，并以图形方式直观显示；可通过发生明细的对方单位、账号信息对款项进行有效的跟踪。

(2)银行数据接收系统：实时与各家银行进行通信，向银行发送数据请求，接收银行信息，并将银行信息处理成本系统可识别的有效数据。不同的银行将采用不同的接口形式进行通信、接收数据。然后让公用接收处理模块对各家银行所接收的数据进行统一处理成本系统的合法数据。

(3)网上实时付款系统。实时扫描终端发出的付款指令，将付款指令按与各银行协定的数据接口发往银行，以快速有效的方式实现母公司向子公司的拨款支付等功能。

(4)资金结算处理系统。用户在本系统中录入电子付款指令后，经相关人员审批电子指令后，把资金从其账户中划转至付款接口子系统，同时本子系统进行相应的账务处理。

(5)银行对账处理系统：它以本账务处理系统所记的账为基本数据与银行提供的对账信息进行对账，其对账结果以银行存款余额调节表反映。

5.功能分析为了达到以上目标，采用收支两条线的管理方法是一个行之有效的方法。这种方法是：把资金账户分为收入和支出两个账户管理，收到的金额都存入收入账户，支出金额从支出账户上划出。还可以设置专户核算专项资金。在各类总账户下，省公司相应为各市分公司开设虚拟分账户，用以分别反映各地市的收入、支出、工程的现金流情况。

1)收入上划管理省总公司为每个地市公司开设一个结算账户(虚拟分账户)，用来记录上划资金以及省总公司下拨款的明细结算。省总公司上划资金记录后，或作出下拨款指令后，自动记录到各分公司的虚拟分账户，并可随时查询虚拟分账户的余额及明细。收入上划影响到分公司在省总公司账务中心的结算余额(增加)和省总公司收入专户存款余额的增加。

2)资金下拨资金下拨与收入上划登记在省总公司账务中心为分公司开立的结算账户上。资金下拨影响分公司的结算账户余额(减少)和省总公司支出总账户或省总公司工程总账户余额(减少)。资金下拨需办理银行付款手续，与支出账户的开户行协商能实现网上银行或企业银行(或类似系统，下称企业网上银行)提供付款接口的，本系统根据其要求，资金下拨登记后将付款请求生成银行能识别的数据，系统自动将付款请求发送到企业网上银行，完成付款手续。

3)资金头寸调拨省总公司支出总账户和省总公司工程总账户的资金全部来源于省总公司收入总账户，为了给分公司下拨资金，需从收入总账户调拨头寸到支出账户。资金头寸调拨影响收入总账户的余额(减少)和支出总账户的余额(增加)或工程总账户的余额(增加)其办理银行手续与资金下拨类似。

4)综合查询分析在此模块中，要求在统一的查询界面，对全省总公司的数据按省、地市、县等级别进行综合性的组合查询，本模块的查询内容包括：各银行账户的基本信息，当日明细、历史明细、当天余额、历史余额、上划款及下拨款等信息，可按地区、银行、账号性质、日期等组合查询各公司在银行的资金使用状况，可通过发生明细的对方单位、账号信息对款项进行有效的跟踪。根据业务描述及计算机处理的要求，可按业务内容划分为以下查询：查询各银行账户的业务明细，包括如下数据：发生日期(时间)、单位名称、交易行、账号、发生额、交易用途、账号类型、交易对方单位及交易对方账号等。查询各银行账户的当前余额，包括如下数据：单位名称、账号、账户开户行、当前余额、可用余额、币别及账号类型。查询各银行账户的历史余额，包括如下数据：日期(时间)、单位名称、账号、账户开户行、当前余额、可用余额、币别及账号类型。查询各单位账户的上划款，包括如下数据：上划款日期(时间)、划款单位、交易行、账号、划款金额及币别等。查询各单位账户的下拨款，包括如下数据：下拨款日期(时间)、拨款单位、交易行、账号、拨款金额及币别等。

5)数据统计报表本系统将根据所收集的数据仓库，进行数据统计分析，生成系列的统计报表，并将以图形方式直观显示，有关报表如：年度上划款统计表、年度下拨款统计表、现金流量表、单位净流分析表、及单位银行存款统计表等等。

6.环境需求集团公司资金监控系统需要具备相应的网络环境，系统网络结构要求如图4-8所示。图4-8系统网络环境

7.系统主要界面根据前面的功能分析，给出系统的主要界面方案。系统启动界面如图4-9所示，资金趋势图界面如图4-10所示。图4-9系统启动界面图4-10资金趋势图界面本章小结需求分析要回答的问题是“系统需要做什么”。本章首先介绍了需求分析的目标和任务以及需求分析过程，重点以任务驱动教学方法介绍了数据流图的绘制方法和数据字典的设计，然后介绍了需求分析报告的书写格式和编写高质量需求分析报告的建议，最后给出了一个案例—某省电信总公司的资金监控系统的需求报告。习题一、选择题

1．数据流图的三种成分为①、②和③，②是数据流中①的变换，③用来存储信息，④对①、②、③进行详细说明，用⑤对③进行详细描述。①②③④A. 消息 B. 文书