2014年计算机三级《信息管理》考试要点(3)

 三级信息管理技术分章节考试要点：软件工程(结构化生命周期方法之软件需求分析)

　　软件需求分析

　　软件需求分析工作是软件生存期中重要的一步，也是决定性的一步。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。软件需求分析工作也是一个不断认识和逐步细化的过程。该过程将软件设计阶段所确定的软件范围(工作域)逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决方法。

　　制定软件的需求规格说明不只是软件开发人员的事，用户也起着至关重要的作用。用户必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而软件分析人员则要认真了解用户的要求，细致地进行调查分析，把用户"做什么"的要求最终转换成一个完全的、精细的软件逻辑模型并写出软件的需求规格说明，准确地表达用户的要求。

　　1.软件需求分析任务

　　需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节。定义软件的其他有效性需求。

　　分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示。在软件完成后，制定的软件需求规格说明还要为评价软件质量提供依据。

　　需求分析阶段研究的对象是软件项目的用户要求。需要注意的是，必须理解用户的各项要求，但又不能全盘接受所有的要求。因为并非所有用户要求都是合理的。对其中模糊的要求还需要澄清，然后才能决定是否可以采纳。对于那些无法实现的要求应向用户做充分的解释，以求得谅解。

　　准确地表达所接受的用户要求，是需求分析的另一个重要方面。只有经过确切描述的软件需求才能成为软件设计基础。

　　通常软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中，它是软件实现的基础。但是目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。与物理模型不同，逻辑模型忽视实现机制与细节，只描述系统要完成的功能和要处理的数据。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的"做什么"的问题。

　　(1)获得当前系统的物理模型。当前系统可能是需要改进的某个已在计算机运行的数据处理系统，也可能是一个人工的数据处理过程。在这一步首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。

　　(2)抽象出当前系统的逻辑模型。在理解当前系统"怎样做"的基础上，抽取其"做什么"的本质，从而从当前系统的物理模型抽象出当前系统的逻辑模型。

　　在物理模型中有许多物理因素，随着分析工作的深入，有些非本质的物理因素就成为不必要的负担，因而需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本质的因素即可获得反映系统本质的逻辑模型。

　　(3)建立目标系统的逻辑模型。分析目标系统与当前系统逻辑上的差别，明确目标系统统到底要"做什么"，从当前系统的逻辑模型导出目标系统的逻辑模型。

　　(4)为了对目标系统做完整的描述，还需要对得到的逻辑模型做一些补充。

　　①说明目标系统的用户界面。根据目标系统所处的应用环境及它与外界环境的相互关系，研究所有可能与它发生联系和作用的部分，从而决定人机界面。

　　②说明至今尚未详细考虑的细节。这些细节包括系统的启动和结束、出错处理、系统的输入输出和系统性能方面的需求。

　　③其他。例如系统的其他必须满足的性能和限制等等。

　　2.需求分析的过程

　　需求分析阶段的工作，可以分成以下4个方面:对问题的识别、分析与综合、制定规格说明和评审。

　　(1)问题识别

　　首先系统分析人员要研究计划阶段产生的可行性分析报告(如果有的话)和软件项目实施计划。主要是从系统的角度来理解软件并评审用于产生计划估算的软件范围是否恰当。确定对目标系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求Υ锏降谋曜肌R簿褪且笏⑷砑鍪裁矗龅绞裁闯潭取U庑┬枨蟀?

　　·功能需求:列举出所开发软件在职能上应做什么。这是最主要的需求。

　　·性能需求:给出所开发软件的技术性能指标，包括存储容量限制、运行时间限制、安全保密性等。

　　·环境需求:这是对软件系统运行时所处环境的要求。例如在硬件方面，采用什么机型、有什么外部设备、数据通信接口等等。在软件方面，采用什么支持系统运行的系统软件(指操作系统、网络软件、数据库管理系统等)。在使用方面，需要使用部门在制度上、操作人员的技术水平上应具备什么样的条件等等。

