第4章 需求分析 教学目的：了解需求分析的任务和步骤、评审标准和过 程，掌握基本技术，理解需求规格说明书的 作用与组成。

Presentation on theme: "第4章 需求分析 教学目的：了解需求分析的任务和步骤、评审标准和过 程，掌握基本技术，理解需求规格说明书的 作用与组成。"— Presentation transcript:

1 第4章 需求分析 教学目的：了解需求分析的任务和步骤、评审标准和过 程，掌握基本技术，理解需求规格说明书的 作用与组成。 教学重点：基本技术、需求规格说明书的 作用与组 成。 教学难点：基本技术。 教 具：多媒体教室、电子教案 作 业：习题 3、4

2 第4章 需求分析 软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。 需求分析就是通过对应用问题及其环境的分析与理解，采用一系列的分析方法和技术，将用户的需求逐步精确化、完全化、一致化，最终形成需求规格说明文档的过程。 系统分析阶段产生的系统规格说明和项目规划是软件需求分析的基础，分析人员需从软件的角度对其进行检查和调整，并在此基础上展开需求分析。

3 第4章 需求分析 需求分析阶段的成果主要是需求规格说明，该成果又是软件设计、编码、测试直至维护的主要基础。 需求分析是系统分析和软件设计的重要桥梁，是软件生存周期的关键性阶段。良好的分析活动能够减少错误和遗漏，从而可提高软件生产率和产品质量、降低开发与维护成本。

4 第4章 需求分析 本章介绍需求分析的基础知识。主要包括： 需求分析的三个主要步骤：问题分析、需求描述、需求评审及各个步骤的主要任务； 进行需求分析的一般技术和方法简介，包括初步需求获取技术、需求建模技术、快速原型技术、多视点分析方法等； 需求规格说明的作用和内容及需求评审的标准和评审过程等。

5 4.1 需求分析的任务 需求分析的任务可通过问题分析、需求描述和需求评审三个步骤来完成。 1．问题分析 软件系统分析人员在这一步骤中的任务是根据对问题及其环境的理解与软件开发经验，改正用户需求的模糊性、歧义性和不一致性，排除由于用户的片面性和短期行为所导致的不合理要求、挖掘用户尚未提出但具有价值的潜在需求，并在用户的帮助下对相互冲突的要求进行折衷，使用户需求逐步精确化、一致化和完全化。

6 4.1 需求分析的任务 1．问题分析 在这一过程中，需要用某种方法为原始问题及其软件解建立模型，以便精确地记录用户从各个视点、在不同抽象级别上对原始问题的描述，并包含了问题及其环境所涉及的信息流、处理功能、用户界面、行为及设计约束等各方面内容。 于是可通过对模型的精确化来达到需求分析的目标。比如，可以采用面向数据流的分析方法，利用数据流图和数据字典等工具来建立模型。 该模型是形成需求规格说明、进行软件设计的基础。

7 2．需求描述 该步骤的主要任务是以需求模型为基础，生成需求规格说明和初步的用户手册，并制定软件产品验收测试计划。 需求规格说明是软件项目的一个关键性文档。其中应包含对目标软件系统的功能、外部行为、性能、质量、可靠性、可维护性、约束条件和需求验证标准等的完整的描述。 初步用户手册应包括目标软件系统的用户界面的描述和使用方法的初步构想。 验收测试计划是进行软件产品验收测试的依据。

8 3．需求评审 需求评审是软件开发过程中的一个重要的里程碑。
需求评审的主要任务是分析人员在用户（客户）和软件设计人员的配合下对需求规格说明和初步用户手册进行审核，检验软件需求的精确性、完全性和一致性，并使用户（客户）和软件设计人员对规格说明和用户手册达成一致的理解。 经过评审确认的需求规格说明将成为客户方与开发方的合同。如果评审未通过，比如发现了遗漏或错误，则必须进行迭代，直至通过评审为止。

9 4.2 需求分析的一般性技术 为了克服困难，更有效地开展需求分析工作，软件系统分析人员必须掌握一些基本的需求分析技术，主要包括： 初步需求获取技术； 需求建模技术； 快速原型技术； 问题的分解与抽象； 多视点分析技术等。

