1、软件工程,1,软件工程 第二章 需求分析,2.1 系统分析 2.2 软件需求分析 2.3 结构化分析方法 2.4 快速原型化方法 2.5 需求定义与评审,软件工程,2,2.1 系统分析,基于计算机的系统的系统元素包括硬件、软件、人、数据库、文档和过程。 系统分析的目标 识别用户要求 评价系统的可行性，进行经济和技术分析 把功能分配给硬件、软件、人、数据库和其它系统元素 建立成本和进度限制 生成系统规格说明,软件工程,3,识别用户要求,分析员必须考虑以下问题：识别希望的功能和性能范围; 确定系统的功能、性能、约束和接口;,功能和性能可靠性和质量总的系统目标成本与进度限制,制造需求市场与竞争情况有
2、效的技术将来可能的扩充,软件工程,4,可行性研究,可行性研究 从经济可行性、技术可行性、法律可行性和用户操作可行性等方面评价系统是否值得做，是否能做。 可行性研究的步骤1) 确定项目的规模和目标2) 研究当前正在运行的系统3) 建立新系统的高层逻辑模型4) 导出和评价各种方案,软件工程,5,推荐可行的方案 编写可行性研究报告成本估算 专家估算技术（Delphi技术） 成本估算模型（COCOMO） 效益估算 投资回收期 纯收入 投资回收率,经济可行性 成本效益分析,软件工程,6,技术可行性 技术风险分析,技术解决方案的实用性 使用的技术实用化程度 技术解决方案合理程度 技术资源的可用性 参与人员
3、的工作基础 基础硬件/软件的可用性 软件工具实用性,软件工程,7,法律可行性 侵权和责任问题,专利法 著作权法 软件保护条例用户类型：外行型熟练型专家型 操作习惯 使用单位的计算机使用情况 使用单位的规章制度,用户操作可行性,软件工程,8,2.2 软件需求分析,需求分析是一项软件工程活动，其目的是： 清楚地理解所要解决的问题，完整地获取用户要求； 刻划出软件的功能和性能； 指明软件与其他系统元素的接口； 建立软件必须满足的约束。,1. 软件需求分析的目的,软件工程,9,需求分析是一项软件工程活动，它包括： 需求获取 刻划出软件的功能和性能； 指明软件与其他系统元素的接口； 建立软件必须满足的约
4、束。 需求建模需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据、体系结构、接口和处理过程设计的模型。,2. 需求分析的任务,软件工程,10,需求规格说明需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。 需求评审 需求分析研究的对象是用户的要求。 必须全面理解用户的各项要求，准确表达被接受的用户要求。 只有经过确切描述的软件需求才能成为软件设计的基础。,软件工程,11,软件开发是要实现目标系统的物理模型。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统 “做什么” 的问题。,软件工程,12,3、需求获取,需求获取是在问题及其最终解决方案之间
5、架设桥梁的第一步。 需求获取的目的是清楚地理解所要解决的问题，完整地获得用户的需求。 获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。,软件工程,13,软件需求的层次,业务需求 反映了组织或客户对系统、产品高层次的目标要求，它们一般在项目视图和范围文档中给予说明。 用户需求 描述用户使用软件需要完成哪些任务，它们可通过使用实例图或脚本说明加以阐明。 功能非功能需求 定义了开发者必须实现的软件功能，而非功能需求如表所示:,软件工程,14,软件工程,15,需求获取过程,需求获取包括以下活动： 发现和分析问题
6、发现问题症结，并分析问题的原因/结果关系。 获取需求 根据对问题的理解定义需求。 使用调查研究方法收集信息； 遵循需求获取框架，按照三个成分观察：即数据、过程和接口。 需求归档 以草稿形式归档调查结果。形式有用例、决策表、需求表等。,软件工程,16,需求获取技术的基本特征,好的需求获取技术，对于规范需求获取活动，高效准确地获取需求定义，是十分重要的。 好的需求获取技术，应具有如下基本特征： 提供便于沟通的工具，如易于理解的语言和直观的图表； 提供定义系统边界（交互）的方法； 提供支持抽象的机制，如“分解”、“映射”等；,软件工程,17,鼓励分析员使用面向问题的术语思考问题，编写文档； 为分析员
7、提供多种可供选择的解决方案； 适应需求的变化。 适于以上特征的需求获取方法： 基于数据流图的结构化分析方法； 基于用例（use case）的建模方法。 需求获取技术的关键点在于： 深入浅出需求获取要尽可能全面、细致。,软件工程,18,获取的需求是个全集，系统真正实现的是个子集。分析时的调研内容并不都纳入到新系统中，目的在于以后的扩充。 以流程为主线在与用户交流的过程中，应该用流程将所有的内容串起来。如信息、组织结构、处理规则等。这样便于交流沟通。流程描述有宏观，也有微观。既要强调总体的业务流程、全生存周期的业务流程，又要对流程细化，有分支的业务流程。,软件工程,19,需求获取应遵循的原则,抽象
8、和分解是在人们认识世界和改造世界的长期实践中总结出来的行之有效的原则，在需求获取的过程中需遵循的三个原则： 分解：捕获问题空间的整体 部分关系。如问题子问题分解； 抽象：捕获问题空间的一般化 特殊化关系。如问题的不同变型； 投影：捕获问题空间的多维视图。即从不同角度考察。,软件工程,20,需求获取的步骤,软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。 下面9个步骤，针对信息系统的需求获取。 定义项目的视图和范围 包括组织结构图、各部门的岗位/角色列表。 确定用户类 包括人员/责任矩阵。 确定目标系统的业务工作流 包括物流、资金流、信息流，建立业务工作流模型。,软件工程
9、,21,运用需求获取技术开发反映主要业务规则的用例（或数据流图）并设置优先级。 收集来自用户的质量特性信息和其他非功能需求 将性能、安全性、可靠性等需求和其他设计约束结合业务规则，形成功能需求。 分类在用例（或数据流图）中涉及的数据 包括数据的组成和数据之间的关系。 详细拟订用例（或数据流图）的规格说明， 建立功能模型，并进行审查，用以澄清需求获取的参与者对需求的理解。,软件工程,22,开发并评估界面原型 设想输入设备、输出设备、显示风格、显示方式、输出格式等，建立接口规范和信息流传输规则。 从功能描述中开发概念测试用例 用测试用例来验证用例（或数据流图）、功能需求和原型。,软件工程,23,需
10、求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。表现在： 需求的不稳定性：在整个软件生存周期内软件需求会随着时间的推移发生变化； 需求的不准确性：用户和开发人员的认识会随着使用系统实现业务流程的实践逐步提高，一开始不可能设想得面面俱到。 需求获取只有通过有效的客户/开发者的合作才能成功。,软件工程,24,针对信息系统的需求调研方法,调研用户的组织结构、岗位设置、职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。 调研每个子系统的工作流程、功能与处理规则，收集原始信息资料，用数据流来表示物流、资金流、信息流三者的关系。 对调研内容事先准备，针对不同管理层
11、次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个需求的层次。,软件工程,25,对与用户沟通的情况及时总结归纳，整理调研结果，初步构成需求基线。若基线符合要求，则需求获取完成。 需求调研的主要手段： 发调查表； 召开调查会； 向用户领域的专家个别咨询； 实地考察， 跟踪现场业务流程； 查阅与待开发系统有关的资料； 使用各种调查工具等。,软件工程,26,需求整理与表达的方法,采用穷举方法可以避免遗漏。 采用归纳方法，通过对各种情况进行综合分类可以使问题条理化。 采用抽象方法，可以发现问题的实质，抓住问题的主要矛盾，忽略其次要矛盾。 需求整理可以多种手段
12、共用，如组织结构图、业务流程图、多叉树、关系矩阵、文字叙述、表格、图形等。需求描述包括组织结构与岗位定义、业务流程、处理规则、数据项、功能以及上述 5 个方面的关系。,软件工程,27,4. 需求建模,需求建模是为了分析需求，以确定项目的确切需求。 需求建模遵循三个原则：划分：描述需求的整体部分关系；抽象：描述需求的一般化特殊化关系；投影：描述需求的多维视图； 定义系统模型要区分逻辑模型和物理模型。 常用模型有数据建模、功能建模和过程建模。,软件工程,28,常用的分析方法,面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开发方法 (
13、DSSD) 面向对象的分析方法 (OOA) 等,软件工程,29,结构化分析方法最初只是着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。 扩充后，将建模技术扩展到数据建模、功能建模和行为建模，以实体-关系图、数据流图和控制流图、状态-迁移图为工具，数据字典为核心，从不同视点建立系统的分析模型。,2.3 结构化分析方法,软件工程,30,结构化分析的分析模型,实体 关系图,状态迁移图,数据流图,数据对象描述,加工规格说明,数据 字典,控制规格说明,软件工程,31,1. 数据建模,数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对
14、象间相互连接的关系。 在需求分析阶段描述数据对象和它们之间的关系，使用了E-R 图。 例如，在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程。因此，教学管理中涉及的对象有学生、教师和课程。,软件工程,32,教学数据模型,软件工程,33,实例的关联有三种：一对一 (1:1) ；一对多 (1:m) ；多对多 (n:m) 。 这种实例的关联称为“基数”，基数表明了“重复性”。,软件工程,34,软件工程,35,2. 功能建模和数据流,最初,结构化分析方法仅讨论数据流建模，目标系统被表示成如图所示的数据变换流程图。系统的功能体现在核心的数据变换中。,顶层数据流图（上下文环境
15、图）,软件工程,36,数据流图中的主要图形元素,软件工程,37,分层的数据流图,软件工程,38,实例考务处理系统的功能,(1) 对考生送来的报名单进行检查; (2) 对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站; (3) 对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者; (4) 制作考生通知单 (含成绩及合格/不合格标志) 送给考生; (5) 按地区进行成绩分类统计和试题难度分析，产生统计分析表。,软件工程,39,软件工程,40,根据考务处理业务，画出顶层数据流图，以反映最主要业务处理流程及系统与外界的关系。 经过分析，考务业务处理的主要功
16、能应当有登记报名单、统计成绩两个主要数据流。输入的源点和输出终点是考生、考试中心和阅卷站。 然后从输入端开始，根据考务业务工作流，画出数据流流经的各加工框，逐步画到输出端，得到第 0 层数据流图。,软件工程,41,软件工程,42,软件工程,43,软件工程,44,3. 行为建模,行为建模给出需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供这种建模的符号。 数据流图不描述时序关系，控制和事件流通过行为模型描述。 在描述系统或各个数据对象的行为时，采用状态迁移图。通过描述系统或对象的状态，以及引起系统或对象状态转换的事件来表示系统或对象的行为。,软件工程,45,状态迁移图,例如，有关
17、处理器分配的进程状态迁移。,软件工程,46,状态迁移图是描述系统的状态如何响应外部的事件进行推移的一种图形表示。 “”表示可得到的系统状态 “”表示从一种状态向另一种状态的迁移。,软件工程,47,Petri网,Petri网已广泛地应用于硬件与软件系统的开发中，它适用于描述相互独立、协同操作的处理系统，也就是并发执行的处理系统。 Petri网简称PNG (Petri Net Graph)，它有两种结点： 位置：符号“”，表示系统状态。 转移：符号 “|”, 表示系统中的事件。 有向边“”表示向转移的输入，或从转移的输出。,软件工程,48,标记，或称令牌 (token)，是表明系统当前处于什么状态
18、的标志。 Petri网可能的变化有：,软件工程,49,例如，处理两个进程PR1和PR2的同步问题（此时两个进程共用一个资源R）：,软件工程,50,软件工程,51,4. 数据字典,数据字典是结构化分析方法的核心，与各模型的图形表示配合，能清楚地表达数据处理的要求。 词条描述对于在模型中每一个被命名的图形元素，均加以定义，其内容有: 名字，别名或编号，分类，描述，定义，位置，其它，等,软件工程,52,（1）数据流词条描述 数据流名： 说明：简要介绍它产生的原因和结果 数据流来源：来自何方 数据流去向：去向何处 数据流组成：数据结构 数据量流通量：数据量，流通量 （2）数据元素词条描述 类型：数字(
19、离散值，连续值)，文字(编码类型)长度,软件工程,53,取值范围： 相关的数据元素及数据结构： （3）数据文件词条描述 数据文件名： 简述：存放的是什么数据 输入输出数据： 数据文件组成：数据结构 存储方式：顺序，直接，关键码 存取频率： （4）加工逻辑词条描述,软件工程,54,加工名： 加工编号：反映该加工的层次 简要描述：加工逻辑及功能简述 输入输出数据流： 加工逻辑：简述加工程序，加工顺序 （5）数据源及数据谭词条描述名称：外部实体名简要描述：什么外部实体有关数据流：数目：,软件工程,55,5. 数据结构的描述,符号 含义 举 例 被定义为 与 x = a+b .,.或 .|. 或 x
20、= a, b, x = a|b . 或 m.n 重复 x = a, x = 3a8 (.) 可选 x = (a) “.” 基本数据元素 x = “a“连结符 x = 19,软件工程,56,存折户名所号帐号开户日性质 (印密) 1 存取行50 户名 2 字母24 所号 001999 帐号 00000001 99999999 开户日年月日 性质“ 1 ”“ 6 ”注：“ 1 ”表示普通户，“ 5 ”表示工资户等 印密“ 0 ”注：印密在存折上不显示 存取行日期（摘要）支出存入余额操作复核,软件工程,57,6. 基本加工逻辑说明,对数据流图的每一个基本加工，必须有一个基本加工逻辑说明。 基本加工逻辑
21、说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则。 加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。 加工逻辑说明中包含的信息应是充足的，完备的，有用的，无冗余的。 描述加工逻辑说明的工具：结构化语言、决策表、决策树。,软件工程,58,(1) 结构化语言,结构化语言是一种伪码，它的词汇表由 命令动词 数据字典中定义的名字 有限的自定义词 逻辑关系词 IF_THEN_ELSE、SWITCH、WHILE_DO、FOR、DO_WHILE等组成。 它是一种介于自然语言和形式化语言之间的语言。用以消除在语法上的歧义性。,软件工程,59,语言的正文用基本控制结构进行分割，加工中的操作
22、用自然语言短语来表示。 其基本控制结构有三种： 简单陈述句结构：避免复合语句； 重复结构：while_do、for_do或do_while结构。 判定结构：if_then_else 或switch_do 结构； 用结构化语言描述的规格说明的正文可以在计算机上编辑，不必过多地考虑语言的在语法上的限制，使得分析员可以集中考虑加工的策略或规则。,软件工程,60,商店业务处理系统中“检查发货单”,if 发货单金额超过$500 thenif 欠款超过了60天 then在偿还欠款前不予批准else （欠款未超期）发批准书，发货单 else （发货单金额未超过$500）if 欠款超过60天 then发批准书
23、，发货单及赊欠报告else （欠款未超期）发批准书，发货单,软件工程,61,(2) 决策表,如果数据流图的加工需要依赖于多个逻辑条件的取值，使用决策表来描述比较合适。,规则,单个条件,单个动作,软件工程,62,以“检查发货单”为例,软件工程,63,(3) 判定树,判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。,软件工程,64,这是一种有效驾驭风险的技术。通过原型 可以增进软件者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求（主要是功能）明确化。 可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。 有的原型可以
24、直接成为产品，有的略加修改就可成为最终系统的一个组成部分。,2.4 快速原型化方法,软件工程,65,探索型：目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。 实验型：这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。 进化型：这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。,1. 原型分类,软件工程,66,2. 原型使用策略,软件原型支持需求工程的两项活动： 需求获取 需求有效性验证 其他用途： 用户培训 系统测试 原型开发主要分类： 进化式原型开发 抛弃式原型开发,软件工程,67,1）进化式
25、原型开发,基本思路是：先给出一个系统的最初实现，让用户去使用和评价，不断进行细化和改善，经过多次这样的反复过程后形成最终的完善的系统。,软件工程,68,2）抛弃式原型开发,基本思路是：原型的根本作用是弄清楚需求和为风险评估提供补充信息。通过评估后，原型被抛弃，重新规划和实施系统的开发。,软件工程,69,3. 原型开发技术,可执行规格说明 基于场景 (scenario) 的设计 自动程序设计 专用语言 可复用(reusable)的软件 简化假设,软件工程,70,1）可执行规格说明,可执行规格说明是用于需求规格说明的一种自动化技术。使用这种方法，人们可以直接观察他们用语言规定的任何系统性行为。包括
26、 代数规格说明 有限状态模型 可执行的数据流图,软件工程,71,代数规格说明,使用集合、定义于这些集合上的函数和定义于这些函数上的方程来描述对象。规格说明的操作语义用这些方程表示。 举例：定义一个无界的栈及其操作,NEW_STACK： Stack PUSH：Stack，Element Stack POP： Stack (Element | Undefined) POP( NEW_STACK ( ) ) Undefined POP( PUSH( Stack，elem) ) elem,软件工程,72,有限状态模型,parnas提出的使用最广泛的一种可执行规格说明形式。从一个初始状态开始接收输入，到
27、产生输出，状态在推移变化。施加在状态元素上的约束确定了有效状态的推移。 举例：建立用户程序对话,软件工程,73,可执行的数据流图,数据流图是基于结构化开发方法的结构化规格说明。 用一种可执行的语言程序代替定义处理逻辑的结构化英语，数据流图就成为由可执行语言程序模块组成的网络，在一定环境或工具的支持下就可成为一个可以执行的原型系统。,软件工程,74,2）基于场景的设计,场景是指用户界面的原型。 一个场景用以模拟在系统运行期间用户经历的事件。它提供了输入处理输出的屏幕格式和有关对话的模型。因此，软件开发人员能够给用户显示系统的逼真的视图，使用户得以判断是否符合他的意图。 分析员与用户的沟通往往通过
28、演示场景。 可在任一场景中使用一套可复用的软件模块，以表达某一方面的要求。,软件工程,75,可使用一种原型语言来描述原型系统。原型开发过程中用这种语言来定义 屏幕 数据项 相关的操作 从系统的外部描述开始，开发与数据库的接口 错误处理和恢复过程等系统的与外部视图一致的细节。,软件工程,76,3）自动程序设计,在程序自动生成环境的支持下，利用计算机实现软件的开发。 可以自动或半自动地把用户的非过程式问题规格说明转换为某种高级语言程序： 演绎综合手段： 基于数学推理的构造式证明。 程序变换手段： 将一程序转换成另一功能等价的程序，并保持其正确性不变。,软件工程,77,实例推广手段： 从实例特征出发
29、，将它推广为待编程序的特征，最后得到程序。 过程化手段： 研究甚高级语言的编译和知识的过程化。专用语言是应用领域的模型化语言。 在原型开发中使用专用语言，可方便用户和软件开发者在计划中的系统特性方面的交流。,4）专用语言,软件工程,78,5）软件复用技术,利用可复用的模块，做出适当的组合，就可得到快速构造的原型系统。 为了快速地构造原型，这些模块 必须有简单而清晰的界面； 应当尽量不依赖其它的模块或数据结构； 应具有一些通用的功能。,软件工程,79,6）简化假设,在开发过程中为使设计者迅速得到一个简化的系统，可以预设一些使得问题简化的假设。尽管这些假设可能实际上并不能成立，但它们在原型开发过程
30、中可以使开发者的注意力集中在一些主要的方面。,软件工程,80,2.5 需求定义与评审,又称需求规格说明或需求规约。 需求定义的主要目的是分析需求草稿和模型，解决其中存在的二义性和不一致性，系统地准确地表达系统需求，形成需求规格说明。包括系统应提供的功能和服务；非功能需求；系统开发或运行的限制条件；与系统互连的其他系统的信息。,软件工程,81,软件需求规格说明的基本原则： 功能与实现分离，描述要“做什么”而不是“怎样实现”。 要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。 如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。 规格说明必须包括系统运行
31、的环境。,1. 需求规格说明的原则,软件工程,82,系统规格说明必须是一个认识的模型，而不是设计或实现的模型。 规格说明必须是可操作的。 规格说明必须容许不完备性并允许扩充。 规格说明必须局部化和松散的耦合。当信息被修改时，只要修改某个单个的段落，能够很容易地加入和删去一些段落。,软件工程,83,2. 需求规格说明的内容,基于IEEE 830改写的规格说明模板内容： 引言 a.1 目的 a.2 文档约定 a.3 预期的读者和阅读建议 a.4 产品的范围 a.5 参考文献 综合描述b.1 产品的前景b.2 产品的功能,软件工程,84,b.3 用户类和特征 b.4 运行环境 b.5 设计和实现的限
32、制 b.6 假设和依赖 外部接口c.1 用户界面c.2 硬件接口c.3 软件接口c.4 通信接口 系统特性d.1 说明和优先级,软件工程,85,d.2 激励响应序列 d.3 功能需求 其他非功能需求e.1 性能需求e.2 基本设施需求e.3 安全性需求e.4 软件质量属性e.5 业务规则e.6 用户文档 其他需求 附录A：词汇表,软件工程,86,附录B: 软件需求分析模型 附录C: 待确定的问题又称需求验证。需求评审的目的是确保需求编写正确。审查的内容包括： 系统定义的目标是否与用户的要求一致； 需求分析阶段提供的文档资料是否齐全； 文档中的所有描述是否完整、清晰、准确反映用户要求；,3. 需求评审,软件工程,87,与所有其它系统成分的重要接口是否都已经描述； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 软件的行为和它必须处理的信息、必须完成的功能是否一致； 设计的限制条件是否符合实际； 是否考虑了开发的技术风险； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；,软件工程,88,4. 需求管理,需求管理就是管理需求变化的过程。 需求管理涉及需求变更如何被处理的策略、规程和过程。它规定了 应如何提交一个需求变更请求？ 如何分析需求变更对范围、进度和成本的影响？ 如何批准或驳回需求变更？ 如果批准了变更，改变更如何实现？,
