ch3 软件工程需求工程.ppt

1、需求工程(Requirement Engineering),outline,需求工程概述 需求获取 需求分析 需求规格说明书,2,outline,需求工程概述 需求获取 需求分析 需求规格说明书,3,需求定义,4,需求分析就是分析软件用户的需求是什么。,IEEE(美国电气电子工程师学会)软件工程标准词汇表（1997年）将需求定义为：（1）用户解决问题或达到目标所需的条件或能力。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。 需求就是以一种清晰、简洁、一致且无二义性的方式对一个待开发系统中各个有意义

2、陈述方面的一个集合。,需求概述,需求的重要性 软件开发的基础和前提 最终目标软件系统验收的标准 避免或者尽早剔除早期的错误 需求分析是软件生存期的一个重要阶段，是软件开发项目得以成功的基础。 其最根本的任务是确定为了满足用户的需要， “系统必须做什么？”的问题。,5,需求概述,需求分析的复杂性和面临的困难 片面, 不完全 模糊, 不准确 不一致, 歧义 需求复杂和庞大 因此必须使用系统的方法、借助于一系列行之有效的技术和工具进行软件需求分析,6,需求的重要性,Statistical material： In 1994, the Standish Group surveyed over 350

3、companies about their over 8000 software projects to find out how well they were faring. The results are sobering. 31% of the software projects were canceled before they were completed. Moreover, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and

4、 16% met those criteria in small companies (Standish 1994).,7,需求的重要性,To understand why, Standish (1995) asked the survey respondents to explain the causes of the failed projects. The top factors were reported to be 1. incomplete requirements (13.1%) 2. lack of user involvement (12.4%) 3. lack of res

5、ources (10.6%) 4. unrealistic expectations (9.9%) 5. lack of executive support (9.3%) 6. changing requirements and specifications (8.7%) 7. lack of planning (8.1%) 8. system no longer needed (7.5%),8,需求的重要性,Five Facts 1. 软件生命周期中，一个错误发现得越晚，修复错误的费用越高。,9,需求出错的高成本,“All together, the results show as much

6、 as a 200:1 cost ratio between finding errors in the requirements and maintenance stages of the software lifecycle.”,100,2.5,5,10,25,.5 - 1,Requirements Time,Design,Coding,Unit Test,Acceptance Test,Maintenance,Stage,The 1-10-100 Rule,10,需求的重要性,2. 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来。 3. 在需求过程中会产生很多错误。 DeMa

7、rco在一份研究报告中指出，被检查出来的错误的56产生的根源可以追溯到需求阶段。 AIRMICS所进行的一项调查发现，在一份美国军方大型管理信息系统的需求现格说明书(SRS)中存在着500多个错误，当然这仅仅是一个软件项目中的一次调查。,11,需求的重要性,4.在需求阶段，代表性的错误为疏忽、不一致和二义性。 美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究。他们对海军A7E飞机上的并行操作程序进行实地测试，以验证许多新设想的可行性。得出的研究数据表明：A7E项目中77的需求错误特点是不明确、疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是： 49不正确的事实

8、，31疏忽，l3不一致，5二义性。,12,需求的重要性,5. 需求错误是可以被检查出来的。,13,14,什么是需求工程,软件需求作为软件生存周期的第一个阶段，其重要性越来越突出，到20世纪80年代中期，逐步形成了软件工程的子领域需求工程。 需求工程：对系统应该提供的服务和所受到的约束进行理解、分析、建立文档、检验的过程,15,需求工程,需求开发,需求管理,需求开发,16,需求获取,需求分析,编写需求规格说明,需求确认,需求管理,17,需求跟踪,需求变更控制,版本管理,需求复用,需求层次,18,业务需求反映企业/组织对软件系统的高层次目标需求，也就是说是软件需求的建设目标。 系统建立的战略出发点

9、，表现为高层次的目标（Objective），它描述了组织为什么要开发系统 。 为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature） 参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision） 特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope）,业务需求,19,执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。 通常是在业务需求定义的基础上通过用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。用户需求是需求捕获的结果。 特性 模糊、不清晰 多特性混杂 多逻辑混

