需求分析zhhfPPT课件

1、.,1,第三章（第四至六讲）,软件需求分析,.,2,一、软件需求分析概念 二、软件需求分析的任务和过程 三、需求的获取与描述 四、结构化分析方法 五、形式化分析技术,本章的主要内容,.,3,一、需求的相关概念,问题空间 人们利用认识现实 世界和描述现实 问题的方法描 述有关问题,解空间 人们利用计算机 能够接受的语言 和方法描述 有关问题,消除语义断层,.,4,系统责任与系统边界,系统责任指所开发的系统应该具备的职能。 目标系统与外部实体（与系统打交道的人或物）之间应具有明确的边界。,.,5,域,产品,平台,控制 计算机,行为者？,业务域,电梯,用户行为,客户,.,6,软件需求（Require

2、ments),需求是指用户或者客户对要开发的软件系统的要求。需求的内容在“问题定义”中得到最抽象的描述（可能是招标文件）。 需求是关于系统将要完成什么(what)工作的描述,必须经过所有涉众(stakeholder)的认可,其目的是彻底解决客户所期望解决的问题。,.,7,IEEE的需求定义,用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表达。 IEEE的软件工程标准术语表（1990）,.,8,Sommerville的需求定义,对应该实现什么功能的说明； 可以

3、是系统运行方式或系统特征与属性的描述； 可能是对系统开发过程的约束。 Sommerville，Sawyer（1997）,.,9,软件需求的类型,功能需求 系统可以完成的所有事情 涉及与本系统有接口的其他系统的所有事情 非功能需求 软件开发过程中必须遵守的约束（Constraint)。是对可以使用的资源和软件质量的各个方面的限制，往往会影响软件工程师做决策的自由度。 非功能需求应是可验证的（Verifiable)。,.,10,.,11,需求分析(Requirements Analysis),指开发人员为了准确地理解和表达用户要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再

4、由需求定义转换到相应的形式功能规约的过程。 Requirements analysis results in the specification of softwares operational characteristics；indicates softwares interface with other system elements; and establishes constraints that software must meet.,.,12,需求分析越来越难,问题域的复杂性越来越高。 交流障碍（涉众的文化背景不同；自然语言的多义性，一语双关等）。 完整性问题（用户对问题的陈述往往

5、是不完备的；用户意见不统一，需求之间可能存在着矛盾；涉及许多细节） 需求易变性（需求永远不会稳定，往往存在错误的需求）,.,13,应该足够重视需求分析,软件项目中40%60%的缺陷都是由需求分析阶段的过失所致（Daivs 1993，Leffingwell 1997） 对欧洲软件行业大量调查显示：确定和管理用户需求是问题最多的两个环节（ESPITI 1995） 许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当 信息收集方式不正规 没有明确提出想要的功能 常常存在未经沟通的错误假设 需求的定义不够充分 未经仔细考虑进行需求变更,.,14,有关软件错误和需求分析的一组事实,在软件生命

6、周期中，一个错误发现得越晚，修复的费用也越高。 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来。 在需求过程中会产生很多错误和误解，人与人之间的“通信”障碍无法避免。 需求阶段代表性的错误：疏忽、不一致、二义性 需求错误是可以被检查和审查出来的。,.,15,对项目需求状况作出快速评估（1）,项目前景（vision)和范围(scope)未曾明确定义 客户太忙，没时间与需求分析和开发人员一起讨论需求 用户代理（如开发经理、用户负责人、营销人员等）自诩可以代表用户，其实不能准确说出用户的要求 需求只存在于那些所谓专家的脑子里，没有被记录下来,.,16,对项目需求状况作出快速评估（2）,客

7、户坚持所有需求都很重要，不愿排出它们的优先次序 开发人员在编码过程中发现需求有歧义，缺少足够的信息，只能去猜测 开发人员与客户沟通时只关心用户界面，忽略了用户需要用软件做什么 客户签字确认了需求却又一直提出修改要求,.,17,对项目需求状况作出快速评估（3）,项目范围因接受需求变更而扩大，却没有相应地增加投入或剪裁功能，进度因而被延误 需求变更的请求被弄丢，开发人员和客户都不了解所有变更请求的状态 开发人员按照客户要求实现的功能无人问津 需求规格说明中的要求都实现了客户却不满意,.,18,领域分析（Domain Analysis),Domain Analysis,Sources of Doma

