计算机三级信息管理技术分章节考试关键考点大全

三级信息管理技术分章节考试要点软件工程(结构化生命周期方法之结构化分析方法)结构化分析方法 结构化分析是面向数据流进行需求分析的方法。20世纪70年代末，经Yourdon E.、Constantine L.、DeMarco T.等人提出和发展，至今已得到广泛应用。结构化分析方法的一些重要概念也渗透在其他开发方法中。例如，结构化分析与设计技术（Structured Analysis and Design Technique，SADT）、面向对象技术（Object-Oreinted Technique，OOT）、IDEF方法等。结构化分析方法适合于数据处理类型软件的需求分析。由于利用图形表达需求，显得清晰、简明，易于学习和掌握。具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。根据DeMarco的论述，结构化分析方法使用的工具有:数据流图、数据词典、结构化英语、判定表、判定树。结构化分析方法有两个明显特点。采用简明易懂、直观的描述方式1.数据流图数据流图也称为Bubble Chart或data Flow Graph。是描述数据处理过程的工具。数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。（1）数据流图的主要图形元素从数据流图中可知，数据流图的基本图形元素有4种。数据流是沿箭头方向传送数据的通道，它们大多是在加工之间传输加工数据的命名通道，也有连接数据存储文件和加工的没有命名的数据通道。这些数据流虽然没有命名，但因联接着有名加工和有名文件，所以其含意也是清楚的。同一数据流图上不能有同名的数据流。多个数据流可以指向同个加工，也可以从一个加工散发出许多数据流。加工是以数据结构或数据内容作为加工对象的。加工的名字通常是一个动词短语，简明扼要地表明完成的是什么加工。文件在数据流图中起保存数据的作用，因而称为数据存储（Data Store）。它可以是数据库文件或任何形式的数据组织。指向文件的数据流可理解为写入文件或查询文件，从文件中引出的数据流可理解为从文件读取数据或得到查询结果。数据流图中第4种元素是数据源点或汇点，它表示图中要处理数据的输入来源及处理结果要送往何处。由于它在图中的出现仅仅是一个符号，并不需要以软件的形式进行设计和实现，因而，它只是数据流图的外围环境中的实体，故称外部实体。在实际问题中它可能是计算机外围设备或是传感装置。（2）数据流与加工之间的关系在数据流图中，如果有两个以上的数据流指向一个加工，或是从一个加工中引出两个以上的数据流，这些数据流之间往往存在一定的关系。（3）分层的数据流图为了表达数据处理过程的数据加工情况，用一个数据流图是不够的。为表达稍为复杂的实际问题需要按照问题的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系。先把整个数据处理过程暂且看成一个加工，它的输入数据和输出数据实际上反映了系统与外界环境的接口。这就是分层数据图的顶层。但只此一图并未表明数据的加工要求，需要进一步细化。如果这个数据处理包括3个子系统，就可以画出表示这3个子系统1、2、3的加工及其相关的数据流。这是顶层下面的第一层数据流图，记为DFD/L1。继续分解这3个子系统，可得到第二层数据流图DFD/L2.1、DFD/L2.2、及DFD/L2.3，它们分别是子系统。1、2和3的细化。仅以DF/2为例，其中的4个加工的编号均可联系到其上层图中的子系统2。这样得到的多层数据流图可十分清晰地表达整个数据加工系统的真实情况。对任何一层数据流图来说，称它的上层图为父图，在它下一层的图则称为子图。在多层数据流图中，可以把顶层流图、底层流图和中间层流图区分开。顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统的输出数据。顶层流图的作用在于表明被开发系统的范围，以及它和周围环境的数据交换关系。底层流图是指其加工不须再做分解的数据流图，其加工称为“原子加工”。中间层流图则表示对其上层父图的细化。它的每一加工可以继续细化，形成子图。中间层次的多少视系统的复杂程度而定。（4）数据流图画法画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。具体步骤可按如下来做。先找系统的数据源点与汇点。它们是外部实体，由它们确定系统与外界的接口。找出外部实体的输出数据流与输入数据流。在图的边上画出系统的外部实体。从外部实体的输出数据流（即系统的源点）出发，按照系统的逻辑需要，逐步画出一系列逻辑加工，直到找到外部实体所需的输入数据流（即系统的汇点），形成数据流的封闭。按照下面所给的原则进行检查和修改。按照上述步骤，再从各加工出发，画出所需的子图。（5）进行检查和修改的原则数据流图上所有图形符号只限于前述四种基本图形元素。数据流的主图必须包括前述4种基本元素，缺一不可。数据流图的主图上的数据流必须封闭在外部实体之间，外部实体可以不只一个。每个加工至少有一个输入数据流和一个输出数据流。在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。即父图与子图的平衡，它表明了在细化过程中输入与输出不能有丢失和添加。图上每个元素都必须有名字。表明数据流和数据文件是什么数据，加工做什么事情。数据流图中不可夹带控制流。因为数据流图是实际业务流程的客观映象，说明系统“做什么”而不是要表明系统“如何做”，因此不是系统的执行顺序，不是程序流程图。初画时可以忽略琐碎的细节，以集中精力于主要数据流。在需求分析期间，有时会要求修改系统的某些方面。使用数据流图可以很容易地把需要修改的区域分离出来。只要清楚地了解穿过要修改区域边界的数据流，就可以为将来的修改做好充分的准备，而且在修改时能够不打乱系统的其他部分.2.数据词典数据词典的任务是对于数据流图中出现的所有被命名的图形元素在数据词典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。数据词典中所有的定义应是严密的、精确的，不可有半点含糊，不可有二义性。（1）数据词典的定义对在数据流图中每一个命名的图形元素均给予定义，其内容有图形元素的名字、别名或编号、分类、描述、定义、位置等。以下是不同词条应给出的内容。数据流词条描述数据流是数据结构在系统内传播的路径。一个数据流词条应有以下几项内容:数据流名:说明:简要介绍作用即它产生的原因和结果。数据流来源:来自何方。数据流去向:去向何方。数据流组成:数据结构。每个数据量:数据量、流通量。数据元素词条描述图中的每一个数据结构都是由数据元素构成的，数据元素是数据处理中最小的，不可再分的单位，它直接反映事物的某一特征。对于这些数据元素也必须在数据词典中给出描述。其描述需要以下信息:数据元素名类型:数字（离散值，连续值），文字S（编码类型）。长度。取值范围。相关的数据元素及数据结构。数据元素的取值可分数字型与文字型。数字型又有离散值与连续值之分。离散值或是枚举的，或是介于上下界的一组数;连续值一般是有取值范围的实数集。对于文字型，需给予编码类型，文字值需加以定义。数据文件词条描述数据文件是数据结构保存的地方。一个数据文件词条应有以下几项内容。数据文件名。简述:存放的是什么数据。输入数据。输出数据。数据文件组成:数据结构。存储方式:顺序、直接、关键码。存取频率。加工逻辑词条描述加工比较复杂，它到后来就是一段程序。加工的表达方式有判定表、判定树和结构化英语等等，它们要全部写在一个词条中是有困难的。主要描述有:加工名。加工编号:反映该加工的层次。简要描述:加工逻辑及功能简述。输入数据流。输出数据流。加工逻辑:简述加工程序、加工顺序。源点及汇（终）点词条描述对于一个数据处理系统来说，源点和汇点应当比较少。如果过多就缺少独立性，人机界面太复杂，这时就要考虑减少，提高系统独立性。定义源点和汇点时，应包括:名称:外部实体名。简要描述:什么外部实体。有关数据流。数目。（2）数据词典的使用在结构化分析的过程中，可以通过名字，方便地查阅数据的定义:同时可按各种要求，随时列出各种表，以满足分析员的需要。还可以按描述内容（或定义）来查询数据的名字，通过检查各个加工的逻辑功能，可以实现和检查在数据与程序之间的一致性和完整性，在以后的设计与实现阶段，以至于到维护阶段。都需要参考数据词典进行设计、修改和查询。（3）数据结构的描述在数据词典的编制中，分析员最常用的描述数据结构的方式有定义式和Warnier图。定义式在数据流图中，数据流和数据文件都具有一定的数据结构。因此必须以一种清晰、准确、无二义性方式来描述数据结构。这种定义方法是自顶向下，逐级给出定义式，直到最后给出基本数据元素为止。Warnier图Warnier图是表示数据层次结构的一种图工具。它用树形结构描绘数据结构，它还能指出某一类数据或某一数据元素重复出现的次数，并能指明某一特定数据在某一类数据中是否是有条件的出现。在进行软件设计时，从Warnier图入手，能够很容易转换成软件的设计描述。 3.加工逻辑说明 在数据流图中，每一个加工框只简单地写上了一个加工名，这显然不能表达加工的全部内容。随着自顶向下逐层细化，功能越来越具体，加工逻辑也越来越精细。到最底一层，加工逻辑详细到可以实现的程序，因此称为“原子加工”或“基本加工”。如果能够写出每一个基本加工的全部详细逻辑功能，再自底向上综合，就能完成全部逻辑加工。在写基本加工逻辑的说明时，应满足如下的要求:对数据流图的每一个基本加工，必须有一个加工逻辑说明;加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则;加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。目前用于写加工逻辑说明的工具有结构化语言、判定表和判定树。下面分别介绍。（1）结构化语言结构化语言也称为PDL，是一种介于自然语言和形式化语言之间的半形式化语言。它是在自然语言基础上加了一些限制而得到的语言，是使用有限的词汇和有限的语句来描述加工逻辑。结构化语言的词汇表由英语命令动词、数据词典中定义的名字、有限的自定义词和控制结构关键词IF-THEN-ELSE、WHELE-DO、REPEAT-UNTIL、CASE-OF等组成。其动词的含义要具体，尽可能少用或不用形容词和副词。语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示。其基本控制结构有简单陈述句结构、判定结构和重复结构。此外在书写时，必须按层次横向向右移行，续行也同样向右移行，对齐。要了解基本加工逻辑的来龙去脉、在数据流图中的位置、加工的使用情况等有更清楚的了解，一般对结构化英语的描述加一些外层说明。（2）判定表在某些数据处理问题中，某数据流图的加工需要依赖于多个逻辑条件的取值，就是说完成这一加工的一组动作是由于某一组条件取值的组合而引发的。这时使用判定表来描述比较合适。下面以“检查发货单”为例，说明判定表的构成。判定表由4个部分组成，双线分割开的4部分是:条件桩（Condition Stub）左上部分:列出了各种可能的条件。除去某些问题中对各个条件的先后次序有特定的要求以外，通常判定表中对各条件的先后次序不要求。条件项（Condition Entry）右上部分:给出各个条件的条件取值的组合。动作桩（Action Stub）:左下部分:列出了可能采取的动作。这些动作的排列顺序没有限制，但为便于阅读也可令共按适当的顺序排列。动作项（Action Entry）:右下部分:是和条件项紧密相关的，它指出了在条件项的各种取值的组合情况下一步应采取什么动作。这里将任一条件取值组合及其相应要执行动作作称为规则，它在判定有中是纵贯条件项和动作项的一列。显然，判定表中列出了多少个条件取值的组合，也就有多少条规则，即条件项一动作项有多少列。在实际使用判定表时，常常先把它化简。如果表中有两条或更多的规则具有相同的动作，并且其条件项之间存在着某些关系，就可设法将它们合并。就是说要执行的动作与第三条件的取值无关，这样，便可将这两条规则合并，合并后的第三条件取值用“”表示，即与取值无关。类似地，无关条件项“”，在逻辑上又可包含其他项值，具有相同动作的规则还可以进一步合并。判定表能够把在什么条件下，系统应完成哪些操作，表达得十分清楚、准确、一目了然。这是用语言说明难以准确、清楚表达的，但是用判定表描述循环比较困难。有时，判定表可以和结构化语言结合起来使用。（3）判定树判定树也是用来表达加工逻辑的一种工具。有时候它比判定表更直观，用它来描述加工，很容易为用户接受。没有一种统一的方法来构造判定树，也不可能有统一的方法。因为客观存在是用结构化语言，甚至是自然语言写成的叙述文作为构造树的原始依据的，但可以从中找些规律。首先，应从文字资料中分清哪些是判定条件，哪些是判定做出的结论。在表达一个基本加工逻辑时，结构化语言、判定表和判定树常常交*使用，互相补充。因为这3种手段各有优缺点。总之，加工逻辑说明是结构化分析方法的一个组成部分，对每个加工都要加以说明。使用的手段，应当以结构化语言为主，对存在判断问题的加工逻辑，可辅之以判定表和判定树。4.软件需求说明软件需求规格说明书包括的主要内容如下:（1）概述（2）数据描述数据流图数据字典系统接口说明内部接口说明（3）功能描述功能处理说明设计的限制（4）性能描述性能指标测试种类预期的软件响应性能其它（5）参考文献目录（6）附录其中概述是从系统的角度描述软件的目标和任务。软件需求文档的生成方法有以下两种。（1）计算机辅助生成:由于需求文档的规模较大，并且需要经常查询、维护，所以使用计算机辅助的软件需求分析工具，来实现软件需求文档的自动生成，是非常有意义的。1977年最先推出了需求陈述语言RSL（RSL中的语句是计算机可以处理的）。同年美国密执安大学开发了PSL/PSA（问题陈述语言/问题陈述分析程序）系统。它是信息系统开发自动化支持环境1SDOS的一个组成部分。其中PSL是用来描述系统的形式语言，它可以对系统需求的一致性进行检查，并可根据开发者的需要，随时生成需求文档。（2）手工与半手工方式:这种方法难以保证文档质量。半手工方式是利用正文编辑程序及其他实用程序辅助手工方式来生成文档，这类方法难以保证文档的正确性、一致性和完整性。n 三级信息管理技术分章节考试要点：软件工程(结构化生命周期方法之软件设计)软件设计 在明确了用户的需求以后，下一步的任务就是对未来的软件系统进行设计。软件设计通常可分为概要设计和详细设计。概要设计的任务是确定软件系统的结构，进行模块划分，确定每个模块的功能、接口以及模块间的调用关系。详细设计的任务是为每个模块设计实现的细节。此外，在概要设计阶段还应对全局数据结构进行设计，详细设计阶段还应对局部数据结构进行设计。有的设计方法不区分概要设计和详细设计，统称为软件设计。人们在开发过程中，总结出许多软件设计的概念和原则，这些概念和原则对提高软件的设计质量有很大的帮助。1.抽象抽象是指忽视一个主题中与当前目标无关的那些方面，以便更充分地注意与当前目标有关的方面。抽象是认识复杂问题的过程中人类使用的最有力的思维工具，它抽取出事物的本质特性而暂时不考虑它的细节。软件工程中从软件定义到软件开发要经历多个阶段，在这个过程中每前进一步都可看作是对软件的抽象层次的一次细化。抽象的最低层次就是实现该软件的源程序代码。在进行模块化设计时可以有多个抽象层次，最高抽象层次的模块用概括的方式叙述问题的解法，较低抽象层次的模块是对较高的抽象层次模块对问题解决描述的细化。过程抽象和数据抽象是常用的两种主要抽象手段。过程抽象是指任何一个完成明确功能的操作都可被使用者当作单个的实体看待，尽管这个操作实际上可能由一系列更低级的操作来完成。过程抽象常常也称为功能/子功能抽象。例如函数、子程序。数据抽象定义了数据类型和施加于该类型的操作，并限定了对象值的范围，只能通过使用这些操作修改和观察这些数据，例如抽象数据类型。2.模块化模块化是指将一个待开发的软件分解成若干个小的简单的部分模块，每个模块可独立地开发、测试，最后组装成完整的程序。这是一种复杂问题的“分而治之”的原则，模块化的目的是使程序的结构清晰，容易阅读，容易理解，容易测试，容易修改。模块是指执行某一特定任务（也可以是实现某一特定的抽象数据类型）的数据结构和程序代码。一个模块有它的外部特征和内部特征。外部特征包括模块的接口（即它的输入/输出参数，引用的全局变量和它需调用的其他模块）和模块的功能，内部特征包括模块的局部数据和实现该模块的程序代码。调用一个模块只需知道它的外部特征，而不必了解其内部特征。3.信息隐蔽信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设计模块中，定义每一个模块时尽可能少地显露其内部的处理。在设计时首先列出一些可能发生变化的因素，在划分模块时将一个可能发生变化的因素隐蔽在某个模块的内部，使其他模块与这个因素无关。在这个因素发生变化时，我们只需修改含有这个因素的模块，而与其他模块无关。隐蔽的对象可以有:什么样的决策、可能修改的决策、数据结构的内部连接以及对它所做的操作细节、内部特征码、与计算机硬件有关的细节等。信息隐蔽原则对提高软件的可修改性、可测试性和可移植性都有重要的作用。4.模块独立模块独立是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系简单。衡量模块独立程序的度量标准有两个:耦合和内聚。耦合是指模块之间联系的紧密程度。耦合度越高则模块的独立性越差。内聚是指模块内部各元素之间联系的紧密程度。例如一个完成多个功能的模块的内聚度就比完成单一功能的模块的内聚度低。内聚度越低模块的独立性越差。因此，模块独立就是希望每个模块都是高内聚低耦合的。（1）耦合两个模块之间的耦合方式通常有如下7种，下面按它们的耦合度从低到高的次序依次作介绍。非直接耦合:非直接耦合是指两个模块没有直接的联系，它们中的任一个都能不依赖于对方而独立地工作。数据耦合:数据耦合是指两个模块借助于参数表传递简单数据。标记耦合（stamp coupling）:当一个数据结构的一部分（如记录的一部分）借助于模块接口被传递时就发生标记耦合。控制耦合:控制耦合指两个模块间传递的信息中包含用于控制模块内部逻辑的控制信息。外部耦合:当模块与软件以外的环境有关时就发生外部耦合。例如，输入/输出把一个模块与特定的设备、格式、通信协议耦合在一起。公共耦合:多个模块引用一全局数据区的模式称为公共耦合。例如FORTRAN语言中的COMMON语句、C语言中的external数据类型、一个磁盘文件等都是全局数据区。内容耦合:内容耦合指两上模块之间出现了下列情况之一:一个模块访问另一个模块的内部数据;一个模块不通过正常入口转到另一模块的内部;两个模块有一部分程序代码重叠;一个模块有多个入口。（2）内聚模块的内聚种类通常可分成7种，下面按内聚度从低到高的次序依次作介绍。偶然内聚:如果一个模块完成一组任务，这组任务彼此间即使有关系，其关系也是很松散的，这个模块属于偶然内聚。逻辑内聚:如果一个模块完成逻辑上相关的一组任务，这个模块是逻辑内聚的。例如，产生与类型无关的全部输出的模块。瞬时内聚（temporal cohesion）:如果一个模块所包含的任务必须在同一时间间隔内执行，这个模块属于瞬时内聚。例如初始化模块。过程内聚:如果一个模块的处理元素是相关的，而且必须按特定的次序执行，这个模块属于过程内聚。通信内聚:如果一个模块的所有处理元素集中在一个数据结构的区域上，该模块属于通信内聚。例如，一个模块中的所有处理元素使用同一输入数据。顺序内聚:如果一个模块的处理元素是相关的，而且必须顺序执行，这个模块属于顺序内聚。功能内聚:如果一个模块完成一个单一的功能，模块中的各部分在此目标下协同工作，而且都是为完成这一功能而不可缺少的，那么这个模块是功能内聚的。5.模块分解时应遵循的准则（1）满足信息隐蔽原则。（2）尽量使得模块的内聚度高，模块间的耦合度低。（3）模块的大小适中（通常一个模块以50100个语句行为适宜）。（4）模块的调用深度不宜过大。一个模块A可以调用另一模块B，模块B还可调用模块C，称模块A直接调用模块B，模块A间接调用模块C，被间接调用的模块还可调其他模块，这样可形成一棵调用树，我们把以某个模块为根结点的调用树的深度称为该模块的调用深度。（5）模块的扇入应尽量大，扇出不宜过大。一个模块的扇入是指直接调用该模块的上级模块个数。一个模块的扇出是指该模块直接调用的下级模块的个数。扇入大表示模块的复用程度高，扇出大表示模块的复杂度高。（6）设计单入口和单出口的模块。（7）模块的作用域应在控制域之内。模块的作用域是指受该模块内一个判定影响的所在模块的集合。模块的控制域是指该模块本身以及被该模块直接或间接调用的所有模块的集合。在设计时，作用域应是控制域的子集，作用域最好是做出判定的模块本身以及它的直属下级模块（直接调用的模块）。（8）模块的功能应是可以预测的，功能可预测是指对相同的输入数据能产生相同的输出。n 三级信息管理技术分章节考试要点：软件工程(结构化生命周期方法之软件需求分析)软件需求分析 软件需求分析工作是软件生存期中重要的一步，也是决定性的一步。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。软件需求分析工作也是一个不断认识和逐步细化的过程。该过程将软件设计阶段所确定的软件范围（工作域）逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决方法。制定软件的需求规格说明不只是软件开发人员的事，用户也起着至关重要的作用。用户必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而软件分析人员则要认真了解用户的要求，细致地进行调查分析，把用户“做什么”的要求最终转换成一个完全的、精细的软件逻辑模型并写出软件的需求规格说明，准确地表达用户的要求。1.软件需求分析任务需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节。定义软件的其他有效性需求。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示。在软件完成后，制定的软件需求规格说明还要为评价软件质量提供依据。需求分析阶段研究的对象是软件项目的用户要求。需要注意的是，必须理解用户的各项要求，但又不能全盘接受所有的要求。因为并非所有用户要求都是合理的。对其中模糊的要求还需要澄清，然后才能决定是否可以采纳。对于那些无法实现的要求应向用户做充分的解释，以求得谅解。准确地表达所接受的用户要求，是需求分析的另一个重要方面。只有经过确切描述的软件需求才能成为软件设计基础。通常软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中，它是软件实现的基础。但是目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。与物理模型不同，逻辑模型忽视实现机制与细节，只描述系统要完成的功能和要处理的数据。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。 （1）获得当前系统的物理模型。当前系统可能是需要改进的某个已在计算机运行的数据处理系统，也可能是一个人工的数据处理过程。在这一步首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。（2）抽象出当前系统的逻辑模型。在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质，从而从当前系统的物理模型抽象出当前系统的逻辑模型。在物理模型中有许多物理因素，随着分析工作的深入，有些非本质的物理因素就成为不必要的负担，因而需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本质的因素即可获得反映系统本质的逻辑模型。（3）建立目标系统的逻辑模型。分析目标系统与当前系统逻辑上的差别，明确目标系统统到底要“做什么”，从当前系统的逻辑模型导出目标系统的逻辑模型。（4）为了对目标系统做完整的描述，还需要对得到的逻辑模型做一些补充。说明目标系统的用户界面。根据目标系统所处的应用环境及它与外界环境的相互关系，研究所有可能与它发生联系和作用的部分，从而决定人机界面。说明至今尚未详细考虑的细节。这些细节包括系统的启动和结束、出错处理、系统的输入输出和系统性能方面的需求。其他。例如系统的其他必须满足的性能和限制等等。2.需求分析的过程 需求分析阶段的工作，可以分成以下4个方面:对问题的识别、分析与综合、制定规格说明和评审。（1）问题识别首先系统分析人员要研究计划阶段产生的可行性分析报告（如果有的话）和软件项目实施计划。主要是从系统的角度来理解软件并评审用于产生计划估算的软件范围是否恰当。确定对目标系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求锏降谋曜肌簿褪且笏砑鍪裁矗龅绞裁闯潭取庑枨蟀?功能需求:列举出所开发软件在职能上应做什么。这是最主要的需求。性能需求:给出所开发软件的技术性能指标，包括存储容量限制、运行时间限制、安全保密性等。环境需求:这是对软件系统运行时所处环境的要求。例如在硬件方面，采用什么机型、有什么外部设备、数据通信接口等等。在软件方面，采用什么支持系统运行的系统软件（指操作系统、网络软件、数据库管理系统等）。在使用方面，需要使用部门在制度上、操作人员的技术水平上应具备什么样的条件等等。可靠性需求:各种软件在运行时，失效的影响各不相同。在需求分析时，应对所开发软件在投入运行后不发生故障的概率，按实际的运行环境提出要求，对于那些重要的软件，或是运行失效会造成严重后果的软件，应当提出较高的可靠性要求，以期在开发的过程中采取必要的措施，使软件能够高度可靠地稳定运行，避免因运行事故而带来的损失。安全保密要求:工作在不同环境的软件对其安全，保密的要求显然是不同的。应当把这方面的需求恰当地做出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全方面的性能得到必要的保证。用户界面需求:软件与用户界面的友好性是用户能够方便、有效、愉快地使用该软件的关键之一。从市场角度来看，具有友好用户界面的软件有很强的竞争力。因此，必须在需求分析时，为用户界面细致地规定达到的要求。资源使用需求:这是指所开发软件运行时所需的数据、软件、内存空间等各项资源外，软件开发时所需的人力、支撑软件、开发设备等则属于软件开发的资源，需要在需求分析时加以确定。软件成本消耗与开发进度需求:在软件项目立项后，要根据合同规定，对软件开发的进度和步骤的费用提出要求，作为开发管理的依据。预先估计以后系统可能达到的目标。这样，在开发过程中，可对系统将来可能扩充与修改做准备。一旦需要时，就比较容易进行补充和修改。功能性需求是人们普遍关注的，但常常忽视对非功能性需求的分析。其实非功能性需求并不是无关紧要的，它们涉及到的方面多而广，因而容易被忽略。如果在进行需求分析之前没有做过可行性分析，那么补充完成这部分工作往往是必要的。从问题定义和调查研究入手，与用户密切联系，详细了解问题提出的背景，弄清要解决什么问题。然后从软件系统特性和用户目标出发，做市场调查和现场考察。仔细收集信息之后进行数据分析和功能分析，建立系统的高层逻辑模型，再进一步做成本/效益分析。最后提交一份可行性分析报告，从技术、经济、社会效应等方面论证可行性，以确认软件开发的目标是否可行。问题识别的另一项工作是建立分析所需要的通信途径，以保证能顺利地对问题进行分析。分析员必须与用户、软件开发机构的管理部门、软件开发组的人员建立联系。项目负责人在此过程中起协调人的作用。分析员通过这种通信途径与各方商讨，以便能满足用户的要求。（2）分析与综合需求分析的第二步工作是问题分析和方案的综合。分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制分析它们是否满足功能要求，是否合理。依据功能需求、性能需求、运行特性和设计上的限制分析它们是否满足功能要求，是否合理。依据功能需求、性能需求、运行环境需求等，剔除其不合理的部分，增加其需要的部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。在这个步骤中，分析和综合工作反复地进行。在对现行问题和期望的信息（输入和输出）进行分析的基础上，分析员开始综合出一个或几个解决方案，然后检查这些方案是否符合软件计划中规定的范围等等，再进行修改。总之，对问题进行分析和综合的过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的规格说明为止。常用的分析方法有面向数据流的结构化分析方法（简称SA）、面向数据结构的Jackson方法（简称JSD）、面向对象的分析方法（简称OOA）等，以及用于建立动态、模型的状态迁移图或Petri网等。这些方法都采用图文结合的方式，可以直观地描述软件的逻辑模型。（3）编制需求分析的文档已经确定的需求应当得到清晰准确的描述。通常把描述需求的文档叫做软件需求规格说明书。同时，为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及编写初步的用户手册，着重反映被开发软件的用户界面和用户使用的具体要求。此外，依据在需求分析阶段对系统的进一步分析，从目标系统的精细模型出发，可以更确切地估计所开发项目的成本与进度，从而修改、完善与确定软件开发的实施计划。（4）需求分析评审作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。评审的主要内容是:系统定义的目标是否与用户的要求一致;系统需求分析阶段提供的文档资料是否齐全;文档中的所有描述是否完整、清晰、准确所反映用户要求;与所在其他系统成分的重要接口是否都已经描述;所开发项目的数据流与数据结构是否足够、确定;所有图表是否清楚，在不补充说明时能否理解;主要功能是否已包括在规定的软件范围之内，是否都已充分说明;设计的约束条件或限制条件是否符合实际;开发的技术风险是什么;是否考虑过软件需求的其他方案;是否考虑过将来可能会提出的软件需求;是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;有没有遗漏、重复或不一致的地方;用户是否审查了初步的用户手册;软件开发计划中的估算是否受到了影响。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外，用户，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。通常，评审的结果都包括了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。3.软件需求分析的原则近年来已提出了许多软件分析与说明的方法，虽然各种分析方法都有其独特的描述方法，但总的看来，所有分析方法还是有它们共同适用的基本原则。（1）必须能够表达和理解问题的数据域和功能域所有软件定义与开发工作最终是为了解决数据处理问题，就是将一种形式的数据转换成另一种形式的数据。其转换过程必定经历输入、加工数据和产生结果数据等步骤。对于计算机程序处理的数据，其数据域应包括数据流、数据内容和数据结构。数据流即数据通过一个系统时的数据存储（如磁盘文件或内存缓冲区）中引入附加数据。对数据进行转换是程序中应有的功能或子功能。两个转换功能之间的数据传递就确定了功能间的接口。数据内容即数据项。例如，学生名册包含了班级、人数、每个学生的学号、姓名、性别、各科成绩等。学生名册的内容由它所包含的项定义。为了理解对学生名册的处理，必须要理解它的数据内容。数据结构即各种数据项的逻辑组织。数据是组织成表格，还是组织成有层次的树型结构?在结构中数据项与其他哪些数据项相关?所有数据是在一个数据结构中，还是在几个数据结构中?一个结构中的数据与其他结构中的数据如何联系?这些问题都由数据结构分析来解决。（2）必须按自项向下、逐层分解的方式对问题进行分解和不断细化如果将软件要处理的问题作为一个整体来看，显得太大太复杂很难理解。如果把问题以某种方式分解为几个较易理解的部分，并确定各部分间的接口，从而实现整体功能。在需求分析阶段，软件的功能域和信息域都能做进一步的分解。这种分解可以是同一层次上的，称为横向分解;也可以是多层次的纵向分解。例如，把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。但如果继续分解，把某些子功能又分解为小的子功能，某个小的子功能又分解为更小的功能，这就属于纵向分解了。（3）要给出系统的逻辑视图和物理视图给出系统的逻辑视图（逻辑模型）和物理视图（物理模型），这对系统满足处理需求所提出的逻辑限制条件和系统中其他成分提出的物理限制条件是必不可少的。软件需求的逻辑视图给出软件要达到的功能和要处理的数据之间的关系，而不是实现的细节。例如，一个商店的销售处理系统要从顾客那里获取订单，系统读取订单的功能并不关心订单数据的物理形式和用什么设计读入，也就是说无需关心输入的机制，只是读取顾客的订单而已。类似的，系统中检查库存的功能只关心库存文件的数据结构，而不关心在计算机中的具体存储方式。软件需求的逻辑描述是软件设计的基础。软件需求的物理视图给出处理功能和数据结构的实际表示形式，这往往是由设备决定的，如一些软件靠终端键盘输入数据，另一些软件靠模拟数据转换设备提供数据。分析员必须弄清系统元素对软件的限制并考虑功能和信息结构的物理表示。4.软件需求分析方法 需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。大多数的需求分析方法是由数据驱动的，也就是说，这些方法提供了一种表示数据域的机制。分析员根据这种表示，确定软件功能及其他特性，最终建立一个待开发软件的抽象模型，即目标系统的逻辑模型。数据域具有3种属性:数据流、数据内容和数据结构。通常，一种需求分析方法总要利用其中的一种或几种属性。目前已经出现了许多需求分析方法，每一种分析方法都引入了不同的记号和分析策略。但是它们仍具有以下的共性:（1）支持数据域分析的机制尽管每种方法进行数据域分析的方式不同，但它们仍有一些共同点。所有的方法都直接或间接地涉及到数据流、数据内容或数据结构域的属性。在多数情况下，数据流特征是用将输入转换成输出的变换（功能）过程来描述的，数据内容可以用数据词典机制明确表示，或者通过描述数据或数据对象的层次结构隐含地表示。（2）功能表示的方法功能一般用数据变换或加工来表示，每项功能可用规定的记号（圆圈或方框）标识。功能的说明可以用自然语言文本来表达，也可以用形式化的规格说明语言来表达，还可以用上述的两种方式的混合方式结构化语言来描述。（3）接口的定义接口的说明通常是数据表示和功能表示的直接产物。某个具体功能的流进和流出数据流应是其他相关功能的流出或流入的数据流。因此，通过数据流的分析可以确定功能间的接口。（4）问题分解的机制以及对抽象的支持问题分解和抽象主要依靠分析员在不同抽象层次上表示数据域和功能域，以逐层细化的手段建立分层结构来实现。例如，无论使用哪种分析方法，都能表示“计算职工每月工资”之类的功能，并在这个抽象层次上操纵这个功能。另外，所有的分析方法都提供逐层分解的机制，把“计算职工每月工资”功能划分成一些子功能，如计算房租、计算用电费、计算用水费、计算养老保险费等等。其中，每项子功能还可以在更低的一级抽象层次上表示。（5）逻辑视图和物理视图大多数方法允许分析员在着手问题的逻辑解决方案之前先分析物理视图。通常，同一种表示法既可用来表示逻辑视图，也可用来表示物理视图。（6）系统抽象模型为了能够比较精确地定义软件需求，可以建立待开发软件的一个抽象的模型，用基于抽象模型的术语来描述软件系统的功能和性能，形成软件需求规格说明。这种抽象的模型是从外部现实世界的问题领域抽象而来，在高级层次上描述和定义系统的服务。对于比较简单的问题，不必建立抽象系统模型。或者可以认为，系统模型在分析员头脑中形成，直接由分析员写成规格说明。但对于比较复杂的问题，仅有在头脑中想象的模型是不够的，必须建立适当的比较形式化的抽象系统模型，才能准确全面地反映问题领域中各种复杂的要求。不同类型的问题有不同的需要解决的中心问题，因而要建立不同类型的系统模型。对于数学软件，设计的中心问题是算法，软件人员主要力量要花在数学模式算法的考虑上。对于数据通信软件，中心问题是数据传送和过程控制，实现算法简单，采用数据流模型比较合适。对于涉及大量数据的数据处理软件，中心问题是数据处理，包括数据的采集、数据的传送、存储、变换、输出等，一旦了解了数据结构，与它相关的算法就很简单了。如果系统要求有数据支持，通过数据库获取和存放信息，还需要考虑数据在数据库中的组织方式和存取方法，建立数据库模型。因此，在分析过程中数据模型是首先要集中精力考虑的问题。系统模型的建立是对现实世界中存在的有关实体和活动的抽象和精化，其建立过程包括观察分析、模型表示和模型检查3个阶段。首先，分析员和用户合作，从各方面观察现实世界中的有关实体和活动，建立理解的共同基准，分清哪些概念与系统相关，必须纳入系统模型，哪些是系统模型不必关心的，分析员和用户在共同理解的基础上，建立系统模型，包括系统提供的各种系统服务，模型表示的细节应有:系统输入、系统输出、系统数据处理、系统控制等。建立系统模型以后，还要进行检查。除了静态检查之外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界系统观察得到的系统跟踪信息进行对照，检查模型是否符合要求。这种建立系统模型并模拟执行和检查的方法叫做系统原型开发。n 三级信息管理技术分章节考试要点：软件工程(结构化生命周期方法之系统需求)结构化生命周期方法 结构化分析与设计方法在软件工程中应用已很普遍，并且越来越成熟。有许多大、中型项目都采用了这种方法进行开发并取得了显著的成果。按B.W.Boehm的描述，瀑布模型的的软件生命周期可划分七个阶段:系统需求分析、软件需求分析、概要设计、详细设计、编码、测试和运行维护。（一）系统需求“系统需求”包括:问题定义、可行性研究及软件计划。1.问题定义软件开发的第一步就是进行问题定义。问题定义阶段必须回答的关键问题:“软件要解决的问题是什么?”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最常被忽视的一个步骤。这里所说的问题，就是指用户的基本要求。说得通俗些，问题定义实际上就是了解用户到底要建立什么系统，并确定分析员下一步应该做什么。因此，问题定义的来源是用户。通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。这一阶段的分析员应尽可能站在较高的角度去抽象、概括所要干的事情，不要拘泥于问题实现的细节。尽管用户可能总是习惯于这样做，但分析员在这一阶段必须超脱出来，居高临下鸟瞰系统的全貌。通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要地写出他对问题的理解，并在使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不清的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。当用户的要求不是很多并且不太复杂时，一两个分析员用上一两天就可以完成这一工作了。但当系统比较大，且复杂时，恐怕就要组织一个问题定义小组，花上一两个星期，甚至数月来定义用户的问题。 如果分析员和用户及使用部门的负责人对所要解决的问题取得完全一致的看法，而且使用部门的负责人同意开发工程继续进行下去，那么开发工程将转入生命周期的下一个阶段可行性研究。 2.可行性研究并不是所有问题都有简单明显的解决办法，事实上，许多问题不能在预定的系统规模之内解决。如果问题没有可行的解，那么花费在这项开发工程上的任何时间、资源、人力和经费和都是无谓的浪费。可行性研究的目的在于用最小的代价确定在问题定义阶段所确定的系统的目标和规模是否现实，所确定的问题是否可以解决，系统方案在经济上、技术上和操作上是否可以接受。可行性研究着重对如下具体方案考虑:（1）经济可行性。估计开发费用以及新系统可能带来的收益，将两者进行权衡，看结果是否可以接受。（2）技术可行性。对要求的功能、性能以及限制条件进行分析，是否能够做成一个可接受的系统。所考虑的因素通常还应包括开发的风险，是否能够得到需要的软件和硬件资源和一个熟练的有能力的开发队伍，与系统开发有关的技术是否足以支持系统的研制。技术可行性的估计，需要有经验的人员去完成。（3）操作可行性。判断系统的