协商与建模需求规约与验证需求管理-Read课件.ppt

1、制作者制作者 程丽程丽软件工程软件工程第二章第二章 需求工程需求工程本章介绍以下内容本章介绍以下内容v可行性分析可行性分析v需求工程概述需求工程概述v需求获取需求获取v需求分析、协商与建模需求分析、协商与建模v需求规约与验证需求规约与验证v需求管理需求管理 接下来介绍接下来介绍v可行性分析可行性分析v需求工程概述需求工程概述v需求获取需求获取v需求分析、协商与建模需求分析、协商与建模v需求规约与验证需求规约与验证v需求管理需求管理可行性分析可行性分析可行性研究的目的可行性研究的目的可行性研究的任务可行性研究的任务v技术可行性技术可行性 确定技术风险，项目实现的可能性确定技术风险，项目实现的可能

2、性v经济可行性经济可行性 考虑投入考虑投入产出，市场前景，经营策略产出，市场前景，经营策略v社会可行性社会可行性 考虑合同、责任、侵权、用户组织的管理模式考虑合同、责任、侵权、用户组织的管理模式及规范问题及规范问题可行性研究的步骤可行性研究的步骤v确定项目规模和目标确定项目规模和目标v研究正在运行的系统系统流程图研究正在运行的系统系统流程图v建立新系统的高层逻辑模型简单数据流图建立新系统的高层逻辑模型简单数据流图v导出和评价各种方案导出和评价各种方案v推荐可行的方案推荐可行的方案v编写可行性研究报告，交使用部门审查编写可行性研究报告，交使用部门审查用用图形符号描述项目处理流程、范围和功能图形符

3、号描述项目处理流程、范围和功能 处理处理 输入输入/输出输出 连接连接 换页连接换页连接 数据流数据流 文档文档 联机存储联机存储 磁盘磁盘 显示显示 人工输入人工输入 人工操作人工操作 辅助操作辅助操作 通信链路通信链路系统流程图系统流程图例子：人工系统计算工资和编制报表例子：人工系统计算工资和编制报表教师教师课时表课时表任务表任务表职工职工工资支付系统工资支付系统工资表工资表工资明细表工资明细表银行银行教师教师职工职工成本效益分析成本效益分析成本效益分析成本效益分析成本效益分析成本效益分析v投资回收期投资回收期 使累计的经济效益等于最初投资费用所需的时使累计的经济效益等于最初投资费用所需的

4、时间间 投资回收期越短，就越快获得利润投资回收期越短，就越快获得利润v纯收入纯收入 整个生存周期之内的累计经济效益（折合成现整个生存周期之内的累计经济效益（折合成现在值）与投资之差在值）与投资之差v一个系统可以有多个可行的实现方案，每个方一个系统可以有多个可行的实现方案，每个方案对成本、时间、人员、技术、设备都有不同案对成本、时间、人员、技术、设备都有不同的要求，不同方案开发出来的系统在功能、性的要求，不同方案开发出来的系统在功能、性能方面也会有所不同。因此要在多个可行的实能方面也会有所不同。因此要在多个可行的实现方案中作出选择。现方案中作出选择。v由于系统的功能和性能受到多种因素的影响，由于

5、系统的功能和性能受到多种因素的影响，某些因素之间相互关联和制约。某些因素之间相互关联和制约。如，为达到高的精度就可能导致长的执行时如，为达到高的精度就可能导致长的执行时间，为达到高可靠性就会导致高的成本等等。间，为达到高可靠性就会导致高的成本等等。因此，在必要时应进行折衷。因此，在必要时应进行折衷。方案的选择和折衷方案的选择和折衷可行性分析的结论可行性分析的结论v可以立即开始进行可以立即开始进行v需要推迟到某些条件（例如资金、人力、设备等）需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行落实之后才能开始进行v需要对开发目标进行某些修改之后才能开始进行需要对开发目标进行某些修改之

