需求工程与需求分析课件

第3章需求工程与需求分析1第3章需求工程与需求分析13.1基本的软件需求22基本的软件需求软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得到的软件存在着巨大期望差异。3基本的软件需求软件项目中百分之四十至百分之六十的问题基本的软件需求在软件工程中，所有的风险承担者(stakeholder)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础。4基本的软件需求在软件工程中，所有的风险承担者(st3.1.1软件需求的定义⑴用户解决问题或达到目标所需的条件或权能（Capability）。⑵系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。⑶一种反映上面⑴或⑵所描述的条件或权能的文档说明。53.1.1软件需求的定义⑴用户解决问题或达到目标所3.1.1软件需求的定义1.一些关于“需求”的解释需求的关键的问题是一定要编写需求文档。如果只有一堆邮件、贴条、会谈过几次或一些零碎的对话，你就确信你已明白用户的需求，那完全是自欺欺人。

许多的需求分析专家给出了不同形式的需求定义，但从这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。任何文档形式的需求（例如：需求规格说明）仅是一个模型，一种叙述（Lawrence1998）。我们需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。63.1.1软件需求的定义1.一些关于“需求”的解释63.1.1软件需求的定义2．需求的层次

下面这些定义是需求工程领域中常见术语的定义说明。软件需求包括三个不同的层次——业务需求、用户需求和功能需求（包括非功能需求）。⑴业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。⑵用户需求（userrequirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本（scenario）说明中予以说明。⑶功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。73.1.1软件需求的定义2．需求的层次73.1.1软件需求的定义83.1.1软件需求的定义83.1.2需求的开发和管理需求中名词术语的混淆将导致对科目（规范，discipline）叫法的不一致。一些作者把整个需求范围称之为“需求工程”，另一些则称之为“需求管理”。软件专家认为可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适：93.1.2需求的开发和管理需求中名词术语的混淆将导3.1.2需求的开发和管理需求开发可进一步分为：需求获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段。需求开发活动包括以下几个方面：⑴确定产品所期望的用户类。⑵获取每个用户类的需求。⑶了解实际用户任务和目标以及这些任务所支持的业务需求。⑷分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。103.1.2需求的开发和管理需求开发可进一步分为：需3.1.2需求的开发和管理⑸将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。⑹了解相关质量属性的重要性。⑺商讨实施优先级的划分。⑻将所收集的用户需求编写成规格说明和模型。⑼评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。113.1.2需求的开发和管理⑸将系统级的需求分为几个3.1.2需求的开发和管理需求管理需要“建立并维护在软件工程中同客户达成的契约”(CMU/SEI1995)。这种契约都包含在编写的需求规格说明与模型中。通常的需求管理活动包括：⑴定义需求基线（迅速制定需求文档的主体）。⑵评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。⑶以一种可控制的方式将需求变更融入到项目中。⑷使当前的项目计划与需求一致。⑸估计变更需求所产生影响并在此基础上协商新的承诺(约定)。⑹让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。⑺在整个项目过程中跟踪需求状态及其变更情况。123.1.2需求的开发和管理需求管理需要“建立并维3.1.2需求的开发和管理需求开发和需求管理之间的区别133.1.2需求的开发和管理需求开发和需求管理之间的区别133.1.3需求工程的作用1．支持项目的开发。

需求工程过程是软件开发阶段的前提和基础。2．支持测试和验证

需求规格说明书将为项目测试和验证提供基准，可以用来检查设计和验证系统。3．支持维护

维护阶段的工作同以下几个方面紧密联系：⑴修改在测试阶段中尚未检查出来的少量残留编码错误。⑵软件运行一段时间后，因环境因素的改变而产生的软件的适应性维护。⑶用户在软件交付使用后又重新提出扩充功能的需求时的软件维护。4．支持项目承包商需求的证实过程为拟构造系统的正确性提供了进一步的根据。5．支持管理为了保证项目的顺利进行，项目管理者必须有一个完备的项目计划，包括开销、交付日期、可用资源、交付条件等等。143.1.3需求工程的作用1．支持项目的开发。143.2需求获取15153.2.1需求获取过程需求获取时期的主要工作：⑴归纳和整理用户提出的各种问题和要求；⑵弄清用户企图通过软件达到的目的；⑶借助各种工具和方法，陈述用户提出的实际需求，并标定软件的作用范围。163.2.1需求获取过程需求获取时期的主要工作：163.2.2需求获取方法需求获取方法包括两个方面：⑴指导开发小组获取用户需求的方法框架。⑵支持控制此项活动进展的过程控制机制。173.2.2需求获取方法需求获取方法包括两个方面：173.2.3当前状况⑴误解：由于分析员并非该应用领域的专家，使得在需求获取时，误解了用户潜在的隐含假设。⑵交流障碍：领域专家同一个新手交谈时的用词往往并不足以解决问题。⑶缺乏共同语言：由于需求分析员和系统用户的经历和教育背景不同，他们之间通常缺乏足够的沟通。⑷“完整性”问题：软件工程师希望提出系统需求的用户领域专家能清晰、简明和完备地描述出确实可行的系统需求，然而，所要的需求知识在其最初阶段可能是模糊、不完备甚至是不正确的。⑸需求永远不会稳定：用户对软件的需求常常会发生变化，并且是不可预测的。⑹用户意见不统一：大系统往往有各种不同的用户，他们往往有互相冲突的需求和不同的需求优先次序，寻求折衷是不容易的。⑺错误的要求：系统的定购者（付钱的人）和系统的使用者经常不是一个人，定购者由于受到组织或经费的限制，提出的需求会与最终用户的需求相冲突。⑻认识混淆：有时系统的目标和系统的需求会发生混淆。目标是系统应达到的更为一般的特征，而需求应是可测试的。183.2.3当前状况⑴误解：由于分析员并非该应用领域解决问题的建议1.了解系统需求2.市场调查3.访问用户和用户领域专家4.考察现场19解决问题的建议1.了解系统需求19调查的方式1.调查提纲或调查表2.小型调查会议3.个别访问4.现场调查5.资料6.调查工具20调查的方式1.调查提纲或调查表20调查中应注意的事项1.不要用计算机专业术语与用户或用户领域专家交谈2.不要使用“你应该…”这样的字眼3.始终记住自己最近一段工作中要达到的目标，引导用户说出你需要的信息4.要善于把用户中职位高的人和职位低的人的谈话结合起来分析21调查中应注意的事项1.不要用计算机专业术语与用户或用户3.3需求分析任务22223.3需求分析任务需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。233.3需求分析任务需求分析所要做的工作是深入描述3.3需求分析任务⑴正确地确定对系统综合要求，充分理解和表达用户的需求。也就是详细定义开发软件的功能、性能、外部接口、设计限制、数据库需求、确定硬件和软件支持环境、辅助软件以及将来可能提出的要求。⑵通过结构分析的方法对系统进行分解，以确定软件系统的主要成分或软件系统的构成。243.3需求分析任务⑴正确地确定对系统综合要求，充分3.3需求分析任务⑶是对以上已进行的两项工作进行描述，以形成需求文档，也就是编制“需求规格说明书”。它应明确地定义要开发软件的需求；系统的构成及有关接口。

需求规格说明书的作用在于：①提供一个用户和开发者对开发软件的共同的理解；②相当于用户和开发单位之间的一份技术合同；③是今后各阶段设计的基本依据；④是今后验收测试阶段对软件进行确认和验收的基准。253.3需求分析任务⑶是对以上已进行的两项工作进行描3.3需求分析任务⑷编写用户手册概要，迫使分析员从用户的角度看待软件，及早考虑用户界面工作，此时编写的重点在系统输入和输出。把整个软件系统分解为若干个子系统或软件成分(如软件包)，把整个软件的外部功能分配给软件系统的各功能成分，并详细地定义每个软件成分的外部功能以及它们间的接口。⑸编写验收计划，作为今后验收测试的依据。⑹修正可行性研究阶段所制订的软件项目开发计划。由于在需求分析过程中对将要开发的系统有了更深入的了解，所以可以更准确地估计开发成本、进度和资源需求。有必要对原计划作出适当修正。263.3需求分析任务⑷编写用户手册概要，迫使分析员3.4需求分析过程27273.4.1功能性需求功能性需求包括：1．功能需求例举出开发软件在职能上应做什么，这是最主要的需求。2．性能需求给出所开发软件的技术性能指标，包括存储容量限制、运行时间限制、安全保密性等。3．环境需求软件系统运行时多所处的环境要求。4．可靠性需求各种软件在运行时，失败的影响各不相同，在需求分析时，应对所开发的软件在投入运行后不发生故障的概率，按实际的运行环境提出的要求。283.4.1功能性需求功能性需求包括：283.4.1功能性需求5．安全保密要求把软件运行的安全需求恰当地做出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全保密方面的性能得到必要的保证。6．用户界面需求软件与用户界面的友好性是用户能够方便有效、愉快地使用该软件的关键之一。7．资源使用需求开发软件运行时所需的数据、软件、内存空间等各项资源。8．软件成本消耗与开发进度需求软件项目立项后，要根据合同规定，对软件开发的进度和各项步骤的费用提出要求，作为开发管理的依据。9．预先估计系统可能达到的目标在开发过程中可对系统将来可能的扩充与修改做准备。293.4.1功能性需求5．安全保密要求29【例1】假设需要制造一个带有四个按钮和两个灯泡的盒子并具有以下功能：⑴有四个按钮输入，分别称为B1，B2，B3和B4；⑵有两个灯泡作为输出，分别称为L1和L2；⑶B1是打开电源的按钮；⑷B4是关闭电源的按钮；⑸B2和B3是操作按钮；⑹在B1被按下后及B4被按下前，系统应称为电源打开状态；⑺在B4被按下后及B1被按下前，系统应称为电源关闭状态；⑻在电源关闭状态下，B2和B3按钮不起作用；⑼在电源关闭状态下，灯应不亮；⑽从最近一次电源打开状态算起，如果B2被按下的次数比B3被按下的次数多，L1亮，否则L2亮。⑾任何时候都不能有一个以上的灯泡亮；⑿如果其中的一个灯泡出现故障，另一个灯泡应以2秒钟的间隔闪烁，而不管B2和B3的操作过程。当B4按下时，闪烁停止；当B1被按下时，闪烁重新开始。当故障被排除后闪烁停止，系统恢复正常状态。30【例1】假设需要制造一个带有四个按钮和两个灯泡的盒子并具有以疑问？1.对于在灯泡出现故障时是否要记录下B2和B3的操作过程2.系统记录或不记录B2和B3的操作，对于故障排除后系统的反应如何31疑问？1.对于在灯泡出现故障时是否要记录下B2和B3的3.4.2非功能性需求非功能性需求即为软件的“约束”:非功能性需求过程需求产品需求外部需求交付需求实现方法需求标准需求可用性需求效用需求可靠性需求可移植性需求可重复需求安全保密性需求…性能需求应用需求法规需求费用需求互操作需求323.4.2非功能性需求非功能性需求即为软件的“约束3.4.3需求分析文档1．需求规格说明书的作用

⑴为用户、分析人员和软件设计人员之间的理解和交流提供了方便；⑵支持目标软件系统的确认；⑶起到控制系统演进的作用。

2．什么样人阅读需求规格说明书

必须阅读需求规格说明书的是各种背景和技术能力都不同的人：客户和使用者，分析人，设计师和工程师，项目管理者等。333.4.3需求分析文档1．需求规格说明书的作用333.4.3需求分析文档3．需求规格说明书编写分类⑴按方法分类：形式化方法和非形式化方法非形式化的需求规格说明书是用自然语言写的，可以用图表和其他符号帮助理解，也可以用标准化的格式来编制。形式化的需求规格说明书是用完全精确的语法和语义来表达。半形式化的需求规格说明书也很有用。它采用了一些符号，但对这些符号并没有给予精确的定义。⑵按文档内容的性质分类：操作性和说明性操作性的需求规格说明书通过说明所要求的行为来描述要求哪种系统，通常提供一个系统模型作为模拟系统行为的抽象装置。说明性的需求规格说明书用纯粹的说明方式来描述系统的特性。343.4.3需求分析文档3．需求规格说明书编写分类343.4.3需求分析文档4．需求规格说明书主要内容：⑴概述。从系统的角度描述软件的目标和任务。⑵数据描述①数据流图②数据字典③系统接口说明④内部接口说明⑶功能描述①功能②处理③设计的限制353.4.3需求分析文档4．需求规格说明书主要内容：33.4.3需求分析文档⑷性能描述①性能指标②测试种类③预期的软件响应性能④其它⑸参考文献目录⑹附录363.4.3需求分析文档⑷性能描述363.5验证37373.5.1需求说明的特征1.完整性每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。2.正确性每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。383.5.1需求说明的特征1.完整性383.5.1需求说明的特征3.可行性每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（elicitation）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。4.必要性每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。393.5.1需求说明的特征3.可行性393.5.1需求说明的特征5.可修改性在必要时或为维护每一需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。6.可跟踪性应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段大段的叙述。403.5.1需求说明的特征5.可修改性403.5.1需求说明的特征7.划分优先级给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。8.无二义性对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。9.可验证性检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。413.5.1需求说明的特征7.划分优先级413.6软件原型系统开发4242传统模型的工作特点传统软件生存期模型的典型代表是“瀑布模型”。这种模型将软件生存期划分为若干阶段，根据不同阶段的工作特点，运用不同的方法、技术和工具来完成该阶段的任务。传统思想之所以强调每一阶段的严格性，尤其是开发初期要有良好的软件说明，主要是源于过去软件开发的经验教训，即在开发的后期或运行维护期间，修改不完善的规格说明要付出巨大的代价。43传统模型的工作特点传统软件生存期模型的典型代表是“瀑什么是原型系统开发建立系统模型以后，还要进行检查。除了静态检查外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界系统观察得到的系统跟踪信息进行对照，检查模型是否符合要求。这种建立系统模型并模拟执行和检查的办法叫做系统原型开发。44什么是原型系统开发建立系统模型以后，还要进行检查。除了软件系统的快速原型的概念的形成在实际工作中，特别是对于一些大型的软件项目，在开发的早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求，软件人员对于要解决的应用问题认识更是模糊不清。随着开发工作向前推进，用户可能产生新的要求，或因环境变化，要求系统也随之变化；开发者又可能在设计与实现的过程中遇到一些没有预料到的困难，需要以改变需求来解脱困境。45软件系统的快速原型的概念的形成在实际工作中，特别是对3.6.1软件原型化方法概述通常，原型是指模拟某种产品的原始模型。在软件开发过程中，原型是软件一个早期可运行的版本，它反映最终系统的部分重要特性。系统原型是软件系统的初始版本，它可用来展示一些概念，给出设计选择、发现问题和可能的解决方案。其目的就是为了有效的控制开发成本，使开发人员可以较早地在原型系统上验证自己的设计。463.6.1软件原型化方法概述通常，原型是指模拟某软件原型支持需求工程过程的活动1.需求的导出系统原型允许用户在上面实验，以便了解系统如何支持他们的工作的。在这个过程中，用户可能产生有关需求的许多新的想法，同时发现系统的优点和不足，进而提出新的系统需求。2.需求的有效性验证原型系统可以暴露出错误和遗漏的东西。一个经过描述的功能可能是很有用且已经是定义了的，但是，当这个功能模块与其他模块一起工作时，用户可能发现他们最初的想法是错误的或是不完善的，必须修改系统描述以反映对需求的新的理解。47软件原型支持需求工程过程的活动1.需求的导出47系统原型开发的优点1.开发人员和用户之间的理解偏差在功能展示显露出来。2.开发小组可能会在原型设计中发现需求的不完善和不一致。3.可以迅速展示一个应用系统对管理的可行性和作用。4.原型可以用作书写产量-质量系统描述的基础。5.原型可支持用户的训练和系统的测试。48系统原型开发的优点1.开发人员和用户之间的理解偏差在功能展原型开发的过程模型49原型开发的过程模型49研究发现系统原型开发的其它优点Gordon和Bieman经过研究发现，在软件过程中使用原型还具有如下的优点：1.提高了系统的实用性。2.使系统与用户需求更贴近。3.提高了系统的设计质量。4.提高了系统的可维护性。5.减少了开发的投入。研究发现，用原型法来提高系统的实用性和更好地满足用户需求并不一定意味着开发成本提高。50研究发现系统原型开发的其它优点Gordon和Biem3.6.2软件过程中的原型开发原型开发的种类有两种：1.进化式原型采用进化式的系统开发方法，就是在系统尚未完善的时候就呈现给用户，边修改边完善，在完善过程中逐渐地把需求弄明白。2.抛弃式原型采用原型开发方法进行需求分析和有效性验证，评估一结束，就抛弃掉原型，重建一个完整的系统。513.6.2软件过程中的原型开发原型开发的种类有两两点重要区别1.进化式原型的目标是给用户一个实用的系统。原型开发必须从对用户需求把握最准的部分做起，最优处理这部分。而对用户需求把握程度较差的部分和模糊的需求安排得稍后一些，可以在用户明确要求后再处理。2.抛弃式原型开发的目标是验证和导出需求。此时应从理解得不够好的那部分需求开始实现，因为要从目标中发现问题，对明确的需求就没必要去做原型。52两点重要区别1.进化式原型的目标是给用户一个实用的系统。原进化式原型开发进化式原型开发的思路是：先给出一个系统的最初实现，让用户去使用和评论，再不断进行细化和完善，经过多个这样的反复过程后形成最后完善的应用系统。进化式开发已经成为快速应用开发(RAD)和联合应用开发(JAD)技术中的一部分,已成为一个软件开发的主流技术。53进化式原型开发进化式原型开发的思路是：先给出一个系统进化式原型开发54进化式原型开发54进化式原型开发方法的优势1.加快系统交付的进度现在的商业节奏加快意味着软件支持能否快速到位是最根本的。在某些情况下，快速交货就比提供完备功能或保证长期可维护性更为重要。2.用户的参与用户在软件开发过程中的介入不仅仅意味着系统可以更好地理解软件需求，还意味着可以使用户逐渐喜欢系统，在工作中依赖它。55进化式原型开发方法的优势1.加快系统交付的进度55进化式原型开法与快速开发方法的共同基本性质1.描述、设计和实现三个过程是交叉进行的，没有详细的系统描述，设计文档一般都依赖于开发系统所使用的工具，用户需求文档只描述系统的最重要的特征。2.系统是逐渐增进的。在每一次增进过程中，最终用户和其他系统项目的相关人员都参与到设计和评估中来。他们可能提出对系统改进的意见。新的需求又会在随后的版本中被实现。3.采用了快速开发技术。4.系统用户界面都是交互式开发系统来实现的。56进化式原型开法与快速开发方法的共同基本性质1.描述、设计和进化式原型开发方法应注意的问题1.管理问题大型系统软件管理机构建立起来以处理软件过程模型。软件过程模型定期产生可交付的文档来评估项目进展的情况。原型的开发太快，以致产生大量的系统文档。专业技术技能不可能应用到每个开发的团队。2.维护问题连续不断地对原型的修改很可能导致系统的崩溃。如果快速原型开发中使用了某项专门的技术，有可能在以后寻找具有相关知识的人来维护系统变得十分困难。3.契约问题客户和软件开发商之间正规的契约模型是基于系统描述的。57进化式原型开发方法应注意的问题1.管理问题57增量开发方法该开发方法避免了进化式原型开发中的经常性变更问题。即首先建立一个总的框架，以后就以该框架结构为基础进行开发。在增量开发方法中，必须给出每一部分的需求和文档。使得用户的意见能及时地反馈，以减少错误的出现。58增量开发方法该开发方法避免了进化式原型开发中的经常性变增量开发方法59增量开发方法59抛弃式原型开发抛弃式原型开发的根本作用是弄清楚需求和为管理人员评估过程风险提供额外的信息。在抛弃式原型开发中，我们只注重其功能，而忽略其质量标准和性能指标，使这些功能经过原型设计而得到深刻理解。经过评估，原型被抛弃，不再作为系统开发的基础。其原型开发和最终系统开发使用的语言也往往不一样。60抛弃式原型开发抛弃式原型开发的根本作用是弄清楚需求和抛弃式原型开发61抛弃式原型开发61抛弃式原型方法存在以下问题1.为了尽快拿出原型，系统可能做了许多简化，因而不可避免要遗漏一些重要特性。2.在客户和承包商之间没有一个能写进合同的对于原型实现的合法规定。3.非功能需求，若可靠性、安全性，在原型实现中不会得到充分反映。62抛弃式原型方法存在以下问题1.为了尽快拿出原型，系统可能3.6.3快速原型技术快速原型技术强调的是交付的速度，而非系统的性能、可维护性和可靠性。目前，有三种较实用的快速原型技术：1.动态高级语言开发。2.数据库编程。3.组件和应用集成。633.6.3快速原型技术快速原型技术强调的是交付的快速原型技术64快速原型技术64使用动态高级语言的开发动态高级语言开发是一种包含运行时数据管理强大功能的编程语言。每当选择一种语言时，需回答以下问题：1.问题的应用领域是什么？2.需要什么样的用户交互？3.语言提供的支撑环境如何？动态的高级语言可以混合使用以构件系统原型。65使用动态高级语言的开发动态高级语言开发是一种包含运行数据库程序设计1.交互式表格定义开发者定义要显示的各个域及其位置。2.表格之间的关联开发者定义某个特定的输入将导致后续的表格显示。3.域验证开发者定义每个域输入值的允许范围。66数据库程序设计1.交互式表格定义66组件和应用集成如果系统中许多部分都可以复用而且不需重新进行设计和实现，那么系统开发的时间就会缩短。利用可复用组件在系统描述中说明哪些可复用组件是可再利用的。67组件和应用集成如果系统中许多部分都可以复用而且不需原型开发的两个层次实现1.应用层整个应用系统与原型结合在一起，功能模块可以共享。2.组件层单个组件集成进标准的框架从而完成系统的构造。

68原型开发的两个层次实现1.应用层68组件和应用集成优势许多原型中的功能模块可以以极低的成本来实现，如果原型用户对这些较熟悉，就不需花费额外的时间去学习这些功能。69组件和应用集成优势许多原型中的功能模块可以以极低的成本3.6.4软件复用可复用的软件与快速构造原型关系很密切。一堆可复用的模块单独看可能是无用的，但快速构造的原型系统就是靠它们连接起来而得到的。对建立软件目标系统而言，复用就是利用早先开发的对建立新系统有用的信息来生产新系统。它是一项活动，而不是一个对象。703.6.4软件复用可复用的软件与快速构造原型关系很密切。软件复用的条件⑴必须有简单而清晰的界面；⑵它们应当有高自包含性，即尽量不依赖其他模块或数据结构；⑶它们应具有一些通用的功能。当然，还应有好的文档，所有模块的接口、功能和错误条件描述应遵守一定的规范。71软件复用的条件⑴必须有简单而清晰的界面；71软件复用的范围1)复用数据：指程序不做任何修改，甚至输入输出数据的格式也无需改动，就可以从一个环境移到另一个环境中使用。2)复用模块：早期可复用模块的概念是指单个函数，它们不需要逐行编码就可以连接到一个程序中去。3)复用结构：有效的复用应有一个结构上的考虑，而不仅是将模块连接在一起。4)复用设计：软件设计与实现是两个不同的阶段。若对于同一个设计，可以采用不同的实现方法，则这样的设计就是可复用的。5)复用规格说明：在基本需求不改变，或某一新问题与过去的某一软件在某个抽象层次上属于同一类的情况下，原规格说明仍可使用或参照使用。72软件复用的范围1)复用数据：指程序不做任何修改，甚至输入输软件复用技术软件复用技术可分为两大类：合成技术和生成技术。1)合成技术：在合成技术中，构件(BuildingBlocks)是复用的基石。构件方法以抽象数据类型为理论基础，借用了硬件中集成电路芯片的思想：即将功能细节与数据结构隐藏封装在构件内部，有着精心设计的接口。构件在开发中像芯片那样使用，它们可以组装成更大的构件。构件可以是某一函数、过程、子程序、数据类型、算法等可复用软件成份的抽象，利用构件来构造软件系统，有较高的生产率和较短的开发周期。73软件复用技术软件复用技术可分为两大类：合成技术和生成技术。7三种方式将构件合成更大的构件①连接。通常，标准函数库中的标准函数是靠编译和连接程序与其他模块一起合成系统的②消息传递和继承。例如smalltalk面向对象的程序设计体系结构，就是通过消息传递和继承机制把对象类与其相关的其他对象类联系起来合成一个系统的。③管道机制。例如，UNIX中用管道(pipe)连接shell命令，使前一命令的输出成为后一命令的输入，用管道机制把多个shell命令连接在一起完成一个更复杂的功能。74三种方式将构件合成更大的构件①连接。通常，标准函数库中的标软件复用技术2)生成技术：生成技术利用可复用的模式(Patterns)，通过生成程序产生一个新的程序或程序段，产生的程序可以看成是模式的实例。可复用的模式有两种不同的形式：代码模式和规则模式。前者的例子是应用生成器，可复用的代码模式就存在于生成器自身。通过特定的参数替换，生成抽象软件模块的具体实体。后者的例子是变换系统，它利用变换规则集合。其变换方法中通常采用超高级的规格说明语言，形式化地给出软件的需求规格说明，利用程序变换系统(有时要经过一系列变换)，把用超高级规格说明语言编写的程序转化成某种可执行语言的程序。这种超高级语言抽象能力高，逻辑性强，形式化好，便于使用软件者维护。75软件复用技术2)生成技术：生成技术利用可复用的模式(Pat两种复用技术比较构件方法支持自底向上的软件开发方法，应当具有硬软件独立性、可读性、可理解性、正确性和可修改性。变换方法侧重于程序的推导方式、推理规则，支持自顶向下的软件开发技术。由于它的形式化程度高，抽象性强，一般软件开发者不易掌握，在描述某些实际问题时也有困难。另外，经过多次变换得到的可执行程序的效率较低，在时间和存储空间方面的需求较高，这都是需要解决的问题。可以将这两种方法结合起来使用，取长补短，再吸收人工智能的研究成果，以知识库为辅助工具，可促进复用技术的成熟。76两种复用技术比较构件方法支持自底向上的软件开发方法，应当具有3.7结构化分析方法7777结构化分析方法(StruturedAnalisys)结构化分析是面向数据流进行分析的方法，结构化分析方法适用与数据处理类型软件的需求分析。结构化分析方法是利用抽象模型的概念，按照软件内部数据传递，变换的关系，自顶向下，逐步分解，直到找到满足功能要求的所有可实现的软件为止。结构化方法使用以下几个工具：数据流图，数据字典，结构化语言，判定树和判定表等。78结构化分析方法(StruturedAnalisys)结构化3.7.1系统流程图1．符号当以概括的方式抽象地描绘一个物理系统时，仅仅使用图3.7.1中列出的基本符号就够了，其中每个符号表示系统中的一个部件。当需要更具体地描绘一个物理系统时还需要使用图3.7.2中列出的系统符号，利用这些符号可以把一个广义的输入／输出操作具体化为读／写存储在特殊设备上的文件（或数据库），把一般的处理具体化为特定的程序或手工操作等等。793.7.1系统流程图1．符号79例子某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果那种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便订货，规定每天向采购部门送一次订货报告。该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出订货报告。80例子某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量例子81例子813.7.2数据流图(DFD,DataFlowDiagram)数据流图描绘系统的逻辑模型，图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。因为数据流图是逻辑系统的图形表示，即使不是专业的计算机技术人员也容易理解，所以是极好的通信工具。823.7.2数据流图(DFD,DataFlowDiag3.7.2数据流图(DFD,DataFlowDiagram)1.符号数据流图有四种基本符号：正方形（或立方体）表示数据的源点或终点；圆角矩形（或圆形）代表变换数据的处理；开口矩形（或两条平行横线）代表数据存储；箭头表示数据流，即特定数据的流动方向。注意，数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。熟悉程序流程图的初学者在画数据流图时，往往试图在数据流图中表现分支条件或循环，殊不知这样做将造成混乱，画不出正确的数据流图。在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。(图示)833.7.2数据流图(DFD,DataFlowDiag数据流图性质①数据流图中的箭头仅能表示在系统中流动的数据；②与程序流程图不同，DFD不能表示程序的控制结构；③DFD表现的范围具有很大的灵活性。84数据流图性质①数据流图中的箭头仅能表示在系统中流动的数据；例1假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据：零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。(勾画分析表)85例1假设一家工厂的采购部每天需要一张订货报表，报表按零件编号例2以到银行取款为例。某年某日储户到银行把存折和取款单一并交给银行出纳员检验。出纳员核对账目，一旦发现存折有效性问题、取款单填写问题或是存折、帐卡与取款单不符等问题时均应报告储户。在检验通过后，出纳员将取款信息登录在存折和帐卡上，并通知付款。根据付款通知给储户付款。到此，整个取款过程完成。首先从问题描述中提取数据流图的四种成分。数据的源点：储户、日历（隐含）。数据的终点：储户处理有：检验、登录、付款。数据存储：存折、帐卡数据流：储户提交的"存折和取款单"、帐卡提供的"帐卡信息"，检验通不过时出纳员告知的"检查出的问题"、通过检验后的"取款信息"、"付款通知"、付给储户的"现款"以及日历提供的"提款时间信息"86例2以到银行取款为例。某年某日储户到银行把存折和取款单一并交例287例2873.7.2数据流图(DFD,DataFlowDiagram)2.命名数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。因此，给这些成分起名字时应该仔细推敲。下面讲述在命名时应注意的问题：⑴为数据流（或数据存储）命名①名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分。②不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类）。③如果在为某个数据流（或数据存储）起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。883.7.2数据流图(DFD,DataFlowDiag3.7.2数据流图(DFD,DataFlowDiagram)⑵为处理命名①通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。②名字应该反映整个处理的功能，而不是它的一部分功能。③名字最好由一个具体的及物动词，加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。④通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。⑤如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。893.7.2数据流图(DFD,DataFlowDiag3.7.2数据流图(DFD,DataFlowDiagram)3.用途画数据流图的基本目的是利用它作为交流信息的工具。分析员把他对现有系统的认识或对目标系统的设想用数据流图描绘出来，供有关人员审查确认。由于在数据流图中通常仅仅使用四种基本符号，而且不包含任何有关物理实现的细节，因此，绝大多数用户都可以理解和评价它。从数据流图的基本目标出发，可以考虑在一张数据流图中包含多少个元素合适的问题。一些调查研究表明，如果一张数据流图中包含的处理多于5～9个，人们就难于领会它的含义了。因此数据流图应该分层，并且在把功能级数据流图细化后得到的处理超过9个时，应该采用画分图的办法，也就是把每个主要功能都细化为一张数据流分图，而原有的功能级数据流图用来描绘系统的整体逻辑概貌。903.7.2数据流图(DFD,DataFlowDiag分层数据流图1.概念为有效控制复杂度，在产生数据流图时采用分层技术。2.组成把一个系统分为顶层DFD、中间层DFD和底层DFD。91分层数据流图1.概念91分层数据流图92分层数据流图92分层数据流图3.分层原则⑴父图与子图关系⑵编号⑶平衡规则⑷文件局部性⑸分解程度93分层数据流图3.分层原则933.7.3数据字典(DD,DataDictionary)数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。任何字典最主要的用途都是供人查阅对不了解的条目的解释，数据字典的作用也正是在软件分析和设计的过程中给人提供关于数据的描述信息。数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数，数据流图就不严格，然而没有数据流因数据字典也难于发挥作用。只有数据流图和对数据流图中每个元素的精确定义放在一起，才能共同构成系统的规格说明。数据字典中所有的定义应是严密的、精确的，不可有半点含混，不可有二义性。943.7.3数据字典(DD,DataDictionary3.7.3数据字典(DD,DataDictionary)1.数据字典的定义对在数据流图中每一个命名的图形元素均给予定义，其内容有图形元素的名字、别名或编号、分类、描述、定义、位置等。⑴数据流词条描述数据流是数据结构在系统内传播的路径。一个数据流词条有以下几项内容。⑵数据元素词条描述图中的每一个数据结构都是由数据元素构成的，数据元素是数据处理中最小的，不可再分的单位，它直接反映事物的某一特征。⑶数据文件词条描述数据文件是数据结构保存的地方。一个数据文件词条有以下几项内容⑷加工逻辑词条描述加工比较复杂，它到后来就是一段程序，加工的表达方式有判定表，判定树如何结构化语言等等，它们要全部写在一个词条中是有困难的。953.7.3数据字典(DD,DataDictionary3.7.3数据字典(DD,DataDictionary)2.定义数据的方法定义绝大多数复杂事物的方法，都是用被定义的事物的成分的某种组合表示这个事物，这些组成成分又由更低层的成分的组合来定义。从这个意义上说，定义就是自顶向下的分解，所以数据字典中的定义就是对数据自顶向下的分解。那么，应该把数据分解到什么程度呢？一般说来，当分解到不需要进一步定义，每个和工程有关的人也都清楚其含义的元素时，这种分解过程就完成了。由数据元素组成数据的方式只有下述三种基本类型：⑴顺序即以确定次序连接两个或多个分量；⑵选择即从两个或多个可能的元素中选取一个；⑶重复即把指定的分量重复零次或多次。⑷可选即一个分量是可有可无的（重复零次或一次）。963.7.3数据字典(DD,DataDictionary3.7.3数据字典(DD,DataDictionary)符号含义解释=被定义为+与例如，X=a+b,表示x由a和b组成[…，…]或例如，X=[a,b],X=[a|b],表示x由a或由b组成[…|…]或{…}重复例如，X={a},表示x由0个或多个a组成m{…}n重复例如，X=3{a}8,表示x中至少出现3次a，至多出现8次(…)可选例如，X=(a)表示a可在X中出现,也可不出现“…”基本数据元素例如，X=“a”,表示x为取值为a的数据元素‥连接符例如，X=1..9,表示a可取1到9之中的任一值973.7.3数据字典(DD,DataDictionary例例：数据文件的存折格式的数据字典中的定义格式为：存折=户名+所号+帐号+开户日+性质+(密印)+1{存取行}50户名=2{字母}24所号=“000”…“999”注：储蓄所编码，规定三位数字帐号=“00000001”..“99999999”注：帐号规定由八位数字组成开户日=年+月+日性质=“1”..“6”注：“1”表示普通用户，“5”表示工资户等印密=”0”注：“1”表示普通用户，“5”表示工资户等存取行=日期+(摘要)+支出+存入+余额+操作+复核日期=年+月+日年=“00”..“99”月=“01”..“12”日=“01”..“31”摘要=1{字母}4注：表明该存取是存？是取？还是换？支出=金额注：金额规定不超过9999999.99元金额=“0000000.01”..“9999999.99”操作=“00001”..“50000”98例例：数据文件的存折格式的数据字典中的定义格式为：983.7.3数据字典(DD,DataDictionary)3.数据字典的用途数据字典最重要的用途是作为分析阶段的工具。在数据字典中建立的一组严密一致的定义有助于改进分析员和用户之间的通信，因此将消除许多可能的误解。对数据的这一系列严密一致的定义也有助于改进在不同的开发人员或不同的开发小组之间的通信。如果要求所有开发人员都根据公共的数据字典描述数据和设计模块，则能避免许多麻烦的接口问题。数据字典中包含的每个数据元素的控制信息是很有价值的。因为列出了使用一个给定的数据元素的所有程序（或模块），所以很容易估计改变一个数据将产生的影响，并且能对所有受影响的程序或模块作出相应的改变。最后，数据字典是开发数据库的第一步，而且是很有价值的一步。993.7.3数据字典(DD,DataDictionary3.7.3数据字典(DD,DataDictionary)4.数据字典的实现目前实现数据字典有三种常见的途径：全人工过程，全自动化过程（利用数据字典处理程序）和混合过程（用正文编辑程序，报告生成程序等已有的实用程序帮助人工过程）。不论使用哪种途径实现的数据字典都应该具有下述特点：⑴通过名字能方便地查阅数据的定义；⑵没有冗余；⑶尽量不重复在规格说明的其他组成部分中已经出现的信息；⑷容易更新和修改；⑸能单独处理描述每个数据元索的信息；⑹定义的书写方法简单方便而且严格。此外，如果再带有产生交叉参照表、错误检测、一致性校验等功能则更好。1003.7.3数据字典(DD,DataDictionary3.7.3数据字典(DD,DataDictionary)如果暂时还没有自动的数据字典处理程序，建议采用卡片形式书写数据字典，每张卡片上保存描述一个数据元素的信息。这种做法较好地实现了上述要求，特别是更新和修改起来很方便，能够单独处理每个数据元素的信息。每张卡片上主要应该包含下述这样一些信息：名字、别名描述、定义、位置。当开发过程进展到能够知道数据元素的控制信息和使用特点时，把这些信息记录在卡片的背面。1013.7.3数据字典(DD,DataDictionary卡片字典的例子名字：订货报表别名：订货信息描述：每天一次送给采购员的需要订货的零件表定义：订货报表＝零件编号+零件名称+订货数量+目前价格+主要供应者+次要供应者位置：输出到打印机名字：零件编号别名：描述：唯一地标识库存清单中一个特定零件的关键域定义：零件编号＝8{字符}8位置：订货报表订货信息库存清单名字：订货数量别名：描述：某个零件一次订货的数量定义：订货数量＝1{数字}5位置：订货报表订货信息102卡片字典的例子名字：订货报表名字：零件编号名字：订货数量103.7.4加工逻辑说明在数据流图中，每个加工框中只简单地写上了一个加工名，这显然不能表达加工的全部内容。随着自顶向下逐步细化，功能越来越具体，加工逻辑也越来越精细。到最底一层，加工逻辑详细到可以实现的程度，因此称为“原子加工”或“基本加工”。如果能够写出每一个基本加工的全部详细逻辑功能，再自底向上综合，就能完成全部逻辑加工。1033.7.4加工逻辑说明在数据流图中，每个加工框中3.7.4加工逻辑说明在写基本加工逻辑的说明时，应满足如下要求：⑴对数据流图的每一个基本加工，必须有一个加工逻辑说明；⑵加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则；⑶加工逻辑说明必须描述实现加工的策略而不是实现加工的细节；目前用于写加工逻辑说明的工具有结构化语言、判定表和判定树。1043.7.4加工逻辑说明在写基本加工逻辑的说明时，3.7.4加工逻辑说明1.结构化语言所谓结构化语言是一种介于自然语言和形式化语言之间的半形式化语言。它是在自然语言基础上加了一些限制而得到的语言，是使用有限的词汇和有限的语句来描述加工逻辑。结构化英语的词汇表由英语命令动词、数据字典中定义的名字、有限的自定义词和控制结构关键词IF-THEN-ELSE、WHILE-DO、REPEAT-UNTIL、CASE-OF等组成。其动词的含义要具体，尽可能少用或不用形容词和副词。1053.7.4加工逻辑说明1.结构化语言1053.7.4加工逻辑说明下面是商店业务处理系统中“检查发货单”的例子。IFtheinvoiceexceeds$500THEN(发货单金额超过$500)IFtheaccounthasanyinvoicemorethan60daysoverdueTHEN(欠款超过60天)theconfirmationpendingresolutionofthedebt(在偿还欠款前不予批准)ELSE(accountisingoodstanding)(欠款未超期)issueconfirmationandinvoice(发批准书及发货单)ENDIFELSE(invoice$500orless)(发货单金额未超过$500)IFtheaccounthasanyinvoicemorethan60daysoverdueTHEN(欠款超过60天)issueconfirmation,invoiceandwritemessageoncreditactionreport(发批准书，发货单及赊欠报告)ELSE(accountisingoodstanding)(欠款未超过)issueconfirmationandinvoice(发批准书及发货单)ENDIFENDIF1063.7.4加工逻辑说明下面是商店业务处理系统中“检查发3.7.4加工逻辑说明2.判定表判定表是描述多条件、多目标动作的广为使用的形式化工具。判定表通常有四部分组成，见下图，用粗实线分开。左上部分是条件定义部分，左下部分是动作定义部分，右上部分是条件值列部分，右下部分是选定的动作列部分。条件定义条件取值列动作定义选定的动作列在条件定义部分由上到下分别列出所有条件。条件的上下次序允许调换。在动作定义部分由上到下依次列出所有的目标动作。在条件取值列部分，与条件定义次序相对应的列出个条件的取值。在选定的动作列部分，按照条件取值组合所选定的目标动作。1073.7.4加工逻辑说明2.判定表条件定义条件取值列3.7.4加工逻辑说明3.判定树判定树实质上是判定表的一种变形。它们只是形式上的区别，在本质上是一样的。判定树绘制的通常规律是：⑴被描述的问题（或处理名称）作为树根放在左边。判定树是由左向右的水平放置的树；⑵由左向右，在树的上方依次列出问题的所有条件名称。⑶所选目标动作作为树页画在图的最后边。1083.7.4加工逻辑说明3.判定树108判定树例子109判定树例子1093.7.5图形工具1.层次方框图

层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素（不能再分割的元素）。1103.7.5图形工具1.层次方框图1103.7.5图形工具例如，描绘一家计算机公司全部产品的数据结构可以用图中的层次方框图表示。这家公司的产品由硬件、软件和服务三类产品组成，软件产品又分为系统软件和应用软件，系统软件又进一步分为操作系统、编译程序和软件工具，……。1113.7.5图形工具例如，描绘一家计算机公司全部3.7.5图形工具2.Warnier图法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。用Warnier图可以表明信息的逻辑组织，也就是说，它可以指出一类信息或一个信息量是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。1123.7.5图形工具2.Warnier图1123.7.5图形工具3.IPO图IPO图是输入／处理／输出图的简称，它是美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。IPO图使用的基本符号既少又简单，因此很容易学会使用这种图形工具。它的基本形式是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。1133.7.5图形工具3.IPO图1133.7.5图形工具1143.7.5图形工具1143.7.5图形工具IPO图中包含的附加信息主要有系统名称、图的作者，完成的日期，本图描述的模块的名字，模块在层次图中的编号，调用本模块的模块清单，本模块调用的模块的清单，注释，以及本模块使用的局部数据元素等。在需求分析阶段可以使用IPO图简略地描述系统的主要算法（即数据流图中各个处理的基本算法）。当然，在需求分析阶段，IPO图中的许多附加信息暂时还不具备，但是在软件设计阶段可以进一步补充修正这些图，作为设计阶段的文档。这正是在需求分析阶段用IPO图作为描述算法的工具的重要优点。1153.7.5图形工具IPO图中包含的附加信息主要有演讲完毕，谢谢观看！演讲完毕，谢谢观看！第3章需求工程与需求分析117第3章需求工程与需求分析13.1基本的软件需求1182基本的软件需求软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得到的软件存在着巨大期望差异。119基本的软件需求软件项目中百分之四十至百分之六十的问题基本的软件需求在软件工程中，所有的风险承担者(stakeholder)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础。120基本的软件需求在软件工程中，所有的风险承担者(st3.1.1软件需求的定义⑴用户解决问题或达到目标所需的条件或权能（Capability）。⑵系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。⑶一种反映上面⑴或⑵所描述的条件或权能的文档说明。1213.1.1软件需求的定义⑴用户解决问题或达到目标所3.1.1软件需求的定义1.一些关于“需求”的解释需求的关键的问题是一定要编写需求文档。如果只有一堆邮件、贴条、会谈过几次或一些零碎的对话，你就确信你已明白用户的需求，那完全是自欺欺人。

许多的需求分析专家给出了不同形式的需求定义，但从这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。任何文档形式的需求（例如：需求规格说明）仅是一个模型，一种叙述（Lawrence1998）。我们需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。1223.1.1软件需求的定义1.一些关于“需求”的解释63.1.1软件需求的定义2．需求的层次

下面这些定义是需求工程领域中常见术语的定义说明。软件需求包括三个不同的层次——业务需求、用户需求和功能需求（包括非功能需求）。⑴业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。⑵用户需求（userrequirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本（scenario）说明中予以说明。⑶功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。1233.1.1软件需求的定义2．需求的层次73.1.1软件需求的定义1243.1.1软件需求的定义83.1.2需求的开发和管理需求中名词术语的混淆将导致对科目（规范，discipline）叫法的不一致。一些作者把整个需求范围称之为“需求工程”，另一些则称之为“需求管理”。软件专家认为可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适：1253.1.2需求的开发和管理需求中名词术语的混淆将导3.1.2需求的开发和管理需求开发可进一步分为：需求获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段。需求开发活动包括以下几个方面：⑴确定产品所期望的用户类。⑵获取每个用户类的需求。⑶了解实际用户任务和目标以及这些任务所支持的业务需求。⑷分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。1263.1.2需求的开发和管理需求开发可进一步分为：需3.1.2需求的开发和管理⑸将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。⑹了解相关质量属性的重要性。⑺商讨实施优先级的划分。⑻将所收集的用户需求编写成规格说明和模型。⑼评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。1273.1.2需求的开发和管理⑸将系统级的需求分为几个3.1.2需求的开发和管理需求管理需要“建立并维护在软件工程中同客户达成的契约”(CMU/SEI1995)。这种契约都包含在编写的需求规格说明与模型中。通常的需求管理活动包括：⑴定义需求基线（迅速制定需求文档的主体）。⑵评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。⑶以一种可控制的方式将需求变更融入到项目中。⑷使当前的项目计划与需求一致。⑸估计变更需求所产生影响并在此基础上协商新的承诺(约定)。⑹让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。⑺在整个项目过程中跟踪需求状态及其变更情况。1283.1.2需求的开发和管理需求管理需要“建立并维3.1.2需求的开发和管理需求开发和需求管理之间的区别1293.1.2需求的开发和管理需求开发和需求管理之间的区别133.1.3需求工程的作用1．支持项目的开发。

需求工程过程是软件开发阶段的前提和基础。2．支持测试和验证

需求规格说明书将为项目测试和验证提供基准，可以用来检查设计和验证系统。3．支持维护

维护阶段的工作同以下几个方面紧密联系：⑴修改在测试阶段中尚未检查出来的少量残留编码错误。⑵软件运行一段时间后，因环境因素的改变而产生的软件的适应性维护。⑶用户在软件交付使用后又重新提出扩充功能的需求时的软件维护。4．支持项目承包商需求的证实过程为拟构造系统的正确性提供了进一步的根据。5．支持管理