10 初步需求获取技术 在分析阶段的初期，由于分析人员和用户的共同知识领域可能不多，致使分析人员对问题往往知之不多，而用户对目标软件的要求及对要求的描述常常是零乱而模糊的，从而会造成相互交流和相互理解上的困难。为了克服困难，获取初步需求，可以采用如下的技术手段： 访谈与会议； 观察用户工作流程； 分析人员和用户组成联合小组。

11 1．访谈与会议 分析人员采用个别访谈或小组会议的形式与用户进行初步交流。在访谈和会议之前，分析人员根据对问题的初步描述精心准备一系列问题，通过用户对问题的回答或互相商讨来逐步理解用户的需求。 准备问题的原则有： ①首先应搞清一般性、整体性问题，然后再涉及细节问题。 ②在组织问题时要尽量做到客观、公证，不应限制用户的自由发挥。 ③所提问题汇总后应能反映应用问题及其子问题的全貌、并且不要过分详细。

12 2．观察用户工作流程 如果可能，可通过实际观察用户的手工操作过程来提取新系统的初步用户需求。
观察手工操作过程不是为了模拟手工操作过程，而是为了获取第一手资料，并从中提取出有价值的需求。分析人员有了第一手资料，再结合自己的软件开发和应用的经验，就能够发现不合理的用户需求、提出用户还没有意识到的潜在的但却很有价值的用户需求，并能够从软件的角度改进操作流程和操作规范，从而可获得用户满意的分析结果。

13 3．用户和开发人员共同组成联合小组 为加强信息沟通、减少误解和避免产生遗漏、充分调动用户的积极性，在可能的条件下，可以建立由开发方和用户方共同组成的联合小组。 联合小组除了双方的分析人员外，应设专门的记录员、负责会议议程的人员和资料员等，并制定小组的规章制度和计划，选定一种易于理解、简洁、精确的表示机制作为双方的共同语言，比如采用带文字说明的流程图等。

14 【例4.1】 这里以“家庭保安系统”为例，简要说明初步需求的获取过程。假设用户的原始需求描述如下：
根据家庭保安市场的增长趋势，我们希望建立一种基于微处理器的家庭保安系统，它能够识别异常事件并采取相应的报警措施。这些异常事件有：非法进入、火灾、水淹，等等。当传感器一旦探测出相应的异常事件时，系统应自动用电话向监控中心报警。此外，系统应允许户主对其行为实施程序式控制。

15 【例4.1】 为进行初步的需求分析，这里采用开发方和用户方组成联合小组的方法。为此，联合小组应制定工作制度：每次会议开始前必须有确定的议程，小组成员必须针对议程进行充分准备并应形成文字。 联合小组会议首先应明确问题的范围、问题与环境的关系，并就开发软件产品的必要性达成共识。 之后的会议，小组负责人要求每位参加者根据负责的范围列出应用问题及环境中有关的对象、对象的操作及对象间的关系。如市场营销人员列出控制面板、电话机、监控中心等对象和用户编程控制、电话拨号、报警等操作；负责传感器的用户可能列举烟雾传感器、门窗监视器、警报器等对象。

16 【例4.1】 接着，将对这些列举的对象和操作进行更详细的讨论和描述，比如，详细地描述接收传感器事件、用户编程控制、电话报警等操作等。
之后，用户可能提出一些约束条件。比如，造价不应超过3000元，对传感器事件的响应时间不得超过1秒，事件必须按优先级顺序进行处理等等。 会后，小组负责人应对这些信息加以整理并形成文档，该文档应能反映“家庭保安系统”的全貌。

17 【例4.1】 之后，根据“家庭保安系统”的特点，将联合小组分成两个小组，并行处理用户编程控制和传感器检测两个子系统，以便使子问题的软件需求进一步细化，这时可能又会增加新对象、新操作、新约束条件。在子系统的需求基本明确并形成文档后，还应就子系统的整合及需求验证标准等进行初步的讨论。 最后，初步需求分析应形成结论性文档。比如，经过初步的需求分析，“家庭保安系统”的部分初步需求文档如下：

