软件工程概论：第3章 需求分析

1、第3章 需求分析3.1 需求分析的任务3.2 需求获取的技术3.3 需求规格说明书3.5 需求验证3.4 需求分析技术结构化技术形式化技术需求的重要性需求问题的典型案例Bray2002PROMS（演出权益协会），1100万，1992，未能以常人能理解和检查的形式表述软件需求，软件规格说明也考虑不周RISP（西萨克斯地区信息系统计划），4300万，1990，缺少清晰的项目范围定义TAURUS（伦敦股票交易）， 7500万（1.4B），1993，未能协调不一致的需求LASDS（伦敦救护车服务派遣系统），1992，社会服务领域糟糕的需求分析ATC（空中交通控制系统），1.8亿，1998-2001，缺

2、乏健壮的需求规格说明2022/9/242与客户沟通的问题需求的边界问题不一致需求的管理问题需求不清晰的问题需求未明确就开始后续工作的问题需求的重要性需求错误的高代价性 需求的重要性Frederick BrooksBrooks1987 “开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。”需求的重要性需求工程的复杂性处理范围广泛 现实世界和计算机世界 涉及诸多参与方 客户、用户、领域专家、需求工程师、软件开发者、系统维

3、护者等 处理内容多样 功能需求、非功能需求处理活动互相交织 需求开发的各项活动虽然在理论上具有顺序处理的特性，但在实际执行过程中往往是迭代和互相交织的 处理结果要求苛刻 正确性、完整性和一致性 3.1.1 需求定义需求分析的任务：完全弄清用户（顾客）对软件系统的确切要求，用规范的格式表达出来。给出一个将要用软件来解决的一个问题的初始定义。需求的定义IEEE：（1）用户为了解决问题或达到某些目标所需要的条件或权能；（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或权能；（3）对（1）或（2）中的一个条件或一种权能的一种文档化表述。3.1.1 需求定义用规范的

4、格式表达出来的需求说明称为需求规格说明书。需求规格说明书应该具有准确性和一致性。具有清晰性和没有二义性。直观、易读和易于修改。软件需求规格说明书（Software Requirements Specification，SRS）功能需求充分描述了软件系统所应具有的外部行为。非功能需求描述了系统展现给用户的行为和执行的操作等。性能、质量、对外接口、约束3.1.1 需求定义需求与规格说明举例功能需求R2.2.3-1：一旦书籍被借出，则在归还之前，它不能被再次借阅。R2.2.3-2：在归还的书超过30天的归还期限时，归还后应该进行超期处罚。3.1.1 需求定义性能需求速度（Speed），系统的响应时间

5、。PR2.3.3-1：所有的用户查询都必须在10秒内完成。容量（Capacity），系统所能存储的数据量。PR2.3.3-2：系统应该能够存储至少10万条销售记录吞吐量（Throughput），系统在连续的时间内完成的事务数量。PR2.3.3-3：解释器每分钟应该至少解析5000条没有错误的语句。负载（Load），系统可以承载的并发工作量PR2.3.3-4：系统应该允许200个用户同时进行正常的工作。实时性（Time-Critical），严格的实时要求。PR2.3.3-5：监测到病人异常后，监控器必须在0.5秒内发出警报。3.1.2 需求的层次将软件的功能需求分为三个层次：业务需求（busin

6、ess requirement）：反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求（user requirement）：描述了用户使用产品必须要完成的任务和具备的功能，这在用例文档或方案脚本说明中予以说明。功能（系统）需求（functional requirement）：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足其业务需求。除此之外，还包括非功能需求。3.1.2 需求的层次业务需求系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统 为了满足用户的业务需求，需求工程师需要描述系统高层

7、次的解决方案，定义系统应该具备的特性（Feature）参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision） 特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope） 3.1.2 需求的层次用户需求执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么对所有的用户需求，都应该有充分的问题域知识作为背景支持 特性模糊、不清晰 多特性混杂 多逻辑混杂 3.1.2 需求的层次系统需求用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求 系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员

