《软件工程》课件-第3章 需求分析

第3章

需求分析XX大学XX系XXX软件工程教程电子科技大学出版社学习目标l

了解需求分析的目的与意义；l

熟悉需求分析的任务与步骤；l

熟悉获取需求的常用方法；l

掌握结构化分析方法和需求描述的图形工具；l

了解需求管理和需求验证的基本内容；l

能够承担一般复杂度的软件需求分析任务，撰写软件规格说明书并进行基本的需求验证。目录010203需求分析的任务需求分析的步骤结构化需求分析方法需求分析的图形工具040506需求验证与管理本章小结需求分析的任务01需求分析的意义软件开发实质上是围绕用户需求的软件实现，对用户需求的深入理解和准确描述是软件开发获得成功的关键，模糊、残缺、变化的需求描述是导致软件开发和维护各种问题的主要根源。在分析和统计以往开发失败的软件工程项目的原因的过程中发现，因为需求不完整而导致失败的项目占13.1%，缺少用户参与导致项目失败的占12.4%，需求和需求规格说明书更改的占8.7%，可见需求分析完成的质量直接影响后续软件开发的质量。需求分析的目标软件按照软件生存周期的划分，需求分析阶段位于软件定义时期的最后一个阶段。在需求分析阶段，软件组织经过可行性研究阶段对软件项目大大压缩简化了的系统分析和设计工作，已经对待开发的软件系统有了初步的了解，为了进入实质性的开发阶段，需求分析的任务还不是确定软件系统怎样实现它所应该完成的工作，而仅仅是确定软件系统必须完成哪些工作才能满足用户对软件的需要，也就是需要确定软件应该“做什么”，而不是确定软件“怎么做”。为此，需对待开发系统的各项功能、性能以及可靠性、安全性、可操作性等质量指标进行进一步的具体化、明确化。需求分析的特征软件项目最困难、最艰巨的工作是弄清楚开发什么，因为，任何需求否都来源于用户，而在实际软件项目中，开发方往往面对的是用户也不知道或描述不清楚、不完全他的需求到底是什么的局面，同时，软件组织可能需要面对各个领域应用开发，而需要沟通的用户特征也千差万别，这又使得获取需求、理解需求进一步复杂化，与用户知识背景的鸿沟必然造成双方交互、沟通的障碍，难以提取出完整、准确、清晰的用户需求。需求分析的特征因此，需求分析过程必须采取行之有效的沟通技术，集中精力的细致工作，而且必须对需求分析的结果进行严格审查和验证。需求分析的另外一个特点是，在不同软件阶段修复由于需求分析阶段引发的问题所带来的成本将大幅度上升。需求分析的特征软件需求分析的最终阶段性结果是软件需求规格说明书，该报告必须遵守如下准则。（1）必须理解并描述问题的信息域，根据这条准则应该建立数据模型；（2）必须定义软件应该完成的功能，要求建立功能模型；（3）必须描述作为外部事件结果的软件行为，要求建立行为模型；（4）必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。需求分析的特征对于单一需求，必须具有如下五个基本性质。（1）必要的，即该需求是用户所要求的；（2）无歧义的，即该需求只能用一种方式解释；（3）可测的，即该需求是可进行测试的；（4）可跟踪的，即该需求可从一个开发阶段跟踪到另一个阶段；（5）可测量的，即该需求是可以量化的。需求分析的具体任务需求分析阶段的具体任务可以划分为六方面。（1）确定对系统的综合要求对系统的综合要求主要包括以下九个方面。①

功能需求指所开发的软件系统必须向用户提供的服务。通过修分析应该划分出软件系统必须完成的所有功能。需求分析的具体任务②

性能需求指系统必须满足的定时或容量约束，通常包括系统响应时间、所占用磁盘容量、所需内存量以及精度等。例如，“人事管理系统查询程序必须在30秒内反馈查询结果，占用内存不应超过200MB”。需求分析的具体任务③

