软件需求分析

高 级 软件工程,陈宁江2008.10,2,需求工程概述需求获取需求分析和建模需求验证与管理,本章内容,3,什么是需求（Requirement） ？,需求用户对目标软件系统在功能、行为、性能、设计约束等方面的期望IEEE的定义（1997年）用户解决问题或达到目标所需的条件或能力系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力反映以上两条的文档说明软件需求分析的目标：调查分析，准确理解用户的要求撰写需求，将用户的非形式的要求转化为完整的、形式的规格说明,4,软件需求分析的任务,5,需求必须描述的基本问题,功能所设计的软件要做什么； 性能软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等； 强加给实现的设计限制在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准； 属性可移植性、正确性、可维护性及安全性等方面的考虑因素； 外部接口与人、硬件、其他软件和其它硬件的相互关系。,6,需求的类型,业务需求（business requirement）客户对系统的高层次的目标要求。在项目视图与范围文档中予以说明用户需求（user requirement）用户使用产品必须要完成的任务功能需求（functional requirement）开发人员必须实现的软件功能，使得用户能完成他们的任务，满足业务需求非功能需求（non-functional requirement ）对系统提供的服务或者功能提出的约束，包括时间、开发过程、软件质量、标准等约束,7,一个例子,从不同的角度来看，需求具有不同的层次，即业务需求、用户需求、功能需求和非功能需求等例子：字处理程序 之 “ 拼写检查器”业务需求：“用户能有效地纠正文档中的拼写错误”用户需求：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”功能需求：“找到并高亮度提示错词的操作”；“显示提供替换词的对话框”；“实现整个文档范围的替换”非功能需求：“替换操作执行速度快”；“异常出现概率小”,8,如一个小型超市需要一个商品的查询系统。 业务需求：进货人员需要查询商品库存以便保证及时进货；收款员需要查询商品的销售价格以便结账；经理需要查询商品的销售及盈利情况。 用户需求:这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。,9,功能需求,对于功能性的系统需求，应需要详细描述系统中的操作功能、输入、输出、异常等功能需求的描述应做到：严密性全面性一致性,10,非功能需求,与软件系统的总体特性相关，并作用于整个系统；与软件系统的开发过程有关,11,非功能需求的度量,12,软件需求各组成部分之间的关系,13,软件需求的作用,软件开发的基础和前提只有在明确了软件需求之后才能开展有针对性的软件开发工作没有需求无法进行设计和编码制定软件开发计划的基础只有知道你想做什么，才能知道需要多少工作量，才能制定计划最终目标软件系统验收的标准只有知道你想做什么，才能知道你最终是否做好了没有定义明确的需求，就不知道最终基于什么进行验收,14,需求分析的意义,软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。,15,需求分析的重要性：例子,31,53,9,16,% 的项目被终止！平均超出时间122%,% 的项目超支，平均超支 89%！,% 的项目按期在预算之内完成！ (大公司),%的项目按期在预算之内完成！ (小公司)Standish Group 98 Chaos Report,用户参与不足！,不完整的用户需求！,需求不断变化！,16,需求分析的重要性：例子说明,17,需求分析的重要性：事实支撑（1/4）,软件生命周期中，一个错误发现得越晚，修复错误的费用越高,18,需求分析的重要性：事实支撑（2/4）,许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来在需求过程中会产生很多错误DeMarco研究报告：被检查出来的错误的56产生的根源可以追溯到需求阶段。,19,需求分析的重要性：事实支撑（3/4）,在需求阶段，代表性的错误为疏忽、不一致和二义性美国海军研究实验室对海军A-7E飞机上的飞行操作程序进行实地测试，得出的研究数据表明：A-7E项目中77的需求错误特点是不明确：疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是：49不正确的事实，31疏忽，l 3不一致，5二义性,20,需求分析的重要性：事实支撑（4/4）,需求错误是可以被检查出来的,21,需求分析的重要性推论,在需求过程中会产生很多错误许多错误并没有在早期被发现这样的错误是能够在产生的初期被检查出来的如果没有及时检查出来这些错误，软件费用会直线上升,22,获取软件需求的复杂性,系统复杂和庞大如何将软件需求得到？描述清楚？片面, 不完全如何保证得到了所有的软件需求？模糊, 不准确如何保证把需求说清楚和准确？不一致, 歧义如何保证所描述的需求是不矛盾的？及时性当需求变更时，如何让相关人员都知道需求已经变更？软件需求变动带来的问题波动性放大性,23,需求分析与程序分析的不同,24,需求分析常见问题,误解交流障碍缺乏共同语言“完整性”问题需求永远不会稳定用户意见不统一错误要求认识混淆,25,案例分析：中源公司的电信软件项目,思考：为什么需求工作出现了问题？在需求出现变更时怎么办？ 如何更好地进行需求管理？下一步可采取什么措施？,26,需求问题的解决方法和手段,技术层面需求分析方法、技术和工具方法：数据流、面向对象技术：抽象、建模、多视点、原型、工具：UML，Rose，Word，Excel，RequisitePro管理层面对需求分析中的人、活动和产品进行管理形成新的研究领域：需求工程,27,需求工程（Requirement Engineering ）,软件工程的子领域。应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义和管理目标系统的需求,需 求 工 程,需求获取,需求 分析,需求 建模,需求 规约,需求 验证,28,软件需求工程：需求获取需求分析与协商需求建模需求描述需求验证需求管理,需求分析和协商,需求描述,需求验证,系统模型,用户需求和系统需求,需求规约,需求管理,需求获取,需求建模,29,（一）需求获取,系统分析人员通过与用户交流，对现有系统的观察及对任务进行分析：确定系统或产品范围与系统或产品有关的人员及特征列表系统的技术环境的描述系统功能的列表及应用于每个需求的领域限制一组描述不同运行条件下系统的应用场景为更好地定义需求而开发的原型 需求获取工作的产品为进行需求分析提供了基础,30,需求获取方法,工作内容用耳 聆听用户的需求用脑 分析和整理所获取的信息用手 形成文档化的描述方法建立顺畅的通信途径 客户访谈和调查建立联合分析小组，观察用户操作流程 组成联合小组及时整理分析，反馈循环快速原型,31,建立顺畅的通信途径,建立分析所需要的通信途径，以保证能顺利地对问题进行分析。,32,访谈与调查,在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化不要限制用户对问题的回答，这有可能会引出原先没有注意的问题提问和回答在汇总后应能够反映用户需求的全貌。,33,需求分析要深入实际,市场调查了解市场对待开发软件的要求；市场上有无与待开发软件类似的系统及其情况访问用户和用户领域的专家考察现场,跟踪现场业务流程 查阅与待开发系统有关的资料,34,观察用户操作流程,到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。,35,组成联合小组,便利的应用规约技术(Facilitated Application Specification Techniques , FAST) ：打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调 鼓励建立客户和系统分析员之间的合作，由他们共同工作来标识问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案需求,加强联系促进交流增进合作,36,FAST基本原则,在中立的地点举行由开发者和用户出席的会议；建立准备和参与会议的规则；建议一个足够正式的议程以便可以进行自由的交流；一个“协调者”(他可以是用户、开发者或其他外人)来控制会议；使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)；目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。,37,需求收集的注意事项,如果应用规模较大，可分成几个需求调查小组同时进行，最后对结果进行汇总一定要和用户进行充分的交流，发现问题要及时沟通要和用户打成一片，建立起良好的合作关系如果发现多个软件需求相互矛盾，要能找到仲裁人或者决策人需求调查应遵循先整体后部分、先抽象后具体的原则帮助用户发现潜在的需求,38,（二）需求分析,需求获取结束后，分析活动对需求进行分类组织，分析每个需求与其它需求的关系，检查需求的一致性、重叠和遗漏的情况，并对需求进行排序在需求获取阶段，经常出现以下问题： 用户提出的要求超出软件系统可以实现的范围或实现能力 不同的用户提出了相互冲突的需求,39,需求协商,协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案 协商不是简单的逻辑或技术上的争论，要注意组织和行政方面的因素 不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异,40,参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员 会议应该讨论那些非正式讨论不能解决的问题,通常会议是解决冲突最快的方式,41,（三）需求建模,为什么需要对软件需求进行建模？需求调查所获取和文档化（文字）的软件需求不能有效地描述软件需求文字描述的局限性(不准确、二义、歧义、不能直观揭示关联)不准确不一致不全面.,42,建模技术,建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图常用的建模方法面向数据流方法面向对象的方法,43,结构化分析方法,数据建模的基础，描述数据对象及其关系,功能建模的基础，描述数据怎样转换以及转换的功能,行为建模的基础，表示系统的各种行为状态以及状态间的转换方式,适用于数据处理类型软件的需求分析,44,数据建模：实体关系图（ERD）,数据模型的基本元素数据对象描述对象的属性描述对象间相互连接的关系数据对象之间的关联一对一（1:1）一对多（1:N）多对多（M:N）,45,数据流图,描述了信息流和数据转换，表达系统内数据的运动情况系统的功能体现在核心的数据变换中系统的输入源于用方框表示的外部实体，这种输入引发系统的数据变换，产生传递给外部实体的输出基本元素,46,数据流图的基本组成,47,数据字典,数据字典描述数据流图的数据存储、数据加工（最底层加工）和数据流。它记录的主要内容有： 基本信息：名字、别名、描述 定义：数据长度、数据类型、数据结构 使用特点：取值范围、使用频率、使用方式等 控制信息：来源、用户、引用程序、读写权限等其它,48,行为建模,状态迁移图/表描述系统或对象的状态，以及导致系统或对象的状态改变的事件，从而描述系统的行为,49,（四）需求规约,需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用,签字不是万能的但没有签字是万万不能！,50,需求的描述,不宜使用自然语言描述系统需求原因：理解的二义性，随意性大，难以模块化书写需求的一些原则设计一个标准的格式，保证需求定义按格式书写使用一致的语言突出显示关键性需求尽量避免使用计算机专业术语,51,需求描述方法,结构化语言描述依赖于定义标准格式或模板来表达需求描述 程序描述语言（PDL）使用一种类似于程序设计语言的语言，但是具有更多抽象特征，通过定义系统的操作模型来定义需求 图形化符号图形语言辅之以文本注释来定义系统的功能需求 数学描述基于数学概念的符号 （如有限状态机、集合等）,52,结构化语言描述,53,程序描述语言（PDL）,好处：可以用软件工具进行语法和语义检查可检查需求遗漏和不一致便于描述比较复杂的操作，如循环、选择等可定义接口便于实现需求到设计的过渡缺点：表达功能的能力不够充分需要具有程序语言知识的人容易提前进入设计阶段，偏离需求分析的目标,54,图形化符号描述,结构化分析用例分析,55,需求的描述（续1）,需求说明语句保持语句和段落的简短采用主动语态的表达方式编写具有正确的语法和标点的完整句子使用的术语应该和词汇表中定义的一致需求陈述应该具有一致的式样，例如“系统必须”，或者“用户必须”，并紧跟一个行为动作和可观察的结果例如：“仓库管理子系统必须实现一张在所请求的仓库中有存货的药品名单。”,56,需求的描述（续2）,为了减少不确定性，避免采用模糊的、主观的术语例如：用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的、健壮的避免使用比较性的词汇例如：提高，最大化，最小化和最佳化定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值,57,需求说明的质量特性,正确性完整性一致性无二义性可修改性可跟踪性可验证性,58,其它需求分析阶段的文档,初步的用户手册：着重反映目标软件的用户功能界面和用户使用的具体要求。测试计划修改和完善软件开发计划,59,（五）需求验证,作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。,60,需求验证方法,需求评审原型建立测试用例生成自动的一致性分析编写用户手册,61,需求评审,需求审查是需求分析阶段工作的最后一步，是由软件工程师和客户一起进行并完成的目的是发现软件需求规格说明中的错误、二义性和遗漏的需求 复审首先在宏观的级别上进行，复审者试图保证软件需求规格说明是完整的、一致的、精确的，然后更详细地关注软件需求规格说明中的措词,62,评审实施(1/2),高级管理者定期参与对软件需求管理活动进行的评审 高级管理者参与定期评审的主要目的是在合适的抽象层次上及时地了解和洞察软件过程。评审间隔时间应该满足组织的需要，如果存在异常情况报告机制，间隔时间可以长些项目负责人可定期或者事件驱动地参与对软件需求管理活动的评审,63,评审实施(2/2),软件质量保证组对软件需求管理活动和工作产品进行评审和(或)审计，并报告其结果 软件需求已评审，且有关问题在软件工程组开发软件之前已得到解决当软件需求更动时，软件计划、工作产品和活动已经适当地更动由软件需求的更动所导致的对承诺的更动已与受影响组进行协商,64,评审人员往往需要检查以下内容：,系统定义的目标是否与用户的要求一致；系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求被开发项目的数据流与数据结构是否确定且充足主要功能是否已包括在规定的软件范围之内，是否都已充分说明设计的约束条件或限制条件是否符合实际开发的技术风险是什么是否详细制定了检验标准，它们能否对系统定义是否成功进行确认,65,自动化工具,需求分析工具帮助分析员制定需求规格说明。软件需求能够用一种规格说明语言来描述，这种语言把关键字指示符与自然语言(例如英语)描述结合起来。规格说明语言被送进一个处理机，它产生出一份需求规格说明，更为重要的是，它同时还产生出一组有关规格说明的一致性和组织的诊断报告。,66,自动化工具的手段,演绎综合手段： 基于数学推理的构造式证明程序变换手段： 将一程序转换成另一功能等价的程序，并保持其正确性不变实例推广手段 从实例特征出发，将它推广为待编程序的特征，最后得到程序。过程化手段： 研究甚高级语言的编译和知识的过程化,67,可执行规格说明基于脚本(scenario)的设计自动程序设计专用语言可复用(reusable)的软件简化假设,原型开发技术,68,小结1：需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的,领域了解,需求收集,需求描述,需求文档,过程入口,分类,冲突解决,优先排序,需求检查,(1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(11),(12),(13),(14),(15),69,小结2：软件需求分析人员应该具备的素质,善于领会一些抽象的概念，重新整理使之成为各种逻辑成分，并根据各种逻辑成分综合出问题的解决办法善于从各种相互冲突或混淆的原始资料中吸取恰当的论据能够理解用户的环境及领域知识具备把系统的硬件和软件部分应用于用户环境的能力具备良好的书面和口头形式进行讨论和交换意见的能力具有“既能看到树木，又能看到森林”的能力,70,（六）需求管理,为什么要需求管理？软件需求肯定是不完全的需求变动，软件演化需求管理是对系统需求变更了解和控制的过程，是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动 从演化的角度看，需求分为：持久的需求易变的需求,71,需求管理常见的问题,软件开发所基于的需求往往不完整不准确模棱两可需求定义没有生成文档，或文档未及时更新即使已采用一个个孤立的文档来管理需求，但是文档散布各处，没人知道哪个是最新版本文档对信息分析、优先级别划分和跟踪效率不高很难从需求文档中提取与项目有关的状态信息对需求没有达成共识随着情况的改变需求产生变更，但无法有效地管理和跟踪,72,导致问题的原因,缺乏用户参与忽略了用户分类在需求阶段，项目的范围尚未很好的定义忽视了运行、操作、法规等方面的约束“张三”不知道怎么写需求说明对需求过程不够了解管理层不重视开发过程中修补原始需求的缺陷不可控制的外因,73,需求管理的内容,74,需求管理的方法,确定需求变更控制过程进行需求变更影响分析维护需求变更的历史记录建立需求基准版本和需求控制版本文档跟踪每项需求的状态衡量需求稳定性,75,需求变更管理,问题分析和变更描述,变更分析和成本计算,识别出的问题,修正后的需求,变更实现,需求变更管理的要求仔细评估已建议的变更制定合适的变更处理变更及时通知所有涉及的人员,76,控制需求的变更(1/3),需求变更不可避免软件需求本身是变化的在需求分析阶段对软件需求的描述和分析不全面、不准确等需求变更对软件项目的开发会产生巨大的影响产品功能开发成本开发进度产品质量,77,控制需求的变更(2/3),需求变更的权衡，需要和用户协商，并对计划进行变更,78,控制需求的变更(3/3),如何控制需求的变更提出软件需求变更请求对软件需求变更进行评审变更软件需求说明书（SRS）将变更后的SRS纳入配置通知受影响小组和人员变更其他产品(软件设计文档、测试文档)和计划(软件开发计划),79,8 .3 软件需求的变更控制,需求变更处理流程,80,需求文档的版本控制,统一确定版本变更必须文档化，及时通知有关人员指定专人更新需求文档应包括版本修正历史需求管理工具的数据库存储需求使用专门的版本管理工具及数据库,81,需求跟踪,当某项业务需求发生变化时，可能会影响到系统需求和功能需求的变化，并且连带地影响到设计、测试、实现、项目计划等各方面的变化需求跟踪：应编制每个需求同系统元素之间的联系文档,82,需求跟踪的方式,正向跟踪：以用户需求为切入点，检查需求规约中的每个需求是否都能在后继工作产品中找到对应点逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在需求规约中找到出处,83,需求跟踪能力矩阵,例子：大量的需求跟踪信息可以使用特定的工具进行管理,84,小结：需求阶段的常见问题,需求的沟通与理解缺乏足够的用户参与添加不必要的特性忽略了用户分类需求的变化与控制用户需求不断增加需求说明的明确与完整需求模棱两可需求说明过于简单,85,CMM对需求管理的要求(1/3),需求管理是CMM 2级的一个关键过程域CMM对需求管理的理解和定义需求管理是指在用户和将处理“分配给软件的系统需求”的软件项目组之间建立对“分配给软件的系统需求”的共同理解，由软件工程组对“分配给软件的系统需求”进行分析