6、后才能开始进行v因为某种原因（如，技术不成熟、经济上不合算因为某种原因（如，技术不成熟、经济上不合算等）不能进行等）不能进行可行性研究的文档可行性研究的文档v在可行性研究后提交的文档，包括在可行性研究后提交的文档，包括 引言引言 可行性研究前提可行性研究前提 对现有系统的分析对现有系统的分析 所建议的系统所建议的系统 可选择的其它系统方案可选择的其它系统方案 投资及效益分析投资及效益分析 社会因素方面的可行性分析社会因素方面的可行性分析 结论结论接下来介绍接下来介绍v可行性分析可行性分析v需求工程概述需求工程概述v需求获取需求获取v需求分析、协商与建模需求分析、协商与建模v需求规约与验证需求规

7、约与验证v需求管理需求管理v软件需求工程细分为软件需求工程细分为 需求获取需求获取 需求分析与协商需求分析与协商 系统建模系统建模 需求规约需求规约 需求验证需求验证 需求管理需求管理需求工程需求工程需求获取需求获取 v系统分析人员与用户交流，对现有系统观察，对系统分析人员与用户交流，对现有系统观察，对任务进行分析，确定系统或产品的范围，与系统任务进行分析，确定系统或产品的范围，与系统或产品有关的人员及特征，系统的技术环境，系或产品有关的人员及特征，系统的技术环境，系统功能，应用于每个需求的领域限制，一组描述统功能，应用于每个需求的领域限制，一组描述不同运行条件下系统或产品使用状况的应用场景。

8、不同运行条件下系统或产品使用状况的应用场景。需求分析与协商 v需求获取结束后，分析活动对需求进行分类组织，需求获取结束后，分析活动对需求进行分类组织，分析每个需求与其它需求的关系，检查需求的一分析每个需求与其它需求的关系，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。需求进行排序。v在需求获取阶段，经常出现以下问题：在需求获取阶段，经常出现以下问题：用户提出的要求超出软件系统可以实现的范围用户提出的要求超出软件系统可以实现的范围或实现能力；或实现能力；不同的用户提出了相互冲突的需求不同的用户提出了相互冲突的需求 系统建模系统建模

9、v建模工具的使用在用户和系统分析人员之间建立建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的错误和弥补不足，确保需求文档正确反映用户的真实意图。真实意图。v常用的分析和建模方法有面向数据流方法、面向常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。数据结构方法和面向对象的方法。需求规约需求规约 v软件需求规约是分析任务的最终产物，通过建立软件需求规约是分析任务的最终产物，

10、通过建立完整的信息描述、详细的功能和行为描述、性能完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。对目标软件的各种需求。v需求规约作为用户和开发者之间的一个协议，在需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。之后的软件工程各个阶段发挥重要作用。需求验证需求验证 v作为需求开发阶段工作的复查手段，需求验证对作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量

11、，评审应给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。以专门指定的人员负责，并按规程严格进行。v在实际的开发过程中，获取、分析、建模、编写规在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复完成。实际上，这些活动是交叉的、递增的和反复的。的。需求管理需求管理 v需求工程包括获取、分析、规定、验证和管理软需求工程包括获取、分析、规定、验证和管理软件需求，而件需求，而“软件需求管理软件需求管理”则是对所有相关活则是对所有相关活动的规划和控

12、制。动的规划和控制。v换句话说，需求管理就是：一种获取、组织并记换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的目团队对不断变更的系统需求达成并保持一致的过程。过程。接下来介绍接下来介绍v可行性分析可行性分析v需求工程概述需求工程概述v需求获取需求获取v需求分析、协商与建模需求分析、协商与建模v需求规约与验证需求规约与验证v需求管理需求管理软件需求包括软件需求包括v功能需求功能需求 v性能需求性能需求 v用户或人的因素用户或人的因素 v环境需求环境需求 v界面需求界面需求 v

13、文档需求文档需求 v数据需求数据需求 v资源使用需求资源使用需求 v安全保密要求安全保密要求 v可靠性需求可靠性需求 v软件成本消耗与开发进软件成本消耗与开发进度需求度需求 v其他非功能性要求其他非功能性要求 需求获取方法与策略需求获取方法与策略 v建立顺畅的通信途径建立顺畅的通信途径 v访谈与调查访谈与调查 v观察用户操作流程观察用户操作流程 v组成联合小组组成联合小组 v用况用况（Use CaseUse Case）建立顺畅的通信途径建立顺畅的通信途径 v建立分析所需要的通信途径，以保证能顺利地建立分析所需要的通信途径，以保证能顺利地对问题进行分析。对问题进行分析。访谈与调查访谈与调查 v在