可靠性和可用性需求可靠性需求描述需定量描述系统的可靠性，例如，“自动驾驶系统一万公里内不应出现两次以上故障”。可用性需求则是从系统可正常使用的角度定量描述了软件系统可以使用的程度。例如，“自动分拣系统一周之内可以正常使用的天数在6天以上”。需求分析的具体任务④

环境需求指设计或实现软件系统所需要遵守的外部限制条件。（如机型、外设、硬件配置、操作系统平台和数据库管理系统以及其他支撑软件、实现语言。⑤

接口需求指应用系统与它的环境通信的格式。常见的接口需求包括：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。需求分析的具体任务⑥

出错处理需求指系统对运行中出现的错误应该怎样相应。此类错误可以分为两类，一类是系统在运行中有关环境出现外部问题，系统应该如何响应。一类是，系统自身运行产生错误，应该如何响应。但是，应该有选择地提出此类需求，毕竟成本和效率也是软件工程的主要目标之一，况且人们所开发出的相关系统也是以正确性为导向的。为了控制成本和提高效率，应对系统本身错误的检测仅限于系统的关键部分或核心部分，而且应该尽可能少。需求分析的具体任务⑦

安全性需求指系统对数据安全、操作安全方面的需求。例如，软件功能使用中的权限边界要去，数据防泄漏、防篡改要求、功能防越权使用要求以及极端条件（物理环境、遭受恶意攻击）下可以正常使用的需求等。⑧

逆向需求指系统不应该“做什么”。理论上这类需求有无限多个，为了控制成本和设计实现效率，应该仅选取为了澄清真实需求而消除需求误解的那些逆向需求。需求分析的具体任务⑨

将来可能提出的要求应该明确列出根据分析将来很可能会提出的要求。目的是在设计过程中对系统将来的可能扩展做预先准备，方便将来的系统扩充和完善。需求分析的具体任务（2）分析系统的数据需求任何一个软件系统本质上都是一个信息处理系统，它所必须提供的服务，实质上可以归纳为信息变换和信息输出，这在很大程度上决定了系统的面貌，对系统的设计与实现具有深远的影响，因此，必须分析系统的数据要求，这项工作也是需求分析的一个重要内容。分析系统的数据需求通常采用建立数据模型的方法，主要描述系统所需要的静态数据、动态数据、数据库结构、数据字典。需求分析的具体任务（3）建立系统的逻辑模型通过以上两项的分析结果可以建立系统的详细的逻辑模型（即系统所包含的处理、处理之间的逻辑关系以及系统所需处理的数据结构。系统的逻辑模型通常包括数据流图、实体联系图、状态转换图、数据字典及主要处理的算法。需求分析的具体任务（4）修订系统开发计划依据在需求分析过程中获得的对系统更深入、更具体、更准确的了解，可以更可靠地估计系统的成本和进度，以修正以前制定的开发计划。需求分析的具体任务（5）编写软件需求规格说明书编写软件需求规格说明书（Software

RequirementSpecification,SRS）的目的是建立用户和开发者对未来软件的共同理解，相当于两者之间的一份技术合同，是进一步设计和实现软件的基础，也是进行确认测试和验收测试的基准。需求说明书应当具有准确、一致、完整、清晰、可检验、直观、易读和可修改特性。书写软件需求规格说明书应当尽量采用标准的图形、表格和简单的符号，尽量不用用户不易理解的术语，使不熟悉计算机的用户也能一目了然。需求分析的具体任务编写软件需求规格说明书可以参照GB/T9835-2008《计算机软件需求规格说明规范》，此标准给出了软件需求规格说明（SRS）的编制要求、内容框架和提纲示例。该规范不提倡把软件需求说明书划分成等级，避免把SRS定义成更小的需求子集。该

