第03章 需求工程

1、厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇2/57 软件项目中百分之四十至百分之六软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的十的问题都是在需求分析阶段埋下的“祸祸根根” 。 可许多组织仍在那些基本的项目功可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）的后果便是一条鸿沟（期望差异）开发开发者开发的与用户所想得到的软件存在着巨者开发的与用户所想得到的软件存在着巨大期望差异。大期望差异。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇3/57 在软件工程中，所有

2、的风险承担者在软件工程中，所有的风险承担者(stakeholder)都感兴趣的就是需求分析阶段。都感兴趣的就是需求分析阶段。 这些风险承担者包括客户、用户、业务或这些风险承担者包括客户、用户、业务或需求分析员需求分析员(负责收集客户需求并编写文档，以负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人及负责客户与开发机构之间联系沟通的人)、开、开发人员、测试人员、用户文档编写者、项目管发人员、测试人员、用户文档编写者、项目管理者和客户管理者。理者和客户管理者。 这部分工作若处理好了，能开发出很出色这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍的产品，

3、同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基因为需求分析奠定了软件工程和项目管理的基础。础。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇4/57需求工程概述需求工程概述需求获取需求获取需求分析、协商与建模需求分析、协商与建模需求规约与验证需求规约与验证需求管理需求管理厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇5/57需求获取需求获取需求分析、协商与建模需求分析、协商与

4、建模需求规约与验证需求规约与验证需求管理需求管理厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇6/57 Alan Davis 把需求工程定义为把需求工程定义为“直到直到（但不包括）把软件分解为实际架构构（但不包括）把软件分解为实际架构构件之前的所有活动件之前的所有活动” Herb Krasner定义了需求工程的五阶段定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求形成需求规格、需求实现与验证、需求演进管理演进管理 Matthias Jarke和和Klaus Pohl提出了三提出了三阶段周期的说法：获

5、取、表示和验证阶段周期的说法：获取、表示和验证 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇7/57 本书将软件需求工程细分为：本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和和需求管理六个阶段。六个阶段。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇8/57 需求开发和需求管理之间的区别需求开发和需求管理之间的区别厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇9/57需求工程概述需求工程概述需求分析、协商与建模需求分析、协商与建模需求规约与验证需求规约与验证需求管理需求管理厦门理工学院应用数学学院厦门理工学院

6、应用数学学院 胡航宇胡航宇10/57 功能需求功能需求 性能需求性能需求 用户或人的因素用户或人的因素 环境需求环境需求 界面需求界面需求 文档需求文档需求 数据需求数据需求 资源使用需求资源使用需求 安全保密要求安全保密要求 可靠性需求可靠性需求 软件成本消耗与开软件成本消耗与开发进度需求发进度需求 其他非功能性要求其他非功能性要求 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇11/57 下面这些定义是需求工程领域中常见术语的定义说明。下面这些定义是需求工程领域中常见术语的定义说明。 软件需求包括三个不同的层次软件需求包括三个不同的层次业务需求、用户业务需求、用户需求和功能

7、需求（包括非功能需求）。需求和功能需求（包括非功能需求）。 业务需求（业务需求（business requirement）反映了组织）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。目视图与范围文档中予以说明。 用户需求（用户需求（user requirement）文档描述了用户）文档描述了用户使用产品必须要完成的任务，这在使用实例（使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（文档或方案脚本（scenario）说明中予以说明。）说明中予以说明。 功能需求功能需求(function

8、al requirement)定义了开发人定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（从而满足了业务需求。所谓特性（feature）是指逻辑）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足上相关的功能需求的集合，给用户提供处理能力并满足业务需求。业务需求。 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇12/57厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇13/57 需求获取时期的主要工作：需求获取时期的主要工作： 归纳和整理用户提出的各种问题和要归纳和整理