8、需要实现什么 将用户需求转化为系统需求的过程是一个复杂的过程首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。 3.1.2 需求的层次3.1.2 需求的层次从功能需求的层次性看需求开发3.1.3 需求的开发与管理可以将整个软件需求工程研究领域划分为需求开发和需求管理两部分，需求开发可进一步分为：需求获取（elicitation）、需求分析（analysis）、编写需求规格说明书

9、（specification）和需求验证（verification）四个阶段。3.1.3 需求的开发与管理需求获取需求获取是从人、文档或者环境当中获取需求的过程需求工程师必须要利用各种方法和技术来“发现”需求 需求分析建模来整合各种信息，以使得人们更好的理解问题为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案检查需求当中存在的错误、遗漏、不一致等各种缺陷，并加以修正 需求获取和需求分析是交织在一起的 3.1.3 需求的开发与管理需求规格说明获取的需求需要被编写成文档，主要目的是为了在系统涉众之间交流需求信息业务需求被写入项目前景和范围文档用户需求被写入用户需求文档（或者用例文

10、档）系统需求被写入需求规格说明需求验证确保需求规格说明文档能正确、准确的反映用户的意图确保文档的高质量：文档内每条需求都正确、准确的反映了用户的意图；文档记录的需求集在整体上具有完整性和一致性；文档的组织方式和需求的书写方式具有可读性和可修改性 3.1.3 需求的开发与管理需求管理：保证需求作用在整个软件的产品生命周期中的持续、稳定和有效发挥定义需求基线（迅速制定需求文档的主体）。评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。以一种可控制的方式将需求变更融入到项目中。使当前的项目计划与需求一致。估计变更需求所产生影响并在此基础上协商新的承诺（约定）。让每项需求都能与其对应的设计

11、、源代码和测试用例联系起来以实现跟踪。在整个项目过程中跟踪需求状态及其变更情况。3.1.3 需求的开发与管理3.1.3 需求的开发与管理需求工程过程的迭代性3.2.1 需求分析人员的组成对于软件开发人员首先要解决的问题是：怎样获取这些需求、并且整理和组织好有关需求文档，以符合行业的规范进行表达。需求分析小组的人员由两方面组成，一方面是熟悉软件开发工作的、参与软件需求分析的专业技术人员，也就是人们常说的系统分析员，另一方面就是用户（或者是顾客），两方人员缺一不可。一般的做法是：由系统分析员作为需求分析的组织者，和用户结合起来共同分析软件需求，3.2.2 需求的类型通常需求分为两种类型：功能性需求

12、：需要计算机系统解决的问题，也就是对数据的处理要求，这是一类最主要的需求。非功能性需求：实际使用环境所要求的需求，往往是一些限制要求，如性能要求、可靠性要求、安全保密要求等等。3.2.3 需求获取和需求分析交流方式互相学习实地考察收集相关资料语言交流面谈：面谈前的准备、面谈的进行、面谈后的总结图形表格工具时间表3.2.3 需求获取和需求分析确定客户需要什么需求阶段：需求阶段的第一步是理解应用域（简称域）一旦开发小组成员达到了对该域的充分理解，就可以建造一个商业模型该商业模型用来确定客户的初始需求，然后应用迭代法发现客户需求的过程被称为需求启发（或称为需求获取、需求捕获、需求引导等）。一旦提出了

13、最初的需求，推敲和扩充的过程被称为需求分析。3.2.3 需求获取和需求分析理解应用域需求启发（获取）尽快熟悉应用域，或聘请领域专家建立术语表建立商业模型（初始）需求分析建立模型的技术：访谈：程式化的（structured）、非程式化的（unstructured）其他技术：发放调查问卷；检查客户在业务上使用的各种表格（硬数据分析、文档检查）；对用户直接观察；集体获取方法 ：头脑风暴（Brainstorming）、专题讨论会（Workshop）3.2.3 需求获取和需求分析初始需求：需求是动态的需求是迭代的功能性需求和非功能性需求的处理3.3 需求规格说明书需求说明的目的为了方便需求分析小组共同讨