14、具体的实践中，通常采用折衷的方法，即适当在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：灵活性。一般按照如下原则进行准备：所提问的问题应该循序渐进，从整体的方面开所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题始提问，接下来的问题应有助于对前面的问题更好的理解和细化；更好的理解和细化；不要限制用户对问题的回答，这有可能会引出不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；原先没有注意的问题；提问和回答在汇总后应能够反映用户需求的全提问和回答

15、在汇总后应能够反映用户需求的全貌。貌。例：例：“赛艇比赛成绩计算系统赛艇比赛成绩计算系统”的第一次面谈的准备的第一次面谈的准备计划计划 初次与初次与Dartchurch航行俱乐部的航行秘书（航行俱乐部的航行秘书（DR）接触，面）接触，面谈有关事宜。谈有关事宜。(在电话交谈时，了解到他们希望得到的是一个在电话交谈时，了解到他们希望得到的是一个“价廉价廉”的，基于的，基于PC的系统，以用于计算赛艇比赛成绩的系统，以用于计算赛艇比赛成绩)时间：时间：2005-6-5地点：对方场地地点：对方场地主要问题主要问题确定基本问题。确定基本问题。确定确定DR的角色的角色还涉及其它人员吗？还涉及其它人员吗？调查

16、财物方面事宜。调查财物方面事宜。系统（大致上）是如何运作的？系统（大致上）是如何运作的？当前存在的问题是什么？当前存在的问题是什么？他们都希望做些什么？他们都希望做些什么？观察用户操作流程观察用户操作流程 v到用户的实际工作环境中对用户的工作流程进行到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。可以有更全面、更细致的认识。组成联合小组组成联合小组 v便利的应用规约技术便利的应用规约技术(Facilitat

17、ed Application(Facilitated Application Specification Techniques,FAST)Specification Techniques,FAST)：打破用户：打破用户（需方）和开发者（供方）的界限，共同组成一个（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调这样有助于发挥各自优势并增进解和协调 FASTFAST基本原则基本原则 在中立的地点举行由开发者和用户出席的会议；在中立的地点举行由开发者和用户出席的会议；建立准备和

18、参与会议的规则；建立准备和参与会议的规则；建议一个足够正式的议程以便可以进行自由的建议一个足够正式的议程以便可以进行自由的交流；交流；一个一个“协调者协调者”(他可以是用户、开发者或其他他可以是用户、开发者或其他外人外人)来控制会议；来控制会议；使用一种使用一种“定义机制定义机制”(它可以是工作表、图表、它可以是工作表、图表、墙上胶黏纸或墙板墙上胶黏纸或墙板)；目标是标识问题、提出解决方案的要素、商议目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。刻画出初步的需求。FASTFAST会议会议 步骤步骤v1)

19、1)当举行了开发者和用户之间的初步访谈后，确当举行了开发者和用户之间的初步访谈后，确定一个定一个FASTFAST会议的时间地点，并在会议日之前将产会议的时间地点，并在会议日之前将产品请求发布给所有的与会者。品请求发布给所有的与会者。v2)2)要求每个要求每个FAST FAST 出席者会前列出一组围绕系统环出席者会前列出一组围绕系统环境的对象，以及对这些对象的操作或对象之间的交境的对象，以及对这些对象的操作或对象之间的交互功能，并开发出约束列表互功能，并开发出约束列表(如，成本、规模大小、如，成本、规模大小、权重权重)和性能标准列表和性能标准列表(如，速度、精度如，速度、精度)。这些列。这些列表

20、可以不是穷尽的，但是，希望每套列表反映的是表可以不是穷尽的，但是，希望每套列表反映的是每个人对系统的感觉。每个人对系统的感觉。v3)3)进行进行FAST FAST 会议时，当团队的每个成员提出单个会议时，当团队的每个成员提出单个列表后，整个团队将创建一个组合的列表，该组合列表后，整个团队将创建一个组合的列表，该组合列表删去冗余项，并加入在表达过程中出现的新思列表删去冗余项，并加入在表达过程中出现的新思想。在建好所有主题的组合列表后，开始讨论活动。想。在建好所有主题的组合列表后，开始讨论活动。缩短、加长或重新组合列表以适当地反映将被开发缩短、加长或重新组合列表以适当地反映将被开发的产品。的产品。