9、用户提出的各种问题和要 求；求； 弄清用户企图通过软件达到的目的；弄清用户企图通过软件达到的目的； 借助各种工具和方法，陈述用户提出借助各种工具和方法，陈述用户提出 的实际需求，并标定软件的作用范的实际需求，并标定软件的作用范 围。围。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇14/57 需求获取方法包括两个方面：需求获取方法包括两个方面： 指导开发小组获取用户需求的方法框架。指导开发小组获取用户需求的方法框架。 支持控制此项活动进展的过程控制机制。支持控制此项活动进展的过程控制机制。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇15/57 建立顺畅的通信途

10、径建立顺畅的通信途径 访谈与调查访谈与调查 观察用户操作流程观察用户操作流程 组成联合小组组成联合小组 用况用况（Use Case） 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇16/57 建立分析所需要的通信途径，以保证能建立分析所需要的通信途径，以保证能顺利地对问题进行分析。顺利地对问题进行分析。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇17/57 在具体的实践中，通常采用折衷的方法，即适当在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：灵活

11、性。一般按照如下原则进行准备： 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化； 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题； 提问和回答在汇总后应能够反映用户需求的全貌。 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇18/57 例子：例子：“赛艇比赛成绩计算系统赛艇比赛成绩计算系统”的第的第一次面谈的准备计划一次面谈的准备计划 初次与初次与Dartchurch航行俱乐部的航行秘书（航行俱乐部的航行秘书（DR）接触，面谈有关）接触，面谈有关事宜。事宜。(在电话交谈时，了解到他们希望得到的是一个在电话交谈时，了解

12、到他们希望得到的是一个“价廉价廉”的，的，基于基于PC的系统，以用于计算赛艇比赛成绩的系统，以用于计算赛艇比赛成绩)时间：时间：2005-6-5地点：对方场地地点：对方场地主要问题主要问题确定基本问题。确定基本问题。确定确定DR的角色的角色还涉及其它人员吗？还涉及其它人员吗？调查财物方面事宜。调查财物方面事宜。系统（大致上）是如何运作的？系统（大致上）是如何运作的？当前存在的问题是什么？当前存在的问题是什么？他们都希望做些什么？他们都希望做些什么？厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇19/57 1. 调查提纲或调查表调查提纲或调查表 2. 小型调查会议小型调查会议 3

13、. 个别访问个别访问 4. 现场调查现场调查 5. 资料资料 6. 调查工具调查工具厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇20/57 1. 不要用计算机专业术语与用户或用户不要用计算机专业术语与用户或用户领域专家交谈领域专家交谈 2. 不要使用不要使用“你应该你应该”这样的字眼这样的字眼 3. 始终记住自己最近一段工作中要达到始终记住自己最近一段工作中要达到的目标，引导用户说出你需要的信息的目标，引导用户说出你需要的信息 4. 要善于把用户中职位高的人和职位低要善于把用户中职位高的人和职位低的人的谈话结合起来分析的人的谈话结合起来分析厦门理工学院应用数学学院厦门理工学院

14、应用数学学院 胡航宇胡航宇21/57 到用户的实际工作环境中对用户的工作流到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细题陈述，对用户需求可以有更全面、更细致的认识。致的认识。 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇22/57 便利的应用规约技术(Facilitated Application Specification Techniques , FAST) ：打破用户（需方）和开发者：打破用户（需方）

15、和开发者（供方）的界限，共同组成一个联合小（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进推进，这样有助于发挥各自优势并增进解和协调解和协调 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇23/57 误解：由于分析员并非该应用领域的专家，使得在需求获取时，误解误解：由于分析员并非该应用领域的专家，使得在需求获取时，误解了用户潜在的隐含假设。了用户潜在的隐含假设。 交流障碍：领域专家同一个新手交谈时的用词往往并不足以解决问题。交流障碍：领域专家同一个新手交谈时的用词往往并不足以解决问题。 缺乏

