软件工程课件：第2章 需求分析

1、第2章 软件需求分析,项目失败的原因,“构建一个软件系统最困难的部分是确定构建什么。其他部分工作不会像这部分工作一样，在出错之后会如此严重地影响随后实现的系统，并且在以后修补竟会如此的困难。”Fred Brooks 项目失败的原因（Standish1994调查8000项目） 1、不完整的需求（13.1%）2、缺少用户参与（12.4 % ） 3、缺少资源（10.6%） 4、不切实际的期望（9.9%） 5、缺乏行政支持（9.3%） 6、改变需求规格说明（8.7%） 7、缺乏计划（8.1%） 8、不再需要该系统（7.5%）,2,软件项目失败的原因,3,需求错误的成本,4,2.1 软件需求分析,1.

2、软件需求分析的目的 需求分析是一项软件工程活动，其目的是： 清楚地理解所要解决的问题，完整地获取用户要求； 刻划出软件的功能和性能； 指明软件与其他系统元素的接口； 建立软件必须满足的约束。,5,2. 需求分析的任务,需求分析是一项软件工程活动，它包括： 1)需求获取 刻划出软件的功能和性能； 指明软件与其他系统元素的接口； 建立软件必须满足的约束。 2)需求建模 需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据、体系结构、接口和处理过程设计的模型。,6,需求规格说明 需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。 需求评审 需求分析研究的对象是用户的要求。 必须全

3、面理解用户的各项要求，准确表达被接受的用户要求。 只有经过确切描述的软件需求才能成为软件设计的基础。,7,软件开发是要实现目标系统的物理模型。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统 “做什么” 的问题。,8,2、需求获取,需求获取是在问题及其最终解决方案之间架设桥梁的第一步。 需求获取的目的是清楚地理解所要解决的问题，完整地获得用户的需求。 获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。,9,软件需求的层次,业务需求 反映了组织或客户对系统、产品高层次的目标要求，

4、它们一般在项目视图和范围文档中给予说明。 用户需求 描述用户使用软件需要完成哪些任务，它们可通过使用实例图或脚本说明加以阐明。 功能非功能需求 定义了开发者必须实现的软件功能，而非功能需求如表所示:,10,不同层次的软件需求,11,案例：小型图书资料管理系统,问题描述 某学院打算开发一个小型图书资料管理系统MiniLibrary，该系统实现教师和学生通过网络对各种图书资料的借阅、查询和管理。 图书管理员负责管理各种图书资料，查询图书资料信息，并进行图书的借阅管理。 注册用户可以随时通过网络查询图书资料信息和个人借阅情况，预订目前借不到的图书资料，并可以快捷地查找和浏览所需要的电子资料。 要求用

5、户界面友好，响应速度快，具有良好的可扩展性。,12,业务需求,业务需求是组织或客户对于系统的高层次目标要求，定义了项目的远景和范围，即确定软件产品的发展方向、功能范围、目标客户和价值来源。 业务需求的内容 业务：产品属于哪类业务范畴？应该完成什么功能？需要为什么服务？ 客户：产品为谁服务？目标客户是谁？ 特性：产品区别于其他竞争产品的特性是什么？ 价值：产品的价值体现在什么方面？ 优先级：产品功能特性的优先级次序是什么？,13,业务需求：MiniLibrary,业务要求 各种图书资料的借阅、查询和管理； 使用计算机实现图书资料的日常管理，提高工作效率和服务质量； 用户通过网络查询和浏览电子资料

6、，改变原有的借阅模式； 由于版权的限制，某些电子资料只能让用户浏览和打印而不能下载。 客户与用户 图书管理员 借阅者：教师、学生,14,14,用户需求,用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。 用户需求的描述 原则：应该易于用户的理解。一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式进行描述。 问题：自然语言表达容易含糊和不准确。,15,用户需求：MiniLibrary,举例： 用户通过网络随时查询图书信息和个人借阅情况，并可以快捷地查找和浏览所需要的电子资料。 分析：上述需求描述包含了三个不同的需求 用户通过网络