10、杂,用户需求,20,对所有的用户需求，都应该有充分的问题域知识作为背景支持。 用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。,用户需求,21,用户对软件系统行为的期望，一系列的行为联系在一起可以帮助用户完成任务，满足业务需求 。 软件需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么 将用户需求转化为软件需求的过程是一个复杂的过程 首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型； 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一

11、个系统行为即为一个系统需求。 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。,系统需求,22,软件需求可以分为： 功能需求 非功能需求 设计约束,软件需求的三种类型,23,功能需求描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。 传统的需求开发方法中，通常会以软件系统-子系统-模块-子模块的层次结构来组织。 现代需求理论更强调需求分析人员从用户的角度，将系统理解为一个黑盒子，从使用角度来整理需求，不管是RUP或者是XP 方法都是如此。,功能需求,24,非功能需求从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额

12、外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。 一般在软件开发过程中可以将非功能需求划分为：性能需求，质量属性，对外接口等。 性能需求：速度（Speed）、容量（Capacity）、吞吐量（Throughput）、负载（Load）、实时性（Time-Critical）。 系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量 。质量属性是为了度量质量要素而选用的特征 。 对外接口是系统和其他系统之间的软硬件接口 ，以及用户界面。,非功能需求,25,设计约束一般包括非技术因素决定的技术选型问题，以及预期的软硬件环境，预期的使用环境等。 设计约束非常重要，不要认为是可用可无的。 非

13、技术因素决定的技术选型：对于软件开发而言，有些技术不是由技术团队决定的，而是会受到企业/组织实际情况的影响。例如：必须采用具有自主知识产权的数据库系统，系统开发必须使用J2EE技术等。 Language、OS、SW to HW interface、Algorithm、Power、Timing、Memory、Processor utilization,设计约束,26,有一大学图书馆系统，该系统能够为学生和教工 提供查询和借阅图书和文献资料的服务。 因此本系统具备以下功能： 基本数据维护功能 基本业务功能 数据库管理功能 信息查询功能,例,27,（1）基本数据维护 提供使用者录入、修改并维护基本数

14、据的途径。基本数据包括读者的信息，可以对这些信息进行修改和更新。 （2）基本业务功能 读者借、还书籍的登记功能，随时根据读者借、还书籍的情况更新数据库系统，如果书籍已经借出，可以进行预留操作以及书籍的编目、入库、更新等操作。,1. 功能需求,28,（3）数据库管理功能 对所有图书信息及作者信息进行统一管理维护的功能，对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。 （4）信息查询功能 提供对各类信息的查询的功能，如对本图书馆的用户借书信息、还书信息、书籍源信息、预留信息等进行查询，对其他图书馆的书籍、资源源的查询。,29,（1）系统安全性需求 为保证系统安全性，对本图书馆的各项功能进

15、行分级、分权限操作。对其他图书馆的查询控制访问范围，如限ID、限用户等。 （2）对系统可用性的需求 为了方便使用者，要求对所有交互操作提供在线帮助功能。,2. 非功能需求,30,（3）对系统查询速度的要求 要求系统在20s 内响应查询服务的请求。 （4）对系统可靠性需求 要求系统失败发生率小于1%。,31,对“大学图书管理系统”提出一些与图书管理的业务相关的需求： 图书编目要求按照中国图书馆分类法进行； 由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。 第一条需求是遵循我国图书管理的规定，执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要，

16、描述了对一类文献资料有限制的使用和服务。,3. 领域需求,32,outline,需求工程概述 需求获取 需求分析 需求规格说明书,33,需求获取,软件需求分析总是从两方或多方之间的通信开始。用户面临的问题需要用基于计算机的方案来解决；开发者应该对用户的需求作出反应，给用户提供帮助。这样就产生了相互通信的需求。 需求获取的目的是从项目的战略规划开始建立最初的原始需求，需要研究系统将来的应用环境，确定系统的涉众，了解现有的情况，建立新系统的目标，获取为支持新系统目标而需要的业务过程细节和具体的用户需求。,34,Requirements Elicitation is difficult,用户和开发人