16、共同语言：由于需求分析员和系统用户的经历和教育背景不同，缺乏共同语言：由于需求分析员和系统用户的经历和教育背景不同，他们之间通常缺乏足够的沟通。他们之间通常缺乏足够的沟通。 “完整性完整性”问题：软件工程师希望提出系统需求的用户领域专家能清晰、问题：软件工程师希望提出系统需求的用户领域专家能清晰、简明和完备地描述出确实可行的系统需求，然而，所要的需求知识在其最简明和完备地描述出确实可行的系统需求，然而，所要的需求知识在其最初阶段可能是模糊、不完备甚至是不正确的。初阶段可能是模糊、不完备甚至是不正确的。 需求永远不会稳定：用户对软件的需求常常会发生变化，并且是不可需求永远不会稳定：用户对软件的需

17、求常常会发生变化，并且是不可预测的。预测的。 用户意见不统一：大系统往往有各种不同的用户，他们往往有互相冲用户意见不统一：大系统往往有各种不同的用户，他们往往有互相冲突的需求和不同的需求优先次序，寻求折衷是不容易的。突的需求和不同的需求优先次序，寻求折衷是不容易的。 错误的要求：系统的定购者（付钱的人）和系统的使用者经常不是一错误的要求：系统的定购者（付钱的人）和系统的使用者经常不是一个人，定购者由于受到组织或经费的限制，提出的需求会与最终用户的需个人，定购者由于受到组织或经费的限制，提出的需求会与最终用户的需求相冲突。求相冲突。 认识混淆：有时系统的目标和系统的需求会发生混淆。目标是系统应认

18、识混淆：有时系统的目标和系统的需求会发生混淆。目标是系统应达到的更为一般的特征，而需求应是可测试的。达到的更为一般的特征，而需求应是可测试的。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇24/57 1. 了解系统需求了解系统需求 2. 市场调查市场调查 3. 访问用户和用户领域专家访问用户和用户领域专家 4. 考察现场考察现场厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇25/57需求工程概述需求工程概述需求获取需求获取需求规约与验证需求规约与验证需求管理需求管理厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇26/57 需求获取结束后，分析活动

19、对需求进行分需求获取结束后，分析活动对需求进行分类组织，分析每个需求其它需求的关系来，类组织，分析每个需求其它需求的关系来，检查需求的一致性、重叠和遗漏的情况，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。并根据用户的需要对需求进行排序。 在需求获取阶段，经常出现以下问题：在需求获取阶段，经常出现以下问题： 用户提出的要求超出软件系统可以实现的范围或实现能力； 不同的用户提出了相互冲突的需求 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇27/57 深入描述软件的功能和性能深入描述软件的功能和性能 确定软件设计的约束和软件同其它确定软件设计的约束和软件同其

20、它系统元素的接口细节系统元素的接口细节 定义软件的其它有效性需求定义软件的其它有效性需求厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇28/57 需求分析研究的对象是软件项目的用户需求分析研究的对象是软件项目的用户要求要求 准确地表达被接受的用户要求准确地表达被接受的用户要求 确定被开发软件系统的系统元素确定被开发软件系统的系统元素 将功能和信息结构分配到这些系统元素将功能和信息结构分配到这些系统元素中中厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇29/57 需求分析的任务需求分析的任务就是借助于当前系统的就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解

21、逻辑模型导出目标系统的逻辑模型，解决目标系统的决目标系统的 “做什么做什么” 的问题。的问题。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇30/57 通常软件开发项目是要实现目标系统的通常软件开发项目是要实现目标系统的物理模型物理模型 目标系统的具体物理模型是由它的逻辑目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域模型经实例化，即具体到某个业务领域而得到的而得到的厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇31/57 信息域：包括信息内容、信息流、以及信包括信息内容、信息流、以及信息结构。息结构。 信息内容信息内容表示了单个数据和控制对

22、象，目标软件所有处理的信息集合由它们构成。 例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇32/57 信息流信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出 信息结构信息结构表示了各种数据和控制项的内部组织 数据或控制项将被组织为数据或控制项将被组织为n维表还是树形结构？维表还是树形结构？ 在结构的语境内，什么信息是和其他信息相关的？在结构的语境内，什么信息是和其他信息相关的？ 信息包含在单个结构中，还是使用不同的结构？信

