2023年安徽省公务员考试计算机软件工程.doc

软件工程
自从1968年初次提出软件工程一词以来，软件工程已成为计算机软件的一个重要分支和研究方向。软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程。其目的是提高软件生产率、提高软件质量、减少软件成本。
一、软件工程基本概念
初期的软件重要指程序。程序的开发采用个体工作方式，开发工作重要依赖于开发人员的个人技能和程序设计技巧。当时的软件通常缺少与程序有关的文档，软件开发的实际成本和进度往往与预计的相差甚远，软件的质量得不到保证，开发出来的软件经常不能使用户满意。随着计算机应用的需求不断增长，软件的规模也越来越大，然而软件开发的生产率远远跟不上计算机应用的迅速增长。此外，由于软件开发时缺少好的方法指导和工具辅助，同时又缺少有关的文档，使得大量已有的软件难以维护。上述这些问题严重地阻碍了软件的发展，20世纪60年代中期，人们把上述软件开发和维护中的各种问题称为“软件危机”。1968年在德国召开的NATO会议上，初次提出了“软件工程”一词，希望用工程化的原则和方法来克服软件危机。在此以后，人们开展了软件开发模型、开发方法、工具与环境的研究，提出了瀑布模型、演化模型、螺旋模型、喷泉模型等开发模型，出现了面向数据流方法、面向数据结构的方法、面向对象方法等开发方法，以及一批CASE（computer aided software engineering）工具和环境。
（一） 软件生存周期
如同人的一生要经历婴儿期、少年期、老年期直至死亡这样一个全过程同样，任何一个软件产品或软件系统也都要经历软件定义、软件开发、软件维护直至被淘汰这样一个全过程，我们把软件的这一全过程称为软件生存周期。软件定义、软件开发、软件维护等阶段还可分为若干个阶段，每个阶段相对独立又彼此有联系，上一阶段的工作结果是下一阶段工作的依据，下一阶段是上一阶段的进化，它更接近于问题的解。
1.软件定义
软件定义阶段重要解决的问题是待开发的软件要“做什么”，也就是要拟定软件的解决对象，软件与外界的接口，软件的功能和性能，界面以及有关的约束和限制。软件定义阶段通常可提成系统分析、软件项目计划、需求分析等阶段。
（1）系统分析这里讲的系统是指计算机系统，涉及计算机硬件、软件和使用计算机的人。系统分析的任务是拟定待开发软件的总体规定和合用范围，以及与之有关的硬件、支撑软件的规定。系统分析阶段的参与人员有用户、项目负责人、系统分析员。该阶段产生的文档可合并在软件项目计划阶段的文档（项目计划书）中。
（2）软件项目计划软件项目计划的任务是拟定待开发软件的目的，对其进行可行性分析，并对资源分派、进度安排等做出合理的计划。软件项目计划阶段的参与人员有用户、项目负责人、系统分析员。该阶段所产生的文档有可行性分析报告、项目计划书。
（3）需求分析需求分析的任务是拟定待开发软件的功能、性能、数据、界面等规定，从而拟定系统的逻辑模型。需求分析阶段的参与人员有用户、项目负责人系统分析员。该阶段产生的文档有需求规约（requirements specification），习惯上称它为需求规格说明书。
2.软件开发
软件开发阶段重要解决的问题是该软件“怎么做”，涉及数据结构和软件结构的设计，算法设计，编写程序，测试，最后得到可交付使用的软件。软件开发阶段通常可提成软件设计、编码、软件测试等阶段。
（1）软件设计软件设计通常还可提成概要设计和具体设计。概要设计的任务是模块分解，拟定软件的结构，模块的功能和模块间的接口，以及全局数据结构的设计。具体设计的任务是设计每个模块的实现细节和局部数据结构的设计。概要设计阶段的参与人员有系统分析员和高级程序员，具体设计阶段的参与人员有高级程序员和程序员。设计阶段产生的文档有设计规约（design specification），也称为设计说明书，它也可分为概要设计说明书和具体设计说明书。根据需要还可产生数据说明书和模块开发卷宗。
（2）编码编码的任务是用某种程序语言为每个模块编写程序。编码阶段的参与人员有高级程序员和程序员，产生的文档有程序清单。
（3）软件测试软件测试的任务是发现软件中的错误，并加以纠正。软件测试阶段的参与人员通常由另一部门（或单位）的高级程序员或系统分析员承担，该阶段产生的文档有软件测试计划和软件测试报告。
3.软件维护
软件开发阶段结束后，软件即可交付使用。软件的使用通常要连续几年甚至几十年，在整个使用期间，都也许由于某种因素而修改软件，这便是软件维护。引起修改软件的因素重要有三种:一是在软件运营过程中发现了软件中隐藏的错误而修改软件;二是为了适应变化了的环境而修改软件;三是为修改或扩充原有软件的功能而修改软件。因此软件维护的任务就是为使软件适应外界环境的变化、实现功能的扩充和质量的改善而修改软件。软件维护阶段的参与人员是维护人员，该阶段产生的文档有维护计划和维护报告。目前，软件生存周期各阶段的划分尚不统一，有的分得粗些，有的分得细些。许多场合软件开发阶段都是从需求分析阶段开始的。本书中，我们也将需求分析看作为软件开发的开始阶段。
（二） 软件开发模型
为了指导软件的开发，用不同的方式将软件生存周期中的所有开发活动组织起来，形成不同的软件开发模型。常见的软件开发模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。瀑布模型如下图所示，它是1970年由W.Royce提出的。该模型给出了软件生存周期各阶段的固定顺序，上一阶段完毕后才干进入到下一阶段，整个过程就像流水下泻，故称之为瀑布模型。图中的虚线部分表达在某一阶段发现错误时，其错误也许是由上一阶段导致的，因此开发过程也许要反馈到上一阶段。在瀑布模型中，各阶段结束后，都要进行严格的评审。
（三） 软件开发方法
软件开发过程模型规定软件开发活动的组合应用方式，要保证开发活动的高质量，还需要有相应的软件开发方法作为技术支持。近2023来，软件工作者研制出了许多工程化的软件开发方法，例如70年代初提出的用于编写程序的结构化程序设计方法，的确起到了提高效率，减少错误的效果。但是70年代中期，软件工作者结识到编写程序仅仅是软件开发的一个环节，而合理地建立系统结构比编定程序更为重要。所以研究的重点前移到设计阶段，出现了设计阶段的结构化设计（SD）方法和JACKSON等方法，到了70年代后期，人们又发现事先对用户的规定进行分析更为重要，故又把重点前移到分析阶段。出现了用于分析阶段的结构化分析（SA）方法、结构化分析与设计技术（SADT）等。随着计算机技术的迅速发展，在80年代初期的实时、并发和网络等软件的开发过程中，特别是在第五代计算机研究工作中，又提出了面向对象的设计方法。现在流行的方法有多种，它们的合用范围也各不相同。有的合用于一般的数据解决系统，如SA、SD（两者统称为结构化分析与设计方法，即Yourdon方法）、JACKSON方法;有的合用于大型的复杂系统，如SADT技术;有的合用于实时事务解决系统，如FSM方法;有的合用于并发软件系统，如PETRI网方法;作为90年代代表作的面向对象方法，其应用已几乎遍布各个领域。这些方法除了合用范围不同外，方法形成的基础、解决规则和对所开发软件风格的规定等都各有侧重。用什么方法来说明用户的规定、用什么方法来设计软件以及用什么方法对软件进行测试和维护，直接影响所开发软件的质量。
（四） 软件开发工具
初期的软件开发除了一般的程序设计语言外尚缺少工具的支持，致使编程工作量大，质量和进度却难以保证，导致人们将很多的精力和时间花费在程序的编制和调试上;相比之下，在更重要的软件的需求和设计上反而得不到必要的精力和时间投入。软件开发工具的发展促进了软件开发的高速度和高质量。工具的发展是从单项工具的开发逐步走向集成的工具发展的。同时，软件开发方法的有效应用也必须得到相应工具的支持，否则方法将难以有效的实行。工具的完善和发展将促进软件开发的进步和完善。原型化方法的实行基础就是得到了开发工具的支持。快速原型化之所以可以实现的基础就是原型化人员在快速建模时得到了工具的支持，否则原型化方法是无法实行的。
（五） 软件开发环境
软件工程环境或称软件开发环境是全面支持软件开发全过程的软件工具集合。这些软件工具按照一定的方法或模式组合起来，并能支持软件开发生命周期的各个阶段和各项任务的完毕。CASE，即计算机辅助软件工程环境是当前软件开发环境中富于特色的研究工作和发展方向，它的成功将最大限度地减少软件工程的技术难度并使软件开发的质量得到保证。
二、结构化生命周期方法
结构化分析与设计方法在软件工程中应用已很普遍，并且越来越成熟。有许多大、中型项目都采用了这种方法进行开发并取得了显著的成果。按B.W.Boehm的描述，瀑布模型的的软件生命周期可划分七个阶段:系统需求分析、软件需求分析、概要分析、具体设计、编码、测试和运营维护。
（一） 系统需求
“系统需求”涉及:问题定义、可行性研究及软件计划。
1.问题定义
软件开发的第一步就是进行问题定义。问题定义阶段必须回答的关键问题:“软件要解决的问题是什么?”假如不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很也许是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却也许是最常被忽视的一个环节。这里所说的问题，就是指用户的基本规定。说得通俗些，问题定义事实上就是了解用户到底要建立什么系统，并拟定分析员下一步应当做什么。因此，问题定义的来源是用户。通过问题定义阶段的工作，系统分析员应当提出关于问题性质、工程目的和规模的书面报告。这一阶段的分析员应尽也许站在较高的角度去抽象、概括所要干的事情，不要拘泥于问题实现的细节。尽管用户也许总是习惯于这样做，但分析员在这一阶段必须超脱出来，居高临下鸟瞰系统的全貌。通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要地写出他对问题的理解，并在使用部门负责人的会议上认真讨论这份书面报告，澄清模糊不清的地方，改正理解不对的的地方，最后得出一份双方都满意的文档。当用户的规定不是很多并且不太复杂时，一两个分析员用上一两天就可以完毕这一工作了。但当系统比较大，且复杂时，恐怕就要组织一个问题定义小组，花上一两个星期，甚至数月来定义用户的问题。假如分析员和用户及使用部门的负责人对所要解决的问题取得完全一致的见解，并且使用部门的负责人批准开发工程继续进行下去，那么开发工程将转入生命周期的下一个阶段———可行性研究。
2.可行性研究
并不是所有问题都有简朴明显的解决办法，事实上，许多问题不能在预定的系统规模之内解决。假如问题没有可行的解，那么花费在这项开发工程上的任何时间、资源、人力和经费和都是无谓的浪费。可行性研究的目的在于用最小的代价拟定在问题定义阶段所拟定的系统的目的和规模是否现实，所拟定的问题是否可以解决，系统方案在经济上、技术上和操作上是否可以接受。可行性研究着重对如下具体方案考虑:
（1）经济可行性。估计开发费用以及新系统也许带来的收益，将两者进行权衡，看结果是否可以接受。
（2）技术可行性。对规定的功能、性能以及限制条件进行分析，是否可以做成一个可接受的系统。所考虑的因素通常还应涉及开发的风险，是否可以得到需要的软件和硬件资源和一个纯熟的有能力的开发队伍，与系统开发有关的技术是否足以支持系统的研制。技术可行性的估计，需要有经验的人员去完毕。
（3）操作可行性。判断系统的操作方式在该用户组织内是否可行。分析、设计人员应以新系统的目的和作用范围为依据提出一种以上的设计方案，从技术可行性、经济可行性、操作可行性等方面进行比较，并选择出综合最优的方案。根据可行性研究结果要做出的决定是:是否继续按预定目的进行这项开发工程，可行性分析人员必须清楚地表白他对这个关键性决定的建议。假如认为值得继续进行这项开发工程，则应提供选择一种最佳的解法并说明理由。可行性分析是在问题的目的和约束之间的一种权衡，还也许有的结果则是修改目的或放宽约束。
3.软件计划
分析人员应当为推荐的系统草拟一份软件计划，其中描述的是为了成功地进行一个软件项目，其所需要做的工作、需要的资源、需要的工作量和费用以及应遵循的进度安排。软件计划由两项任务组成:分析和估算。分析是对系统内各软件功能的界线的划定。估算是指根据已有的定性数据和已往的经验对系统开发的资源、费用和进度进行定量的估计。软件开发项目的进度安排可以从两种观点来考虑:一是项目的交付日期已定，负责开发工作的软件机构被限制在一个规定的时间范围内分派其工作量。二是项目最后的交付日期由软件机构自已拟定，可以从最佳的运用各种资源的角度出发来分派工作量，项目最后的交付日期通过对软件各部分仔细分析后才拟定。在多数项目中，碰到的往往是第一种情况。软件计划的阅读者可以涉及软件主管部门、用户和技术人员。所拟定的成本与进度可供主管部门复审。它同时也给出了整个软件生命周期的基本成本预算的进度安排。
（二） 软件需求分析
软件需求分析工作是软件生存期中重要的一步，也是决定性的一步。只有通过软件需求分析，才干把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。软件需求分析工作也是一个不断结识和逐步细化的过程。该过程将软件设计阶段所拟定的软件范围（工作域）逐步细化到可具体定义的限度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决方法。制定软件的需求规格说明不只是软件开发人员的事，用户也起着至关重要的作用。用户必须对软件功能和性能提出初步规定，并澄清一些模糊概念。而软件分析人员则要认真了解用户的规定，细致地进行调查分析，把用户“做什么”的规定最终转换成一个完全的、精细的软件逻辑模型并写出软件的需求规格说明，准确地表达用户的规定。
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个阶段。一方面，分析员和用户合作，从各方面观测现实世界中的有关实体和活动，建立理解的共同基准，分清哪些概念与系统相关，必须纳入系统模型，哪些是系统模型不必关心的，分析员和用户在共同理解的基础上，建立系统模型，涉及系统提供的各种系统服务，模型表达的细节应有:系统输入、系统输出、系统数据解决、系统控制等。建立系统模型以后，还要进行检查。除了静态检查之外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界系统观测得到的系统跟踪信息进行对照，检查模型是否符合规定。这种建立系统模型并模拟执行和检查的方法叫做系统原型开发。
（三） 结构化分析方法
结构化分析是面向数据流进行需求分析的方法。20世纪70年代末，经Yourdon E.，Conˉstantine L.，DeMarco T.等人提出和发展，至今已得到广泛应用。结构化分析方法的一些重要概念也渗透在其他开发方法中。例如，结构化分析与设计技术（Structured Analysis and Design Technique，SADT）、面向对象技术（Object-Oreinted Technique，OOT）、IDEF方法等。结构化分析方法适合于数据解决类型软件的需求分析。由于运用图形表达需求，显得清楚、简明，易于学习和掌握。具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能规定的所有可实现的软件为止。根据DeMarco的论述，结构化分析方法使用的工具有:数据流图、数据词典、结构化英语、鉴定表、鉴定树。结构化分析方法有两个明显特点:
（1）自顶向下逐层分解。采用简明易懂、直观的描述方式
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.数据词典
数据词典的任务是对于数据流图中出现的所有被命名的图形元素在数据词典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。数据词典中所有的定义应是严密的、精确的，不可有半点模糊，