第4章 需求分析基础

软件工程教学目的：了解需求分析的任务和步骤、评审标准和过程，掌握基本技术，理解需求规格说明书的作用与组成。教学重点：基本技术、需求规格说明书的作用与组成。教学难点：基本技术。教具：多媒体教室、电子教案作业：习题3、4第4章需求分析软件工程第4章需求分析软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。需求分析就是通过对应用问题及其环境的分析与理解，采用一系列的分析方法和技术，将用户的需求逐步精确化、完全化、一致化，最终形成需求规格说明文档的过程。系统分析阶段产生的系统规格说明和项目规划是软件需求分析的基础，分析人员需从软件的角度对其进行检查和调整，并在此基础上展开需求分析。软件工程第4章需求分析需求分析阶段的成果主要是需求规格说明，该成果又是软件设计、编码、测试直至维护的主要基础。需求分析是系统分析和软件设计的重要桥梁，是软件生存周期的关键性阶段。良好的分析活动能够减少错误和遗漏，从而可提高软件生产率和产品质量、降低开发与维护成本。软件工程第4章需求分析本章介绍需求分析的基础知识。主要包括：需求分析的三个主要步骤：问题分析、需求描述、需求评审及各个步骤的主要任务；进行需求分析的一般技术和方法简介，包括初步需求获取技术、需求建模技术、快速原型技术、多视点分析方法等；需求规格说明的作用和内容及需求评审的标准和评审过程等。软件工程4.1需求分析的任务需求分析的任务可通过问题分析、需求描述和需求评审三个步骤来完成。1．问题分析软件系统分析人员在这一步骤中的任务是根据对问题及其环境的理解与软件开发经验，改正用户需求的模糊性、歧义性和不一致性，排除由于用户的片面性和短期行为所导致的不合理要求、挖掘用户尚未提出但具有价值的潜在需求，并在用户的帮助下对相互冲突的要求进行折衷，使用户需求逐步精确化、一致化和完全化。软件工程4.1需求分析的任务1．问题分析在这一过程中，需要用某种方法为原始问题及其软件解建立模型，以便精确地记录用户从各个视点、在不同抽象级别上对原始问题的描述，并包含了问题及其环境所涉及的信息流、处理功能、用户界面、行为及设计约束等各方面内容。于是可通过对模型的精确化来达到需求分析的目标。比如，可以采用面向数据流的分析方法，利用数据流图和数据字典等工具来建立模型。该模型是形成需求规格说明、进行软件设计的基础。软件工程2．需求描述该步骤的主要任务是以需求模型为基础，生成需求规格说明和初步的用户手册，并制定软件产品验收测试计划。需求规格说明是软件项目的一个关键性文档。其中应包含对目标软件系统的功能、外部行为、性能、质量、可靠性、可维护性、约束条件和需求验证标准等的完整的描述。初步用户手册应包括目标软件系统的用户界面的描述和使用方法的初步构想。验收测试计划是进行软件产品验收测试的依据。软件工程3．需求评审需求评审是软件开发过程中的一个重要的里程碑。需求评审的主要任务是分析人员在用户（客户）和软件设计人员的配合下对需求规格说明和初步用户手册进行审核，检验软件需求的精确性、完全性和一致性，并使用户（客户）和软件设计人员对规格说明和用户手册达成一致的理解。经过评审确认的需求规格说明将成为客户方与开发方的合同。如果评审未通过，比如发现了遗漏或错误，则必须进行迭代，直至通过评审为止。软件工程4.2需求分析的一般性技术为了克服困难，更有效地开展需求分析工作，软件系统分析人员必须掌握一些基本的需求分析技术，主要包括：初步需求获取技术；需求建模技术；快速原型技术；问题的分解与抽象；多视点分析技术等。软件工程4.2.1初步需求获取技术在分析阶段的初期，由于分析人员和用户的共同知识领域可能不多，致使分析人员对问题往往知之不多，而用户对目标软件的要求及对要求的描述常常是零乱而模糊的，从而会造成相互交流和相互理解上的困难。为了克服困难，获取初步需求，可以采用如下的技术手段：访谈与会议；观察用户工作流程；分析人员和用户组成联合小组。软件工程1．访谈与会议分析人员采用个别访谈或小组会议的形式与用户进行初步交流。在访谈和会议之前，分析人员根据对问题的初步描述精心准备一系列问题，通过用户对问题的回答或互相商讨来逐步理解用户的需求。准备问题的原则有：①首先应搞清一般性、整体性问题，然后再涉及细节问题。②在组织问题时要尽量做到客观、公证，不应限制用户的自由发挥。③所提问题汇总后应能反映应用问题及其子问题的全貌、并且不要过分详细。软件工程2．观察用户工作流程如果可能，可通过实际观察用户的手工操作过程来提取新系统的初步用户需求。观察手工操作过程不是为了模拟手工操作过程，而是为了获取第一手资料，并从中提取出有价值的需求。分析人员有了第一手资料，再结合自己的软件开发和应用的经验，就能够发现不合理的用户需求、提出用户还没有意识到的潜在的但却很有价值的用户需求，并能够从软件的角度改进操作流程和操作规范，从而可获得用户满意的分析结果。软件工程3．用户和开发人员共同组成联合小组为加强信息沟通、减少误解和避免产生遗漏、充分调动用户的积极性，在可能的条件下，可以建立由开发方和用户方共同组成的联合小组。联合小组除了双方的分析人员外，应设专门的记录员、负责会议议程的人员和资料员等，并制定小组的规章制度和计划，选定一种易于理解、简洁、精确的表示机制作为双方的共同语言，比如采用带文字说明的流程图等。软件工程【例4.1】这里以“家庭保安系统”为例，简要说明初步需求的获取过程。假设用户的原始需求描述如下：根据家庭保安市场的增长趋势，我们希望建立一种基于微处理器的家庭保安系统，它能够识别异常事件并采取相应的报警措施。这些异常事件有：非法进入、火灾、水淹，等等。当传感器一旦探测出相应的异常事件时，系统应自动用电话向监控中心报警。此外，系统应允许户主对其行为实施程序式控制。软件工程【例4.1】为进行初步的需求分析，这里采用开发方和用户方组成联合小组的方法。为此，联合小组应制定工作制度：每次会议开始前必须有确定的议程，小组成员必须针对议程进行充分准备并应形成文字。联合小组会议首先应明确问题的范围、问题与环境的关系，并就开发软件产品的必要性达成共识。之后的会议，小组负责人要求每位参加者根据负责的范围列出应用问题及环境中有关的对象、对象的操作及对象间的关系。如市场营销人员列出控制面板、电话机、监控中心等对象和用户编程控制、电话拨号、报警等操作；负责传感器的用户可能列举烟雾传感器、门窗监视器、警报器等对象。软件工程【例4.1】接着，将对这些列举的对象和操作进行更详细的讨论和描述，比如，详细地描述接收传感器事件、用户编程控制、电话报警等操作等。之后，用户可能提出一些约束条件。比如，造价不应超过3000元，对传感器事件的响应时间不得超过1秒，事件必须按优先级顺序进行处理等等。会后，小组负责人应对这些信息加以整理并形成文档，该文档应能反映“家庭保安系统”的全貌。软件工程【例4.1】之后，根据“家庭保安系统”的特点，将联合小组分成两个小组，并行处理用户编程控制和传感器检测两个子系统，以便使子问题的软件需求进一步细化，这时可能又会增加新对象、新操作、新约束条件。在子系统的需求基本明确并形成文档后，还应就子系统的整合及需求验证标准等进行初步的讨论。最后，初步需求分析应形成结论性文档。比如，经过初步的需求分析，“家庭保安系统”的部分初步需求文档如下：软件工程【例4.1】“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与户主进行信息交互。系统开机后，软件系统负责显示系统当前的工作状态，接收并处理户主的命令。当系统处于配置状态，软件系统允许户主进行配置操作。配置操作包括：①指定每一传感器的种类和编号；②设置开、关机密码；③指定报警电话号码；④指定报警延迟和电话重拨延迟时间（以秒为单位）。当系统处于监视状态时，软件系统即开始对所有传感器实施监控。当软件系统接收到传感器发出的数据后，判别是否出现异常事件，如果是，则经过指定的延迟时间即开始拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。此时软件系统负责向监控中心报告异常事件发生的地点、时间和性质。软件工程【例4.1】以上文档没有包括约束条件、测试标准等方面的内容。初步需求文档将是后续详细需求分析的基础。在此基础上，就可以采用某种需求分析方法进行详细的需求分析。在以后几章中，将分别介绍几种详细的需求分析方法和其中最重要的需求建模技术，它们是：“面向数据流的需求分析方法”；“面向数据的需求分析方法”；“面向对象的需求分析方法”。软件工程4.2.2需求建模技术为了使用户需求逐步精细化、完全化、一致化，通常采用需求建模技术，即用建立目标软件系统模型的方法来刻画软件系统中的信息、处理功能和外部行为。通常，分析人员选定一种分析方法，并用该方法中的一些图形记号分别表示信息流、处理功能和系统行为，并利用受限制的自然语言给出用户需求的描述。这种模型的表示机制还应具有良好的结构化能力，以便处理大型问题的按层次分解的问题。软件需求分析的过程，实际上是软件模型的建造和不断完善的过程。软件工程需求建模的步骤①在分析的初期，分析人员通过访谈、会议、实际观察、分析现有系统等方法获取初步的用户需求。②分析人员根据选定的一种分析方法，在初步用户需求的基础上构筑初步的模型作为开发方和用户相互沟通的表示机制。③分析人员在用户的密切配合下，利用选定的分析方法不断地对模型进行精细化、一致化、完全化，直至获得满意的用户需求为止。在分析阶段构筑的模型不应涉及软件实现的细节，以免分散分析人员的注意力、限制软件设计人员为提高软件质量和效率而选择实现方法的自由度。需求分析结束时确立的软件模型是生成需求规格说明的依据，也是软件设计和实现的基础。软件工程4.2.3快速原型技术如果按照传统的软件开发方法，需要经过漫长的开发时间之后用户才能看到目标软件的最初版本。此时用户常常会提出许多修改意见，有时甚至全盘否定，导致开发失败。为了降低开发风险，在需求分析阶段常常采用快速原型技术。1．快速原型技术的基本思想在软件开发的早期，快速开发一个目标软件系统的原型，让用户对其进行评价并提出修改意见，然后开发人员根据用户的意见对原型进行改进。当原型几经改进最终确认后，它将直接进化成软件产品，或者由软件设计、编码人员按照模型所确立的外部特征去实现软件产品。软件工程2．采用快速原型技术的具体步骤①采用一种分析方法生成一个软件系统或其中所关心部分的简化需求规格说明。②对该规格说明进行评审通过后，立即生成设计规格说明。为了快速生成原型，这种设计仅注重所关心的问题，如软件的总体结构、用户界面和数据设计、或者某个复杂的算法等等，不注重过程内部的控制流设计。③使用可重用软部件、用户界面自动生成器等工具快速生成可运行的软件原型并通过测试。④将原型提交给用户进行评价，以便征求改进意见。⑤上述过程反复迭代，直至用户完全满意。此时的原型已完全、准确地反映了目标软件在所关心方面的需求，可作为需求规格说明的一部分而成为软件设计的基础。软件工程3．快速原型技术的适用场合该技术特别适合于软件产品要求大量的用户交互、或产生大量的可视输出、或设计一些复杂的算法等场合，目前的绝大多数软件都适合于快速原型技术。除非由于问题相当复杂，致使开发快速原型可以获得的支持太少、所冒的风险太大时，就不易采用。但对于其中的某些子问题，尤其是用户界面，还可采用快速原型技术进行部分分析。软件工程4.2.4问题分解与抽象、多视点分析技术问题分解技术分析人员常常采用一种问题分解的技术。即将一个大型复杂的问题分解为若干个子问题，然后对每一个子问题逐个进行分析，再自底向上综合成整个问题的分析结果。这种分解可以逐级进行，直至子问题的规模降到合适的程度。问题抽象技术分析人员在分析过程中要善于从诸多的特殊问题中抽象出一般的问题，首先关注一般问题的解决途径，再用其指导特殊问题的求解。在抽象的过程中，还要注意用户的描述所处的抽象级别的不同，以便建立清晰的思路。软件工程4.2.4问题分解与抽象、多视点分析技术比如，在“家庭保安系统”中，用户可能提出