23、息包含在单个结构中，还是使用不同的结构？ 在某信息结构中的信息如何和在另一个结构中的在某信息结构中的信息如何和在另一个结构中的信息相关？信息相关？ 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇33/57厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇34/57【例【例1】假设需要制造一个带有四个按钮和两个灯泡的盒子并具有以】假设需要制造一个带有四个按钮和两个灯泡的盒子并具有以下功能：下功能： 有四个按钮输入，分别称为有四个按钮输入，分别称为B1，B2，B3和和B4； 有两个灯泡作为输出，分别称为有两个灯泡作为输出，分别称为L1和和L2； B1是打开电源的按钮；是

24、打开电源的按钮； B4是关闭电源的按钮；是关闭电源的按钮； B2和和B3 是操作按钮；是操作按钮； 在在B1被按下后及被按下后及B4被按下前，系统应称为电源打开状态；被按下前，系统应称为电源打开状态； 在在B4被按下后及被按下后及B1被按下前，系统应称为电源关闭状态；被按下前，系统应称为电源关闭状态； 在电源关闭状态下，在电源关闭状态下，B2和和B3按钮不起作用；按钮不起作用； 在电源关闭状态下，灯应不亮；在电源关闭状态下，灯应不亮； 从最近一次电源打开状态算起，如果从最近一次电源打开状态算起，如果B2被按下的次数比被按下的次数比B3被被按下的次数多，按下的次数多，L1亮，否则亮，否则L2亮。

25、亮。 任何时候都不能有一个以上的灯泡亮；任何时候都不能有一个以上的灯泡亮； 如果其中的一个灯泡出现故障，另一个灯泡应以如果其中的一个灯泡出现故障，另一个灯泡应以2秒钟的间隔秒钟的间隔闪烁，而不管闪烁，而不管B2和和B3的操作过程。当的操作过程。当B4按下时，闪烁停止；当按下时，闪烁停止；当B1被按下时，闪烁重新开始。当故障被排除后闪烁停止，系统恢复被按下时，闪烁重新开始。当故障被排除后闪烁停止，系统恢复正常状态。正常状态。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇35/57 1. 对于在灯泡出现故障时是否要记录下对于在灯泡出现故障时是否要记录下B2和和B3的操作过程的操作过

26、程 2. 系统记录或不记录系统记录或不记录B2和和B3的操作，对的操作，对于故障排除后系统的反应如何于故障排除后系统的反应如何厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇36/57 问题抽象方法要求分析人员在分析过程中要求分析人员在分析过程中捕捉用户描述或问题本身固有的捕捉用户描述或问题本身固有的一般-特殊关系 首先关注一般问题的解决途径，进而指导首先关注一般问题的解决途径，进而指导特殊问题的解决方法。特殊问题的解决方法。 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇37/57 问题分解的目的是要能以层次化的方式的目的是要能以层次化的方式对问题进行分解和不断

27、细化。对问题进行分解和不断细化。 较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析 分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分 例如横向分解横向分解纵向分解纵向分解厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇38/57 需要能够表达和理解问题的信息域和功能域 要能以层次化的方式对问题进行分解和不断细化 要给出系统的逻辑视图和物理视图厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇39/57厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇40/57 协商的过程就是讨论需求冲突，找出每协商的过程就是讨论需求冲突，找出每个人都

28、满意的折衷方案个人都满意的折衷方案 协商不是简单的逻辑或技术上的争论协商不是简单的逻辑或技术上的争论 要注意组织和行政方面的因素要注意组织和行政方面的因素 不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇41/57 通常会议是解决冲突最快的方式通常会议是解决冲突最快的方式 参加者应该包括发现冲突、遗漏或重叠参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的的分析员，以及可以解决发现的问题的项目相关人员项目相关人员 会议应该讨论那些非正式讨论不能解决会议应该讨论那些非正式讨论不能解决的问题的问