14、论软件需求作为下一步软件设计的基础作为软件测试的根据需求说明的方法在进行需求说明工作过程中，往往采取自上而下、由粗到细、多次循环、逐步完善的方法。使用图表和形式语言表达的需求是用户和开发人员沟通的桥梁。3.5 需求验证为确保系统分析员和用户之间都能正确理解需求，通常要在下面几个方面验证：需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？系统真的能做顾客所请求做的事吗？每一条需求所描述的事物是顾客需要的吗？需求是可检验的吗？需求是可跟踪的吗？每一系统功能都能被跟踪到要求它的需求集合吗？容易找到处理一个系统特定方面的需求集合吗？3.5 需求验证对目标系统的逻辑模型进行完善和补充。

15、最后按照约定的格式写出规范完整的需求说明书。作为需求分析阶段最后一项工作，就是双方或者三方的复审后的签字，作为软件开发合同的组成内容，签字后，如果在后续的开发过程中要更改，双方要重新协商，达成协议后再更改。需求分析技术需求分析技术结构化需求分析技术面向对象需求分析技术形式化需求分析技术软件开发方法结构化开发方法面向对象开发方法形式化开发方法需求分析技术1、结构化方法（Structure Method）结构化方法由结构化分析、结构化设计和结构化程序设计构成，也称Yourdon方法。最早的、最传统的软件开发方法指导思想是自顶向下、逐步求精面向数据流的开发方法基本原则是功能的分解与抽象出现较早，适用

16、于数据处理领域不适用于规模大以及特别复杂的项目需求分析技术结构化方法包括：结构化分析，就是根据分解与抽象的原则，按照系统中数据处理的流程，用数据流图来建立系统的功能模型，从而完成需求分析。结构化设计，就是根据模块独立性准则、软件结构准则，将数据流图转换为软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的概要设计。结构化程序设计，就是根据结构程序设计原理，将每个模块的功能用相应的标准控制结构表示出来，从而实现详细设计。需求分析技术2、面向对象方法：一种运用对象、类、继承、封装、聚合、消息传送、多态性等概念来构造系统的软件开发方法。发展历程：面向对象真正的第一个里程碑是1980年Smal

17、ltalk-80的出现。但最后使面向对象广泛流行的则是面向对象的程序设计语言C+。 面向对象开发的基本出发点是尽可能按照人类认识世界的方法和思维方式来分析和解决问题。面向对象开发方法包括面向对象分析、面向对象设计和面向对象实现。需求分析技术面向对象建模方法：一种用于辨识系统环境中的对象及这些对象之间关系的技术OMT （James Rumbaugh）Booch方法（Grady Booch） UMLOOSE （Ivar Jacobson）Coad-YourdonShlaer-MellorFusion当前的主流：UML需求分析技术3、形式化方法形式化开发方法：提供了规约环境的基础，使得所生成的模型比

18、用传统的或面向对象的方法生成的模型更完整、一致和无二义性。代表：适用于实时事务处理系统的有限状态机方法（FSM）适用于并发软件系统的Petri网方法3.4.1 结构化技术结构化需求分析方法（Structured Analysis ，SA）是一种面向数据流的自顶向下逐步求精的分析方法。结构化分析的基本步骤是：自顶向下对系统进行功能分解，画出分层数据流图，由后向前定义系统的数据和加工，编制数据字典，最终写出软件需求规格说明书。3.4.1 结构化技术过程建模数据流图Data Flow Diagram上下文图Context Diagram微规格说明Mini-Specification ：逻辑说明数据字

19、典Data Dictionary ：数据说明数据建模实体关系图Entity Relationship Diagram行为建模状态（转换）图/矩阵State （Transition） Diagram/Matrix过程/数据关系建模功能实体矩阵Function/Entity Matrix数据流图数据流图（Data Flow Diagram，DFD）表示法DeMarco-Yourdon表示法Gane-Sarson表示法DFD的基本元素外部实体过程数据流数据存储数据流图外部实体外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统，它们不受系统的控制，开发者不能以任何方式操纵它们 需要进行建模

20、的外部实体是那些和待构建的软件系统之间存在着数据交互的外部实体，它们是待构建系统的数据源或者数据目的地所有的外部实体联合起来构成了软件系统的外部上下文环境 数据流图过程过程是指施加于数据的动作或者行为，它们使得数据发生变化，包括被转换、被存储或者被分布可能是由软件系统控制的，也可能是由人工执行的，重在数据发生变化的效果而不是其执行者 可能会表现为不同的抽象层次 内容足够细节和具体，能够对其直接进行“编码”处理的过程被称为原始过程（Primitive Process，又称为基本过程Elementary Process） 数据流图数据流数据流是指数据的运动，它是系统与其环境之间或者系统内两个过程之

