2021年度安徽省公务员考试计算机软件工程.pdf

软件工程自从1968年初次提出软件工程一词以来，软件工程已成为计算机软件一种重要分支和研究方向。软件工程是指应用计算机科学、数学及管理科学等原理，以工程化原则和办法来解决软件问题工程。其目是提高软件生产率、提高软件质量、减少软件成本。一、软件工程基本概念初期软件重要指程序。程序开发采用个体工作方式，开发工作重要依赖于开发人员个人技能和程序设计技巧。当时软件普通缺少与程序关于文档，软件开发实际成本和进度往往与预测相差甚远，软件质量得不到保证，开发出来软件经常不能使顾客满意。随着计算机应用需求不断增长，软件规模也越来越大，然而软件开发生产率远远跟不上计算机应用迅速增长。此外，由于软件开发时缺少好办法指引和工具辅助，同步又缺少关于文档，使得大量已有软件难以维护。上述这些问题严重地阻碍了软件发展，20世纪60年代中期，人们把上述软件开发和维护中各种问题称为“软件危机”。1968年在德国召开NATO会议上，初次提出了“软件工程”一词，但愿用工程化原则和办法来克服软件危机。在此后来，人们开展了软件开发模型、开发办法、工具与环境研究，提出了瀑布模型、演化模型、螺旋模型、喷泉模型等开发模型，浮现了面向数据流办法、面向数据构造办法、面向对象办法等开发办法，以及批CASE(computer aided software engineering)工具和环境。(-)软件生存周期犹如人毕生要经历婴儿期、少年期、老年期直至死亡这样一种全过程同样，任何一种软件产品或软件系统也都要经历软件定义、软件开发、软件维护直至被裁减这样一种全过程，咱们把软件这一全过程称为软件生存周期,软件定义、软件开发、软件维护等阶段还可分为若干个阶段，每个阶段相对独立又彼此有联系，上一阶段工作成果是下一阶段工作根据，下一阶段是上一阶段进化，它更接近于问题解。1 .软件定义软件定义阶段重要解决问题是待开发软件要“做什么”，也就是要拟定软件解决对象，软件与外界接口，软件功能和性能，界面以及关于约束和限制。软件定义阶段普通可提成系统分析、软件项目筹划、需求分析等阶段。(1)系统分析这里讲系统是指计算机系统，涉及计算机硬件、软件和使用计算机人。系统分析任务是拟定待开发软件总体规定和合用范畴，以及与之关于硬件、支撑软件规定。系统分析阶段参加人员有顾客、项目负责人、系统分析员。该阶段产生文档可合并在软件项目筹划阶段文档(项目筹划书)中。(2)软件项目筹划软件项目筹划任务是拟定待开发软件目的，对其进行可行性分析，并对资源分派、进度安排等做出合理筹划。软件项目筹划阶段参加人员有顾客、项目负责人、系统分析员。该阶段所产生文档有可行性分析报告、项目筹划书。(3)需求分析需求分析任务是拟定待开发软件功能、性能、数据、界面等规定，从而拟定系统逻辑模型。需求分析阶段参加人员有顾客、项目负责人系统分析员。该阶段产生文档有需求规约(requirements specification),习惯上称它为需求规格阐明书。2.软件开发软件开发阶段重要解决问题是该软件“怎么做”，涉及数据构造和软件构造设计，算法设计，编写程序，测试，最后得到可交付使用软件。软件开发阶段普通可提成软件设计、编码、软件测试等阶段。(1)软件设计软件设计普通还可提成概要设计和详细设计。概要设计任务是模块分解，拟定软件构造，模块功能和模块间接口，以及全局数据构造设计。详细设计任务是设计每个模块实现细节和局部数据构造设计。概要设计阶段参加人员有系统分析员和高档程序员，详细设计阶段参加人员有高档程序员和程序员。设计阶段产生文档有设计规约(design specificatio n),也称为设计阐明书，它也可分为概要设计阐明书和详细设计阐明书。依照需要还可产生数据阐明书和模块开发卷宗。（2）编码编码任务是用某种程序语言为每个模块编写程序。编码阶段参加人员有高档程序员和程序员，产生文档有程序清单。（3）软件测试软件测试任务是发现软件中错误，并加以纠正。软件测试阶段参加人员普通由另一部门（或单位）高档程序员或系统分析员承担，该阶段产生文档有软件测试筹划和软件测试报告。3.软件维护软件开发阶段结束后，软件即可交付使用。软件使用普通要持续几年甚至几十年，在整个有效期间，都也许由于某种因素而修改软件，这便是软件维护。引起修改软件因素重要有三种:一是在软件运营过程中发现了软件中隐藏错误而修改软件;二是为了适应变化了环境而修改软件;三是为修改或扩充原有软件功能而修改软件。因而软件维护任务就是为使软件适应外界环境变化、实现功能扩充和质量改进而修改软件。软件维护阶段参加人员是维护人员，该阶段产生文档有维护筹划和维护报告。当前，软件生存周期各阶段划分尚不统一，有分得粗些，有分得细些。许多场合软件开发阶段都是从需求分析阶段开始。本书中，咱们也将需求分析看作为软件开发开始阶段。（二）软件开发模型为了指引软件开发，用不同方式将软件生存周期中所有开发活动组织起来，形成不同软件开发模型。常用软件开发模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。瀑布模型如下图所示，它 是 1970年由W.Royce提出。该模型给出了软件生存周期各阶段固定顺序，上一阶段完毕后才干进入到下一阶段，整个过程就像流水下泻，故称之为瀑布模型。图中虚线某些表达在某一阶段发现错误时，其错误也许是由上一阶段导致，因而开发过程也许要反馈到上一阶段。在瀑布模型中，各阶段结束后，都要进行严格评审。（三）软件开发办法软件开发过程模型规定软件开发活动组合应用方式，要保证开发活动高质量，还需要有相应软件开发办法作为技术支持。近来，软件工作者研制出了许多工程化软件开发办法，例如70 年代初提出用于编写程序构造化程序设计办法，的确起到了提高效率，减少错误效果。但是 70年代中期，软件工作者结识到编写程序仅仅是软件开发一种环节，而合理地建立系统构造比编定程序更为重要。因此研究重点前移到设计阶段，浮现了设计阶段构造化 设 计（SD）办法和J A C K S O N 等办法，到了 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）、面向对象分析办法（简称0 0 A）等，以及用于建立动态、模型状态迁移图或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,SA D T)、面向对象技术(Object-Oreinted Technique,OOT)、IDEF 办法等。构造化分析办法适合于数据解决类型软件需求分析。由于运用图形表达需求，显得清晰、简要，易于学习和掌握。详细来说，构造化分析办法就是用抽象模型概念，按照软件内部数据传递、变换关系，自顶向下逐级分解，直到找到满足功能规定所有可实现软件为止。依照DeMarco阐述，构造化分析办法使用工具备:数据流图、数据词典、构造化英语、鉴定表、鉴定树。构造化分析办法有两个明显特点：(1)自顶向下逐级分解。采用简要易懂、直观描述方式1.数据流图数据流图也称为Bubble Chart或 data Flow Graph 是描述数据解决过程工具。数据流图从数据传递和加工角度，以图形方式刻画数据流从输入到输出移动变换过程。(1)数据流图重要图形元素从数据流图中可知，数据流图基本图形元素有4 种。数据流是沿箭头方向传送数据通道，它们大多是在加工之间传播加工数据命名通道，也有连接数据存储文献和加工没有命名数据通道。这些数据流虽然没有命名，但因联接着有名加工和有名文献，因此其含意也是清晰。同一数据流图上不能有同名数据流。各种数据流可以指向同个加工，也可以从一种加工散发出许多数据流。加工是以数据构造或数据内容作为加工对象。加工名字普通是一种动词短语，简要扼要地表白完毕是什么加工。文献在数据流图中起保存数据作用，因而称为数据存储(Data S tore)。它可以是数据库文献或任何形式数据组织。指向文献数据流可理解为写入文献或查询文献，从文献中引出数据流可理解为从文献读取数据或得到查询成果。数据流图中第4 种元素是数据源点或汇点，它表达图中要解决数据输入来源及解决成果要送往何处。由于它在图中浮现仅仅是一种符号，并不需要以软件形式进行设计和实现，因而，它只是数据流图外围环境中实体，故称外部实体。在实际问题中它也许是计算机外围设备或是传感装置。(2)数据流与加工之间关系在数据流图中，如果有两个以上数据流指向一种加工，或是从一种加工中引出两个以上数据流，这些数据流之间往往存在一定关系。(3)分层数据流图为了表达数据解决过程数据加工状况，用一种数据流图是不够。为表达稍为复杂实际问题需要按照问题层次构造进行逐渐分解，并以分层数据流图反映这种构造关系。先把整个数据解决过程暂且当作一种加工，它输入数据和输出数据事实上反映了系统与外界环境接口。这就是分层数据图顶层。但只此一图并未表白数据加工规定，需要进一步细化。如果这个数据解决涉及3 个子系统，就可以画出表达这3 个子系统1、2、3 加工及其有关数据流。这是顶层下面第一层数据流图，记为DFD/L1。继续分解这3 个子系统，可得到第二层数据流图DFD/L2、DFD/L2.2,及 DFD/L2.3,它们分别是子系统。1、2 和 3 细化。仅以DF/2为例，其中4 个加工编号均可联系到其上层图中子系统2。这样得到多层数据流图可十分清晰地表达整个数据加工系统真实状况。对任何一层数据流图来说，称它上层图为父图，在它下一层图则称为子图。在多层数据流图中，可以把顶层流图、底层流图和中间层流图区别开。顶层流图仅包括一种加工，它代表被开发系统。它输入流是该系统输入数据，输出流是系统输出数据。顶层流图作用在于表白被开发系统范畴，以及它和周边环境数据互换关系。底层流图是指其加工不须再做分解数据流图，其加工称为“原子加工”。中间层流图则表达对其上层父图细化。它每一加工可以继续细化，形成子图。中间层次多少视系统复杂限度而定。(4)数据流图画法画数据流图基本环节概括地说，就是自外向内，自顶向下，逐级细化,完善求精。详细环节可按如下来做。先找系统数据源点与汇点。它们是外部实体，由它们拟定系统与外界接口。找出外部实体输出数据流与输入数据流。在图边上画出系统外部实体。从外部实体输出数据流(即系统源点)出发，按照系统逻辑需要，逐渐画出一系列逻辑加工，直到找到外部实体所需输入数据流(即系统汇点)，形成数据流封闭。按照下面所给原则进行检查和修改.按照上述环节，再从各加工出发，画出所需子图。(5)进行检查和修改原则数据流图上所有图形符号只限于前述四种基本图形元素。数据流主图必要涉及前述4 种基本元素，缺一不可。数据流图主图上数据流必要封闭在外部实体之间，外部实体可以不只一种。每个加工至少有一种输入数据流和一种输出数据流。在数据流图中，需按层给加工框编号。编号表白该加工处在哪一层，以及上下层父图与子图相应关系。任何一种数据流子图必要与它上一层一种加工相应，两者输入数据流和输出数据流必要一致。即父图与子图平衡，它表白了在细化过程中输入与输出不能有丢失和添加。图上每个元素都必要有名字。表白数据流和数据文献是什么数据，加工做什么事情。数据流图中不可夹带控制流。由于数据流图是实际业务流程客观映象，阐明系统“做什么”而不是要表白系统“如何做”，因而不是系统执行顺序，不是程序流程图。初画时可以忽视琐碎细节，以集中精力于重要数据流。在需求分析期间，有时会规定修改系统某些方面。使用数据流图可以很容易地把需要修改区域分离出来。只要清晰地理解穿过要修改区域边界数据流，就可觉得将来修改做好充分准备，并且在修改时可以不打乱系统其她某些。2.数据词典数据词典任务是对于数据流图中浮现所有被命名图形元素在数据词典中作为一种词条加以定义，使得每一种图形元素名字均有一种确切解释。数据词典中所有定义应是严密、精准，不可有半点含糊，不可有二义性。（1）数据词典定义对在数据流图中每一种命名图形元素均予以定义，其内容有图形元素名字、别名或编号、分类、描述、定义、位置等。如下是不同词条应给出内容。数据流词条描述数据流是数据构造在系统内传播途径。一种数据流词条应有如下几项内容:数据流名:阐明:简要简介作用即它产生因素和成果。数据流来源:来自何方。数据流去向:去向何方。数据流构成:数据构造。每个数据量:数据量，流通量.数据元素词条描述图中每一种数据构造都是由数据元素构成，数据元素是数据解决中最小，不可再分单位，它直接反映事物某一特性。对于这些数据元素也必要在数据词典中给出描述。其描述需要如下信息:数据元素名类型:数字（离散值，持续值），文字S（编码类型）。长度。取值范畴。有关数据元素及数据构造。数据元素取值可分数字型与文字型。数字型又有离散值与持续值之分。离散值或是枚举，或是介于上界一组数;持续值普通是有取值范畴实数集。对于文字型，需予以编码类型，文字值需加以定义。数据文献词条描述数据文献是数据构造保存地方。一种数据文献词条应有如下几项内容。数据文献名。简述:存储是什么数据。输入数据。输出数据。数据文献构成:数据构造。存储方式:顺序，直接，核心码。存取频率。加工逻辑词条描述加工比较复杂，它到日后就是一段程序。加工表达方式有鉴定表，鉴定树和构造化英语等等，它们要所有写在一种词条中是有困难。重要描述有。加工名。加工编号:反映该加工层次。简要描述:加工逻辑及功能简述。输入数据流。输出数据流。加工逻辑:简述加工程序，加工顺序。源点及汇（终）点词条描述对于一种数据解决系统来说，源点和汇点应当比较少。如果过多就缺少独立性，人一机界面太复杂，这时就要考虑减少，提高系统独立性。定义源点和汇点时，应涉及。名称:外部实体名。简要描述:什么外部实体。关于数据流。数目。（2）数据词典使用在构造化分析过程中，可以通过名字，以便地查阅数据定义:同步可按各种规定，随时列出各种表，以满足分析员需要。还可以按描述内容（或定义）来查询数据名字，通过检查各个加工逻辑功能，可以实现和检查在数据与程序之间一致性和完整性，在后来设计与实现阶段，以至于到维护阶段。都需要参照数据词典进行设计、修改和查询。（3）数据构造描述在数据词典编制中，分析员最惯用描述数据构造方式有定义式或Warnie r图。定义式在数