8、in Knowledge,Domain Analysis Model,Technical literature,Existing applications,Customer surveys,Expert advice,Current/future requirements,Class taxonomies,Reuse standards,Functional models,Domain languages,.,19,整个软件项目的涉众（stake holder）,客户（Customer） 用户（User） 需求分析员 开发人员 测试人员 项目经理：负责制定项目计划保证项目顺利进行 法律人员：确

9、保产品符合所有相关法规 市场营销、技术支持人员 与产品和客户打交道的其他人员,.,20,资金 需求,合同义务,软件系统,需求,客户 发起系统开发,用户 使用系统,开发者 建立系统,软件开发的主要涉众之间的关系,.,21,需求分析的涉众,合同监督人员，提出里程碑（Milestones）和约束系统开发进度的计划 需求者：客户(Customer)和使用者(User)。 开发者 项目管理者，必须理解建立和使用目标系统所可能产生的后果。 系统分析员，分析阶段活动的主体。 设计员，依据需求提出可接受的解决方案。 测试员，确保软件系统满足每一需求。,.,22,系统分析员应具有的素质,综合能力 总体规划，抽象

10、和分解，本质确认的能力 过程能力 保证整个过程的善始善终的能力 交流能力 理解和表达能力 技术水平 了解问题域和描述解空间的能力,.,23,二、软件需求分析的任务与过程,深入描述软件的功能和性能 确定软件设计的约束和软件同其它系统元素的接口细节 定义软件的其它有效性需求 研究用户要求,准确地表达被接受的用户要求 确定被开发软件系统的系统元素 将功能和信息结构分配到这些系统元素中,.,24,需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。,.,25,通常软件开发项目是要实现目标系统的物理模型 目标系统的具体物理模型是由它的逻辑模型经实例化，即

11、具体到某个业务领域而得到的,.,26,需求获取和分析的步骤,通过对现实环境研究，获得系统具体模型。 去掉具体模型的非本质因素，抽取出当前系统的逻辑模型 分析当前系统和目标系统的差别，建立目标系统的逻辑模型。 对目标系统进行完善和补充，写出完整的需求分析。,.,27,学生在学校教材科购买教材的系统的例子,一、通过对现实环境的研究，获得系统具体物理模型,购书 发票,购书单,书,购书 证明,购书申请,学生,学生,李 保管,孙 出纳,钱 会计,赵 秘书,.,28,学生在学校教材科购买教材的系统的例子,二、去掉具体模型的非本质因素，抽取出当前系统的逻辑模型,发票,购书单,书,有效单,购书单,学生,学生,

12、发书,开领书单,开发票,有效性,.,29,学生在学校教材科购买教材的系统的例子,三、分析当前系统和目标系统的差别，建立目标系统的逻辑模型。,发票,购书单,书,购书单,学生,学生,发书,开领书单,审查并开发票,.,30,学生在学校教材科购买教材的系统的例子,四、对目标系统进行完善和补充，写出完整的需求说明。 五、对需求说明进行复审，直到确认文档齐全并符合用户的全部需求为止。,无效书单,发票,购书单,购书单,学生,学生,开领书单,审查并开发票,.,31,需求规格说明书SRS,SRS（software requirements specification)： 引言：问题定义所确定的目标和范围 数据描

13、述：数据流图，数据字典等等 功能描述：功能要求文档（可形式化描述） 性能描述：性能要求文档 质量保证：描述交付前需要进行的各种测试和验 收标准 其它：运行要求、将来可能的要求,.,32,三、软件需求获取与分析技术,观察（Observation) 面谈(Interviewing) 头脑风暴(Brainstorming) 原型化(Paper prototype or Rapid prototype) 非正式用例分析(Informal use case analysis),.,33,需求阶段所要获取的主要内容,物理环境(Physical Environment) 接口( Interfaces) 用户

14、或人的因素(Factors) 功能(Functionality) 文档(Documentation) 数据(Data) 资源(Resources) 安全性(Security) 质量保证(Quality Assurance),.,34,设备的主要用途，在哪里发挥什么作用？ 所须设置的设备的多少？ 环境限制等，如温度、湿度或磁声干扰？,1） 物理环境描述(Physical Environment),.,35,来自一个或多个其他系统的输入？ 对一个或多个其它系统的输出？ 数据是否必须预先进行规定的格式化处理？ 数据是否需要预先存放的介质？,2） 接口描述（Interface Description）