17、员的背景不同，立场不同 首先是知识理解的困难。 尽力去研究应用的背景，理解组织的状况，形成一个能够和用户进行有效沟通的粗略的知识框架 默认（Tacit）知识现象 利用有效的获取方法与技巧（角色扮演、观察等）来发现并获取默认知识,35,Requirements Elicitation is difficult,普通用户缺乏概括性、综合性的表述能力 普通用户的知识结构就相对局限于一些具体的业务细节 善于表达具体业务的细节问题 专家用户的知识结构因其渊博性而具有概括性和广泛性 能够回答概括性和综合性的问题 开发人员在与用户接触之前就先行确定获取的内容主题，然后设计具体的应用环境和场景条件，由用户根据

18、细节业务的执行来描述问题、表达期望。,36,Requirements Elicitation is difficult,缺乏用户参与 用户数量太多，选择困难 用户认识不足，不愿参与 用户情绪抵制，消极参与 没有明确的用户 对系统的用户以及用户的替代源等相关涉众进行分析,37,需求获取技术,38,获取信息的方法,传统方法 问卷调查、访谈、硬数据分析、文档检查、需求剥离等 集体获取方法 头脑风暴（Brainstorming）、专题讨论会（Workshop）等 快速建立软件原型 认知方法 任务分析（Task Analysis）、协议分析（Protocol Analysis）等 基于上下文的方法 观察

19、、民族志（Ethnography）和话语分析（Conversation Analysis）,39,访谈,1. 正式访谈 系统分析员将提出一些事先准备好的具体问题。 2. 非正式访谈 分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。 3. 调查表 经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。,40,4. 情景分析技术 对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。 情景分析技术的用处： 能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。 能保证用户在需求分析过程中始终扮演一个积极主

20、动的角色。让用户起积极主动的作用对需求分析工作获得成功是至关重要的。,41,快速建立软件原型,快速建立软件原型是最准确、最有效、最强大的需求分析技术。 快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。 构建原型的要点是，它应该实现用户看得见的功能，省略目标系统的“隐含”功能。,42,快速原型的特性： “快速”。快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型。因此，原型的某些缺陷是可以忽略的。 “容易修改”。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户需求。如果修改耗时过多，势必延误软件开发时间。,

21、43,outline,需求工程概述 需求获取 需求分析 需求规格说明书,44,Objectives of Software Analysis,45,需求分析的目的是保证需求的完整性和一致性。以需求获取阶段的原始需求和业务过程细节出发，将目标、功能和约束映射为软件行为，建立系统模型，然后在抽象后的系统模型中进行分析，标识并修复其中存在的不一致问题，发现并弥补遗漏的需求。,46,Tasks of Software Analysis,47,Software Model,A model is an abstract representation of a system that enables us

22、to answer questions about the system. When we represent it with real world language, its user model When we represent it with computing world language, its design model When we represent it with codes, its program model When we represent it with a neutral, formal language, its analysis model ,48,Dif

23、ferent means of “model” in SE,General knowledge Software model A view of general knowledge Viewpoint: design model, analysis model Content type: data model, function model A perspective language and its usage E-R model, UML model, DFD model Process model?,49,Software modeling,Software modeling is th

24、e process of developing abstract models of a system, with each model presenting a different view or perspective of that system. Software modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling La

25、nguage (UML). Software modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.,，,50,Entity-Relationship Diagram Composition( semantic data) model UML Object diagram Classification model Behavioral diagram OCL Use case diagram Proce

26、ss Model (DFD) Data processing model State Machine Model Stimulus/response model,Fact Model Entity-event model Object Role Model Organization model Petri Nets ,51,Notation, Technology, Method, Tool,Notation Graphic mapping of one or many technique models For example, UML Technology Modeling things u

27、sing notations For example, Object modeling Method Approach to solve problem of modeling, composite of many technologies For example, OOA Methodology A world view to do different work For example object-oriented methodology Tool Software system which support at least one notation or technology For e

28、xample, Rational Rose,52,Common analysis technologies and methods,Structure analysis DFD,ERD,ORM,STD Information engineering A special structure analysis method for information systems FDD, DD, BPM, besides above Object-Oriented analysis UML,53,Method Based Analysis (In historical order, we have ) N