规范既适用于软件客户，也适用于软件开发者。需求分析的具体任务（6）需求分析评审评审需求分析结果的目的是发现其中的错误、遗漏和矛盾，需要对需求分析的各项内容进行全面仔细的审查，以确认“软件需求规格说明书”，使其成为合格的软件设计和实现的基础。需求分析的步骤02需求分析的步骤需求分析需要遵循一定的步骤才能有序进行，保障获得正确的需求。一般说来，需求分”析可以划分为需求获取、分析建模、需求描述和需求验证四个步骤进行。需求分析的步骤（1）需求获取获取需求实质上是一个需求收集的过程，要做充分的调查研究。通常是从分析当前系统包含的数据开始，分析当前系统在处理信息时的不足，用户”希望改进的主要问题及迫切性等。收集需求的常用方法有问卷调查、访谈、实地操作、建立原型等，收集的需求主要包括功能需求、性能需求、可靠性需求、可用性、人机界面需求、约束、出错处理等内容。需求分析的步骤（2）分析建模需求分析的核心任务是建立分析模型，即把来自用户的需求信息通过分析、提取、归纳、抽象建立起描述目标系统的模型。常用的模型工具包括数”据流图、系统流程图、实体联系图、状态转换图、用例图以及类间关系图等。传统的面向过程的软件工程方法学，主要采用数据流图建立目标系统的逻辑模型。需求分析的步骤（3）需求描述需求描述是指编制需求分析阶段各类文档。一般情况下，对于大型、复杂软件系统在需求分析阶段会产生三个文档，分别是系统定义文档（用于描述用户需求的报告）”、系统需求规格说明书、软件需求规格说明书，分别从不同的角度和层次描述项目开发的需求。对于简单的小规模软件系统，只需编制SRS即可。SRS是站在开发者的角度，以开发者的术语描述待开发系统的业务模型、功能模型、数据模型、行为模型等内容，经过严格评审后将软件概要设计和详细设计的基线。需求分析的步骤对于大型项目，需求分析阶段需要完成的文档，包括可行性研究报告、项目开发计划、软件需求规格说明、数据要求说明和测试计划；对于中型项目，可将可行性研究报告合并到项目开发计划，软件数据需求合并到软件规格说明书；对于小型项目，一般只需完成软件需求和开发计划即可。”需求分析的步骤（4）需求验证第四步是验证以上的分析结果。因为需求分析的成果是后续开发的重要依据和基础，为了提高软件产”品的最终质量，降低开发成本，必须对需求分析结果从完整性、一致性、有效性和现实性四个方面进行严格的正确性验证，并且要对需求的变更实施可回溯的管理，避免无法追踪错误来源导致的混乱。需求分析的步骤①

一致性。是指所有需求必须是一致的，任何需求不能存在相互矛盾。②

完整性。是指所有需求必须是完整的，规格”说明书应该包括用户需要的每一项。③

现实性。是指指定的需求应该是现有软硬件技术基本上可以实现的。需求分析的步骤④

有效性。是指必须证明需求确实能够解决用户面对的问题。”⑤

可回溯。是指所有需求分析的过程性结果要有完整的记录，便于定位问题位置。需求分析的步骤图3.2需求分析的步骤结构化需求分析方法03结构化需求分析方法结构化分析（Structured

Analysis，SA）方法，20世纪70年代由Yourdon

Constaintine及DeMarco等人正式提出和发展，并得到了广泛的应用。它采用归纳思维和演绎思维的逻辑方法，逐步建立目标系统的逻辑模型（包括数据模型、功能模型和行为模型），进而描绘出满足用户要求的软件系统。结构化需求分析方法结构化需求分析的基础是获取用户描述的需求，结果是形成系统分析员描绘的用户需求。获取用户描述的需求常用的方法有访谈、简易的应用规格说明技术、快速原型法。需求的获取（1）访谈访谈法是最早开始使用的获取用户需求的技术，也是迄今为止仍在广泛使用的需求获取技术。访谈有两种基本形式，一是正式访谈，一是非正式的访谈。正式访谈时，系统分析员要事先准备一些具体问题，这类问题一般具有固定的答案。非正式访谈时，分析员所提出的问题是开放性的，没有固定答案，目的是鼓励用户说出自己的想法。需求的获取当需要调查大量人员的意见时，也可以采取调查表的做法。调查表的书面表达方式，往往更正式、更准确。分析员在收集调查表后需要仔细阅读，然后再有针对性地访问一些用户，以便向用户询问新发现的问题。需求的获取（2）简易的应用规格说明技术在使用传统的访谈法时，用户处于被动地位，而且往往有意无意与开发者区分“彼此”，双方无法进行深入交流，而这恰恰是准确获取需求的关键，所以有时并不能获得理想的效果。需求的获取为了解决上述问题，人们研究出一种面向团队的需求收集方法，称为简易的应用规格说明技术。这种方法提倡用户和开发者密切合作，共同标识问题，提出解决方案要素，并指定基本需求。目前，这种技术已经成为主流技术。需求的获取①