15、,.,36,谁使用系统？ 有几种类型的用户？ 每种类型用户的技术水平怎样？ 对每型用户需要什么样的培训？ 用户理解、使用系统的难易度怎样？ 用户误用系统的困难程度怎样？,3） 用户和人为因素,.,37,系统将做什么？ 系统将在何时做？ 有几种操作方式？ 系统能在何时、怎样被改变或增强？ 对执行速度，响应时间或数据流量有何限制和约束？,4）功能描述（Function Description）,.,38,5） 文档（Documents）,需要多少文档？ 是联机文档还是静态文档或者二者皆可？ 文档所面向的对象（读者）？,.,39,6）数据（Data）,I/O数据格式应该是什么样的？ 数据收或发的频度

16、？ 数据的精确度 系统流经的数据流量？ 数据必须在何时予以保存，保存多久？,.,40,7） 资源描述（Resource Description）,建立和维护系统都要什么材料、人员或其他资源？ 开发者必须具有哪些技术？ 系统占用多少物理空间？ 对开发规定了时间表了？ 对用于开发或软硬件上的资金有限制？,.,41,对系统或信息的存取必须在我们的控制之下？ 不同用户的数据之间将如何实现隔离？ 不同用户程序之间，以及和操作系统间怎样隔离？ 系统如何备份？ 备份副本必须被存于一个不同的位置？ 应采取措施防火，防水防盗等安全措施？,8）安全描述(Security),.,42,系统必须有效检测并隔离故障？

17、平均无故障时间规定为多少？ 对一次失败后重启系统有一个最大时间？ 系统如何将变化合并到设计？ 维护仅仅是纠正错误，包括改进系统吗？ 对资源和响应时间使用什么样的有效度量？ 系统移植性、可维护性等要求？ 如何向别人示范系统的特征？,9）质量保证(Quality Assurance),.,43,结构化分析方法 Z 语言，RSL，RSML等（形式化的需求描述语言） 原型需求分析方法 面向对象方法（能够更好地消除“语义断层”）,软件需求分析方法学,.,44,How to Express Requirements,Static descriptions Dynamic descriptions Obje

18、ct-oriented specification Formal Methods,.,45,1） Static Descriptions,数据流图、数据字典、加工说明等（p31） 判定表（ Decision Tables ）（p63） 判定树 E-R模型（p52） 层次方框图、Warnier图、IPO图（p58）,.,46,Warnier Diagrams,Software products,System,Application,OS(n1) Compiler(n2) Software Tool,Editor(n3) Test driver(n4) CAD tool(n5),.,47,IPO

19、Diagrams,.,48,A New Form of IPO,IPO System: Modules: Date: NO.,Call:,Be Called:,Input:,Output:,Process:,Local data:,Annotation:,.,49,E-R模型（Entity-Relationship),概念模型（E-R图） 逻辑模型（二维表的定义） 物理模型（存储空间的定义，如定义各个字段的大小） 数据库的设计一般应经过由概念模型到逻辑模型，再到物理模型的映射过程。,.,50,数据结构的规范化,1970年，IBM的E.F.Godd提出关系模型，由二维表表示。 按照属性间的依赖程

20、度区分关系规范化的程度，由范式（Normal Form)来表示。 1NF：表中不能有表（每个信息项必须是一个不可分割的数据项） 2NF：非主属性由关键字唯一确定 3NF：任何非主属性间不存在函数依赖，即非主属性相互独立。,.,51,Decision Tables,.,52,2） Dynamic Descriptions,Functional Descriptions and Transition Diagrams （p55) Event Tables Petri Nets （p72),.,53,Functional Descriptions,State i,State k,Condition

21、j,.,54,Transition Diagrams,S i,S k,Event or Condition X,状态迁移图是描述系统的状态如何响应外部的信号进行推移的一种图形表示。 圆圈“”表示可得到的系统状态 箭头“”表示从一种状态向另一种状态的迁移。,.,55,Transition Diagrams Transition Table,S1,S2,S3,0,1,1,1,0,0,.,56,例如, 当有多个申请占用CPU运行的进程时, 有关CPU分配的进程的状态迁移。 t1 中断事件 t2 中断已处理 t3 分配CPU t4 用完CPU时间,.,57,可得到的状态就绪，运行，等待 生成的事件t1

22、，t2， t3， t4 t1 中断事件 t2 中断已处理 t3 分配CPU t4 用完CPU时间,.,58,状态迁移图的优点,状态之间的关系能够直观地捕捉到 由于状态迁移图的单纯性，能够机械地分析许多情况，可很容易地建立分析工具,.,59,Fence Diagram showing State Transitions,(Null),Requested,On waiting list,Confirmed,Used,Canceled,Archive,(Hotel reservations),.,60,Event Tables,.,61,UML notation for state transiti