18 【例4.1】 “家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与户主进行信息交互。
系统开机后，软件系统负责显示系统当前的工作状态，接收并处理户主的命令。 当系统处于配置状态，软件系统允许户主进行配置操作。配置操作包括：①指定每一传感器的种类和编号；②设置开、关机密码；③指定报警电话号码；④指定报警延迟和电话重拨延迟时间（以秒为单位）。 当系统处于监视状态时，软件系统即开始对所有传感器实施监控。当软件系统接收到传感器发出的数据后，判别是否出现异常事件，如果是，则经过指定的延迟时间即开始拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。此时软件系统负责向监控中心报告异常事件发生的地点、时间和性质。

19 【例4.1】 以上文档没有包括约束条件、测试标准等方面的内容。
初步需求文档将是后续详细需求分析的基础。在此基础上，就可以采用某种需求分析方法进行详细的需求分析。 在以后几章中，将分别介绍几种详细的需求分析方法和其中最重要的需求建模技术，它们是： “面向数据流的需求分析方法”； “面向数据的需求分析方法”； “面向对象的需求分析方法”。

20 需求建模技术 为了使用户需求逐步精细化、完全化、一致化，通常采用需求建模技术，即用建立目标软件系统模型的方法来刻画软件系统中的信息、处理功能和外部行为。 通常，分析人员选定一种分析方法，并用该方法中的一些图形记号分别表示信息流、处理功能和系统行为，并利用受限制的自然语言给出用户需求的描述。这种模型的表示机制还应具有良好的结构化能力，以便处理大型问题的按层次分解的问题。 软件需求分析的过程，实际上是软件模型的建造和不断完善的过程。

21 需求建模的步骤 ①在分析的初期，分析人员通过访谈、会议、实际观 察、分析现有系统等方法获取初步的用户需求。
②分析人员根据选定的一种分析方法，在初步用户需 求的基础上构筑初步的模型作为开发方和用户相互 沟通的表示机制。 ③分析人员在用户的密切配合下，利用选定的分析方 法不断地对模型进行精细化、一致化、完全化，直 至获得满意的用户需求为止。 在分析阶段构筑的模型不应涉及软件实现的细节，以免分散分析人员的注意力、限制软件设计人员为提高软件质量和效率而选择实现方法的自由度。 需求分析结束时确立的软件模型是生成需求规格说明的依据，也是软件设计和实现的基础。

22 快速原型技术 如果按照传统的软件开发方法，需要经过漫长的开发时间之后用户才能看到目标软件的最初版本。此时用户常常会提出许多修改意见，有时甚至全盘否定，导致开发失败。为了降低开发风险，在需求分析阶段常常采用快速原型技术。 1．快速原型技术的基本思想 在软件开发的早期，快速开发一个目标软件系统的原型，让用户对其进行评价并提出修改意见，然后开发人员根据用户的意见对原型进行改进。当原型几经改进最终确认后，它将直接进化成软件产品，或者由软件设计、编码人员按照模型所确立的外部特征去实现软件产品。

23 2．采用快速原型技术的具体步骤 ①采用一种分析方法生成一个软件系统或其中所关心部分的简化需求规格说明。
②对该规格说明进行评审通过后，立即生成设计规格说明。为了快速生成原型，这种设计仅注重所关心的问题，如软件的总体结构、用户界面和数据设计、或者某个复杂的算法等等，不注重过程内部的控制流设计。 ③使用可重用软部件、用户界面自动生成器等工具快速生成可运行的软件原型并通过测试。 ④将原型提交给用户进行评价，以便征求改进意见。 ⑤上述过程反复迭代，直至用户完全满意。此时的原型已完全、准确地反映了目标软件在所关心方面的需求，可作为需求规格说明的一部分而成为软件设计的基础。