29、one Method “Traditional” analysis (1950s) Structured Method Classical Structured Analysis (late 1960s) “Modern” Structured Analysis (late 1970s) Information Engineering (late 1980s) OO Method Object Oriented Analysis (1990s),Approaches to analysis,54,DFD,1960s,“Classical” Structured Analysis,“Modern

30、” Structured Analysis,ERD,Data separated,Event separated,FSM,STD,Information Engineering,Adjust for IE,FDD, DD,late of 1970s,1980s,BPM,BPR,1990s,ELH,OO,UML,ORM,PN,Rules separated,Workflow,Now,FM,Enterprise Model,Future,Ontology?,OOA,Goal Model,Domain Model,55,Technique Models VS Analysis Technologie

31、s,Entity-relationship model,Object model,Process model,State machine model,Others,ERD,UML,DFD,FDD,DD,FSM,SC,STD,Decision Table( tree), Structured English,Action diagram, Data dictionary,Grasp,Grasp,Know,Understand,Grasp,Understand,Understand,Know,None: Goal Model, Enterprise Model, Domain Model,56,结

32、构化建模思想,怎么理解复杂世界？ 复杂简单（分解） 简单可理解性（最基本单位） 简单（高内聚） 简单 VS 简单（低耦合） 简单复杂（接口和实现） 结构化建模 复杂世界复杂处理过程（事情的发生发展） 简单过程（可表达的“函数”） 软件“函数”、程序 复杂简单 功能分解结构 简单复杂（函数调用）,57,结构化分析,结构化分析（Structured Analysis, SA）是一种确定模型的活动。 SA用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层功能分解的系统分析方法来定义系统的需求。,58,Structured Analysis (SA),Context Diagrams,D

33、ata Flow Diagrams,Data Dictionaries Entity-Relation Diagram,Module Hierarchy (FDD, PDD/DD) Mini-Specification,Structured Analysis (SA),59,分析模型的结构,SA应该建立3种模型，分别是： 数据模型 功能模型 行为模型,60,数据建模,数据模型包含三种相互关联的信息：数据对象、描述数据对象的属性及数据对象彼此间相互连接的关系。 最常用的表示概念性数据模型的方法，是实体联系方法（Entity-Relationship Approach） ER图描述现实世界中的实体

34、，而不涉及这些实体在系统中的实现方法。,61,E-R图元素,62,实体是客观世界中存在的且可相互区分的事务。实体可以是人也可以是物，可以是具体的事物也可以是抽象概念。例如，职工、学生、课程、教师等都是实体。,E-R图元素,属性是实体或联系所具有的性质，通常一个实体由若干个属性来刻画。应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。 例如，“学生”实体有学号、姓名、性别、系、年级,63,E-R图元素,实体彼此之间相互连接的方式称为关系，也称为联系。 (1) 一对一联系(11)，(2) 一对多联系(1N) (3) 多对多联系(MN) 例如，教师与课程间存在“教”这种联系。,64

35、,某校教学管理系统的E-R图,65,例：银行储蓄系统的ER图 银行计算机储蓄系统的工作过程大致如下： 储户填写的存款单或取款单由业务员键入系统，如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息，并印出存单给储户； 如果是取款而且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并印出利息清单给储户。,66,银行储蓄系统的ER图,67,变换,输入信息,输出信息,外部实体,外部实体,外部实体,输入信息,外部实体,外部实体,输出信息,输出信息,数据存储,系统逻辑模型,功能建模（DFD）,68,DFD

36、,数据流图说明(Yourdon表示)： 表示外部实体，代表数据源和数据目的地 表示加工，代表接收输入，经过变换，继而产生输出的处理过程。 表示数据流，代表数据的流向和路径。 表示数据存储，代表系统加工的数据所存储的地方。,69,人事工资管理系统,70,系统逻辑模型,人事工资管理系统1层DFD图,71,人事工资管理系统2层DFD:功能3分解图,72,分层数据流图,73,在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据 底层流图是指其加工不需再做分解的数据流图，它处在最底层 中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。,74,数据字典,DD是对所有与系统相关的数据元素的一个有组织的列表，以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解。 数据字