23、on,S1,S2,condition,actions,.,62,Petri Nets,C. A. Petri (1962,German) . To represent a complexity system in graphical mode and describe synchronization an parallel processing f (State A, Event) State S f (State A, Event 1, Event 2, ,Event N) State S f (State A, Event 1, Event 2, ,Event N) State1, Sta

24、te2,State M,.,63,Petri网已广泛地应用于硬件与软件系统的开发中，它适用于描述与分析相互独立、协同操作的处理系统，也就是并发执行的处理系统。,Cont.,.,64,Petri网简称PNG (Petri Net Graph)，它有两种结点： 位置(place)：符号为“”，它用来表示系统的状态。 转移(transition)：符号为 “|”, 它用来表示系统中的事件。 图中的有向边表示对转移的输入，或由转移的输出,Cont.,.,65,标记，或称令牌(token)，是表明系统当前处于什么状态的标志,.,66,Firing Rules,.,67,应用示例一,.,68,.,69,处

25、理两个进程的同步问题,应用示例二,.,70,.,71,Object Class Method or Operation Encapsulation Inheritance hierarchy Multiple Inheritance Polymorphism,3）Object-oriented specification,.,72,4） Formal Methods,The Encyclopedia of Software Engineering defines formal methods in the following manner: A method is formal if it h

26、as a sound mathematical basis, typically given by a formal specification language. This basis provides a means of precisely defining notions like consistency and completeness, and more relevantly,specification, implementation and correctness. .,.,73,对需求说明书的要求,正确性 无二义性（需求确实是用户所需吗？） 完整性（完备性，包括用户需要的每一功

27、能或性能） 一致性（需求之间不能互相矛盾） 可检验性（非计算机人员可以理解） 可实现性（有效性，需求是能够现实的吗？硬件系统的支持力度怎样？） 可修改性 可跟踪性 注释,.,74,对需求规约的验证,验证的方法 复审和进一步需求分析 实现原型系统 支持需求分析工具 验证的主要内容 一致性验证 现实性验证（需求是现实的吗？） 完整性（完备性）和有效性验证,.,75,四、面向数据流的结构化分析方法,Yourdon E.和Constantine L.等人提出 是一种结构化分析（Structured Analysis）方法。 分析与描述工具 数据流图（Data flow Diagram） 数据字典(Da

28、ta Dictionary, or Data about Data) 结构化英语 判定表和判定树,.,76,数据流图中的主要图形元素,数据流图,.,77,描述银行取款过程的数据流图,.,78,数据流与数据加工之间的关系,.,79,数据流图的层次结构,为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统,.,80,数据流图的层次结构,.,81,在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据 底层流图是指其加工不需再做分解的

29、数据流图，它处在最底层 中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。,.,82,商店业务处理系统的顶层数据流图,.,83,是一种高层的系统逻辑模型 这个数据流图只有一个，它反映了目标系统要实现的功能 确定系统的边界：内部实体和外部实体,.,84,数据流图绘制步骤,首先确定系统的输入和输出 根据商店业务，画出顶层数据流图，以反映最主要业务处理流程 经过分析，商店业务处理的主要功能应当有销售、采购、会计三大项。主要数据流输入的源点和输出终点是顾客和供应商。 然后从输入端开始，根据商店业务工作流程，画出数据流流经的各加工框，逐步画到输出端，得到第一层数据流图,.,85,第

30、一层数据流图,.,86,加细每一个加工框 销售细化,.,87,采购细化,.,88,检查和修改数据流图的原则,数据流图上所有图形符号只限于前述四种基本图形元素 数据流图的主图必须包括前述四种基本元素，缺一不可 数据流图的主图上的数据流必须封闭在外部实体之间 每个加工至少有一个输入数据流和一个输出数据流 在数据流图中，需按层给加工框编号。编号表明该加工所处层次及上下层的亲子关系,.,89,检查和修改数据流图的原则(cont.),规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡 可以在数据流图中加入物质流，帮助用户理解数据流图 图上每个元

31、素都必须有名字 数据流图中不可夹带控制流 初画时可以忽略琐碎的细节，以集中精力于主要数据流,.,90,机票预定系统顶层图,旅行社,机票预定系统,旅客,取票单,订票单,取票单,机票,.,91,机票预定系统0层图,旅行社,预定机票 1,顾客取票 2,旅客,取票通知单,机票文件,订票单,机票,取票单,.,92,一个数据流图的例子,.,93,数据流图实例采购管理系统,P 32,.,94,数据词典,数据词典与数据流图配合，能清楚地表达数据处理的要求 词条描述 对于在数据流图中每一个被命名的图形元素，均加以定义，其内容有:名字，别名或编号，分类，描述，定义，位置，其它，等,.,95,（1）数据流词条描述,