进行初步访谈，通过用户对基本问题的回答，初步确定待解决问题的范围和解决方案。然后，开发者和用户分别写出“产品需求”。②

定会议的时间和地点以及主持会议的协调人。邀请双方的代表出席会议，并在会前预先把写好的产品需求分发给每一位与会者。需求的获取③

要去每位与会者会前认真审查产品需求，并列出作为系统环境组成的部分对象、系统将产生的对象以及系统为了完成自己的功能将使用的对象。此外，还要求每位与会者列出操作这些对象或与这些对象交互的服务（即处理或功能）。最后还应该列出约束条件（例如成本、规模、完成日期）和性能标准（例如速度、容量）。并不希望每位与会者列出的内容毫无遗漏，但求能够获得对目标系统准确的认识。需求的获取④

会议开始后，讨论的第一个问题是是否需要这个新产品，一旦大家都同意确实需要这个新产品，每位与会者则把他们会前准备好的列表展示出来供大家讨论。在这个阶段，严格禁止批评和争论，以免影响每位与会者深入交流的意愿。需求的获取⑤

在讨论的基础上，大家一起共同创建一张包含各个议题的组合列表。调整后的组合列表并不真正删除某项内容。在每个议题的组合列表都建立起来后，在由协调人主持讨论这些列表，以形成每个议题都达到意见一致的局面。需求的获取⑥

一旦得到了意见一致的列表，就把与会者分成更小的小组，针对每张列表中的项目制定小型规格说明（需要对列表中包含的单词或短语进行准确的说明）。需求的获取⑦

每个小组向全体与会者展示他们制定的小型规格说明，供大家讨论。意见一致后，每个与会者都制定一整套确认标准，并把自己制定的标准再次提交会议讨论，以创建出意见一致的确认标准。最后，有一名或多名与会者根据会议成果起草完整的软件规格说明书。需求的获取（3）快速原型法快速原型是最准确、最有效、最强大的需求获取技术。快速原型就是快速建立起旨在演示目标系统主要功能的可运行的程序。需求的获取为了快速地构建和修改原型，通常使用以下三种方法和工具。①

第四代技术包括数据库SQL语言和报表语言、程序以及应用系统生成器和其他非常高级的非过程性语言。需求的获取②

可重用的软件构件这种方法通过使用软件构件（软件构件也叫组件）直接装配成原型系统。软件构件可以使数据结构或程序模块。需求的获取③