24 3．快速原型技术的适用场合 该技术特别适合于软件产品要求大量的用户交互、或产生大量的可视输出、或设计一些复杂的算法等场合，目前的绝大多数软件都适合于快速原型技术。 除非由于问题相当复杂，致使开发快速原型可以获得的支持太少、所冒的风险太大时，就不易采用。但对于其中的某些子问题，尤其是用户界面，还可采用快速原型技术进行部分分析。

25 4.2.4 问题分解与抽象、多视点分析技术 问题分解技术
问题分解与抽象、多视点分析技术 问题分解技术 分析人员常常采用一种问题分解的技术。即将一个大型复杂的问题分解为若干个子问题，然后对每一个子问题逐个进行分析，再自底向上综合成整个问题的分析结果。这种分解可以逐级进行，直至子问题的规模降到合适的程度。 问题抽象技术 分析人员在分析过程中要善于从诸多的特殊问题中抽象出一般的问题，首先关注一般问题的解决途径，再用其指导特殊问题的求解。在抽象的过程中，还要注意用户的描述所处的抽象级别的不同，以便建立清晰的思路。

26 问题分解与抽象、多视点分析技术 比如，在“家庭保安系统”中，用户可能提出“系统状态显示”、“用户编制程序时的系统外部行为”等的需求。分析人员则应在“用户界面”这一抽象级别上统一地规划软件系统与用户的交互行为。可见，在不同的抽象级别上去分析不同层次的问题，也是解决复杂问题的一个重要方法，它可以避免不一致性，减少分析的工作量。 多视点分析技术： 为了获得全面的需求分析结果，防止遗漏，有必要从各个视点分别对问题进行理解与分析，然后综合成全面的理解。分析人员可以就系统视点与用户视点、信息视点、功能视点与行为视点等多个视点分别进行分析，以确保需求分析的完全性。

27 4.3 需求规格说明与评审 需求分析的主要阶段性产品是需求规格说明书。它必须通过需求评审后才能生效，这是一个重要的里程碑。
4.3 需求规格说明与评审 需求分析的主要阶段性产品是需求规格说明书。它必须通过需求评审后才能生效，这是一个重要的里程碑。 需求规格说明书的作用与内容 1. 需求规格说明书的作用主要有： 1）它是软件设计人员进行设计和编码的出发点和基础； 2）它是对目标软件产品进行验收测试的依据。这就要求需求规格说明书中的各项需求都应该是可测试的； 3）它起到软件开发方和客户（或用户）方之间的一份合同的作用。

28 4.3.1 需求规格说明书的作用与内容 2. 需求规格说明书中的内容 应主要包括功能与行为的需求描述和非行为需求描述。
需求规格说明书的作用与内容 2. 需求规格说明书中的内容 应主要包括功能与行为的需求描述和非行为需求描述。 功能与行为需求的分析与描述方法将在以后几章中根据不同的需求建模方法分别介绍。 非行为需求是指目标软件系统在工作时应具备的属性，主要有运行效率、可靠性、安全性、可维护性、可移植性等等。 在需求规格说明书中不应包括如人员需求、成本预算、进度计划、质量保证计划等内容，以便使其简洁、目标明确。

29 需求规格说明书的基本格式框架 目录 1． 引言 1.1 本说明的编写目的 1.2 软件产品的作用范围 1.3 定义、同义词与缩写 1.4 参考文献 2． 概述 2.1 产品与其环境间的关系 2.2 功能概述 2.3 用户特征 2.4 约束条件 2.5 假设与前提条件

30 需求规格说明书的基本格式框架 3．功能或行为需求 3.1 功能或行为需求1：1）引言 ）输入 3）处理过程描述 4）输出 3.2 功能或行为需求2：1）引言 ）输入 … … … … … 3.n 功能或行为需求n: 1）引言 ）输入

31 需求规格说明书的基本格式框架 4．外部界面需求 4.1 用户界面 4.2 硬件界面 4.3 软件界面 5．性能需求 5.1 精度 5.2 时间特征 5.3 灵活性 6．设计约束 6.1 标准化约束 6.2 硬件约束 … …

32 需求规格说明书的基本格式框架 7．其他需求 7.1 数据库需求 7.2 用户操作需求 7.3 工作场地需求 8．软件产品属性 8.1 可用性 8.2 安全性 8.3 可维护性 8.4 可移植性 附录 索引