·可靠性需求:各种软件在运行时，失效的影响各不相同。在需求分析时，应对所开发软件在投入运行后不发生故障的概率，按实际的运行环境提出要求，对于那些重要的软件，或是运行失效会造成严重后果的软件，应当提出较高的可靠性要求，以期在开发的过程中采取必要的措施，使软件能够高度可靠地稳定运行，避免因运行事故而带来的损失。

　　·安全保密要求:工作在不同环境的软件对其安全，保密的要求显然是不同的。应当把这方面的需求恰当地做出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全方面的性能得到必要的保证。

　　·用户界面需求:软件与用户界面的友好性是用户能够方便、有效、愉快地使用该软件的关键之一。从市场角度来看，具有友好用户界面的软件有很强的竞争力。因此，必须在需求分析时，为用户界面细致地规定达到的要求。

　　·资源使用需求:这是指所开发软件运行时所需的数据、软件、内存空间等各项资源外，软件开发时所需的人力、支撑软件、开发设备等则属于软件开发的资源，需要在需求分析时加以确定。

　　·软件成本消耗与开发进度需求:在软件项目立项后，要根据合同规定，对软件开发的进度和步骤的费用提出要求，作为开发管理的依据。

　　·预先估计以后系统可能达到的目标。这样，在开发过程中，可对系统将来可能扩充与修改做准备。一旦需要时，就比较容易进行补充和修改。

　　·功能性需求是人们普遍关注的，但常常忽视对非功能性需求的分析。其实非功能性需求并不是无关紧要的，它们涉及到的方面多而广，因而容易被忽略。如果在进行需求分析之前没有做过可行性分析，那么补充完成这部分工作往往是必要的。从问题定义和调查研究入手，与用户密切联系，详细了解问题提出的背景，弄清要解决什么问题。然后从软件系统特性和用户目标出发，做市场调查和现场考察。仔细收集信息之后进行数据分析和功能分析，建立系统的高层逻辑模型，再进一步做成本/效益分析。最后提交一份可行性分析报告，从技术、经济、社会效应等方面论证可行性，以确认软件开发的目标是否可行。

　　问题识别的另一项工作是建立分析所需要的通信途径，以保证能顺利地对问题进行分析。分析员必须与用户、软件开发机构的管理部门、软件开发组的人员建立联系。项目负责人在此过程中起协调人的作用。分析员通过这种通信途径与各方商讨，以便能满足用户的要求。

　　(2)分析与综合

　　需求分析的第二步工作是问题分析和方案的综合。分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制分析它们是否满足功能要求，是否合理。依据功能需求、性能需求、运行特性和设计上的限制分析它们是否满足功能要求，是否合理。依据功能需求、性能需求、运行环境需求等，剔除其不合理的部分，增加其需要的部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。

　　在这个步骤中，分析和综合工作反复地进行。在对现行问题和期望的信息(输入和输出)进行分析的基础上，分析员开始综合出一个或几个解决方案，然后检查这些方案是否符合软件计划中规定的范围等等，再进行修改。总之，对问题进行分析和综合的过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的规格说明为止。

　　常用的分析方法有面向数据流的结构化分析方法(简称SA)、面向数据结构的Jackson方法(简称JSD)、面向对象的分析方法(简称OOA)等，以及用于建立动态、模型的状态迁移图或Petri网等。这些方法都采用图文结合的方式，可以直观地描述软件的逻辑模型。

　　(3)编制需求分析的文档

　　已经确定的需求应当得到清晰准确的描述。通常把描述需求的文档叫做软件需求规格说明书。同时，为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及编写初步的用户手册，着重反映被开发软件的用户界面和用户使用的具体要求。

　　此外，依据在需求分析阶段对系统的进一步分析，从目标系统的精细模型出发，可以更确切地估计所开发项目的成本与进度，从而修改、完善与确定软件开发的实施计划。

　　(4)需求分析评审

　　作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。评审的主要内容是:

　　·系统定义的目标是否与用户的要求一致;

　　·系统需求分析阶段提供的文档资料是否齐全;

　　·文档中的所有描述是否完整、清晰、准确所反映用户要求;