形式化规格说明在过去的几十年中，人们已经研究出许多形式化规格说明语言和工具，用于替代自然语言描述需求，远期愿景是开发出能够把形式化描述的规格说明书直接翻译成可执行的目标代码。结构化需求分析结构化需求分析方法基于“分解”和“抽象”的基本指导思想，采用面向数据流自顶向下逐步求精的分析策略，逐步建立目标系统的逻辑模型。“分解”是面对一个复杂系统时，为了将复杂性降低到人类认知能力可以掌握的程度，而把一个大系统（问题）分解成若干个小问题，然后分别解决。结构化需求分析需求分析的目标之一是把数据流图中的数据流和数据存储分解定义到元素级。通常做法是从数据流图的输出端着手分析，这是因为输出数据决定了系统必须具有的最基本的组成元素（即功能）。结构化需求分析具体做法是，沿着数据流图从输出端往输入端回溯，以确定每个数据元素的来源，与此同时也就初步定义了有关的算法。通常把分析过程中得到的数据元素的信息定义成数据字典，对算法的简明描述记录在IPO表中。通过分析而补充的数据流、数据存储和处理，应该添加到数据流图的适当位置。结构化需求分析复查的过程是从输入端开始，向用户解释输入的数据是经过怎样的处理一步步变成了输出数据。反复经过上述过程，把数据流图“分解”扩展到更低（即更详细）的层次，从而得到更具体、更令人满意的功能性需求的了解。需求分析的图形工具04E-R图E-R图也叫实体联系图，用于描述用户对数据的要求。系统分析员在与用户沟通中通常需要建立一个面向问题的概念性数据模型，用以描述站在用户角度看到的数据，这种概念性的数据模型中包含三种相互关联的信息，即数据对象、数据对象的属性以及数据对象间的相互连接关系。E-R图是描述概念性数据模型的常用工具，这种概念性数据模型因而也叫做E-R模型，它包括三种要素，即数据对象、属性和联系。E-R图（1）数据对象数据对象是对软件必须理解的复合信息的抽象。复合信息是指具有一系列不同性质或属性的事物，仅有单个属性值的事物不能抽象成对象（例如颜色、长度等）。数据对象可以是实体世界的事物、行为、事件、角色、部门、地址或结构等。总之，可以由一组属性来描述的实体都可以被归纳成数据对象。E-R图数据对象之间彼此是有连接关系的，例如，学生“借”书，学生“选”课程。数据对象只封装了数据而没有涵盖可以施加于其上的操作，即不包含对数据的操作的抽象。这是数据对象和面向对象范型中的“类”和“对象”的显著区别。E-R图（2）属性属性，用于定义数据对象的性质。在数据库设计时，属性被映射为相应的字段，数据对象被定义为相应的表。在确定哪些性质作为数据对象的属性时，应该根据对要解决的问题的理解，选择一组合适的属性，避免选择跟解决问题无关的属性。E-R图（3）联系联系，是指实体间的一种连接关系。正因为这种联系，实体才构成了同一个系统。联系，又称关系，从数量的角度可以分为三种类型。E-R图①

一对一联系(1:1)。例如，某公司一个部门只能有一个经理。②