33 需求评审 软件系统中的错误约有15%来源于需求分析中的错误。而在维护阶段去改正这部分错误是相当困难的。为了及时发现并纠正这类错误，必须对需求规格说明书进行评审，即需求评审。 1. 评审标准（按照重要性的次序） 1）正确性。指需求规格说明书中的每一项功能、行为、性能的描述都是正确的、合理的，并能满足用户的期望。 2）无歧义性。指规格说明书中的每个需求陈述都只有唯一的解释。要避免产生歧义性，就应使用标准化术语，并对术语的语义进行统一的解释。

34 1. 评审标准（按照重要性的次序） 3）完全性。指不遗漏任何用户需求。即需求规格说明书中包括了所有的功能、行为、性能约束等。
1. 评审标准（按照重要性的次序） 3）完全性。指不遗漏任何用户需求。即需求规格说明书中包括了所有的功能、行为、性能约束等。 4）可验证性。指需求规格说明书中的每一项需求都是可以检验的。 5）一致性。指陈述的需求之间不存在矛盾之处。 6）可理解性。指规格说明应尽量简洁、明确，便于分析人员、客户（用户）、设计人员、测试人员和维护人员的理解。因此，应尽量减少专业化的词汇。

35 1. 评审标准（按照重要性的次序） 7）可修改性。指需求规格说明书的框架结构应能比较容易地实现对其可能进行的增补、删除和修改，并能保持总体结构不变。 8）可追踪性。指规格说明可向前追踪，即其中的每一项需求与用户的原始需求项清晰地联系起来；也可向后追踪，即为后续开发和其他文档引用这些需求项提供了依据。

36 2. 需求评审过程 需求评审过程应采用召开正式评审会议的形式。
2. 需求评审过程 需求评审过程应采用召开正式评审会议的形式。 参加的人员应当有用户、系统分析员、系统设计人员等。在评审会上，分析人员应说明软件产品的总体目标，也就是介绍需求规格说明书中的主要内容。之后，与会人员对说明书的核心部分——需求模型进行评估。并按照上述的评审标准逐一进行审查，最后确认其是否具有良好的品质、是否构成以后开发的良好的基础。如果在评审过程中发现说明书中存在错误或遗漏，应责承分析人员返工，并再行评审。需求评审也可采用先进行技术评审，再进行管理复审的方法进行。管理复审应有开发方和客户方（或用户方）管理部门负责人参加，复审通过后，双方应签订正式的合同。

37 部分习题答案，仅供参考 4.3 以下描述哪些属于不精确的用户需求描述？如果不精确，应如何改正？ 1）系统应表现出良好的响应速度。
4.3 以下描述哪些属于不精确的用户需求描述？如果不精确，应如何改正？ 1）系统应表现出良好的响应速度。 2）系统必须用菜单驱动。 3）在数据录入界面，应该有10个按钮。 4）系统运行时占用的内存不得超过256KB。 5）电梯应平稳运行。 6）即使系统崩溃，也不能损坏用户数据。 答：1）不精确，应指出具体项目和响应时间。 2）“必须”不精确，因系统还可以用其他方式驱动。 3）不精确，因过于细致，限制了设计的自由度。 5）不精确，应指出加速、减速、运行速度的大小。 6）不精确，因这是一个难以保证的“用户需求”。 4）仅是一个约束条件。

38 部分习题答案，仅供参考 4.4 判断下述语句对中两种陈述的一致性： 1）所有命令的响应时间应小于1秒。 EDIT命令的响应时间应小于3秒。
4.4 判断下述语句对中两种陈述的一致性： 1）所有命令的响应时间应小于1秒。 EDIT命令的响应时间应小于3秒。 2）所有命令的响应时间应小于3秒。 EDIT命令的响应时间应小于1秒。 3）所有命令的响应时间都应该恰为3秒。 EDIT命令的响应时间应小于5秒。 4）EDIT命令的响应时间应小于3秒。 答：1）、3）、4）语句中的两种陈述不一致。 返回目录