21、FASTFAST会议会议 步骤步骤 (续续)v4)4)一旦创建了意见一致的列表，应该将团队分为一旦创建了意见一致的列表，应该将团队分为更小的小组，每个小组力图为每个列表中的一个或更小的小组，每个小组力图为每个列表中的一个或多个项开发出小型的规约（即对包含在列表中的单多个项开发出小型的规约（即对包含在列表中的单词或短语的精细化）。每个小组然后将他们开发的词或短语的精细化）。每个小组然后将他们开发的每个小规约提交给所有的每个小规约提交给所有的FAST FAST 出席者讨论，进行出席者讨论，进行添加、删除或进一步的精化等工作。（在所有讨论添加、删除或进一步的精化等工作。（在所有讨论过程中，团队可能提

22、出某些不能在会议过程中解决过程中，团队可能提出某些不能在会议过程中解决的问题，此时要保留问题列表以使这些思想在以后的问题，此时要保留问题列表以使这些思想在以后的活动中产生作用。）的活动中产生作用。）v5)5)在小规约完成后，每个在小规约完成后，每个FAST FAST 的出席者提出一个的出席者提出一个针对产品的确切标准列表，并将该列表提交给团队，针对产品的确切标准列表，并将该列表提交给团队，然后创建一个意见一致的确定的标准列表。这个列然后创建一个意见一致的确定的标准列表。这个列表作为需求获取的结果，为需求分析和建模提供基表作为需求获取的结果，为需求分析和建模提供基础信息。础信息。用况用况（Use

23、 CaseUse Case）v当需求作为非正式会议、当需求作为非正式会议、FastFast的一部分而收集起的一部分而收集起来之后，分析员就可以创建一组标识一串待建造来之后，分析员就可以创建一组标识一串待建造系统的使用场景。系统的使用场景。v创建用况模型的主要步骤如下：创建用况模型的主要步骤如下：1)1)确定谁会直接使用该系统，即参与者（确定谁会直接使用该系统，即参与者（ActorActor）2)2)选取其中一个参与者选取其中一个参与者 3)3)定义该参与者希望系统做什么，参与者希望系定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况统作的每件事将成为一个用况 4)4)对每件事来

24、说，何时参与者会使用系统，通常对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程会发生什么，这就是用况的基本过程 5)5)描述该用况的基本过程描述该用况的基本过程接下来介绍接下来介绍v可行性分析可行性分析v需求工程概述需求工程概述v需求获取需求获取v需求分析、协商与建模需求分析、协商与建模v需求规约与验证需求规约与验证v需求管理需求管理需求分析原则需求分析原则 v1 1必须能够表示和理解问题的信息域必须能够表示和理解问题的信息域v2 2必须能够定义软件将完成的功能必须能够定义软件将完成的功能v3 3必须能够表示软件的行为必须能够表示软件的行为(作为外部事件的结果作为外部事

25、件的结果)v4 4必须划分描述数据、功能和行为的模型，从而必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节可以分层次地揭示细节v5 5分析过程应该从要素信息移向细节信息分析过程应该从要素信息移向细节信息为什么要引入信息域？为什么要引入信息域？v所有的软件应用程序均可被称为数据处理。如：所有的软件应用程序均可被称为数据处理。如：工资系统的批处理软件，开发控制汽车发动机油工资系统的批处理软件，开发控制汽车发动机油流的实时嵌入式软件。流的实时嵌入式软件。v将数据从一种形式变换为另一种形式将数据从一种形式变换为另一种形式v对事件的处理也不例外。例如，压力传感器检测对事件的处理也不例外。例如

26、，压力传感器检测压力是否超过安全值，并发送警报到监控软件，压力是否超过安全值，并发送警报到监控软件，警报信号是一个事件，该事件控制系统的行为。警报信号是一个事件，该事件控制系统的行为。v因此，数据因此，数据(数值、字符、图象、声音等数值、字符、图象、声音等)和控制和控制(事件事件)二者均驻留于问题的信息域内。二者均驻留于问题的信息域内。信息域信息域 v信息域：包括信息内容、信息流、以及信息结构。信息域：包括信息内容、信息流、以及信息结构。信息内容表示了单个数据和控制对象，目标软信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。件所有处理的信息集合由它们构成。例如，数据对象