29、题 通常会议分为三个阶段：通常会议分为三个阶段： 叙述阶段 讨论阶段 决策阶段 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇42/57 在软件需求分析阶段，所创建的模型，要在软件需求分析阶段，所创建的模型，要着重于描述系统要着重于描述系统要做什么做什么，而不是，而不是如何去如何去做做 目标软件的模型不应涉及软件实现细节目标软件的模型不应涉及软件实现细节 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇43/57 建模工具的使用在用户和系统分析人员之建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时间建立了统一的语言和理解的桥梁，同时系统分析

30、人员借助建模技术对获取的需求系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。保需求文档正确反映用户的真实意图。 常用的分析和建模方法有面向数据流方法、常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。面向数据结构方法和面向对象的方法。 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇44/57常用的分析方法：常用的分析方法： 面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开发方法 (DSSD) 面向对

31、象的分析方法 (OOA)厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇45/57需求工程概述需求工程概述需求获取需求获取需求分析、协商与建模需求分析、协商与建模需求管理需求管理厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇46/57 软件需求规约是分析任务的最终产物，通软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需适的验收标准，给出对目标软件的各种需求。求。 需求规约作为用户和开发者之间的一个协

32、需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要议，在之后的软件工程各个阶段发挥重要作用。作用。 厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇47/57 1从现实中分离功能，即描述要从现实中分离功能，即描述要“做什做什么么”而不是而不是“怎样实现怎样实现”。 2要求使用面向处理的规约语言（或称要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到一个行为模型，从而得到“做什么做什么”的规约。的规

33、约。 3如果被开发软件只是一个基于计算机如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。在规格说明的描述之中。 4规约必须包括系统运行环境。规约必须包括系统运行环境。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇48/57 5规约必须是一个认识模型，而不是设规约必须是一个认识模型，而不是设计或实现的模型。计或实现的模型。 6规约必须是可操作的，以便能够利用规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。决方

34、案是否都能满足规约。 7规约必须允许不完备性并允许扩充。规约必须允许不完备性并允许扩充。 8规约必须局部化和松散耦合。它所包规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。很容易地加入和删去一些段落。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇49/57. 引言引言 A.系统参考文献系统参考文献B.整体描述整体描述C.软件项

35、目约束软件项目约束. 信息描述信息描述 A.信息内容表示信息内容表示B.信息流表示：信息流表示： 数据流数据流 控制流控制流. 功能描述功能描述 A.功能划分功能划分 B.功能描述：功能描述： 处理说明处理说明 限制限制局限局限 性能需求性能需求 设计约束设计约束 支撑图支撑图 C.控制描述控制描述 控制规约控制规约 设计约设计约束束. 行为描述行为描述 A.系统状态系统状态 B.事件和响应事件和响应. 检验标准检验标准 A.性能范围性能范围B.测试种类测试种类C.期望的软件响应期望的软件响应D.特殊的考虑特殊的考虑. 参考书目参考书目. 附录附录厦门理工学院应用数学学院厦门理工学院应用数学学

36、院 胡航宇胡航宇50/57引言：陈述软件目标，在基于计算机的系统语境内：陈述软件目标，在基于计算机的系统语境内进行描述。进行描述。信息描述：给出软件必须解决问题的详细描述，记：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。录信息内容和关系、流和结构。功能描述：描述解决问题所需的每个功能。其中包：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互件的整体结构和软件功能与其他系

37、统元素间的相互影响。影响。行为描述：描述作为外部事件和内部产生的控制特：描述作为外部事件和内部产生的控制特征的软件操作。征的软件操作。检验标准：描述检验系统成功的标志。即对系统进：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是已经成功实现了。它是“确认测试确认测试”的基础。的基础。参考书目：包含了对所有和该软件相关的文档的引：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。厂商文献以及标准。附录：包含了规约的补充信息，表格数据、算法的：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。详细描述、图表以及其他材料。厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇51/57n 软件需求说明书软件需求说明书n 数据要求说明书数据要求说明书n 初步的用户手册初步的用户手册n 修改、完善与确定软件开发实施计划修改、完善与确定软件开发实施计划厦门理工学院应用数学学院厦门理工学院应用数学学院 胡航宇胡航宇52