上海交大之软件需求分析 PPT课件

13 04 2020 1 第6讲需求分析 13 04 2020 2 内容 需求分析的重要性需求分析的困难性需求工程需求分析过程概念模型和规范化图形工具需求验证原型技术 13 04 2020 3 需求分析 需求分析是软件定义时期的最后一个阶段回答 系统必须做什么 的问题 13 04 2020 4 需求分析的重要性 真的很重要吗 例 Ourreal timeexampleisbasedontheembeddedsoftwareintheAriane 5 aspacerocketbelongingtotheEuropeanSpaceAgency ESA OnJune4 1996 onitsmaidenflight theAriane 5waslaunchedandperformedperfectlyforapproximately40seconds Then itbegantoveeroffcourse AtthedirectionofanArianegroundcontroller therocketwasdestroyedbyremotecontrol Thedestructionoftheuninsuredrocketwasalossnotonlyoftherocketitself butalsoofthefoursatellitesitcontained thetotalcostofthedisasterwas 500million Newsbyteshomepage1996 Lionsetal 1996 13 04 2020 5 需求分析的重要性 Thereason therewasnodiscussionintherequirementsdocumentsofthewaysinwhichtheAriane 5trajectorywouldbedifferentfromAriane 4 统计资料 In1994 theStandishGroupsurveyedover350companiesabouttheirover8000softwareprojectstofindouthowwelltheywerefaring Theresultsaresobering Thirty onepercentofthesoftwareprojectswerecanceledbeforetheywerecompleted Moreover inlargecompanies only9 oftheprojectsweredeliveredontimeandcostwhattheywerebudgeted and16 metthosecriteriainsmallcompanies Standish1994 13 04 2020 6 需求分析的重要性 13 04 2020 7 需求分析的重要性 5点事实软件生命周期中 一个错误发现得越晚 修复错误的费用越高 13 04 2020 8 需求分析的重要性 许多错误是潜伏的 并且在错误产生后很长一段时间才被检查出来在需求过程中会产生很多错误DeMarco在一份研究报告中指出 被检查出来的错误的56 产生的根源可以追溯到需求阶段 AIRMICS所进行的一项调查发现 在一份美国军方大型管理信息系统的需求现格说明书 SRS 中存在着500多个错误 当然这仅仅是一个软件项目中的一次调查 在需求阶段 代表性的错误为疏忽 不一致和二义性美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究 他们对海军A 7E 它机上的 宅行操作程序进行实地测试 以验证许多新设想的可行性 得出的研究数据表明 A 7E项目中77 的需求错误特点是不明确 疏忽 不一致和二义性 按错误类型对这些错误分布进行分析的结果是 49 不正确的事实 31 疏忽 l3 不一致 5 二义性 13 04 2020 9 需求分析的重要性 需求错误是可以被检查出来的 13 04 2020 10 需求分析的重要性 在需求过程中会产生很多错误 事实3和4 许多错误并没有在早期被发现 事实2 这样的错误是能够在产生的初期被检查出来的 事实5 如果没有及时检查出来这些错误 软件费用会直线上升 事实1 13 04 2020 11 需求管理的困难性 13 04 2020 12 需求工程 需求是什么 需求就是以一种清晰 简洁 一致且无二义性的方式 对一个待开发系统中各个有意义方面的陈述的一个集合 需求工程一般指应用已证实有效的原理 方法 通过合适的工具和记号 系统地描述出待开发系统及其行为特征和相关约束 通常是一些过程的集合 需求获取 需求引出 需求分析和编写软件规格说明书 SRS 及验证 包括鉴定和证实 13 04 2020 13 需求工程涉及人员 13 04 2020 14 软件需求 功能需求性能需求环境需求可靠性需求安全保密要求用户界面需求 资源使用需求成本消耗需求开发进度需求预先估计以后系统可能达到的目标 13 04 2020 15 需求分析与程序分析的不同 13 04 2020 16 需求分析现状 误解交流障碍缺乏共同语言 完整性 问题需求永远不会稳定用户意见不统一错误要求认识混淆 13 04 2020 17 需求分析的任务 可行性分析阶段已经粗略了解了用户的需求 甚至已经提出了一些可行的方案 但是 可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的方案 因此许多细节被忽略 在系统开发前 还需要进一步确定 13 04 2020 18 需求分析的任务 FinalstageofDefinitionphase 仍然回答 What 而不是 How 但更细致 精确 合同的拟定 13 04 2020 19 需求分析的任务 完整准确清晰具体 13 04 2020 20 需求分析的任务 13 04 2020 21 需求分析的任务 1 确定要求 功能要求 functionalrequirements 系统必须做什么 性能要求 performancerequirements 做得怎样 例 responsetime memory back upmemory security 运行要求 operationalrequirements 运行环境 软硬件配置等 未来可能的扩充要求 possibleevolution 如3维虚拟现实的效果等等 13 04 2020 22 需求分析的任务 2分析数据 建立概念模型 conceptualmodels E RDiagram 形象描绘数据结构 DataHierarchy WarnierDiagram IPO 数据结构规范化 Normalization 3 导出逻辑模型 DFD DD IPO 4 修正计划 重估成本 进度等 13 04 2020 23 需求分析的任务 样机试用 C D G 5 开发原型系统 Prototyping 13 04 2020 24 分析过程 软件系统本质上是信息处理系统 任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息数据是分析的出发点 在可行性分析阶段许多实际的数据元素被忽略了 需求分析阶段将定义这些数据元素结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法 13 04 2020 25 分析过程 1 沿DFD回溯 1 DFD的输出端是系统的最终目的 2 向回确定每个数据元素的来源 3 为了得到某个数据元素需要用到数据流图中目前还没有的数据元素 或者得出某个数据元素需要用的算法尚不清楚 可加细DFD及DD 并将相关算法记录在IPO图中 13 04 2020 26 分析过程 2 用户复查数据字典准确完整吗 算法正确吗 有没有遗漏必要的处理或数据元素 某些数据元素是从哪里来的 构成一个循环 认识螺旋式上升 13 04 2020 27 分析过程 3 细化DFD 加细前后的I O须相同 分解到须考虑具体实现的代码时即可仃止 13 04 2020 28 分析过程 4 修正计划5 文档 需求规格说明书 13 04 2020 29 需求分析规格说明书 13 04 2020 30 需求分析规格说明书 系统规格说明 系统概貌 功能要求 性能要求 运行要求 可能增加的要求 DFD IPO 数据要求 DD Hierarchy或WarnierDiagram 用户系统描述 初步用户手册 从用户的观点考虑系统 系统功能 性能 使用与步骤等 修正的开发计划 成本估计 资源使用计划 进度计划 13 04 2020 31 需求分析规格说明书 从现实中分离功能 即描述要 做什么 而不是 怎样实现 要求使用面向处理的规格说明语言 或称系统定义语言 如果被开发软件只是一个大系统中的一个元素 那么整个大系统也包括在规格说明的描述之中规格说明必须包括系统运行环境规格说明必须是一个认识模型规格说明必须是可操作的规格说明必须容许不完备性并允许扩充规格说明必须局部化和松散耦合 13 04 2020 32 分析过程 轻松一分钟 TrueTechSupportStories Awomancompliedwithatech srequesttosendinacopyofadefectivediskette Afewdayslater thetechreceivedaletterfromheralongwithaxeroxcopyofthefloppy Atechadvisedacustomertoputhistroubledfloppybackinthedriveandclosethedoor Thecustomerputhisphonedownandwasheardwalkingacrosstheroomandshuttingthedoortotheroom 13 04 2020 33 分析过程 节选自目前我国的一些实际系统中的功能性需求的说明方式 根据详细的系统调研和需求分析 系统的功能必须满足以下需求 1 编制计划 计划工程拨款管理 工程批复管理 工程进度统计 2 工程项目管理 3 计划拨款 征费收缴信息及其他收拨款信息查询统计 4 路产管理 违章建筑管理 工程材料管理 超限运输管理 5 养征信息查询管理 收费站信息管理 6 文档管理 会议管理 合同管理 驾驶员外勤管理 常用管理 7 养护信息管理 公路维护预警 8 路况信息管理 交通量信息管理 科研项目信息管理 13 04 2020 34 需求表达 需求说明语句保持语句和段落的简短采用主动语态的表达方式编写具有正确的语法和标点的完整句子使用的术语应该和词汇表中定义的一致需求陈述应该具有一致的式样 例如 系统必须 或者 用户必须 并紧跟一个行为动作和可观察的结果 例如 仓库管理子系统必须现实一张在所请求的仓库中有存货的药品名单 13 04 2020 35 需求表达 为了减少不确定性 避免采用模糊的 主观的术语 例如 用户友好 容易 简单 迅速 有效 支持 许多 最新技术 优越的 可接受的和健壮的 避免使用比较性的词汇 例如 提高 最大化 最小化和最佳化 定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值 13 04 2020 36 需求表达 产品必须在固定的时间间隔内提供状态消息 并且每次时间间隔不得小于60秒 后台任务管理器应该在用户界面的指定区域显示状态消息在后台任务进程启动之后 消息必须每隔60 10 秒更新一次 并且保持连续的可见性 如果正在正常处理后台任务进程 那么后台任务管理器必须显示后台任务进程已完成的百分比当完成后台任务时 后台任务管理器必须显示一个 已完成 的消息 如果后台任务中止执行 那么后台任务管理器必须显示一个出错信息 13 04 2020 37 需求表达 产品必须在显示和隐藏非打印字符之间进行瞬间切换 用户在编辑文档时 通过激活特定的触发机制 可以在显示和隐藏所有HTML标记之间进行切换 13 04 2020 38 需求表达 分析程序应该能生成HTML标记出错的报告 这样就可以使HTML的初学者使用它来迅速排错 在HTML分析程序完全分析完一个文件后 该分析程序必须生成一个出错报告 这个报告中包含了在分析文件中所发生错误的HTML所在的行号以及文本内容 还包含了对每个错误的描述 如果分析过程中未发生任何错误 就不必生成任何错误报告 13 04 2020 39 分析过程 第六步审查和复审以上六步构成一个循环 13 04 2020 40 需求分析过程 13 04 2020 41 概念模型和规范化 软件系统开发过程中必须考虑两方面的问题 数据 及对数据的 处理 为了把用户的数据要求清晰明确地表达出来 系统分析员通常建立一个概念性的数据模型 也称为信息模型 概念性数据模型是一种面向问题的数据模型 是按照用户的观点来对数据和信息建模 13 04 2020 42 概念模型和规范化 最常用的表示概念性数据模型的方法 是实体联系方法 Entity RelationshipApproach ER图描述现实世界中的实体 而不涉及这些实体在系统中的实现方法 13 04 2020 43 概念模型和规范化 实体是客观世界中存在的且可相互区分的事务 实体可以是人也可以是物 可以是具体的事物也可以是抽象概念 例如 职工 学生 课程 教师等都是实体 13 04 2020 44 概念模型和规范化 客观世界中的事物彼此间往往是有联系的 例如 教师与课程间存在 教 这种联系 13 04 2020 45 概念模型和规范化 属性是实体或联系所具有的性质 通常一个实体由若干个属性来刻画 例如 学生 实体有学号 姓名 性别 系 年级 13 04 2020 46 概念模型和规范化 例 13 04 2020 47 概念模型和规范化 2 范式 NormalForms 消除数据冗余的程度IBME F Godd 1970 例 Keyword 可唯一地标识一个元组的属性 13 04 2020 48 概念模型和规范化 范式级别越高 存储同样数据就要分解成更多张表 因此 存储自身 的过程也就越复杂随着范式级别的提高 数据的存储结构与基于问题域的结构间的匹配程度也随之下降 因此 在需求变化时数据的稳定性较差范式级别的提高则需要访问的表增多 性能 速度 将下降 13 04 2020 49 概念模型和规范化 1 NF 所有属性都是原子值 即不出现 表中有表 13 04 2020 50 概念模型和规范化 2 NF 在1 NF基础上 每个non key word都由整个keyword决定 而非依赖于keyword的一部分 例 Major 实际上由 ID 的第6 7位决定 可省去 13 04 2020 51 概念模型和规范化 3 NF 在2 NF基础上 non key word之间无从属关系 13 04 2020 52 图形工具 1 层次方框图 Hierarchy 描绘数据的结构例 ARoomhierarchybasedonaninteriordesigner sperspective 13 04 2020 53 图形工具 2 WarnierDiagram 13 04 2020 54 图形工具 3 IPO图 Input Process Output 简要的算法描述 1 校验主记录2 校验事务记录3 更新主记录 旧的主文件事务文件 有效的主记录有效的事务记录更新后的主文件 13 04 2020 55 改进的IPO图 13 04 2020 56 需求验证 方法 人工审查 初步用户手册 Prototyping 使用软件工具 完整性 一致性 13 04 2020 57 需求验证 例1 SoftwareRequirementsEngineeringMethodology SREM TRWCorporation 1977 SREM RequirementsStatementLanguage RSL RequirementsEngineeringValidationSystem REVS 13 04 2020 58 需求验证 13 04 2020 59 自动化工具 近年来已经开发出一些需求分析工具 它们提供一组程序 帮助分析员制定需求规格说明 以自动化为主的工具给分析员提供另一种可供选择的方案 软件需求能够用一种规格说明语言来描述 这种语言把关键字指示符与自然语言 例如英语 描述结合起来 规格说明语言被送进一个处理机 它产生出一份需求规格说明 更为重要的是 它同时还产生出一组有关规格说明的一致性和组织的诊断报告 在过去的10年间 已经提出过一些用于制订需求规格说明的自动化工具 13 04 2020 60 自动化工具 13 04 2020 61 自动化工具 软件需求工程方法学 SREM 和问题陈述语言 问题陈述分析器 PSL PSA 是有代表性的自动化工具 此外 一些基于知识或形式化方法都需要有自动工具来支持 才能有较好实用价值 13 04 2020 62 自动化工具 软件需求工程方法学 SREM SREM是一种自动化的需求分析工具 它用一种需求陈述语言 RSL 来描述 元素 属性 关系和结构 元素 按照SREM的术语 包括一组用来制定需求规格说明的对象和概念 各对象之间的关系规定为RSL的一部分 而属性则用来描述或说明元素 结构用来说明信息流程 这些RSL基本成分与叙述性信息一起构成需求规格说明的细节 13 04 2020 63 自动化工具 问题陈述语言与问题陈述分析 PSL PSAPSL PSA是1968年由D Teichroew在密执安大学 Un5versitynfMichigan 提出的 它是为ISDOS项目而开发的 又是一个称之为计算机辅助设计与规格说明分析工具 computer aideddesignandsPecificationanalysisto01 CADSAT 的更大的系统的部分 PSL PSA给分析员提供的功能包括 一般信息系统的描述 不论其应用领域如何 建立一个包含用于信息系统的描述符的数据库 描述符的添加 删除和修改 提供格式化的文档资料和关于规格说明的各种报告 13 04 2020 64 自动化工具 1 问题陈述语言 theproblemstatementlanguage PSL PSL是一种用来描述信息系统的语言 PSL模型的结构由表达以下内容的描述符构成 系统信息流 系统结构 数据结构 数据的导出 系统的规模和容量 系统的动态特性 系统的性质以及项目的管理等 2 问题陈述分析 theproblemstatementanalyzer PSA PSA能够对由PSL描述的问题进行分析 使用者对系统建立了一个完整的PSL描述后 就调用问题陈述分析器 PSA 对其进行分析 PSA将产生一系列报告 其中包括修改规格说明数据的所有记录 以各种格式介绍数据库信息的参考报告 提供研制项目管理信息的小结报告和评价该数据库文件的分析报告等 13 04 2020 65 自动化工具 基于知识的途径软件开发是一种高级智能活动 极富创造性 是知识密集型产业 需要使用有关领域的大量知识 因此 引入人工智能技术 构造基于知识的软件工具或软件工程环境是十分必要的 随着知识工程的进步 目前在软件开发过程中使用人工智能在技术上已成为可能 引入人工智能的原理和技术 把演进型原型的思想进一步提高和细化 可以得出如图所示的扩展的自动程序设计范型 这是一个把用受限自然语言描述的初步需求逐步演进成最终的源程序的自动程序设计系统的概念模型 是由美国南加州大学信息科学研究所首先提出来的 13 04 2020 66 原型化方法 在开发初期 要想得到一个完整准确的规格说明不是一件容易的事 特别是对一些大型的软件项目 用户往往对系统只有一个模糊的想法 很难完全准确地表达对系统的全面要求 软件开发者对于所要解决的应用问题认识更是模糊不清随着开发工作向前推进 用户可能会产生新的要求 或因环境变化 要求系统也能随之变化 开发者又可能在设计与实现的过程中遇到些没有预料到的实际困难 需要以改变需求来解脱困境 因此规格说明难以完善 需求的变更 以及通信中的模糊和误解 都会成为软件开发顺利推进的障碍 为了解决这些问题 逐渐形成了软件系统的快速原型的概念 13 04 2020 67 软件原型的分类 在软件开发中 原型是软件的一个早期可运行的版本 它反映最终系统的部分重要特性 探索型 目的是要弄清对目标系统的要求 确定所希望的特性 并探讨多种方案的可行性 实验型 这种原型用于大规模开发和实现之前 考核方案是否合适 规格说明是否可靠 进化型 这种原型的目的不在于改进规格说明 而是将系统建造得易于变化 在改进原型的过程中 逐步将原型进化成最终系统 13 04 2020 68 建立快速原型好处 增进软件者和用户对系统服务需求的理解 使比较含糊的具有不确定性的软件需求 主要是功能 明确化 软件原型化方法提供了一种有力的学习手段 使用原型化方法 可以容易地确定系统的性能 确认各项主要系统服务的可应用性 确认系统设计的可行性 确认系统作为产品的结果 软件原型的最终版本 有的可以原封不动地成为产品 有的略加修改就可以成为最终系统的一个组成部分 这样有利于建成最终系统 13 04 2020 69 可执行规格说明基于脚本 scenario 的设计自动程序设计专用语言可复用 reusable 的软件简化假设 原型开发技术 13 04 2020 70 可执行规格说明 可执行规格说明是用于需求规格说明的一种自动化技术 使用这种方法 人们可以直接观察他们用语言规定的任何系统性行为 包括代数规格说明有限状态模型可执行的数据流图 13 04 2020 71 1 代数规格说明 代数规格说明使用集合 定义于这些集合上的函数和定义于这些函数上的方程来描述对象 规格说明的操作语义用这些方程表示 举例 定义一个无界的栈及其操作NEW STACK StackPUSH Stack Element StackPOP Stack Element Undefined POP NEW STACK UndefinedPOP PUSH stk elem elem其中 前三行定义了操作的语法 后两行把它们的语义定义为一些方程 13 04 2020 72 2 有限状态模型 parnas提出的使用最广泛的一种可执行规格说明形式 从一个初始状态开始接收输入 到产生输出 状态在推移变化 施加在状态元素上的约束确定了有效状态的推移 举例 建立用户 程序对话 13 04 2020 73 3 可执行的数据流图 数据流图是基于结构化开发方法的结构化规格说明用一种可执行的语言程序代替定义处理逻辑的结构化英语 数据流图就成为由可执行语言程序模块组成的网络 在一定环境或工具的支持下就可成为一个可以执行的原型系统 13 04 2020 74 基于脚本的设计 脚本是指用户界面的原型 一个脚本用以模拟在系统运行期间用户经历的事件 它提供了输入 处理 输出的屏幕格式和有关对话的模型 因此 软件开发者能够给用户显示系统的逼真的视图 使用户得以判断是否符合他的意图 可在任一脚本中使用一套可复用的软件模块 以表达某一方面的要求 可使用一种原型语言来描述原型系统 原型开发过程中用这种语言来定义屏幕 数据项 及其相关的操作 从系统的外部描述开始 开发与数据库的接口 错误处理和恢复过程等系统的与外部视图一致的细节 13 04 2020 75 自动程序设计 自动程序设计是指在程序自动生成环境的支持下 利用计算机实现软件的开发 它可以自动地或半自动地把用户的非过程式问题规格说明转换为某种高级语言程序 演绎综合手段 基于数学推理的构造式证明 程序变换手段 将一程序转换成另一功能等价的程序 并保持其正确性不变 实例推广手段 从实例特征出发 将它推广为待编程序的特征 最后得到程序 过程化手段 研究甚高级语言的编译和知识的过程化 13 04 2020 76 专用语言 专用