27、例如，数据对象“工资工资”是一组重要数据体的是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、组合：领款人的姓名、净付款数、付款总额、扣除额等等扣除额等等 信息流表示了数据和控制在系统中流动时的变信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息化方式，输入对象被变换为中间信息(数据和数据和/或控制或控制)，然后进一步被变换为输出，然后进一步被变换为输出 信息结构表示了各种数据和控制项的内部组织信息结构表示了各种数据和控制项的内部组织 数据或控制项将被组织为数据或控制项将被组织为n n维表还是树形结构？维表还是树形结构？在结构的语境内，什么信息是和其他信息相在结构

28、的语境内，什么信息是和其他信息相关的？关的？信息包含在单个结构中，还是使用不同的结信息包含在单个结构中，还是使用不同的结构？构？在某信息结构中的信息如何和在另一个结构在某信息结构中的信息如何和在另一个结构中的信息相关？中的信息相关？信息域信息域 抽象、分解与多视点分析抽象、分解与多视点分析 v问题抽象方法要求分析人员在分析过程中捕捉用问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的户描述或问题本身固有的一般一般-特殊关系特殊关系v首先关注一般问题的解决途径，进而指导特殊问首先关注一般问题的解决途径，进而指导特殊问题的解决方法。题的解决方法。v问题分解的目的是要能以层次化的方式对

29、问题进行问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。分解和不断细化。较大规模或较为复杂的问题可以被分解为若干子较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析问题进行理解和分析 分解可以逐级进行，直至子问题被分解为一个容分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分易分析理解的部分 例如例如横向分解横向分解纵向分纵向分解解需求协商需求协商 v协商的过程就是讨论需求冲突，找出每个人都协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案满意的折衷方案 v协商不是简单的逻辑或技术上的争论协商不是简单的逻辑或技术上的争论 v要注意组织和行政方面的因素要注意组织

30、和行政方面的因素 不一致的目标不一致的目标 责任的丧失或转移责任的丧失或转移 组织文化组织文化 组织管理态度和士气组织管理态度和士气 部门差异部门差异 v通常会议是解决冲突最快的方式通常会议是解决冲突最快的方式 v参加者应该包括发现冲突、遗漏或重叠的分析员，参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员以及可以解决发现的问题的项目相关人员 v会议应该讨论那些非正式讨论不能解决的问题会议应该讨论那些非正式讨论不能解决的问题 v通常会议分为三个阶段：通常会议分为三个阶段：叙述阶段叙述阶段 讨论阶段讨论阶段 决策阶段决策阶段 需求建模需求建模 v在软件需求分析阶段，

31、所创建的模型，要着重于在软件需求分析阶段，所创建的模型，要着重于描述系统要描述系统要做什么做什么，而不是，而不是如何去做如何去做v目标软件的模型不应涉及软件实现细节目标软件的模型不应涉及软件实现细节 v常用的分析方法：常用的分析方法：面向数据流的结构化分析方法面向数据流的结构化分析方法 (SA)(SA)面向数据结构的分析方法面向数据结构的分析方法 面向对象的分析方法面向对象的分析方法 (OOA)(OOA)接下来介绍接下来介绍v可行性分析可行性分析v需求工程概述需求工程概述v需求获取需求获取v需求分析、协商与建模需求分析、协商与建模v需求规约与验证需求规约与验证v需求管理需求管理需求规约的原则需

32、求规约的原则 v1 1从现实中分离功能，即描述要从现实中分离功能，即描述要“做什么做什么”而而不是不是“怎样实现怎样实现”。v2 2要求使用面向处理的规约语言（或称系统定要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模统做出什么样的功能性反应，来定义一个行为模型，从而得到型，从而得到“做什么做什么”的规约。的规约。v3 3如果被开发软件只是一个基于计算机的系统如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说中的一个元素，那么整个大系统也包括在规格说