32、数据流名： 说明：简要介绍作用即它产生的原因和结果 数据流来源：来自何方 数据流去向：去向何处 数据流组成：数据结构 数据量流通量：数据量，流通量,.,96,（2）数据元素词条描述,数据元素名： 类型：数字（离散值，连续值），文字（编码类型） 长度： 取值范围： 相关的数据元素及数据结构：,.,97,（3）数据文件词条描述,数据文件名： 简述：存放的是什么数据 输入数据： 输出数据： 数据文件组成：数据结构 存储方式：顺序，直接，关键码 存取频率：,.,98,（4）加工逻辑词条描述,加工名： 加工编号：反映该加工的层次 简要描述：加工逻辑及功能简述 输入数据流： 输出数据流： 加工逻辑：简述加

33、工程序，加工顺序,.,99,（5）源点及汇(终)点词条描述,名称：外部实体名 简要描述：什么外部实体 有关数据流： 数目：,.,100,数据结构的描述,符 号 含 义 举 例 被定义为 与 x = ab .,. 或 .|. 或 x = a,b，x = a|b . 或 m.n 重复 x = a， x = 3a8 (.) 可选 x = (a) “.” 基本数据元素 x = “a” . 连结符 x = 1.9,.,101,存折格式,.,102,存折户名所号帐号开户日性质（印密）1存取行50 户名2字母24 所号“001”.“999” 帐号“00000001”.“99999999” 开户日年月日 性质

34、“1”.“6” 注：“1”表示普通户，“5”表示工资户等 印密“0” 注：印密在存折上不显示 存取行日期（摘要）支出存入余额操作复核,.,103,基本加工逻辑说明,对数据流图的每一个基本加工，必须有一个基本加工逻辑说明 基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则 加工逻辑说明必须描述实现加工的策略而不是实现加工的细节 加工逻辑说明中包含的信息应是充足的，完备的，有用的，没有重复的多余信息,.,104,用于写加工逻辑说明的工具, 结构化英语 判定表 判定树,.,105,（1）结构化英语,结构化英语的词汇表由 英语命令动词 数据词典中定义的名字 有限的自定义词 逻辑

35、关系词 IF_THEN_ELSE、 CASE_OF 、 WHILE_DO、 REPEAT_UNTIL等组成。,.,106,是一种介于自然语言和形式化语言之间的语言 语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示 其基本控制结构有三种： 简单陈述句结构：避免复合语句； 重复结构：WHILE_DO 或 REPEAT_UNTIL结构。 判定结构：IF_THEN_ELSE 或 CASE_OF结构；,.,107,商店业务处理系统中“检查发货单”,IF 发货单金额超过$500 THEN IF 欠款超过了60天 THEN 在偿还欠款前不予批准 ELSE （欠款未超期） 发批准书，发货单

36、ENDIF ELSE （发货单金额未超过$500） IF 欠款超过60天 THEN 发批准书，发货单及赊欠报告 ELSE （欠款未超期） 发批准书，发货单 ENDIF ENDIF,.,108,（2）判定表,如果数据流图的加工需要依赖于多个逻辑条件的取值，使用判定表来描述比较合适,.,109,以“检查发货单”为例,.,110,.,111,（3）判定树,判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。,.,112,结构化分析方法小结,主要基于功能分解，仅是一个静态模型，没有反映处理的顺序，即控制流程。因此，不适合描述实时控制系统。 使用DFD分析与描述“数据要求”有局限，DFD应与数据库技术中的ER图结合。 DFD不适合人机界面系统的需求。 为精确描述软件需求，提高软件系统的可靠性、安全性，需用更形式化的描述方法。,.,113,五、形式化分析技术,非形式化与形式化方法的比较（p65） 应用形式化方法的准则 有穷状态机 Petri 网 Z语言,.,114,非形式化方法的缺点,矛盾（相互冲突的需求陈述） 二义性（存在不同方式理解的陈述） 含糊性（不确定性，不可验证性） 抽象层次混乱 ,.,115,形式化方法的优点,能够简洁准确地描述需求 各个阶段活动间的平滑过渡 提供了高层确认的手段（正确性证