软件工程导论课件之第3章 需求分析 (第五版)(张海藩编著)_a

第3章 软件需求分析,教学目的与要求： 深刻理解需求分析阶段的概念及任务，熟练掌握ER图，HIOP图的画法。教学重点：需求分析阶段的任务、方法、具体任务。教学难点：写出需求规格说明书,第3章 需求分析,3.1 需求分析的任务3.2 与用户沟通获取需求的方法3.3 分析建模与规格说明3.4 实体-联系图3.5 数据规范化,3.6 状态转换图3.7 其他图形工具3.8 验证软件需求3.9 小结习题,成功来之不易,31%,（取消）,16.2%,（成功地完成）,53.8%,（受到挑战）,Source: Standish Group,2,软件项目失败的原因,软件项目失败的最重要的五个原因,需求不完整,缺少客户的参与 缺少资源,期望值过高,缺少高层的支持,0%,5%,10%,15%,3,需求错误的成本,4,4.1软件需求,软件需求的重要性 软件需求是决定软件开发是否成功的一个关键因素-需求分析可以帮助开发人员真正理解业务问题 - 需求分析是估算成本和进度的基础-需求分析可以避免建造错误的系统，从而减少不必要的浪费 -软件规格说明有助于开发人员与客户在“系统应做什么”问题 上达成正式契约 - 需求分析形成了软件开发的基线，有助于管理软件的演化和 变更- 软件需求是软件质量的基础，为系统验收测试提供了标准,5,IEEE给软件需求的定义如下：1）用户解决问题或到达目标所需的条件或能力。2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力3）一种反映上面1）或2）所描述的条件或能力的文档说明什么是软件需求分析： 将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的需求规格说明的过程。,软件需求分析的重要性： 软件需求分析是软件生存期决定性的一步，是软件开发的基础。分析员和用户： 在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。 软件需求分析的基本任务是准确地回答“系统必须做什么?”,3.1 需求分析的任务,软件需求分析的基本任务是准确地回答“系统必须做什么?”,3.1 需求分析的任务,案例：小型图书资料管理系统, 问题描述 - 某学院打算开发一个小型图书资料管理系统 MiniLibrary，该 系统基于Internet 实现教师和学生对各种图书资料的借阅、查 询和管理。- 图书管理员负责管理各种图书资料，查询图书资料信息，并 进行图书的借阅管理。 - 注册用户可以通过Internet 随时查询图书资料信息和个人借阅 情况，预订目前借不到的图书资料，并可以快捷地查找和浏 览所需要的电子资料。 - 系统可以提供适当的浏览器供用户阅读电子文献资料。 - 要求用户界面友好，响应速度快，具有良好的可扩展性 。,8,不同层次的软件需求,功能需求,非功能需求,业务需求,项目视图与范围文档,业务规则,用户需求,质量属性,用例文档,外部接口,系统需求 功能需求,约束条件,软件需求规格说明,9,1业务需求, 业务需求是组织或客户对于系统的高层次目标要求， 定义了项目的远景和范围，即确定软件产品的发展方向、功能范围、目标客户和价值来源。 业务需求的内容- 业务：产品属于哪类业务范畴？应该完成什么功 能？需要为 什么服务？- 客户：产品为谁服务？目标客户是谁？ - 特性：产品区别于其他竞争产品的特性是什么？ - 价值：产品的价值体现在什么方面？ - 优先级：产品功能特性的优先级次序是什么？,10,业务需求：MiniLibrary, 业务要求 - 各种图书资料的借阅、查询和管理；- 使用计算机实现图书资料的日常管理，提高工作 效率和服务质量;- 用户通过网络查询和浏览电子资料，改变原有的 借阅模式;- 由于版权的限制，某些电子资料只能让用户浏览 和打印 而不能下载。 客户与用户 - 学院的高层管理者 - 图书管理员 - 借阅者：教师、学生,11,2用户需求,用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的 内部特性。 用户需求的描述- 原则：应该易于用户的理解。一般 不采用技术性很强的语言，而是采 用自然语言和直观图形相结合的方 式进行描述。- 问题：自然语言表达容易含糊和不准确.,12,用户需求：MiniLibrary, 举例： 用户可以通过Internet 随时查询图书信息和个人借阅情况，并 可以快捷地查找和浏览所需要的电子资料。 分析：上述需求描述包含了三个不同的需求 - 用户可以通过Internet 随时查询图书信息。 - 用户可以通过Internet 随时查询个人借阅情况。 用户可以通过Internet 快捷地查找和浏览所需要的电 子资料。 问题： -“随时”和“快捷”是对系统功能的约束，十分模糊。,13,3功能需求, 功能需求 - 描述系统应该提供的功能或服务，通常涉及用户 或外部系统 与该系统之间的交互，一般不考虑系 统的实现细节。 举例：MiniLibrary - 用户可以从图书资料库中查询或者选择其中的一个子集。 - 系统可以提供适当的浏览器供用户阅读电子文献。 用户每次借阅图书应该对应一个唯一的标识号，它被记录 到用户的帐户上。,15,非功能需求, 非功能需求 从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、 开发过程的标准等。 举例：MiniLibrary - 系统应在 20 秒之内响应所有的请求。 - 系统每周 7 天、每天 24 小时都可以使用。 - 对于一个没有经验的用户而言，经过两个小时的 培训就可以 使用系统的所有功能。,16,非功能需求,非功能需求,过程需求,产品需求,外部需求,软件交付 实现方法 标准,互操作性 道德 法规 成本,可用性 软件性能,存贮空间,可靠性,可移植性 安全性,17,非功能需求,特性,度量指标,每秒处理的事务 用户或事件的响应时间 屏幕的刷新时间,速度,字节数 RAM 芯片数,存贮空间,培训时间 帮助页面数,可用性,平均失败时间 系统无效的概率 失败发生率,可靠性, 失败后的重启次数 事件引起失败的比例 失败时数据崩溃的可能性,容错性,18,4系统需求, 系统需求是更加详细地描述系统应该做什么，通常包括许多不同的分析模型，诸如对象模型、数据模型、 状态模型等。 系统需求模型的描述 结构化英语（ PDL ） 可视化模型 - 形式化方法 系统需求主要是面向开发人员进行描述，是开发人员 进行软件设计的基础。,14,需求的来源, 客户或用户 学院的高层管理者、项目投资人 - 系统管理员 - 教师、学生、图书管理员 标准图书资料的标准 政策或法律 图书资料管理规程、知识产权和版权保护等 系统或过程文档 - 当前手工管理的文件、表格、记录等 相关领域的专家,19,3.1.1 确定对系统的综合要求,1. 功能需求 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。2. 性能需求 性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、等方面的需求。3. 可靠性、可用性、安全性、保密性等需求 要求定量地指定系统的可靠性、可用性、安全性、保密性等。,思考题例： A银行长年开放100台ATM机，1000台用于商场酒店的POS机，B银行没有ATM和POS机只有10个每天8点上班17点下班的储蓄所。请问：A、B银行的可靠性可用性各应如何设置？4. 出错处理需求 在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少,5. 接口需求 接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。6. 约束 常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。7、用户界面需求,系统环境-多少台机器、 机型等接口；8、系统可移植性、可维护性等方面的需求。9. 将来可能提出的要求,这是软件需求分析的一个重要任务。通常采用建立数据流图、数据字典和数据模型的方法。 常用的图形工具有层次方框图HIPO和Warnier图，在本章第3.7节中将简要地介绍这两种图形工具。 软件系统经常使用各种长期保存的信息，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化(见3.5节)。3.1.3 导出系统的逻辑模型 在分析综合中逐步细化软件功能划分各子功能，对系统数据域进行分析，建立新系统的逻辑模型(系统图.数据流图.数据字典.E-R图、UML模型图表示)。 常用方法是，面对结构化分析方法（SA）面向数据结构（JSP）方法，面向对象OOA方法。,3.1.2 分析系统的数据要求,3.1.4 修正系统开发计划,3.1.4 修正系统开发计划 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。3.2 与用户沟通获取需求的方法需求获取的困难 用户通常并不真正知道自己希望计算机系统做什么 用户通常使用业务语言表达需求，开发人员缺乏相关的领域知识和经验，难以准确理解这些需求 不同的用户提出不同的需求，可能存在矛盾和冲突 管理者可能出于增加影响力的原因而提出特别的需求 由于经济和业务环境的动态性，需求经常发生变更,补充：与用户沟通获取需求的方法,3.2 与用户沟通获取需求的方法,需求获取的关键在于通过与用户的沟通和交流，收集和理解用户的各项要求。 3.2.(1) 访谈-访问用户和用户领域的专家 (2) 需求讨论会 (3) 问卷调查 (4) 现场考察 3.2.(5) 快速建立软件原型 -原型化方法 (6)基于用例的方法,1.用户面谈, 用户面谈 一种理解商业功能和商业规则的最有效方法 面谈过程需要认真的计划和准备 面谈之前 确立面谈目的 确定要包括的相关用户 确定参加会议的项目小组成员 建立要讨论的问题和要点列表 复查有关文档和资料 确立时间和地点 通知所有参加者有关会议的目的、时间和地点,52,1.用户面谈, 面谈过程需要认真的计划和准备（续）,进行面谈 衣着得体，准时到达 寻找异常和错误情况 深入调查细节 详细记录 指出和记录下未回答条目和未解决问题 面谈之后 复查笔记的准确性、完整性和可理解性 把所收集的信息转化为适当的模型和文档 确定需要进一步澄清的问题域 适当的时候向参加会议的每一个人发一封感谢信,53,2.需求专题讨论会, 需求专题讨论会,- 项目主要风险承担人在短暂而紧凑的时间段内集中在一起， 一般为 1 至 2 天，与会者可以在应用需求上达成共识、对操作过程尽快取得统一意见。, 优点,协助建立一支高效的团队，围绕项目成功的目标； - 所有的风险承担人都畅所欲言；,促进风险承担人和开发团队之间达成共识； - 揭露和解决那些妨碍项目成功的行政问题； - 能够很快地产生初步的系统定义。,54,2.需求专题讨论会, 专题讨论会准备,- 参加会议人员：主持人、用户、技术人员、项目组人员 - 安排日程：通常在具有相应支持设备的专用房间进行, 举行会议,- 可能出现行政间的责备或冲突，主持人应掌握讨论气氛并控制会场。,- 会议最重要的部分是自由讨论阶段，这种技术非常符合专题 讨论会的气氛，并且营造一种创造性的和积极的氛围，同时可以获得所有相关者的意见。,- 注意分配会议时间，记录所有言论。,55,2.需求专题讨论会,56,3.问卷调查, 问卷调查,- 可用于确认假设和收集统计倾向数据 - 问卷需要快速回答，允许匿名方式 存在问题,- 相关的问题不能事先决定,问题背后的假设对答案造成偏颇，如这符合你的期望吗？- 难以探索一些新领域,- 难以继续用户的模糊响应, 在完成最初的面谈和分析后，可作为一项协作技术可以收到良好的效果。,57,4.现场考察, 现场观察商业过程和工作流程,- 掌握用户如何实际使用一个系统以及到底用户需要哪些信 息，最好的办法是亲自观察用户是如何完成实际工作的。, 一般方法,- 对办公室进行快速浏览，了解布局、设备要求和使用、工作 流总体情况。,- 安排几个小时观察用户是如何实际完成他们的工作，理解用户实际使用计算机系统和处理事务的细节。,像用户一样接受训练和做实际工作，发现关键问题和瓶颈。 注意：观察可能使用户紧张。,58,5.原型化方法, 原型化方法,- 一个软件原型是所提出的新产品的部分实现，帮助开发人 员、用户以及客户更好地理解系统的需求，它比开发人员常 用的技术术语更易于理解。, 建立原型的原因,- 解决在产品开发的早期阶段需求不确定的问题，用户、经理 和其他非技术项目风险承担者发现在确定和开发产品时，原 型可以使他们的想象更具体化。, 基于 WEB 的应用系统原型,- 使用 HTML 进行界面设计,59,6.基于用例的方法, 用例建模是以任务和用户为中心的，开发和描述用户需要系统做什么。, 用例建模的步骤,- 确定系统的参与者 - 确定场景,- 确定系统用例,- 确定用例之间的关系 - 编写用例描述文档,60,3.3.1分析建模1、问题识别 双方确定对问题的综合需求。基于项目有关的软件的功能、性能、环境、用户界面、可靠性、安全性、保密性、可移植性、可维护性、等方面的需求。,3.3 分析建模与规格说明 需求分析的步骤,2、分析和综合导出软件的逻辑模型,2、分析和综合导出软件的逻辑模型 1）分析人员对获取的需求进行一致的分析检查，逐步细化软件功能，划分各子功能； 2）对系统数据域进行分解，分配到各子功能上； 3）用图文结合的形式，建立新系统的逻辑模型和物理视图。 物理视图指系统数据输入输出使用什么设备或方式，例键盘输入、数据扫描、数据传送等方式。,3.3.2 软件需求规格说明,3.3.2 软件需求规格说明 软件需求规格说明书，是需求分析阶段得出的最主要的文档。 补充：需求分析阶段要编写文档： 1）编写“需求规格说明书” 2）编写初步用户手册 3）编写“确认测试计划”(为系统完成后确认验收的依据). 4） 修改完善软件开发计划 需求规格说明书写法见实验指导书,3.4 实体-联系图（E-R图）,应该包括在SRS（需求规格说明）中的内容- 功能： 软件应该提供什么功能？外部接口：软件如何与人、系统硬件和其他系统等进行相互 作用？- 性能： 软件系统在运行速度、可用性、响应时间、恢复时间 等方面有什么要求？- 特性：软件系统在可移植性、可维护性、安全性等方面有什 么考虑？设计约束：是否存在必要的标准、开发语言、数据库、资源 限制、运行环境等因素的影响和策略？不应该包括在SRS 中的内容- 项目开发计划: 如成本、人员、进度、工具、方法等 - 产品保证计划 : 如配置管理、验证与测试、 质量保证等- 软件设计细节: 需求通常用于表达“做什么”， 而不描述“如何做”。,编写需求规格说明的原则,原则 1：只描述“做什么”而无须描述“怎么做” 原则 2：必须说明运行环境 原则 3：考虑用户、分析员和实现者的交流 -对形式化和自然语言之间作出恰当的选择 - 明确的理解最重要，不存在十全十美的软件规格说明书,编写需求规格说明的原则,原则 4：力求寻找到恰如其分的需求详细程度 - 一个有益的原则就是编写单个的可测试需求文档 - 建议将可测试的需求作为衡量软件产品规模大小的尺度 原则 5：文档段落不宜太长 简短 - 记住：不要在需求说明中使用“和/或”、“等等”之类的词原则 6：避免使用模糊的、主观的术语- 如用户友好、容易、简单、迅速、有效、许多、最新技术、 优越的、可接受的、最大化、最小化、提高等- 不可验证 建议：采用一种标准的SRS 模板,需求工程, 需求工程是应用已证实有效的原理和方法，并通过合 适的工具和符号，系统地描述出待开发系统及其行为 特征和相关约束。,活动,持续进行的需求管理 需求,需求获取,需求分析,需求验证,规格说明,工作产品,已确认的,需求规格,会议记录等,分析模型,需求规格,说明书,说明书,22,为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型(也称为信息模型)。数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。3.4.1 数据对象 3.4.2 属性 3.4.3 联系3.4.4 实体-联系图的符号 通常，使用实体-联系图(entity-relationship diagram)来建立数据模型。可以把实体-联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。,3.4 实体-联系图（E-R图）,ER信息模型的设计,ER信息模型的设计E R方法是英文 entity relationship approach 的简称，译作实体一联系方法。此法通过ER图形表示信息世界中的实体、属性、关系的模型。1）ER图约定：实体用方框表示，联系用菱形框表示。框内填入相应的实体名，联系名及属性名。下图举了三个例子，表示了二个实体间的联系，而三个例子由三种不同的联系方法。,三个例子,三个例子，表示了二个实体间的联系，而三个例子由三种不同的联系方法。,第一种情况,第一种情况：是一对一的关系，一个工厂只有一个正厂长。第二种情况：是一对多的联系，一个仓库存放多种和多个产品；第三种情况：是多对多的联系，一个学生要学习多门课程，而一门课程又有多名学生学习，所以是多对多的联系。同时从图中也可看出联系也可能有属性，如存放有属性数量，学习有属性成绩等。2）如何设计ER图先画出局部ER图，再对局部ER加以综合，产生一个总体ER图,先画出局部ER图，再对局部ER加以综合，产生一个总体ER图。,软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。下面给出第一、第二和第三范式的定义：(1) 第一范式在同一表中没有重复项出现，如果有则应将重复项去掉。 每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。,3.5 数据规范化,(2) 第二范式满足第一范式条件,(2) 第二范式满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。 每个表必须有一个（而且仅一个）数据元素为主关键字，其它元素与主关键字一一对应。(3) 第三范式符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。 表中的所有数据元素，不但要能够唯一地被主关键字所标识，而且它们之间还必须相互独立，不存在其它的函数关系。,3.6 状态转换图,根据本章开头讲的结构化分析的第3条准则，在需求分析过程中应该建立起软件系统的行为模型。状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。因此，状态图提供了行为建模机制，可以满足第3条分析准则的要求。 （面向对象模型中介绍）,3.6 状态转换图（略）,3.7 其他图形工具,3.7 其他图形工具3.7.1 层次方框图(H图） 层次方框图是用树形结构的一系列多层次的矩形框描绘数据的层次结构。 树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。,3.7.2 Warnier图,图3.5 层次方框图的一个例子,法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。,3.7.2 Warnier图,HIPO图,图3.6 Warnier图的一个例子,3.7.3 HIPO图HIPO（Hierarchy Plus InputProcessOutput）图，是IBM公司于70年代中期在层次结构图的基础上，做出的一种描述系统结构和模块内部处理功能的工具。 HIPO图，有H图和IPO图两部分组成。H图描述整个系统的设计结构合格模块之间的关系，H图画n层，每层根据经验一般为310个模块，层次（n层）按具体情况定。IPO图描述某一特定模块内部的处理过程和输入输出关系。HIPO图一般有1张H图，多张 IPO图组成,层次模块结构图,H图特点,层次模块结构图（H图）,1、H图基本做法：是将系统划分为若干子系统，子系统下再划分为若干的模块，大模块内再分子模块。 2、H图特点：主要关心模块的外部属性，不关心模块的内部，即只关心它是什么能够作什么，不关心它怎么做。（怎么做IPO图解决） 3、模块的定义(什么是模块)：具有输入输出、逻辑功能、运行程序和内部数据这四种属性的一个程序。IPO图 IPO图是输入、处理、输出图的简称,图3.7 IPO图的一个例子图,图3.7 IPO图的一个例子图,c.5.4.4上组模块送入出入库单据,1核对纪录2核对价格3核对用户纪录4记录合格,将合格标志送回上一级模块c.5.4.4,模块编号:c.5.5.8,图3.8 改进的IPO图的形式,图3.8 改进的IPO图的形式,本书建议使用一种改进的IPO图(也称为IPO表)，,3.8 验证软件需求,需求工程, 需求工程是应用已证实有效的原理和方法，并通过合 适的工具和符号，系统地描述出待开发系统及其行为 特征和相关约束。,活动,持续进行的需求管理 需求,需求获取,需求分析,需求验证,规格说明,工作产品,已确认的,需求规格,会议记录等,分析模型,需求规格,说明书,说明书,22,(1) 一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。(2) 完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。(3) 现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。(4) 有效性必须证明需求是正确有效的，确实能解决用户面对的问题。,3.8.2 验证软件需求的方法,3.8 验证软件需求3.8.1 从哪些方面验证软件需求的正确性,需求验证是检验需求能否满足客户的意愿。 需求验证的技术需求评审：由不同代表（如分析员、客户、设计人员、测试 人员）组成的评审小组以会议形式对需求进行系统性分析。 原型评价：客户和用户在一个可运行的系统模型上实 际检验 系统是否符合他们的真正需要。- 测试用例生成：通过设计具体的测试方法，发现 需求中的许 多问题。,3.8.2 验证软件需求的方法,需求验证,33,需求验证主要围绕需求规格说明的质量特性展开。它主要是： 正确性 无二义性 完整性 可验证性 一致性 可修改性 可跟踪性,需求规格说明的质量特性, 正确性 需求规格说明对系统功能、行为、性能等的描述必须 与用户的期望相吻合，代表了用户的真正需求。 审查需求的正确性应该考虑的问题 用户参与需求过程的程度如何？- 每一个需求描述是否准确地反映了用户的需要？ - 系统用户是否已经认真考虑了每一项描述？ 需求可以追溯到来源吗？ 举例：下面的需求描述正确吗？- 在用户每次存钱的时候系统将进行信用检查。,34,需求规格说明的质量特性, 无二义性 - 需求规格说明中的描述对于所有人都只能有一种 明确统一的解释。 审查需求的无二义性应该考虑的问题- 需求规格说明是否有术语词汇表？- 具有多重含义或未知含义的术语是否已经定义？ - 需求描述是否可量化和可验证？ 每一项需求都有测试准则吗？ 举例：下面的需求描述是无歧义的吗？- 如果用户试图透支，系统将采取适当的行动。,35,需求规格说明的质量特性, 完整性 - 需求规格说明应该包括软件要完成的全部任务， 不能遗漏任 何必要的需求信息。 审查需求的完整性应该考虑的问题 - 是否存在遗漏的功能或业务过程？ - 在每个定义的功能之间是否有接口？ - 是否有信息或消息在所定义的功能之间传递？ - 是否定义了功能的使用者？- 是否已经清楚地定义了用户与功能之间的交互？ - 是否定义了与外部过程和系统之间的接口？,36,需求规格说明的质量特性, 审查需求的完整性应该考虑的问题（续） - 所描述的功能是否可以映射到业务过程中？ - 文档中是否存在待确定的需求引用？ - 文档中是否存在未定义的术语和引用？ - 文档的各个部分都完整吗？- 需求包括非功能属性的说明吗？ 是否考虑了软件性能？ 是否考虑了安全性要求？ 是否考虑了可靠性？ 是否考虑了系统容量问题？,37,需求规格说明的质量特性, 可验证性,- 需求规格说明中描述的需求都可以运用一些可行的手段对其 进行验证和确认。, 审查需求的可验证性应该考虑的问题,- 在需求文档中是否存在不可验证的陈述，诸如“用户界面友 好”、“容易”、“简单”、“快速”、“健壮”、“最新技术”等？ - 所有描述都是具体的和可测量的吗？, 举例：下面的两个需求描述中哪一个难以验证？,- 系统将在 20 秒内响应所有有效的请求。,- 如果用户试图透支，系统将采取适当的行动。,38,需求规格说明的质量特性, 一致性,- 需求规格说明对各种需求的描述不能存在矛盾，如术语使用 冲突、功能和行为特性方面的矛盾以及时序上的不一致等。, 审查需求的一致性应该考虑的问题 - 文档的组织形式是否易于一致？ - 不同功能的描述之间是否存在矛盾？ - 是否存在有矛盾的需求描述或术语？ - 文档中是否存在时序上的不一致？, 举例：下面的两个需求描述是否有矛盾？,- 系统允许立即使用所存的资金。,- 只有在手工验证所存资金后，系统才能允许使用。,39,需求规格说明的质量特性, 可修改性,- 需求规格说明的格式和组织方式应保证后续的修改能够比较 容易和协调一致。, 审查需求的可修改性应该考虑的问题,- 是否存在明显的需求交叉引用？,- 是否有内容列表和索引？,- 是否存在冗余的需求，即同一个需求的描述出现在文档的不 同地方？如果存在，它们是交叉引用吗？,40,需求规格说明的质量特性, 可跟踪性,- 每一项需求都能与其对应的来源、设计、源代码和测试用例 联系起来。, 可跟踪性的两种形式,- 每一项需求都可以在早期的文档中追溯到其来源，例如备忘 录、法规、会议记录等；,- 每一项需求都有唯一的名称或索引号，与后期实现对应。 举例：下面的需求描述记录了早期的文档来源。,- 系统将在 20 秒内响应所有有效的请求。,来自与用户的面谈，备忘录编号 #1234,41,需求管理, 需求管理是分析变更影响并控制变更的过程，主要包 括变更控制、版本控制和需求跟踪等活动。,需求管理,变更控制,版本控制,需求跟踪,需求状态跟踪, 建议变更, 确定需求文档, 定义对其它需, 定义需求状态, 分析影响,的版本,求的连接链, 跟踪需求的每, 作出决策, 确定单个需求, 定义对其它系,一个状态, 交流,文档的版本,统元素的连接, 合并,链, 测量需求的稳 定性,42,下面的需求描述正确吗？ 在用户每次存钱的时候系统将进行信用检查。 下面的需求描述是无歧义的吗？如果用户试图透支，系统将采取适当的行动。下面的两个需求描述中哪一个难以验证？ 系统将在 20 秒内响应所有有效的请求。 - 如果用户试图透支，系统将采取适当的行动。下面的两个需求描述是否有矛盾？- 系统允许立即使用所存的资金。- 只有在手工验证所存资金后，系统才能允许使用。,需求描述示例, 举例 如果可能的话，应当根据图书编号的列表在线确认所输入的图书编号。 问题“如果可能的话”意味着什么？ “应当”是否精确？改正？ 系统必须根据在线的图书编号列表确认所输入的图书编号。如果在图书编号列表中查不到该图书的编号，或者当进行图书编号确 认时图书编号列表不可访问，系统必须显示一个出错信息并且拒 绝预订。,需求描述示例, 举例 1,产品必须在固定的时间间隔内提供状态信息，并且每次时间间隔不得小于 60 秒。,?,?,?,?, 问题,- 上述需求描述有什么缺陷？ - 如何改正？,46,需求描述示例与改正, 改正,后台任务管理器应该在用户界面的指定区域显示状态信息。 （1）在后台任务进程启动之后，消息必须每隔 6010 秒更新一 次，并且保持连续的可见性。,（2）如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比。,（3）当完成后台任务时，后台任