33、明的描述之中。明的描述之中。v4 4规约必须包括系统运行环境。规约必须包括系统运行环境。需求规约的原则需求规约的原则 (续续)v5 5规约必须是一个认识模型，而不是设计或实规约必须是一个认识模型，而不是设计或实现的模型。现的模型。v6 6规约必须是可操作的，以便能够利用它决定规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是对于任意给定的测试用例，已提出的解决方案是否都能满足规约。否都能满足规约。v7 7规约必须允许不完备性并允许扩充。规约必须允许不完备性并允许扩充。v8 8规约必须局部化和松散耦合。它所包括的信规约必须局部化和松散耦合。它所包括的信息必须局部化，

34、这样当信息被修改时，只要修改息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。入和删去一些段落。需求规约需求规约 .引言引言 A.系统参考文献系统参考文献B.整体描述整体描述C.软件项目约束软件项目约束.信息描述信息描述 A.信息内容表示信息内容表示B.信息流表示：信息流表示：数据流数据流 控制流控制流.功能描述功能描述 A.功能划分功能划分 B.功能描述：功能描述：处理说明处理说明 限制限制局限局限 性能需求性能需求

35、 设计设计约束约束 支撑图支撑图 C.控制描述控制描述 控制规约控制规约 设计约束设计约束.行为描述行为描述 A.系统状态系统状态 B.事件和响应事件和响应.检验标准检验标准 A.性能范围性能范围B.测试种类测试种类C.期望的软件响应期望的软件响应D.特殊的考虑特殊的考虑.参考书目参考书目.附录附录v引言引言陈述软件目标，在基于计算机的系统语境内进陈述软件目标，在基于计算机的系统语境内进行描述。行描述。v信息描述信息描述给出软件必须解决问题的详细描述，记录信息给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。内容和关系、流和结构。v功能描述功能描述描述解决问题所需的每个功能。其中包

36、括，为描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素示软件的整体结构和软件功能与其他系统元素间的相互影响。间的相互影响。需求规约需求规约 v行为描述行为描述 描述作为外部事件和内部产生的控制特征的软描述作为外部事件和内部产生的控制特征的软件操作。件操作。v检验标准检验标准 描述检验系统成功的标志。即对系统进行什么描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已样的测试，得

37、到什么样的结果，就表示系统已经成功实现了。它是经成功实现了。它是“确认测试确认测试”的基础。的基础。v参考书目参考书目 包含了对所有和该软件相关的文档的引用，其包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。厂商文献以及标准。v附录附录 包含了规约的补充信息，表格数据、算法的详包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。细描述、图表以及其他材料。需求规约需求规约 需求描述需求描述v我们的研究表明，家庭安全系统的市场正以每年我们的研究表明，家庭安全系统的市场正以每年40的比率增长，我们

38、希望能进入该市场，并的比率增长，我们希望能进入该市场，并试图建造基于微处理器的家庭安全系统，该系统试图建造基于微处理器的家庭安全系统，该系统将保护和将保护和/或识别一系列出人意料之外的或识别一系列出人意料之外的“情情况况”，如非法进入、火警、水灾或其他。该产品，如非法进入、火警、水灾或其他。该产品，暂时称为暂时称为SafeHome，产品将使用合适的传感，产品将使用合适的传感器来检测各种情况，具体使用时房主可按需要编器来检测各种情况，具体使用时房主可按需要编程，并且当系统检测到情况时，会自动地给监控程，并且当系统检测到情况时，会自动地给监控机构拨打电话。机构拨打电话。提出话题列表提出话题列表v为

39、为SafeHome描述的对象可能包括：描述的对象可能包括：若干烟雾检测器若干烟雾检测器 若干窗口和门传感器若干窗口和门传感器 若干运动检测器若干运动检测器 一个警报器一个警报器 一个事件一个事件(启动某传感器启动某传感器)一个控制模板一个控制模板 一个显示器一个显示器 一串电话号码一串电话号码 一次电话拨号等等。一次电话拨号等等。提出话题列表提出话题列表v服务的列表可能包括：服务的列表可能包括：设置警报器设置警报器 设置监控传感器设置监控传感器 电话拨号电话拨号 控制面板编程控制面板编程 读显示器读显示器(注意，服务作用于对象注意，服务作用于对象)v系统的制造成本必须低于系统的制造成本必须低于

