第2章(需求分析基础).ppt

单击此处编辑母版标题样式,*,安徽工程大学计算机与信息学院,*,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,问 题,对于两个聪明人来说，,正确的结论通常只有 一个，因此，如果发生争执，那么讨论的一定不是同一问题。,2026/3/1 周日,1,安徽工程大学计算机与信息学院,第,2,章,需求分析基础,需求分析的定义,分析的任务与原则,初步需求获取技术,需求建模,问题抽象、问题分解与度视点,支持需求分析的快速原型技术,需求规格说明与评审,2026/3/1 周日,2,安徽工程大学计算机与信息学院,第,2,章,需求分析基础,软件需求,用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。,需求分析的重要性 开发依据和验收依据。,软件需求分析阶段的工作，通过,对问题及环境的理解、分析以及建模,，将用户需求,借助建模使其精确化、完全化，,最终形成需求规格说明，描述系统信息、功能和行为。,2026/3/1 周日,3,安徽工程大学计算机与信息学院,需求分析基础,主要内容,三个主要阶段：问题分析、需求描述、需求评审,技术和方法,初步需求获取技术 需求建模技术 快速原型技术,问题抽象、问题分解与多视点分析,需求建模方法和,CASE,工具的进一步研究,面向数据流的分析 面向数据的分析 面向对象的分析,第,2,章 需求分析基础,2026/3/1 周日,4,安徽工程大学计算机与信息学院,需求定义,软件需求包括三个不同的层次：业务需求、用户需求、和功能需求也包括非功能需求。,业务需求 反映了组织机构或者客户对系统、产品高层次的目标要求。,用户需求(,user requirement),文档描述了用户使用产品必须要完成的任务。,功能需求(,functional requirement),定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。,2026/3/1 周日,5,安徽工程大学计算机与信息学院,需求定义,需求定义的组成各部分间的关系,业务需求,项目视图与范围文档,用户需求,使用实例文档,质量属性,功能需求,软件需求规格说明,其它非功能,需求,约束条件,系统需求,2026/3/1 周日,6,安徽工程大学计算机与信息学院,2.1,分析的任务与原则,2.1.1,需求分析的任务,问题分析（理解、建模）,需求描述,需求评审,第,2,章 需求分析基础,2026/3/1 周日,7,安徽工程大学计算机与信息学院,1 问题分析,分析人员应寻求用户需求,分析人员应了解问题及环境，应与用户合作,清除,用户需求的模糊性、岐义性和不一致性，并对相互冲突的需求进行,折衷,。,分析人员与用户合作对问题进行分析、综合，结合软件的特点及开发经验，寻求软件需求，增加,潜在,的用户需求。,但用户群体中各个用户往往会,从不同的角度，抽象层次,阐述他们对原始问题的理解，对目标软件的需求。,存在问题,用户在心目中所想像的系统,分析人员所理解得到的系统,他们所想象的系统是不可见的,两者系统相同？是否全面？一致？精确？,怎么样，借助什么手段来回答上面几个问题？,2.1,分析的任务与原则,2026/3/1 周日,8,安徽工程大学计算机与信息学院,问题分析,建立模型,针对以上问题以及需求是一种逻辑对象，需要对它们化不可见为可见化，对它们进行文档描述，因此有必要为原始问题和软件解,建立模型,，用文档对它们进行描述。,模型精确地记录用户从不同角度、不同抽象层次对原始问题即目标软件的描述。,模型应帮助用户和分析人员发现、排除用户需求不一致，不合理的部分，挖掘潜在的用户需求。,模型可作为分析人员关于原始问题级软件解的一种知识结构，包含问题和环境所涉及的信息流、处理功能、用户界面、行为模型和设计约束等。,2.1,分析的任务与原则,2026/3/1 周日,9,安徽工程大学计算机与信息学院,问题分析 建立模型,模型的组成 包括与问题和环境相关的信息流、处理功能、用户界面、行为及设计约束。,模型是形成需求规格说明、进行软件设计的基础。,需求建模方法,面向数据流的分析方法、面向数据的分析方法、面向对象的分析方法。,2.1,分析的任务与原则,2026/3/1 周日,10,安徽工程大学计算机与信息学院,2 需求描述,需求描述的任务,以需求模型为基础，考虑到软件问题的可解性，生成需求规格说明和初步的用户手册。,需求规格说明包含对目标软件系统的外部行为的完整描述、需求验证标准以及用户在性能、质量、可维护性等方面的要求。,用户手册包括用户界面描述以及有关目标软件使用方法的初步构想。,2.1,分析的任务与原则,2026/3/1 周日,11,安徽工程大学计算机与信息学院,需求描述,需求描述的文档,遵循规范，内容全面、结构清晰、措辞准确、格式严谨。,将初步用户手册作为分析文档,有助于分析人员从用户角度考虑软件需求，并鼓励用户尽早参予软件开发活动。,2.1,分析的任务与原则,2026/3/1 周日,12,安徽工程大学计算机与信息学院,3 需求评审,分析人员在用户和软件设计人员的配合下,对自己生成的需求规格说明和初步的用户手册进行评审，确保软件需求的完全性、精确性和一致性，并使用户和软件设计人员对需求规格说明及用户手册的理解达成一致。,需求规格说明得到用户和软件开发方的确认后，应成为用户方与软件开发方合同的一部分。,2.1,分析的任务与原则,2026/3/1 周日,13,安徽工程大学计算机与信息学院,需求评审,分析活动,对于大型软件项目，分析人员可以先对问题的某些子系统进行需求分析、描述与评审，子系统完成后，再对其它子系统进行分析，进而构筑整个系统的需求模型。,2.1,分析的任务与原则,2026/3/1 周日,14,安徽工程大学计算机与信息学院,2.1.2,需求,分析,的,原则,每一种分析方法都有都适用下面的基本原则。,能够表达和理解问题的信息域和功能域,对于计算机程序处理的数据，其信息域包括信息流（如下图，即数据通过一个系统时的变化方式)、信息内容和信息结构，而功能域反映上述三方面的控制信息。,数据存储,转换1,转换2,附加,数据,输入数据,中间数据,结果数据,2026/3/1 周日,15,安徽工程大学计算机与信息学院,需求分析的原则（续）,能够对问题进行分解和不断细化，建立问题的不同抽象层次结构。,需要给出系统的逻辑视图和物理视图,软件需求的逻辑视图给出的是软件要达到的功能和要处理信息之间的关系，而不是实现的细节。,软件需求的物理视图给出的是处理功能和信息结构的实际表现形式，这往往是由设备本身决定的。,2026/3/1 周日,16,安徽工程大学计算机与信息学院,2.2,初步需求获取技术,访谈与会议,观察用户的工作流程,建立联合工作小组,第,2,章 需求分析基础,2026/3/1 周日,17,安徽工程大学计算机与信息学院,2.2.1,访谈与会议,个别访谈或小组会议,分析人员应精心准备问题，通过用户对问题的回答，逐步理解用户对目标软件的要求。,(1)循序渐进,首先关心一般性、整体性问题，然后再讨论细节问题。,(2)客观、公正,不应限制用户在回答问题过程中自由发挥。,(3)总结,问题汇总后应能反映软件或其子系统的全貌，能覆盖用户对目标软件或其子系统在功能、行为、性能诸方面的要求。,细节问题留待以后解决。,2.2,初步需求获取技术,2026/3/1 周日,18,安徽工程大学计算机与信息学院,2.2.2,考察用户的业务流程,调查研究,学习用户的有关业务知识，在用户帮助下了解用户的软件或子系统业务流程，结合软件开发和应用的经验提出新的用户需求，包括改进工作业务流程。例如，医院门诊收费系统。,2.2,初步需求获取技术,2026/3/1 周日,19,安徽工程大学计算机与信息学院,2.2.3,联合小组,调动用户的积极性、发挥主动性。建立软件开发方和用户方共同组成的联合小组，小组成员对分析负有相同的责任。,便于沟通、相互学习，弥补领域知识和业务流程方面的不足，使得问题分析的描述模型易于达成完善和一致。,联合小组要制定自己的工作制度和计划，确定专门的记录员，另设专人负责会议的议程和资料的综合、整理。,选择易于理解、比较简洁、精确的表示机制作为描述语言，如辅以文字说明的流程图。,2.2,初步需求获取技术,2026/3/1 周日,20,安徽工程大学计算机与信息学院,2.2.4,例 家庭保安系统,问题描述：,家庭保安市场正以每年40%的速度增长。希望建立一种基于微处理器的家庭保安系统，它能够识别异常事件并采取相应的防护措施。这些异常事件包括：非法侵入、火灾、水淹等。一旦异常情况被传感器探测出来，系统应自动通过电话向监控中心报警。此外，应允许户主对系统行为进行程序控制。,2.2,初步需求获取技术,2026/3/1 周日,21,安徽工程大学计算机与信息学院,家庭保安系统,联合小组成员,市场营销人员、传感器技术人员、小组负责人等。,分析初期联合小组的工作程序,联合小组首先制定工作制度：每次会议开始前必须有确定的议程，参加者必须针对各项议程进行充分的准备，并用文字表示。,2.2,初步需求获取技术,2026/3/1 周日,22,安徽工程大学计算机与信息学院,例 家庭保安系统,经过会议讨论，明确问题的范围、问题与环境的关系，并就开发软件产品的必要性达成共识。,小组负责人要求每位参加者列出问题及环境中的有关对象，对这些对象施行的操作以及对象间的相互作用。列出的操作和对象尽可能完全，如，控制面板、电话机、监控中心、烟雾传感器、门窗监视器、警报器等对象，以及用户编程控制、电话拔号、报警等操作。,2.2,初步需求获取技术,2026/3/1 周日,23,安徽工程大学计算机与信息学院,例 家庭保安系统,负责人应要求小组成员对接收传感器事件、用户编程控制、电话报警等操作进行更详细的描述，必要时可用流程图表示。,用户可能提出一些条件，如造价不能超过3，000元，对传感器事件必须在1秒内作出响应，事件必须按优先级进行处理等。会后小组负责人对这些信息进行综合、整理，形成文档，该文档应能反映“家庭保安系统”的全貌。,2.2,初步需求获取技术,2026/3/1 周日,24,安徽工程大学计算机与信息学院,例 家庭保安系统,联合小组分成两个小组，分别处理用户编程控制和传感器监测两个子系统。目的是对子系统的软件需求进行细化。对出现的新对象、新操作、新约束应及时添加到相应的子系统。,确定子系统需求并形成文档,联合小组讨论子系统的集成及需求验证标准。子系统集成包括子系统接口的一致性检查、系统功能和行为的完整性检查。需求验证标准应该是可测试的，以便开发人员在代码生成后能够通过测试结果向用户表明软件系统已完整地实现了用户需求。,初步分析活动应形成结论性文档，该文档将作为后续分析活动的基础。,2.2,初步需求获取技术,2026/3/1 周日,25,安徽工程大学计算机与信息学院,例 家庭保安系统,初步分析生成的“家庭保安系统”部分需求文档,(不包括约束条件和测试标准),“,家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。,配置操作,(1)指定每一传感器的种类和编号；,(2)设置开、关机密码；,(3)指定报警电话号码；,(4)指定报警延迟和电话重拔延迟时间(以秒为单位)。,2.2,初步需求获取技术,2026/3/1 周日,26,安徽工程大学计算机与信息学院,例 家庭保安系统,当软件系统接收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拔报警电话号码，拔号操作将按照重拔延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。,开机后软件系统负责显示当前工作状态，接收并处理用户指令。,2.2,初步需求获取技术,2026/3/1 周日,27,安徽工程大学计算机与信息学院,2.3,需求建模,目标软件系统的模型是刻画描述其所涉及的信息、功能处理、外部行为和约束。,建立软件模型是需求分析的中心工作，是焦点。借助模型使得用户和分析人员心中的系统一致。,软件的需求模型是需求分析中问题识别的结果，需求分析过程,本质上是对软件模型的建造和不断完善的过程。,需求分析的初期 使用初步需求技术收集资料，同时建立初步模型作为相互沟通的需求表示机制。,有了初步模型后，使用结构化分析方法等对模型进行精确化、一致化和完全化等方面工作。,第,2,章 需求分析基础,2026/3/1 周日,28,安徽工程大学计算机与信息学院,需求建模（续）,建模方法，提供建模语言机制和具体指导方法。,模型的特点要求,模型不应涉及软件实现细节，这样会分散分析人员的注意力，限制软件设计人员的聪明才智。,分析人员应以简洁、准确、清晰的方式，系统地描述软件需求模型，如，选择图形符号表示信息流、处理功能及系统行为，利用受限的自然语言给出用户需求描述。,为了处理大型问题，模型表示机制应具备良好的结构化能力。,2026/3/1 周日,29,安徽工程大学计算机与信息学院,2.4,问题的抽象、分解与多视点分析,抽象,要求捕捉用户描述或者问题本身所固有的一般,特殊关系,关注一般问题的解决途径，以此指导特殊问题的求解。,分析人员应该注意用户描述的抽象级别，统一规划系统行为,避免不一致性，减少分析的工作量。,第,2,章 需求分析基础,2026/3/1 周日,30,安徽工程大学计算机与信息学院,问题的抽象、分解与多视点分析,分解,根据问题的规模和复杂性进行分解，并对子问题展开进一步的分析。,逐级分解，直至子问题的规模降至合适程度。,在问题分解过程中，要建立子问题之间的相互联系。,必须遵循子问题内部紧藕合，子问题之间松藕合的原则。,2.4,问题抽象、问题分解与多视点分析,2026/3/1 周日,31,安徽工程大学计算机与信息学院,问题的抽象、分解与多视点分析,视点分解法,在分析的初期，整体地把握一个大型问题的软件需求是困难的。需要从各个角度分别对问题进行理解和分析，然后再综合，达到全面理解的目,需求分析视点,系统观点 用户观点 信息观点,功能观点 行为观点等。,整理、综合用户描述，应注意用户视点的变化，避免遗漏。,2.4,问题抽象、问题分解与多视点分析,2026/3/1 周日,32,安徽工程大学计算机与信息学院,2.5,支持需求分析的快速原型技术,按照传统的软件开发方法，目标软件要等到木已成舟才能交用户认可。,软件开发早期，快速建立目标软件系统原型，让用户对原型进行评估并提出意见。,原型几经改进最终确定，,它将进化成软件产品,。,设计和编码人员遵循原型确立的外部特征实现软件产品。,如果软件产品含有大量人机交互、可视输出、或者涉及复杂的算法，应采用快速原型技术。,第,2,章 需求分析基础,2026/3/1 周日,33,安徽工程大学计算机与信息学院,快速建造原型,(1)利用需求分析技术、方法，生成简化的需求规格说明,(2)对简化的需求规格说明进行检查、修订，生成设计规格说明。为了快速生成原型,只关心软件的总体结构、用户界面和数据设计，而不注重过程内部的控制流。,(3)在快速原型工具或环境的帮助下，快速生成可运行的软件原型并进行测试、改进。主要工具有：可重用软部件库、用户界面自动生成器等。,2.5,支持需求分析的快速原型技术,2026/3/1 周日,34,安徽工程大学计算机与信息学院,快速建造原型,(4)将原型提交用户评估并征求改进意见。,(5)迭代上述过程，直到用户满意。,通过评审的原型应全面、准确地反映用户对目标软件在外部行为方面的需求，可以作为需求规格说明的一部分并成为软件设计和编码的基础。,2.5,支持需求分析的快速原型技术,2026/3/1 周日,35,安徽工程大学计算机与信息学院,2.6,需求规格说明与评审,产生需求规格说明并进行评审。,需求规格说明应成为开发过程必须遵循的指导原则。,第四章 需求分析基础,2026/3/1 周日,36,安徽工程大学计算机与信息学院,2.6.1,需求规格说明,目标,(1)用户通过需求规格说明可初步判定目标软件能否满足需求，设计人员将需求规格说明作为软件设计的基础。,(2)支持目标软件系统的确认，需求规格说明的各项需求应该是可测试的。,(3)控制系统进化过程，需求分析完成后，如果用户追加需求，开发人员再次进行需求分析，扩充需求规格说明，进行软件设计等。,2.6,需求规格说明与评审,2026/3/1 周日,37,安徽工程大学计算机与信息学院,需求规格说明,内容,功能、行为需求,描述系统的输入、输出及相互关系,非行为需求,描述软件系统工作时应具备的各种属性，如效率、可靠性、安全性、可维护性、可移植性等。,为使需求规格说明更加简洁，其它内容不应写入，如人员、成本、进度、设计方案、质量控制等。这些内容单独形成文档。,2.6,需求规格说明与评审,2026/3/1 周日,38,安徽工程大学计算机与信息学院,需求规格说明,1 引言,1.1需求规格说明的目的,1.2软件产品的作用范围,1.3定义、同义词与缩写,1.4参考文献,1.5需求规格说明概览,2,一般性描述,2.1产品与其环境之间的关,2.2产品功能,2.3用户特征,2.4限制与约束,2.5假设与前提条件,3,特殊需求,附录,索引,2.6,需求规格说明与评审,2026/3/1 周日,39,安徽工程大学计算机与信息学院,需求规格说明 特殊需求描述,3特殊需求,3.1功能或行为需求,3.1.1功能或行为需求1,3.1.1.1引言,3.1.1.2输入,3.1.1.3处理过程描述,3.1.1.4输出,3.1.2,功能或行为需求2,3.1.,n,功能或行为需求,n,3.2,外部界面需求,3.2.1用户界面,3.2.2硬件界面,3.2.3软件界面,3.3,性能需求,3.4设计约束,3.4.1标准化约束,3.4.2硬件约束,3.5,属性,3.5.1可用性,3.5.2安全性,3.5.3可维护性,3.5.4可移植性,3.6,其它需求,3.6.1数据库需求,3.6.2用户操作需求,3.6.3工作场地需求,2.6,需求规格说明与评审,2026/3/1 周日,40,安徽工程大学计算机与信息学院,2.6.2,需求评审,需求规格说明进入设计阶段之前，必须进行评审。如果发现错误或缺陷，应及时纠正或更改需求分析、模型，需求规格说明，并重新评审。,衡量需求规格说明的标准（优秀需求规格说明）,正确性 无歧义性 完全性,可验证性 一致性 可理解性,可修改性 可追踪性,2.6,需求规格说明与评审,2026/3/1 周日,41,安徽工程大学计算机与信息学院,需求评审,(1)正确性。,需求规格说明书的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。,(2)无歧义性。,需求规格说明的任何语法单位只能有唯一的语义解释。确保无歧义性的一种有效措施是在需求规格说明中使用标准化术语，并对术语的语义进行显式的、统一解释。,2.6,需求规格说明与评审,2026/3/1 周日,42,安徽工程大学计算机与信息学院,需求评审,(3)完全性。,需求规格说明书不能遗漏任何用户需求。具体地说，目标软件产品的所有功能、行为、性能约束，以及它在所有可能情况下的预期行为均应完整地包含在需求规格说明。,(4)可验证性。,对于规格说明书中的任意需求，均应存在技术和经济上可行的手段进行验证和确认。,2.6,需求规格说明与评审,2026/3/1 周日,43,安徽工程大学计算机与信息学院,需求评审,(5)一致性。,需求规格说明书的各部分之间不能相互矛盾。这些矛盾可以表现为术语使用方面的冲突，功能和行为特征方面的冲突以及时序方面的前后不一致。,(6)可理解性。,追求上述目标不应妨碍需求规格说明书对于用户、设计人员和测试人员的易理解性。特别是对于非计算机专业的用户而言，不宜在说明书中使用太多的专业化词汇。,2.6,需求规格说明与评审,2026/3/1 周日,44,安徽工程大学计算机与信息学院,需求评审,(7)可修改性。,需求规格说明的格式和组织方式应支持内容的增、删和修改。,(8)可追踪性。,需求规格说明的每项需求必须与用户的原始需求相对应，为后续开发和其它文档引用这些需求提供方便。,2.6,需求规格说明与评审,2026/3/1 周日,45,安徽工程大学计算机与信息学院,需求评审,需求评审采用会议形式，用户、分析人员和系统设计人员共同参加。,分析人员介绍软件产品的总体目标，包括产品的主要功能、与环境的交互行为，以及其它性能指标。,评估需求模型，讨论需求模型及需求规格说明是否具备良好的属性，能否构成良好的软件设计基础。,2.6,需求规格说明与评审,2026/3/1 周日,46,安徽工程大学计算机与信息学院,需求评审,讨论软件求解的其它途径，对影响软件设计和软件质量的因素进行折衷，决定需求规格说明采用的方案是否合理。,讨论软件的质量确认方法，形成用户和开发人员均能接受的各项测试指标。,2.6,需求规格说明与评审,2026/3/1 周日,47,安徽工程大学计算机与信息学院,小结,需求分析的主要任务是实现用户需求的一致化、精确化和完全化。,需求分析活动可按照问题分析、需求描述及需求评审三个子阶段逐步进行。,初始需求可用访谈、会议、考察用户工作流程的方式导出。,问题分析阶段的核心技术是问题抽象、问题分解及需求建模。,使用快速原型可以让用户更多、更早地参与需求分析过程。,第,2,章 需求分析基础,2026/3/1 周日,48,安徽工程大学计算机与信息学院,小结,在需求描述阶段生成的需求规格说明应遵循标准的格式。问题分析阶段生成的需求模型构成需求规格说明的主体。,需求评审阶段，分析人员审查需求规格说明的标准：,正确性、无歧义性、完全性、,可验证性、一致性、可理解性、,可修改性、可追踪性。,第,2,章 需求分析基础,2026/3/1 周日,49,安徽工程大学计算机与信息学院,