7、随时查询图书信息。 用户通过网络随时查询个人借阅情况。 用户可以通过网络快捷地查找和浏览所需要的电子资料。 问题： “随时”和“快捷”是对系统功能的约束，十分模糊。,16,16,功能需求,功能需求 描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。 举例：MiniLibrary 用户可以从图书资料库中查询或者选择其中的一个子集。 系统可以提供适当的浏览器供用户阅读电子文献。 用户每次借阅图书应该对应一个唯一的标识号，它被记录到用户的帐户上。,17,17,非功能需求,非功能需求 从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求

8、，例如响应时间、数据精度、可靠性、开发过程的标准等。 举例：MiniLibrary 系统应在20 秒之内响应所有的请求。 系统每周7 天、每天24 小时都可以使用。 对于一个没有经验的用户而言，经过两个小时的培训就可以使用系统的所有功能。,18,非功能需求,19,非功能需求,20,需求的来源,客户或用户 学院的高层管理者、项目投资人 系统管理员 教师、学生、图书管理员 标准 图书资料的标准 政策或法律 图书资料管理规程、知识产权和版权保护等 系统或过程文档 当前手工管理的文件、表格、记录等 相关领域的专家,21,需求获取过程,需求获取包括以下活动： 发现和分析问题 发现问题症结，并分析问题的原

9、因/结果关系。 获取需求 根据对问题的理解定义需求。 使用调查研究方法收集信息； 遵循需求获取框架，按照三个成分观察：即数据、过程和接口。 需求归档 以草稿形式归档调查结果。形式有用例、决策表、需求表等。,22,需求获取技术的基本特征,好的需求获取技术，对于规范需求获取活动，高效准确地获取需求定义，是十分重要的。 好的需求获取技术，应具有如下基本特征： 提供便于沟通的工具，如易于理解的语言和直观的图表； 提供定义系统边界（交互）的方法； 提供支持抽象的机制，如“分解”、“映射”等；,23,鼓励分析员使用面向问题的术语思考问题，编写文档； 为分析员提供多种可供选择的解决方案； 适应需求的变化。

10、适于以上特征的需求获取方法： 基于数据流图的结构化分析方法； 基于用例（use case）的建模方法。 需求获取技术的关键点在于： 深入浅出 需求获取要尽可能全面、细致。,24,获取的需求是个全集，系统真正实现的是个子集。分析时的调研内容并不都纳入到新系统中，目的在于以后的扩充。 以流程为主线 在与用户交流的过程中，应该用流程将所有的内容串起来。如信息、组织结构、处理规则等。这样便于交流沟通。 流程描述有宏观，也有微观。既要强调总体的业务流程、全生存周期的业务流程，又要对流程细化，有分支的业务流程。,25,需求获取应遵循的原则,抽象和分解是在人们认识世界和改造世界的长期实践中总结出来的行之有效

11、的原则，在需求获取的过程中需遵循的三个原则： 分解：捕获问题空间的整体 部分关系。如问题子问题分解； 抽象：捕获问题空间的一般化 特殊化关系。如问题的不同变型； 投影：捕获问题空间的多维视图。即从不同角度考察。,26,需求获取的步骤,软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。 下面9个步骤，针对信息系统的需求获取。 定义项目的视图和范围 包括组织结构图、各部门的岗位/角色列表。 确定用户类 包括人员/责任矩阵。 确定目标系统的业务工作流 包括物流、资金流、信息流，建立业务工作流模型。,软件工程,27,运用需求获取技术开发反映主要业务规则的用例（或数据流图）并设置优