40、200200万美元，界面必须万美元，界面必须是友好的，以及必须是和标准电话线接口是友好的，以及必须是和标准电话线接口)v性能标准性能标准 应该在一秒钟之内识别传感器事件应该在一秒钟之内识别传感器事件 应该实现事件优先级模式。应该实现事件优先级模式。产生小规约产生小规约vSafeHome中的对象中的对象“控制面板控制面板”的小规约可的小规约可能是：能是：安装在墙纸上。安装在墙纸上。大小大约为大小大约为95英寸。英寸。包含标准的包含标准的12键键盘和特殊键。键键盘和特殊键。包含包含LCD显示，操作如草图所示显示，操作如草图所示(未在此给未在此给出出)。所有的客户交互通过键盘发生，键盘被用于启所有的

41、客户交互通过键盘发生，键盘被用于启动或关闭系统。动或关闭系统。连接提供交互指南、回显等的软件到所有的传连接提供交互指南、回显等的软件到所有的传感器。感器。撰写完整规约撰写完整规约v在小规约完成后，每个在小规约完成后，每个FAST的出席者提出一个的出席者提出一个针对产品针对产品/系统的确切标准列表系统的确切标准列表v将该列表提交给团队将该列表提交给团队v创建一个意见一致的确定标准列表创建一个意见一致的确定标准列表v一个或多个参与者一个或多个参与者(或外来者或外来者)被赋予撰写完整的被赋予撰写完整的规约草案的任务规约草案的任务(用来自用来自FAST会议的结果为输会议的结果为输入入)。需求工程的指导

42、性原则需求工程的指导性原则 v在开始建立分析模型前先理解问题。在开始建立分析模型前先理解问题。v开发原型，使得用户能够了解将如何发生人机交开发原型，使得用户能够了解将如何发生人机交互。互。v记录每个需求的起源及原因。记录每个需求的起源及原因。v使用多个需求视图。使用多个需求视图。v给需求赋予优先级。给需求赋予优先级。v努力删除含糊性。努力删除含糊性。需求验证需求验证 v需求验证目的是要检验需求是否能够反映用户的需求验证目的是要检验需求是否能够反映用户的意愿意愿 需求验证需求验证v评审人员评审时往往需要检查以下内容：评审人员评审时往往需要检查以下内容：1.1.系统定义的目标是否与用户的要求一致；

43、系统定义的目标是否与用户的要求一致；2.2.系统需求分析阶段提供的文档资料是否齐全；文系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户档中的描述是否完整、清晰、准确地反映了用户要求；要求；3.3.被开发项目的数据流与数据结构是否确定且充足；被开发项目的数据流与数据结构是否确定且充足；4.4.主要功能是否已包括在规定的软件范围之内，是主要功能是否已包括在规定的软件范围之内，是否都已充分说明；否都已充分说明；5.5.设计的约束条件或限制条件是否符合实际；设计的约束条件或限制条件是否符合实际；6.6.开发的技术风险是什么；开发的技术风险是什么；7.7.是否详细制定

44、了检验标准，它们能否对系统定义是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。是否成功进行确认。接下来介绍接下来介绍v可行性分析可行性分析v需求工程概述需求工程概述v需求获取需求获取v需求分析、协商与建模需求分析、协商与建模v需求规约与验证需求规约与验证v需求管理需求管理需求管理需求管理v需求管理是一组用于帮助项目组在项目进展中的需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动任何时候去标识、控制和跟踪需求的活动 v需求跟踪有两种方式，正向跟踪与逆向跟踪需求跟踪有两种方式，正向跟踪与逆向跟踪 正向跟踪：以用户需求为切入点，检查正向跟踪：以用户需求为切入点，检查需求需求规约规约中的每个需求是否都能在后继工作产品中的每个需求是否都能在后继工作产品中找到对应点中找到对应点 逆向跟踪：检查设计文档、代码、测试用况等逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在工作产品是否都能在需求规约需求规约中找到出处中找到出处作业作业v教材教材4545页，第页，第3 3题题v教材教材6161页：页：2 2、8 8、9 9（第一问）（第一问）