资源描述
2020/7/14,1,第6讲 需求分析,2020/7/14,2,内容,需求分析的重要性 需求分析的困难性 需求工程 需求分析过程 概念模型和规范化 图形工具 需求验证 原型技术,2020/7/14,3,需求分析,需求分析是软件定义时期的最后一个阶段 回答“系统必须做什么？”的问题,2020/7/14,4,需求分析的重要性,真的很重要吗？ 例：Our real-time example is based on the embedded software in the Ariane-5, a space rocket belonging to the European Space Agency (ESA). On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then, it began to veer off course. At the direction of an Ariane ground controller, the rocket was destroyed by remote control. The destruction of the uninsured rocket was a loss not only of the rocket itself, but also of the four satellites it contained; the total cost of the disaster was $500 million (Newsbytes home page 1996; Lions et al. 1996).,2020/7/14,5,需求分析的重要性,The reason: there was no discussion in the requirements documents of the ways in which the Ariane-5 trajectory would be different from Ariane-4.,统计资料： In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. Thirty-one percent 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 16% met those criteria in small companies (Standish 1994).,2020/7/14,6,需求分析的重要性,2020/7/14,7,需求分析的重要性,5点事实 软件生命周期中，一个错误发现得越晚，修复错误的费用越高,2020/7/14,8,需求分析的重要性,许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 在需求过程中会产生很多错误 DeMarco在一份研究报告中指出，被检查出来的错误的56产生的根源可以追溯到需求阶段。 AIRMICS所进行的一项调查发现，在一份美国军方大型管理信息系统的需求现格说明书(SRS)中存在着500多个错误，当然这仅仅是一个软件项目中的一次调查。 在需求阶段，代表性的错误为疏忽、不一致和二义性 美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究。他们对海军A7E它机上的”宅行操作程序进行实地测试，以验证许多新设想的可行性。得出的研究数据表明：A7E项目中77的需求错误特点是不明确：疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是： 49不正确的事实，31疏忽，l 3不一致，5二义性,2020/7/14,9,需求分析的重要性,需求错误是可以被检查出来的,2020/7/14,10,需求分析的重要性,在需求过程中会产生很多错误(事实3和4)。 许多错误并没有在早期被发现(事实2)。 这样的错误是能够在产生的初期被检查出来的(事实5)。 如果没有及时检查出来这些错误，软件费用会直线上升(事实1),2020/7/14,11,需求管理的困难性,2020/7/14,12,需求工程,需求是什么?需求就是以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的一个集合。 需求工程一般指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述出待开发系统及其行为特征和相关约束；通常是一些过程的集合：需求获取(需求引出)、需求分析和编写软件规格说明书(SRS)及验证(包括鉴定和证实)。,2020/7/14,13,需求工程涉及人员,2020/7/14,14,软件需求,功能需求 性能需求 环境需求 可靠性需求 安全保密要求 用户界面需求,资源使用需求 成本消耗需求 开发进度需求 预先估计以后系统可能达到的目标,2020/7/14,15,需求分析与程序分析的不同,2020/7/14,16,需求分析现状,误解 交流障碍 缺乏共同语言 “完整性”问题 需求永远不会稳定 用户意见不统一 错误要求 认识混淆,2020/7/14,17,需求分析的任务,可行性分析阶段已经粗略了解了用户的需求，甚至已经提出了一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的方案。因此许多细节被忽略。 在系统开发前，还需要进一步确定,2020/7/14,18,需求分析的任务,Final stage of Definition phase,仍然回答“What”，而不是“How”， 但更细致、精确（合同的拟定）,2020/7/14,19,需求分析的任务,完整 准确 清晰 具体,2020/7/14,20,需求分析的任务,2020/7/14,21,需求分析的任务,1、确定要求 功能要求(functional requirements):系统必须做什么？ 性能要求(performance requirements)：做得怎样？ 例：response time , memory , back-up memory , security , 运行要求(operational requirements) ：运行环境、软硬件配置等。 未来可能的扩充要求(possible evolution)：如3维虚拟现实的效果等等。,2020/7/14,22,需求分析的任务,2分析数据 建立概念模型(conceptual models): E-R Diagram 形象描绘数据结构: Data Hierarchy, Warnier Diagram, IPO 数据结构规范化(Normalization),3、导出逻辑模型： DFD + DD + IPO,4、修正计划：重估成本、进度等,2020/7/14,23,需求分析的任务,“样机 试用”,C,D,G,5、开发原型系统(Prototyping),2020/7/14,24,分析过程,软件系统本质上是信息处理系统，任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息 数据是分析的出发点，在可行性分析阶段许多实际的数据元素被忽略了，需求分析阶段将定义这些数据元素 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法,2020/7/14,25,分析过程,1、沿DFD回溯 （1）DFD的输出端是系统的最终目的 （2）向回确定每个数据元素的来源 （3）为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出某个数据元素需要用的算法尚不清楚，可加细DFD及DD，并将相关算法记录在IPO图中。,2020/7/14,26,分析过程,2、用户复查 数据字典准确完整吗？ 算法正确吗？ 有没有遗漏必要的处理或数据元素？ 某些数据元素是从哪里来的？ 构成一个循环，认识螺旋式上升,2020/7/14,27,分析过程,3、细化DFD： 加细前后的IO须相同。 分解到须考虑具体实现的代码时即可仃止,2020/7/14,28,分析过程,4、修正计划 5、文档：需求规格说明书,2020/7/14,29,需求分析规格说明书,2020/7/14,30,需求分析规格说明书,系统规格说明： 系统概貌 功能要求 性能要求 运行要求 可能增加的要求 DFD IPO, 数据要求： DD Hierarchy 或 Warnier Diagram, 用户系统描述 初步用户手册：从用户的观点考虑系统 系统功能、性能 使用与步骤 等,修正的开发计划： 成本估计 资源使用计划 进度计划,2020/7/14,31,需求分析规格说明书,从现实中分离功能，即描述要“做什么”而不是“怎样实现” 要求使用面向处理的规格说明语言（或称系统定义语言） 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中 规格说明必须包括系统运行环境 规格说明必须是一个认识模型 规格说明必须是可操作的 规格说明必须容许不完备性并允许扩充 规格说明必须局部化和松散耦合,2020/7/14,32,分析过程,轻松一分钟 True Tech Support Stories A woman complied with a techs request to send in a copy of a defective diskette. A few days later, the tech received a letter from her along with a xerox copy of the floppy. A tech advised a customer to put his troubled floppy back in the drive and close the door. The customer put his phone down and was heard walking across the room and shutting the door to the room.,2020/7/14,33,分析过程,节选自目前我国的一些实际系统中的功能性需求的说明方式：“根据详细的系统调研和需求分析，系统的功能必须满足以下需求： 1)编制计划、计划工程拨款管理，工程批复管理，工程进度统计； 2)工程项目管理； 3)计划拨款、征费收缴信息及其他收拨款信息查询统计； 4)路产管理，违章建筑管理，工程材料管理，超限运输管理； 5)养征信息查询管理，收费站信息管理； 6)文档管理，会议管理，合同管理，驾驶员外勤管理，常用管理； 7)养护信息管理，公路维护预警； 8)路况信息管理，交通量信息管理，科研项目信息管理；,2020/7/14,34,需求表达,需求说明语句 保持语句和段落的简短 采用主动语态的表达方式 编写具有正确的语法和标点的完整句子 使用的术语应该和词汇表中定义的一致 需求陈述应该具有一致的式样，例如“系统必须”，或者“用户必须”，并紧跟一个行为动作和可观察的结果，例如“仓库管理子系统必须现实一张在所请求的仓库中有存货的药品名单。”,2020/7/14,35,需求表达,为了减少不确定性，避免采用模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。 避免使用比较性的词汇，例如：提高，最大化，最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。,2020/7/14,36,需求表达,“产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒” 后台任务管理器应该在用户界面的指定区域显示状态消息 在后台任务进程启动之后，消息必须每隔60（+_10）秒更新一次，并且保持连续的可见性。 如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比 当完成后台任务时，后台任务管理器必须显示一个“已完成”的消息。 如果后台任务中止执行，那么后台任务管理器必须显示一个出错信息。,2020/7/14,37,需求表达,“产品必须在显示和隐藏非打印字符之间进行瞬间切换” “用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有HTML标记之间进行切换。”,2020/7/14,38,需求表达,“分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错” 在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件中所发生错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。 如果分析过程中未发生任何错误，就不必生成任何错误报告,2020/7/14,39,分析过程,第六步 审查和复审 以上六步构成一个循环,2020/7/14,40,需求分析过程,2020/7/14,41,概念模型和规范化,软件系统开发过程中必须考虑两方面的问题 “数据”及对数据的“处理” 为了把用户的数据要求清晰明确地表达出来，系统分析员通常建立一个概念性的数据模型（也称为信息模型）。概念性数据模型是一种面向问题的数据模型，是按照用户的观点来对数据和信息建模。,2020/7/14,42,概念模型和规范化,最常用的表示概念性数据模型的方法，是实体联系方法（Entity-Relationship Approach） ER图描述现实世界中的实体，而不涉及这些实体在系统中的实现方法。,2020/7/14,43,概念模型和规范化,实体是客观世界中存在的且可相互区分的事务。实体可以是人也可以是物，可以是具体的事物也可以是抽象概念。例如，职工、学生、课程、教师等都是实体。,2020/7/14,44,概念模型和规范化,客观世界中的事物彼此间往往是有联系的，例如，教师与课程间存在“教”这种联系。,2020/7/14,45,概念模型和规范化,属性是实体或联系所具有的性质。通常一个实体由若干个属性来刻画。 例如，“学生”实体有学号、姓名、性别、系、年级,2020/7/14,46,概念模型和规范化,例：,2020/7/14,47,概念模型和规范化,2、范式(Normal Forms)：消除数据冗余的程度 IBM E. F. Godd (1970) 例：,*Keyword:可唯一地标识一个元组的属性,2020/7/14,48,概念模型和规范化,范式级别越高，存储同样数据就要分解成更多张表，因此“存储自身”的过程也就越复杂 随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差 范式级别的提高则需要访问的表增多，性能（速度）将下降,2020/7/14,49,概念模型和规范化,1 - NF：所有属性都是原子值，即不出现“表中有表”,2020/7/14,50,概念模型和规范化,2 - NF：在 1-NF 基础上，每个non-key-word都由整个key word 决定（而非依赖于key word 的一部分）。例：“Major”实际上由“ID”的第6、7位决定，可省去。,2020/7/14,51,概念模型和规范化,3 - NF：在 2-NF基础上，non-key-word之间无从属关系。,2020/7/14,52,图形工具,1、层次方框图 (Hierarchy) 描绘数据的结构 例：A Room hierarchy based on an interior designers perspective.,2020/7/14,53,图形工具,2、Warnier Diagram：,2020/7/14,54,图形工具,3、IPO图(Input / Process / Output)：简要的算法描述,1. 校验 主记录 2. 校验 事务记录 3. 更新 主记录,旧的主文件 事务文件,有效的 主记录 有效的 事务记录 更新后的 主文件,2020/7/14,55,改进的IPO图,2020/7/14,56,需求验证,方法： 人工审查 初步用户手册 Prototyping 使用软件工具 完整性、一致性,2020/7/14,57,需求验证,例1：Software Requirements Engineering Methodology (SREM) (TRW Corporation, 1977) SREM = Requirements Statement Language (RSL) + Requirements Engineering Validation System (REVS),2020/7/14,58,需求验证,2020/7/14,59,自动化工具,近年来已经开发出一些需求分析工具，它们提供一组程序，帮助分析员制定需求规格说明。以自动化为主的工具给分析员提供另一种可供选择的方案。软件需求能够用一种规格说明语言来描述，这种语言把关键字指示符与自然语言(例如英语)描述结合起来。规格说明语言被送进一个处理机，它产生出一份需求规格说明，更为重要的是，它同时还产生出一组有关规格说明的一致性和组织的诊断报告。 在过去的10年间，已经提出过一些用于制订需求规格说明的自动化工具。,2020/7/14,60,自动化工具,2020/7/14,61,自动化工具,软件需求工程方法学(SREM)和问题陈述语言问题陈述分析器(PSLPSA)是有代表性的自动化工具。此外，一些基于知识或形式化方法都需要有自动工具来支持，才能有较好实用价值。,2020/7/14,62,自动化工具,软件需求工程方法学(SREM) SREM是一种自动化的需求分析工具，它用一种需求陈述语言(RSL)来描述“元素、属性、关系和结构”。元素(按照SREM的术语)包括一组用来制定需求规格说明的对象和概念。各对象之间的关系规定为RSL的一部分，而属性则用来描述或说明元素，结构用来说明信息流程。这些RSL基本成分与叙述性信息一起构成需求规格说明的细节。,2020/7/14,63,自动化工具,问题陈述语言与问题陈述分析PSLPSA PSLPSA是1968年由DTeichroew在密执安大学(Un5versity nf Michigan)提出的。 它是为ISDOS项目而开发的，又是一个称之为计算机辅助设计与规格说明分析工具(computeraided design and sPecification analysisto01，CADSAT)的更大的系统的部分。 PSLPSA给分析员提供的功能包括： 一般信息系统的描述，不论其应用领域如何。 建立一个包含用于信息系统的描述符的数据库。 描述符的添加、删除和修改。 提供格式化的文档资料和关于规格说明的各种报告。,2020/7/14,64,自动化工具,(1)问题陈述语言(the problem statement language，PSL)。PSL是一种用来描述信息系统的语言。PSL模型的结构由表达以下内容的描述符构成：系统信息流、系统结构、数据结构、数据的导出、系统的规模和容量、系统的动态特性、系统的性质以及项目的管理等。 (2)问题陈述分析(the problem statement analyzer，PSA)。PSA能够对由PSL描述的问题进行分析。使用者对系统建立了一个完整的PSL描述后，就调用问题陈述分析器(PSA)对其进行分析。PSA将产生一系列报告。其中包括修改规格说明数据的所有记录、以各种格式介绍数据库信息的参考报告、提供研制项目管理信息的小结报告和评价该数据库文件的分析报告等。,2020/7/14,65,自动化工具,基于知识的途径 软件开发是一种高级智能活动，极富创造性，是知识密集型产业，需要使用有关领域的大量知识。因此，引入人工智能技术，构造基于知识的软件工具或软件工程环境是十分必要的。随着知识工程的进步，目前在软件开发过程中使用人工智能在技术上已成为可能。 引入人工智能的原理和技术，把演进型原型的思想进一步提高和细化，可以得出如图所示的扩展的自动程序设计范型。这是一个把用受限自然语言描述的初步需求逐步演进成最终的源程序的自动程序设计系统的概念模型，是由美国南加州大学信息科学研究所首先提出来的。,2020/7/14,66,原型化方法,在开发初期，要想得到一个完整准确的规格说明不是一件容易的事。特别是对一些大型的软件项目。 用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求。 软件开发者对于所要解决的应用问题认识更是模糊不清 随着开发工作向前推进，用户可能会产生新的要求，或因环境变化，要求系统也能随之变化；开发者又可能在设计与实现的过程中遇到些没有预料到的实际困难，需要以改变需求来解脱困境。 因此规格说明难以完善、需求的变更、以及通信中的模糊和误解，都会成为软件开发顺利推进的障碍。 为了解决这些问题，逐渐形成了软件系统的快速原型的概念。,2020/7/14,67,软件原型的分类,在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。 探索型：目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。 实验型：这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。 进化型：这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。,2020/7/14,68,建立快速原型好处,增进软件者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求（主要是功能）明确化。 软件原型化方法提供了一种有力的学习手段。 使用原型化方法，可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。 软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。,2020/7/14,69,可执行规格说明 基于脚本(scenario)的设计 自动程序设计 专用语言 可复用(reusable)的软件 简化假设,原型开发技术,2020/7/14,70,可执行规格说明,可执行规格说明是用于需求规格说明的一种自动化技术。使用这种方法，人们可以直接观察他们用语言规定的任何系统性行为。包括 代数规格说明 有限状态模型 可执行的数据流图,2020/7/14,71,（1）代数规格说明,代数规格说明使用集合、定义于这些集合上的函数和定义于这些函数上的方程来描述对象。规格说明的操作语义用这些方程表示。 举例：定义一个无界的栈及其操作 NEW_STACK： Stack PUSH：Stack，Element Stack POP： Stack (Element | Undefined) POP (NEW_STACK ( ) ) Undefined POP (PUSH ( stk，elem ) ) elem 其中，前三行定义了操作的语法，后两行把它们的语义定义为一些方程。,2020/7/14,72,（2）有限状态模型,parnas提出的使用最广泛的一种可执行规格说明形式。从一个初始状态开始接收输入，到产生输出，状态在推移变化。施加在状态元素上的约束确定了有效状态的推移。 举例：建立用户程序对话,2020/7/14,73,（3）可执行的数据流图,数据流图是基于结构化开发方法的结构化规格说明 用一种可执行的语言程序代替定义处理逻辑的结构化英语，数据流图就成为由可执行语言程序模块组成的网络，在一定环境或工具的支持下就可成为一个可以执行的原型系统。,2020/7/14,74,基于脚本的设计,脚本是指用户界面的原型。一个脚本用以模拟在系统运行期间用户经历的事件。它提供了输入处理输出的屏幕格式和有关对话的模型。因此，软件开发者能够给用户显示系统的逼真的视图，使用户得以判断是否符合他的意图。 可在任一脚本中使用一套可复用的软件模块，以表达某一方面的要求。 可使用一种原型语言来描述原型系统。原型开发过程中用这种语言来定义屏幕、数据项、及其相关的操作。从系统的外部描述开始，开发与数据库的接口、错误处理和恢复过程等系统的与外部视图一致的细节。,2020/7/14,75,自动程序设计,自动程序设计是指在程序自动生成环境的支持下，利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程式问题规格说明转换为某种高级语言程序： 演绎综合手段： 基于数学推理的构造式证明。 程序变换手段： 将一程序转换成另一功能等价的程序，并保持其正确性不变。 实例推广手段： 从实例特征出发，将它推广为待编程序的特征，最后得到程序。 过程化手段： 研究甚高级语言的编译和知识的过程化。,2020/7/14,76,专用语言,专用语言是应用领域的模型化语言。在原型开发中使用专用语言，可方便用户和软件开发者在计划中的系统特性方面的交流。,2020/7/14,77,软件复用技术,利用可复用的模块，做出适当的组合，就可得到快速构造的原型系统。 为了快速地构造原型，这些模块首先必须有简单而清晰的界面；其次它们应当尽量不依赖其它的模块或数据结构；第三，它们应具有一些通用的功能。,2020/7/14,78,简化假设,简化假设是在开发过程中使设计者迅速得到一个简化的系统所做的假设。尽管这些假设可能实际上并不能成立，但它们在原型开发过程中可以使开发者的注意力集中在一些主要的方面。 在修改一个文件时，可以假设这个文件确实存在 在存取文件时，待存取的记录总是存在 一旦计划中的系统满足用户所有的要求，就可以撤消这些假设，并追加一些细节。,2020/7/14,79,系统动态分析,系统的需求规格说明通常是用自然语言来叙述的，但是用自然语言描述往往会出现歧义性。 为了直观地分析系统的动作，从特定的视点出发描述系统的行为，需要采用动态分析的方法。 最常用的动态分析方法 状态迁移图 时序图 Petri网,2020/7/14,80,状态迁移图,状态迁移图是描述系统的状态如何相应外部的信号进行推移的一种图形表示。 圆圈“”表示可得到的系统状态 箭头“”表示从一种状态向另一种状态的迁移。 例如, 当有多个申请占用CPU运行的进程时, 有关CPU分配的进程的状态迁移。,2020/7/14,81,可得到的状态就绪，运行，等待 生成的事件t1，t2， t3， t4 t1 中断事件 t2 中断已处理 t3 分配CPU t4 用完CPU时间,状态迁移图,2020/7/14,82,状态迁移图的优点,状态之间的关系能够直观地捕捉到 由于状态迁移图的单纯性，能够机械地分析许多情况，可很容易地建立分析工具,2020/7/14,83,Petri网,Petri网已广泛地应用于硬件与软件系统的开发中，它适用于描述与分析相互独立、协同操作的处理系统，也就是并发执行的处理系统。 Petri网简称PNG (Petri Net Graph)，它有两种结点： 位置(place)：符号为“”，它用来表示系统的状态。 转移(transition)：符号为 “”, 它用来表示系统中的事件。 图中的有向边表示对转移的输入，或由转移的输出,2020/7/14,84,标记，或称令牌(token)，是表明系统当前处于什么状态的标志,Petri网,2020/7/14,85,Petri网,2020/7/14,86,Petri网,2020/7/14,87,处理两个进程的同步问题,Petri网,2020/7/14,88,Petri网,
展开阅读全文