　　·与所在其他系统成分的重要接口是否都已经描述;

　　·所开发项目的数据流与数据结构是否足够、确定;

　　·所有图表是否清楚，在不补充说明时能否理解;

　　·主要功能是否已包括在规定的软件范围之内，是否都已充分说明;

　　·设计的约束条件或限制条件是否符合实际;

　　·开发的技术风险是什么;

　　·是否考虑过软件需求的其他方案;

　　·是否考虑过将来可能会提出的软件需求;

　　·是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;

　　·有没有遗漏、重复或不一致的地方;

　　·用户是否审查了初步的用户手册;

　　·软件开发计划中的估算是否受到了影响。

　　为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外，用户，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。通常，评审的结果都包括了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。

3.软件需求分析的原则

　　近年来已提出了许多软件分析与说明的方法，虽然各种分析方法都有其独特的描述方法，但总的看来，所有分析方法还是有它们共同适用的基本原则。

　　(1)必须能够表达和理解问题的数据域和功能域

　　所有软件定义与开发工作最终是为了解决数据处理问题，就是将一种形式的数据转换成另一种形式的数据。其转换过程必定经历输入、加工数据和产生结果数据等步骤。对于计算机程序处理的数据，其数据域应包括数据流、数据内容和数据结构。

　　数据流即数据通过一个系统时的数据存储(如磁盘文件或内存缓冲区)中引入附加数据。对数据进行转换是程序中应有的功能或子功能。两个转换功能之间的数据传递就确定了功能间的接口。

　　数据内容即数据项。例如，学生名册包含了班级、人数、每个学生的学号、姓名、性别、各科成绩等。学生名册的内容由它所包含的项定义。为了理解对学生名册的处理，必须要理解它的数据内容。

　　数据结构即各种数据项的逻辑组织。数据是组织成表格，还是组织成有层次的树型结构?在结构中数据项与其他哪些数据项相关?所有数据是在一个数据结构中，还是在几个数据结构中?一个结构中的数据与其他结构中的数据如何联系?这些问题都由数据结构分析来解决。

　　(2)必须按自项向下、逐层分解的方式对问题进行分解和不断细化

　　如果将软件要处理的问题作为一个整体来看，显得太大太复杂很难理解。如果把问题以某种方式分解为几个较易理解的部分，并确定各部分间的接口，从而实现整体功能。

　　在需求分析阶段，软件的功能域和信息域都能做进一步的分解。这种分解可以是同一层次上的，称为横向分解;也可以是多层次的纵向分解。

　　例如，把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。但如果继续分解，把某些子功能又分解为小的子功能，某个小的子功能又分解为更小的功能，这就属于纵向分解了。

　　(3)要给出系统的逻辑视图和物理视图

　　给出系统的逻辑视图(逻辑模型)和物理视图(物理模型)，这对系统满足处理需求所提出的逻辑限制条件和系统中其他成分提出的物理限制条件是必不可少的。软件需求的逻辑视图给出软件要达到的功能和要处理的数据之间的关系，而不是实现的细节。例如，一个商店的销售处理系统要从顾客那里获取订单，系统读取订单的功能并不关心订单数据的物理形式和用什么设计读入，也就是说无需关心输入的机制，只是读取顾客的订单而已。类似的，系统中检查库存的功能只关心库存文件的数据结构，而不关心在计算机中的具体存储方式。软件需求的逻辑描述是软件设计的基础。

　　软件需求的物理视图给出处理功能和数据结构的实际表示形式，这往往是由设备决定的，如一些软件靠终端键盘输入数据，另一些软件靠模拟数据转换设备提供数据。分析员必须弄清系统元素对软件的限制并考虑功能和信息结构的物理表示。

　　4.软件需求分析方法

　　需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。大多数的需求分析方法是由数据驱动的，也就是说，这些方法提供了一种表示数据域的机制。分析员根据这种表示，确定软件功能及其他特性，最终建立一个待开发软件的抽象模型，即目标系统的逻辑模型。数据域具有3种属性:数据流、数据内容和数据结构。通常，一种需求分析方法总要利用其中的一种或几种属性。