12、先级。 收集来自用户的质量特性信息和其他非功能需求 将性能、安全性、可靠性等需求和其他设计约束结合业务规则，形成功能需求。 分类在用例（或数据流图）中涉及的数据包括数据的组成和数据之间的关系。 详细拟订用例（或数据流图）的规格说明，建立功能模型，并进行审查，用以澄清需求获取的参与者对需求的理解。,28,开发并评估界面原型 设想输入设备、输出设备、显示风格、显示方式、输出格式等，建立接口规范和信息流传输规则。 从功能描述中开发概念测试用例 用测试用例来验证用例（或数据流图）、功能需求和原型。,29,需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。表现在： 需求的不稳定性：在整

13、个软件生存周期内软件需求会随着时间的推移发生变化； 需求的不准确性：用户和开发人员的认识会随着使用系统实现业务流程的实践逐步提高，一开始不可能设想得面面俱到。 需求获取只有通过有效的客户/开发者的合作才能成功。,30,针对信息系统的需求调研方法,调研用户的组织结构、岗位设置、职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。 调研每个子系统的工作流程、功能与处理规则，收集原始信息资料，用数据流来表示物流、资金流、信息流三者的关系。 对调研内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个需求的层次。

14、,31,对与用户沟通的情况及时总结归纳，整理调研结果，初步构成需求基线。若基线符合要求，则需求获取完成。 需求调研的主要手段： 发调查表； 召开调查会； 向用户领域的专家个别咨询； 实地考察， 跟踪现场业务流程； 查阅与待开发系统有关的资料； 使用各种调查工具等。,32,需求整理与表达的方法,采用穷举方法可以避免遗漏。 采用归纳方法，通过对各种情况进行综合分类可以使问题条理化。 采用抽象方法，可以发现问题的实质，抓住问题的主要矛盾，忽略其次要矛盾。 需求整理可以多种手段共用，如组织结构图、业务流程图、多叉树、关系矩阵、文字叙述、表格、图形等。需求描述包括组织结构与岗位定义、业务流程、处理规则、

15、数据项、功能以及上述 5 个方面的关系。,33,4. 需求建模,需求建模是为了分析需求，以确定项目的确切需求。 需求建模遵循三个原则： 划分：描述需求的整体部分关系； 抽象：描述需求的一般化特殊化关系； 投影：描述需求的多维视图； 定义系统模型要区分逻辑模型和物理模型。 常用模型有数据建模、功能建模和过程建模。,34,2.2 结构化分析方法,结构化分析方法最初只是着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。 扩充后，将建模技术扩展到数据建模、功能建模和行为建模，以实体-关系图、数据流图和控制流图、状态-迁移图为工具，数据字典为核心，

16、从不同视点建立系统的分析模型。,35,结构化分析的分析模型,36,实体 关系图,状态迁移图,数据流图,数据对象描述,加工规格说明,数据 字典,控制规格说明,1. 功能建模和数据流,最初,结构化分析方法仅讨论数据流建模，目标系统被表示成如图所示的数据变换流程图。系统的功能体现在核心的数据变换中。,37,顶层数据流图（上下文环境图）,数据流图中的主要图形元素,Data Flow Diagram (DFD)教材P44图3-4,38,多个数据流之间的关系,教材P44图3-5,39,40,分层的数据流图,实例考务处理系统的功能,(1) 对考生送来的报名单进行检查; (2) 对合格的报名单编好准考证号后将

17、准考证送给考生，并将汇总后的考生名单送给阅卷站; (3) 对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者; (4) 制作考生通知单 (含成绩及合格/不合格标志) 送给考生; (5) 按地区进行成绩分类统计和试题难度分析，产生统计分析表给考试中心。,41,42,根据考务处理业务，画出顶层数据流图，以反映最主要业务处理流程及系统与外界的关系。 经过分析，考务业务处理的主要功能应当有登记报名单、统计成绩两个主要数据流。输入的源点和输出终点是考生、考试中心和阅卷站。 然后从输入端开始，根据考务业务工作流，画出数据流流经的各加工框，逐步画到输出端，得到第 0 层数据流图。,43,4