21、间的通信形式 数据流的分割和组合 数据字典和ERD通常被用来描述DFD数据流的详细内容 数据流图数据存储 数据存储是软件系统需要在内部收集、保存，以供日后使用的数据集合 数据存储的详细内容通常也是用数据字典和ERD来进行描述的数据流图示例： 食物订货系统 DeMarco-Yourdon表示法数据流图示例：食物订货系统 Gane-Sarson表示法数据流图规则过程是对数据的处理，必须有输入，也必须有输出，而且输入数据集和输出数据集应该存在差异。数据流图数据流是必须和过程产生关联的，它要么是过程的数据输入，要么是过程的数据输出。数据流图DFD当中所有的对象都应该有一个可以唯一标识自己的名称。过程使

22、用动词外部实体、数据流和数据存储使用名词数据流图层次结构依据所含过程的不同抽象程度，DFD可以在不同的抽象层次上进行系统的描述功能分解：一个比较抽象的过程可以被展开为一个子过程更加具体的DFD图DFD的层次类别上下文图（顶层图）0层图N层图（N0）数据流图上下文图（顶层图）将整个系统看做是一个过程，这个过程实现系统的所有功能 ，是系统功能的最高抽象 上下文图中存在且仅存在一个过程，表示整个系统。这个单一的过程通常编号为0 上下文图中需要表示出所有和系统交互的外部实体，并描述交互的数据流，包括系统输入和系统输出 上下文图中不会出现数据存储实例 非常适合于描述系统的应用环境、定义系统的边界 。可脱

23、离DFD单独使用。数据流图数据流图0层图位于上下文图下面一层，是上下文图中单一过程的细节描述，是对该单一过程的第一次功能分解 是整个系统的功能概图 0层图应该被描述的简洁、清晰，需求工程师要根据系统的复杂度掌握0层图中过程的抽象程度数据流图数据流图N层图对0层图的过程分解产生的子图称为1层图，对N层图的过程分解后产生的子图称为N+1层图（N0） ，过程分解是可以持续进行的，直至最终产生的子图都是原始DFD图（父过程子图）原始DFD图可以进一步展开为微规格说明数据字典在低于0层图的子图上通常不显示外部实体 子图中过程的编号要以父过程的编号为前缀：1.2、1.2.1数据流图数据流图创建上下文图在需

24、求获取阶段获得的业务需求以及业务需求所决定的项目前景与范围可以用来帮助建立系统的上下文图 数据流图产生0层图对DFD图（尤其是0层图）质量的判定有下面几个准则：没有语法错误，遵守如前所述的各项规则。具有良好的语义，过程的功能设置要高内聚、低耦合。保持数据一致性，过程的输入流要足以产生数据输出。同时过程的输出流是在充分利用输入数据的基础上产生的，不存在输入数据的浪费。控制复杂度，不要一次在图中显示太多的信息。一般情况下，一个图中的过程数量最好控制在59（人脑的最佳信息处理量）个。而且图中的数据流数量越少越好，越简洁越好（接口最小化）。数据流图功能分解产生N层图功能分解是一个拆分功能的描述，将单个

25、复杂的过程变为多个更加具体、更加精确和更加细节的过程 在功能分解过程当中，最重要的是要保证分解过程的平衡性（Balance） ，它要求DFD子图的输入流、输出流必须和父过程的输入流、输出流保持一致 数据流图在分解产生的子图为下述情景之一时，可以判定其为原始DFD图，此时应该停止持续的功能分解活动：所有过程都已经被简化为一个选择、计算或者数据库操作；所有数据存储都仅仅表示了一个单独的数据实体；用户已经不关心比子图更为细节的内容，或者子图的描述已经详细的足以支持后续的开发活动；每一个数据流都已经不需要进行更详细的切分，以展示对不同数据的不同处理方式；每一个业务表单、事务、计算机的屏幕显示和业务报表