　　目前已经出现了许多需求分析方法，每一种分析方法都引入了不同的记号和分析策略。但是它们仍具有以下的共性:

　　(1)支持数据域分析的机制

　　尽管每种方法进行数据域分析的方式不同，但它们仍有一些共同点。所有的方法都直接或间接地涉及到数据流、数据内容或数据结构域的属性。在多数情况下，数据流特征是用将输入转换成输出的变换(功能)过程来描述的，数据内容可以用数据词典机制明确表示，或者通过描述数据或数据对象的层次结构隐含地表示。

　　(2)功能表示的方法

　　功能一般用数据变换或加工来表示，每项功能可用规定的记号(圆圈或方框)标识。功能的说明可以用自然语言文本来表达，也可以用形式化的规格说明语言来表达，还可以用上述的两种方式的混合方式---结构化语言来描述。

　　(3)接口的定义

　　接口的说明通常是数据表示和功能表示的直接产物。某个具体功能的流进和流出数据流应是其他相关功能的流出或流入的数据流。因此，通过数据流的分析可以确定功能间的接口。

　　(4)问题分解的机制以及对抽象的支持

　　问题分解和抽象主要依靠分析员在不同抽象层次上表示数据域和功能域，以逐层细化的手段建立分层结构来实现。例如，无论使用哪种分析方法，都能表示"计算职工每月工资"之类的功能，并在这个抽象层次上操纵这个功能。另外，所有的分析方法都提供逐层分解的机制，把"计算职工每月工资"功能划分成一些子功能，如计算房租、计算用电费、计算用水费、计算养老保险费等等。其中，每项子功能还可以在更低的一级抽象层次上表示。

　　(5)逻辑视图和物理视图

　　大多数方法允许分析员在着手问题的逻辑解决方案之前先分析物理视图。通常，同一种表示法既可用来表示逻辑视图，也可用来表示物理视图。

　　(6)系统抽象模型

　　为了能够比较精确地定义软件需求，可以建立待开发软件的一个抽象的模型，用基于抽象模型的术语来描述软件系统的功能和性能，形成软件需求规格说明。这种抽象的模型是从外部现实世界的问题领域抽象而来，在高级层次上描述和定义系统的服务。

　　对于比较简单的问题，不必建立抽象系统模型。或者可以认为，系统模型在分析员头脑中形成，直接由分析员写成规格说明。但对于比较复杂的问题，仅有在头脑中想象的模型是不够的，必须建立适当的比较形式化的抽象系统模型，才能准确全面地反映问题领域中各种复杂的要求。不同类型的问题有不同的需要解决的中心问题，因而要建立不同类型的系统模型。对于数学软件，设计的中心问题是算法，软件人员主要力量要花在数学模式算法的考虑上。对于数据通信软件，中心问题是数据传送和过程控制，实现算法简单，采用数据流模型比较合适。对于涉及大量数据的数据处理软件，中心问题是数据处理，包括数据的采集、数据的传送、存储、变换、输出等，一旦了解了数据结构，与它相关的算法就很简单了。如果系统要求有数据支持，通过数据库获取和存放信息，还需要考虑数据在数据库中的组织方式和存取方法，建立数据库模型。因此，在分析过程中数据模型是首先要集中精力考虑的问题。

　　系统模型的建立是对现实世界中存在的有关实体和活动的抽象和精化，其建立过程包括观察分析、模型表示和模型检查3个阶段。

　　首先，分析员和用户合作，从各方面观察现实世界中的有关实体和活动，建立理解的共同基准，分清哪些概念与系统相关，必须纳入系统模型，哪些是系统模型不必关心的，分析员和用户在共同理解的基础上，建立系统模型，包括系统提供的各种系统服务，模型表示的细节应有:系统输入、系统输出、系统数据处理、系统控制等。

　　建立系统模型以后，还要进行检查。除了静态检查之外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界系统观察得到的系统跟踪信息进行对照，检查模型是否符合要求。这种建立系统模型并模拟执行和检查的方法叫做系统原型开发。