18、4,软件工程,45,46,2. 数据建模,数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。 在需求分析阶段描述数据对象和它们之间的关系，使用了E-R 图。 例如，在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程。因此，教学管理中涉及的对象有学生、教师和课程。,47,数据对象,数据对象是目标系统所需要的复合信息的表示，所谓复合信息是具有若干不同属性的信息。在ER图中用矩形表示数据对象。 在实际问题中，数据对象（实体）可以是外部实体、事物、角色、行为或事件、组织单位、地点或结构等。,48,属性,属性定义数据对象的特征，如数据对象学生

19、的学号、姓名、性别、专业等，课程的课程编号、课程名称、学分等。 在ER图中用椭圆或圆角矩形表示属性，并用无向边将属性与相关的数据对象连接在一起。,49,关系,不同数据对象的实例之间是有关联关系的，在ER图上用无向边表示。 在无向边的两端应标识出关联实例的数量，也称为关联的重数。 从关联重数的角度可以将关联分为种。 (1) 一对一（1:1）关联 (2) 一对多（1:m）关联 (3) 多对多（m:n）关联 实例关联还有“必须”和“可选”之分。,关联数量的表示,在ER图中用圆圈表示所关联的实例是可选的，隐含表示“0”，没有出现圆圈就意味着是必须的。出现在连线上的短竖线可以看成是“1”。,52,关联关

20、系举例,53,关系的属性,关系本身也可能有属性，这在多对多的关系中尤其常见，如学生和课程之间的关系可起名为“选课”，其属性应该有学期、成绩等。 关系属性的表示：在表示关系的无向边上再加一个菱形框，并在菱形框中标明关系的名字，关系的属性同样用椭圆形或圆角矩形表示，并用无向边将关系与其属性连接起来。,55,教学数据模型,3. 行为建模,行为建模给出需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供这种建模的符号。 数据流图不描述时序关系，控制和事件流通过行为模型描述。 在描述系统或各个数据对象的行为时，采用状态迁移图。通过描述系统或对象的状态，以及引起系统或对象状态转换的事件来表示系

21、统或对象的行为。,56,状态转换图,状态转换图（简称状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图中使用的主要符号如图所示。,57,状态,状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式，状态规定了系统对事件的响应方式。 状态可能有：初态（初始状态）、终态（最终状态）和中间态。 在一张状态图中只能有一个初态，而终态则可以有多个，也可以没有。,58,状态的表示：初态用实心圆表示，终态用牛眼图形表示，中间态用圆角矩形表示。,59,状态转换,状态图中两个状态之间带箭头的连线称为状态转换。 状态的变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭

22、头线上标出触发转换的事件表达式。 如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。,60,状态转换 下图为计算机应用软件的启动过程，在这个过程中没有外部事件触发，每个状态下的活动完成时，状态发生转换。,61,事件,事件是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外部事件的抽象。事件表达式的语法如下： 事件说明（守卫条件）/动作表达式 (1) 事件说明的语法如下： 事件名（参数表） (2) 守卫条件是一个布尔表达式。如果同时使用守卫条件和事件说明，则当且仅当事件发生且布尔表达式成立时，状态转换才发生。如果只有守卫条件没有事件说明，则只要