一对多联系(1:N）。例如，一个学生可以选择多门课程。③

多对多联系(M:N)。例如，一门课由多个老师任教，一个老师也不只教一门课。E-R图（4）符号E-R图中三种要素的图形符号表示如图3.3所示，通常用矩形框表示实体，菱形框表示联系，椭圆形或圆角矩形表示实体（或关系）的属性。实体属性关系图3.3E-R图要素符号E-R图图3.4是教学管理系统中的一个E-R模型，描述了课程、学生、教师3个实体之间的关系。图3.4教学管理系统E-R图状态图状态图也叫状态转换图，是用于描述软件系统行为模型的图形工具，它通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为，它并不描述系统中数据的流动，尤其适合描述实时系统。状态图（1）状态状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对时间的相应方式。系统对事件响应，既可以是做一个或一系列动作，也可以是仅仅改变系统本身的状态，还可以是两者兼有。状态图在状态图中定义的状态主要有，初态、终态和中间状态。一张状态图中只能有一个初态，而终态可以有0至多个。状态图描绘循环运行过程时，通常并不关心循环是怎样启动的。当描绘单程生存周期时，需要标明初始状态（系统启动时进入初始状态）和最终状态（系统运行结束时到达最终状态）。状态图（2）事件事件是特定时刻发生的事情，它是对引起系统状态改变或做动作的外部事件的抽象，它实质上是外部事件传递给系统的控制信息。状态图（3）符号状态图中使用的主要符合如图3.5所示。初态用实心圆表示，终态用一对同心圆表示（内为实心圆）。中间态用圆角矩形表示，分为上中下三个部分。上面标注状态名称，此为必须项；中间标注状态变量的名字和值，为可选项；下部为活动表，为可选项。状态图图3.5状态图使用的符号排除了卡纸故障卡纸状态图例3.1：下面以一个办公室复印机工作过程的例子，具体说明如何使用状态图描绘系统的行为模型。do/警告复印复印命令完成命令闲置do/复印缺纸装满纸do/警告图3.6复印机状态图状态图打印机开机后处于循环工作状态，因此不关心初态和终态，未接到命令时处于闲置状态，一旦接到复印命令则进入复印状态，完成复印后又回到闲置状态，等待下一个复印命令；如果在执行复印命令时出现缺纸，则进入缺纸状态，并发出警告，等待装纸，装满纸后进入闲置状态；如果复印时发生卡纸故障，则进入卡纸状态，并发出警告等待维修人员排除卡纸，故障排除后又回到闲置状态。层次方框图层次方框图，用树形结构的一系列多层次矩形描绘数据的层次结构。结构的顶层是一个单独的矩形框，表示数据结构的整体，下面的各层矩形框表示这个数据不同层次的子集，最底层的矩形框表示这个数据结构最小的分解单元。需要注意的是，层次方框图表示的不是调用关系，而是组成关系。Warnier图Warnier图是表示数据层次结构的另一种图形工具，它比层次方框图提供了更详细的描绘手段，能指出某一类数据或某一个最小数据单元重复出现的次数，并能指明数据组成上的条件关系。Warnier图在Warnier图中，用花括号区分信息的层次，同一个花括号中的所有名称都属于一类信息。用异或符号⊕表明一类信息或一个数据元素在一定条件下才出现，而且在此符号上、下方的两个数据只能出现一个。用圆括号（）中的数字标明这个数据元素在这个数据结构中出现的次数。图3.8是用Warnier图描述的软件产品的组成结构。操作系统（P

1

）编译程序（P

2

）Warnier图系统软件编辑程序（P

3

）测试驱动程序（P

4

）设计辅助工具（P

5

）软件工具+软件产品应用软件图3.8软件产品组成的Warnier图IPO图IPO是输入-处理-输出图的简称，由美国IBM公司发展完善而来，能够方便第描绘输入数据、对数据的处理和输出数据之间的关系。它的基本形式是在左边的框中列出有关的输入数据，在中间的框内，按处理的执行秩序从上到下依次列出主要的处理，右边框内列出产生的输出数据，三个框之间用类似向量符号的粗大箭头清除地指出数据通信的情况，如下图3.9所示。IPO图图3.9主文件更新的IPO图IPO图按照上面的方法还不足以精确描述执行处理的详细情况，建议使用另一种改进的IPO图（也称为IPO表，如图3.10所示）。改进的IPO图包含的附加信息主要有系统名称、图的作者、完成日期、本图描述的模块的名字、模块在层次图中的编号、调用本模块的模块清单、本模块调用的模块的清单、注释、本模块使用的局部数据元素等。IPO图在“处理”部分可以简略地描述系统的主要算法（即数据流图中对应的各个处理的基本算法）。在需求分析阶段，IPO图中的许多附加信息暂时还不具备，但是可以在后续的阶段进一步补充修正，作为设计阶段的文档，这正是IPO图在需求分析阶段的价值和意义。IPO图图3.10改进的IPO图形式需求验证与管理05需求验证（1）验证需求的一致性验证需求分析的一致性分两种情况：①

需求分析的结果采用自然语言的形式进行描述。目前，面对这种情况，还没有更好的“测试”方法，只能采用人工技术审查的方式进行验证。由于自然语言无法精确描述、容易引起歧义的特点，往往使得软件规格说明书的一致性难以验证。尤其在目标系统规模庞大、结构复杂、文档篇幅很长的情况下，人工审查的效果是无法保证的。需求验证②

需求分析的结果采用形式化的方法进行描述。当采用形式化的陈述语言描述软件规格说明时，可以借助相应的软件工具验证需求的一致性。这种方法相较于人工审查能更好地保证软件需求的一致性。需求验证（2）验证需求的现实性为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软硬件技术实现目标系统的可能性。必要时可以采用仿真或模拟技术辅