26、都已经被表示为一个单独的数据流；系统的每一个最低层菜单选项都能在子图中找到独立的过程。 数据流图注意：DFD的画法和分解过程以ppt前面的例子为准，书上例子仅做参考。DFD：示例使用DFD描述电梯控制系统。一个控制系统控制多个电梯。每个电梯被置于一个相应甬道之中，在卷扬电机的作用下在甬道内做上下运动。甬道内安装有多个传感器，通常每个电梯停靠点一个，用来感应电梯的实时位置。电梯内部和建筑的每个电梯停靠层都设置有指示器，用来告知用户的电梯实时位置和运动状况。电梯内和建筑的每个电梯停靠层都设有按钮，用户可以通过这些按钮提出服务申请并进出电梯。控制系统调度用户的申请，让电梯以最有效的方式满足用户的服务

27、要求DFD：示例1. 建立上下文图DFD：示例DFD：示例2.建立DFD片段DFD：示例DFD：示例3.建立0层图DFD：示例DFD：示例4.功能分解建立N层图（略）实体关系模型实体关系模型（Entity-Relationship Modeling，ERM）没有标准的表示法 Peter Chen表示法James Martin表示法基本元素实体关系属性实体关系模型1、实体实例（Instance）需要在系统中收集和存储的现实世界事物 实体（Entity）具有相同特征和属性的实例集的类别描述 实体关系模型概念实体逻辑实体StudentStudentIDNameDOB实体关系模型2、属性属性实体的描述

28、特征以数字、代号、单词、短语、文本乃至声音和图像的形式存在一系列属性的存在集成起来就可以描述一个实体的实例 属性是实体的特征，不是数据。属性会以一定的形式存在，这种存在才是数据，被称为属性的值（Value） 实体关系模型属性的值就应该是一个合法的或者有业务含义的值，这个合法的取值范围称为域（Domain） 数据类型类型说明域例子Number整数最小最大月份的域：112Real实数最小最大考试得分：0.0100.0Text文本TEXT（属性的最大长度）电话号码：TEXT（20）Date日期最早最晚出生日期：1900-01-01今天Time时间最早最晚Boolean布尔Enumeration枚举值

29、1、值n性别：男、女、未知Binary二进制实体关系模型标识符，又称为键（Key） 可以被用来唯一的确定和标识每个实例的属性或者属性组合一个实体可能有多个键 ，都被称为候选键（Candidate Key） 人们通常会从多个候选键中选择和使用固定的某一个键来进行实例的标识，这个被选中的候选键被称为主键（Primary Key）没有被选做主键的候选键被称为替代键（Alternate Key） 实体关系模型属性的类型单值属性和多值属性：email 简单属性和组合属性 ：address存储属性和导出属性：age 实体关系模型3、关系关系存在于一个或多个实体之间的自然业务联系所有的关系隐含地都是双向的

30、关系表达的不是实体物理上的联系（例如车与车轮），而是逻辑上的链接（例如整体部分关系） 实体关系模型度数参与关系的实体数量 实体关系模型基数（约束）最大基数（键约束Key Constraint）对关系中任意的其他实体实例，该实体可能参与关系的最大数量 ：1或many最小基数（参与约束Participant Constraint）对关系中任意的其他实体实例，该实体可能参与关系的最小数量 ：0或1实体关系模型基数最大基数是关于一个对象可以与另一个对象的出现次数相关联的出现次数的规约。一对一（1：1）一对多（1：n）多对多（m：n）形态最小基数如果对关系的出现没有明显的需要或关系是可选的时，关系的形态是0如果关系必须出现一次，则形态是1实体关系模型实体关系模型子类型关系在多个实体大部分相似、少部分不同时，可以从相似的实体当中抽取共性，建立一个公共的超类型（Super-type），所有实体都是超类型的子类型 实体关系模型被关系影响的实体弱实体指存在和标识需要依赖于其他实体的实体 关联实体实体间建立关系时的副产品 实体关系模型ERD表示法：Peter Chen表示法实体关系模型ERD表示法：James Martin表示法实体关系模型示例实体关系模型简单情况下的ERD建模从描述信息中辨识实体 可以重点关注描述信息中的名词，看系统是否需要收集其相关的特征确定实体的标识