23、守卫条件为真，状态转换就发生。 (3) 动作表达式是一个过程表达式，当状态转换开始时执行该表达式。,62,存款过程的状态图(考虑新开户 ),63,取款过程的状态图,64,4. 数据字典,数据字典是结构化分析方法的核心，与各模型的图形表示配合，能清楚地表达数据处理的要求。 词条描述对于在模型中每一个被命名的图形元素，均加以定义，其内容有: 名字，别名或编号，分类，描述，定义，位置，其它，等,65,（1）数据流词条描述 数据流名： 说明：简要介绍它产生的原因和结果 数据流来源：来自何方 数据流去向：去向何处 数据流组成：数据结构 数据量流通量：数据量，流通量 （2）数据元素词条描述 类型：数字(离

24、散值，连续值)，文字(编码类型)长度,66,取值范围： 相关的数据元素及数据结构： （3）数据文件词条描述 数据文件名： 简述：存放的是什么数据 输入输出数据： 数据文件组成：数据结构 存储方式：顺序，直接，关键码 存取频率： （4）加工逻辑词条描述,67,加工名： 加工编号：反映该加工的层次 简要描述：加工逻辑及功能简述 输入输出数据流： 加工逻辑：简述加工程序，加工顺序 （5）数据源及数据汇点词条描述 名称：外部实体名 简要描述：什么外部实体 有关数据流： 数目：,68,5. 数据结构的描述,69,符号 含义 举 例 被定义为 与 x = a+b .,.或 .|. 或 x = a, b,

25、x = a|b . 或 m.n 重复 x = a, x = 3a8 (.) 可选 x = (a) “.” 基本数据元素 x = a . 连结符 x = 1.9,定义式举例：存折,存折的定义格式（1）,存折户名所号帐号开户日性质 (印密) 1 存取行50 户名 2 字母24 所号 001.999 帐号 00000001. 99999999 开户日年月日 性质“ 1 ”.“ 6 ”注：“ 1 ”表示普通户，“ 5 ”表示工资户等 印密“ 0 ”注：印密在存折上不显示 存取行日期（摘要）支出存入余额操作复核,71,摘要1字母4 支出金额 存入金额 余额金额 金额“0000000.01”.“99999

26、99.99” 操作“00001”.“99999” 复核“00001”.“99999” 字母“a”.“z”|“A”.“Z”,存折的定义格式（2）,6. 基本加工逻辑说明,对数据流图的每一个基本加工，必须有一个基本加工逻辑说明。 基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则。 加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。 加工逻辑说明中包含的信息应是充足的，完备的，有用的，无冗余的。 描述加工逻辑说明的工具：结构化语言、决策表、决策树。,软件工程,73,(1) 结构化语言,结构化语言是一种伪码，它的词汇表由 命令动词 数据字典中定义的名字 有限的自定义词

27、逻辑关系词 IF_THEN_ELSE、SWITCH、WHILE_DO、FOR、DO_WHILE等组成。 它是一种介于自然语言和形式化语言之间的语言。用以消除在语法上的歧义性。,74,语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示。 其基本控制结构有三种： 简单陈述句结构：避免复合语句； 重复结构：while_do、for_do或do_while结构。 判定结构：if_then_else 或switch_do 结构； 用结构化语言描述的规格说明的正文可以在计算机上编辑，不必过多地考虑语言的在语法上的限制，使得分析员可以集中考虑加工的策略或规则。,75,76,商店业务处理系统中

28、“检查发货单”,if 发货单金额超过$500 then if 欠款超过了60天 then 在偿还欠款前不予批准 else （欠款未超期） 发批准书，发货单 else （发货单金额未超过$500） if 欠款超过60天 then 发批准书，发货单及赊欠报告 else （欠款未超期） 发批准书，发货单,(2) 决策表,如果数据流图的加工需要依赖于多个逻辑条件的取值，使用决策表来描述比较合适。,77,规则,单个条件,单个动作,78,以“检查发货单”为例,(3) 判定树,判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。,79,2.4 需求定义与评审,又称需求规格说明或需求规约。 需求定义的主要目的是分析需求草稿和模型，解决其中存在的二义性和不一致性，系统地准确地表达系统需求，形成需求规格说明。包括 系统应提供的功能和服务； 非功能需求； 系统开发或运行的限制条件； 与系统互连的其他系统的信息。,80,1. 需求规格说明的原则,软件需求规格说明的基本原则： 功能与实现分离，描述要“做什么”而不是“怎样实现”。 要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。 如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。 规格说明必须包括系