第3章需求工程与需求分析

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

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

3、色的产品，同时会使客户感到满能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础。程和项目管理的基础。第3章 需求工程与需求分析53.1.1 软件需求的定义软件需求的定义 用户解决问题或达到目标所需的条件用户解决问题或达到目标所需的条件或权能（或权能（CapabilityCapability）。）。 系统或系统部件要满足合同、标准、系统或系统部件要满足

4、合同、标准、规范或其它正式规定文档所需具有的条规范或其它正式规定文档所需具有的条件或权能。件或权能。 一种反映上面一种反映上面或或所描述的条件或所描述的条件或权能的文档说明。权能的文档说明。第3章 需求工程与需求分析63.1.1 软件需求的定义软件需求的定义1. 一些关于一些关于“需求需求”的解释的解释 需求的关键的问题是一定要编写需求文档。需求的关键的问题是一定要编写需求文档。 如果只有一堆邮件、贴条、会谈过几次或一些零碎的如果只有一堆邮件、贴条、会谈过几次或一些零碎的对话，你就确信你已明白用户的需求，那完全是自欺对话，你就确信你已明白用户的需求，那完全是自欺欺人。欺人。 许多的需求分析专家

5、给出了不同形式的需求定义，但许多的需求分析专家给出了不同形式的需求定义，但从这些不同形式的定义不难发现：并没有一个清晰、从这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的毫无二义性的“需求需求”术语存在，真正的术语存在，真正的“需求需求”实实际上在人们的脑海中。任何文档形式的需求（例如：际上在人们的脑海中。任何文档形式的需求（例如：需求规格说明）仅是一个模型，一种叙述（需求规格说明）仅是一个模型，一种叙述（Lawrence 1998）。我们需要确保所有项目风险承担者在描述需）。我们需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。求的那些名词的理解上务必达成共识。第3

6、章 需求工程与需求分析73.1.1 软件需求的定义软件需求的定义 2需求的层次需求的层次 下面这些定义是需求工程领域中常见术语的定义说明。下面这些定义是需求工程领域中常见术语的定义说明。 软件需求包括三个不同的层次软件需求包括三个不同的层次业务需求、用户需求和功能需业务需求、用户需求和功能需求（包括非功能需求）。求（包括非功能需求）。 业务需求（业务需求（business requirement）反映了组织机构或客户对系）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。说明。 用户需求（用户需求（us

7、er requirement）文档描述了用户使用产品必须要）文档描述了用户使用产品必须要完成的任务，这在使用实例（完成的任务，这在使用实例（use case）文档或方案脚本）文档或方案脚本（scenario）说明中予以说明。）说明中予以说明。 功能需求功能需求(functional requirement)定义了开发人员必须实现的软定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满

8、足业务需求。供处理能力并满足业务需求。 第3章 需求工程与需求分析83.1.1 软件需求的定义软件需求的定义第3章 需求工程与需求分析93.1.2 需求的开发和管理需求的开发和管理 需求中名词术语的混淆将导致对科目（规范，需求中名词术语的混淆将导致对科目（规范，discipline）叫法的不一致。一些作者把整个需）叫法的不一致。一些作者把整个需求范围称之为求范围称之为“需求工程需求工程”，另一些则称之为，另一些则称之为“需求管理需求管理”。 软件专家认为可把整个软件需求工程研究领域软件专家认为可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适：划分为需求开发和需求管理两部分更合适

9、：第3章 需求工程与需求分析103.1.2 需求的开发和管理需求的开发和管理 需求开发可进一步分为：需求获取需求开发可进一步分为：需求获取(elicitation)、分析分析(analysis)、编写规格说明、编写规格说明(specification)和和验证验证(verification)四个阶段。四个阶段。 需求开发活动包括以下几个方面：需求开发活动包括以下几个方面： 确定产品所期望的用户类。确定产品所期望的用户类。 获取每个用户类的需求。获取每个用户类的需求。 了解实际用户任务和目标以及这些任务所支了解实际用户任务和目标以及这些任务所支持的业务需求。持的业务需求。 分析源于用户的信息以区

10、别用户任务需求、分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方功能需求、业务规则、质量属性、建议解决方法和附加信息。法和附加信息。第3章 需求工程与需求分析113.1.2 需求的开发和管理需求的开发和管理 将系统级的需求分为几个子系统，并将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。将需求中的一部份分配给软件组件。 了解相关质量属性的重要性。了解相关质量属性的重要性。 商讨实施优先级的划分。商讨实施优先级的划分。 将所收集的用户需求编写成规格说明将所收集的用户需求编写成规格说明和模型。和模型。 评审需求规格说明，确保对用户需求评审需求规格说明，

11、确保对用户需求达到共同的理解与认识，并在整个开发达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。小组接受说明之前将问题都弄清楚。第3章 需求工程与需求分析123.1.2 需求的开发和管理需求的开发和管理 需求管理需要需求管理需要“建立并维护在软件工程中同客户达成的契建立并维护在软件工程中同客户达成的契约约”(CMU/SEI 1995)。这种契约都包含在编写的需求规格说明与。这种契约都包含在编写的需求规格说明与模型中。模型中。 通常的需求管理活动包括：通常的需求管理活动包括： 定义需求基线（迅速制定需求文档的主体）。定义需求基线（迅速制定需求文档的主体）。 评审提出的需求变更、

12、评估每项变更的可能影响从而决定是否评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。实施它。 以一种可控制的方式将需求变更融入到项目中。以一种可控制的方式将需求变更融入到项目中。 使当前的项目计划与需求一致。使当前的项目计划与需求一致。 估计变更需求所产生影响并在此基础上协商新的承诺估计变更需求所产生影响并在此基础上协商新的承诺(约定约定)。 让每项需求都能与其对应的设计、源代码和测试用例联系起来让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。以实现跟踪。 在整个项目过程中跟踪需求状态及其变更情况。在整个项目过程中跟踪需求状态及其变更情况。第3章 需求工程与需求分

13、析133.1.2 需求的开发和管理需求的开发和管理l需求开发和需求管理之间的区别需求开发和需求管理之间的区别第3章 需求工程与需求分析143.1.3 需求工程的作用需求工程的作用 1支持项目的开发。支持项目的开发。 需求工程过程是软件开发阶段的前提和基础。需求工程过程是软件开发阶段的前提和基础。 2支持测试和验证支持测试和验证 需求规格说明书将为项目测试和验证提供基准，可以用来检查设计和验需求规格说明书将为项目测试和验证提供基准，可以用来检查设计和验证系统。证系统。 3支持维护支持维护 维护阶段的工作同以下几个方面紧密联系：维护阶段的工作同以下几个方面紧密联系： 修改在测试阶段中尚未检查出来的

14、少量残留编码错误。修改在测试阶段中尚未检查出来的少量残留编码错误。 软件运行一段时间后，因环境因素的改变而产生的软件的适应性维护。软件运行一段时间后，因环境因素的改变而产生的软件的适应性维护。 用户在软件交付使用后又重新提出扩充功能的需求时的软件维护。用户在软件交付使用后又重新提出扩充功能的需求时的软件维护。 4支持项目承包商支持项目承包商 需求的证实过程为拟构造系统的正确性提供了进一步的根据。需求的证实过程为拟构造系统的正确性提供了进一步的根据。 5支持管理支持管理 为了保证项目的顺利进行，项目管理者必须有一个完备的项目计划，包为了保证项目的顺利进行，项目管理者必须有一个完备的项目计划，包括

15、开销、交付日期、可用资源、交付条件等等。括开销、交付日期、可用资源、交付条件等等。第3章 需求工程与需求分析153.2 需求获取需求获取第3章 需求工程与需求分析163.2.1 需求获取过程需求获取过程 需求获取时期的主要工作：需求获取时期的主要工作： 归纳和整理用户提出的各种问题和要归纳和整理用户提出的各种问题和要求；求； 弄清用户企图通过软件达到的目的；弄清用户企图通过软件达到的目的； 借助各种工具和方法，陈述用户提出借助各种工具和方法，陈述用户提出的实际需求，并标定软件的作用范围。的实际需求，并标定软件的作用范围。第3章 需求工程与需求分析173.2.2 需求获取方法需求获取方法 需求获

16、取方法包括两个方面：需求获取方法包括两个方面： 指导开发小组获取用户需求的方法框架。指导开发小组获取用户需求的方法框架。 支持控制此项活动进展的过程控制机制。支持控制此项活动进展的过程控制机制。第3章 需求工程与需求分析183.2.3 当前状况当前状况 误解：由于分析员并非该应用领域的专家，使得在需求获取时，误解了误解：由于分析员并非该应用领域的专家，使得在需求获取时，误解了用户潜在的隐含假设。用户潜在的隐含假设。 交流障碍：领域专家同一个新手交谈时的用词往往并不足以解决问题。交流障碍：领域专家同一个新手交谈时的用词往往并不足以解决问题。 缺乏共同语言：由于需求分析员和系统用户的经历和教育背景

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

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

19、标是系统应达到的更为一般的特征，而需求应是可测试的。到的更为一般的特征，而需求应是可测试的。第3章 需求工程与需求分析19解决问题的建议解决问题的建议 1. 了解系统需求了解系统需求 2. 市场调查市场调查 3. 访问用户和用户领域专家访问用户和用户领域专家 4. 考察现场考察现场第3章 需求工程与需求分析20调查的方式调查的方式 1. 调查提纲或调查表调查提纲或调查表 2. 小型调查会议小型调查会议 3. 个别访问个别访问 4. 现场调查现场调查 5. 资料资料 6. 调查工具调查工具第3章 需求工程与需求分析21调查中应注意的事项调查中应注意的事项 1. 不要用计算机专业术语与用户或用户领

20、不要用计算机专业术语与用户或用户领域专家交谈域专家交谈 2. 不要使用不要使用“你应该你应该”这样的字眼这样的字眼 3. 始终记住自己最近一段工作中要达到的始终记住自己最近一段工作中要达到的目标，引导用户说出你需要的信息目标，引导用户说出你需要的信息 4. 要善于把用户中职位高的人和职位低的要善于把用户中职位高的人和职位低的人的谈话结合起来分析人的谈话结合起来分析第3章 需求工程与需求分析223.3 需求分析任务需求分析任务第3章 需求工程与需求分析233.3 需求分析任务需求分析任务 需求分析所要做的工作是深入描述软件的需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件

21、同功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它其它系统元素的接口细节，定义软件的其它有效性需求。有效性需求。 分析员通过需求分析，逐步细化对软件的分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质后，制定的软件规格说明还要为评价软件质量提供依据。量提供依据。第3章 需求工程与需求分析243.3 需求分析任务需求分析

22、任务 正确地确定对系统综合要求，充分理解和表达用户的需求。正确地确定对系统综合要求，充分理解和表达用户的需求。 也就是详细定义开发软件的功能、性能、外部接口、设计限制、也就是详细定义开发软件的功能、性能、外部接口、设计限制、数据库需求、确定硬件和软件支持环境、辅助软件以及将来可能数据库需求、确定硬件和软件支持环境、辅助软件以及将来可能提出的要求。提出的要求。 通过结构分析的方法对系统进行分解，以确定软件系统的主要通过结构分析的方法对系统进行分解，以确定软件系统的主要成分或软件系统的构成。成分或软件系统的构成。第3章 需求工程与需求分析253.3 需求分析任务需求分析任务 是对以上已进行的两项工

23、作进行描述，以形是对以上已进行的两项工作进行描述，以形成需求文档，也就是编制成需求文档，也就是编制“需求规格说明书需求规格说明书”。它应明确地定义要开发软件的需求；系统的构它应明确地定义要开发软件的需求；系统的构成及有关接口。成及有关接口。 需求规格说明书的作用在于：需求规格说明书的作用在于： 提供一个用户和开发者对开发软件的共同的提供一个用户和开发者对开发软件的共同的理解；理解； 相当于用户和开发单位之间的一份技术合同；相当于用户和开发单位之间的一份技术合同； 是今后各阶段设计的基本依据；是今后各阶段设计的基本依据； 是今后验收测试阶段对软件进行确认和验收是今后验收测试阶段对软件进行确认和验

24、收的基准。的基准。第3章 需求工程与需求分析263.3 需求分析任务需求分析任务 编写用户手册概要，迫使分析员从用户的角度看待编写用户手册概要，迫使分析员从用户的角度看待软件，及早考虑用户界面工作，此时编写的重点在系软件，及早考虑用户界面工作，此时编写的重点在系统输入和输出。统输入和输出。 把整个软件系统分解为若干个子系统或软件成分把整个软件系统分解为若干个子系统或软件成分(如软如软件包件包)，把整个软件的外部功能分配给软件系统的各功，把整个软件的外部功能分配给软件系统的各功能成分，并详细地定义每个软件成分的外部功能以及能成分，并详细地定义每个软件成分的外部功能以及它们间的接口。它们间的接口。

25、 编写验收计划，作为今后验收测试的依据。编写验收计划，作为今后验收测试的依据。 修正可行性研究阶段所制订的软件项目开发计划。修正可行性研究阶段所制订的软件项目开发计划。由于在需求分析过程中对将要开发的系统有了更深入由于在需求分析过程中对将要开发的系统有了更深入的了解，所以可以更准确地估计开发成本、进度和资的了解，所以可以更准确地估计开发成本、进度和资源需求。有必要对原计划作出适当修正。源需求。有必要对原计划作出适当修正。第3章 需求工程与需求分析273.4 需求分析过程需求分析过程第3章 需求工程与需求分析283.4.1 功能性需求功能性需求 功能性需求包括：功能性需求包括： 1功能需求功能需

26、求 例举出开发软件在职能上应做什么，这是最主要的需例举出开发软件在职能上应做什么，这是最主要的需求。求。 2性能需求性能需求 给出所开发软件的技术性能指标，包括存储容量限制、给出所开发软件的技术性能指标，包括存储容量限制、运行时间限制、安全保密性等。运行时间限制、安全保密性等。 3环境需求环境需求 软件系统运行时多所处的环境要求。软件系统运行时多所处的环境要求。 4可靠性需求可靠性需求 各种软件在运行时，失败的影响各不相同，在需求分各种软件在运行时，失败的影响各不相同，在需求分析时，应对所开发的软件在投入运行后不发生故障的析时，应对所开发的软件在投入运行后不发生故障的概率，按实际的运行环境提出

27、的要求。概率，按实际的运行环境提出的要求。第3章 需求工程与需求分析293.4.1 功能性需求功能性需求 5安全保密要求安全保密要求 把软件运行的安全需求恰当地做出规定，以便对所开发的软件给把软件运行的安全需求恰当地做出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全保密方面的性能得到必要的予特殊的设计，使其在运行中其安全保密方面的性能得到必要的保证。保证。 6用户界面需求用户界面需求 软件与用户界面的友好性是用户能够方便有效、愉快地使用该软软件与用户界面的友好性是用户能够方便有效、愉快地使用该软件的关键之一。件的关键之一。 7资源使用需求资源使用需求 开发软件运行时所需的数据、软件

28、、内存空间等各项资源。开发软件运行时所需的数据、软件、内存空间等各项资源。 8软件成本消耗与开发进度需求软件成本消耗与开发进度需求 软件项目立项后，要根据合同规定，对软件开发的进度和各项步软件项目立项后，要根据合同规定，对软件开发的进度和各项步骤的费用提出要求，作为开发管理的依据。骤的费用提出要求，作为开发管理的依据。 9预先估计系统可能达到的目标预先估计系统可能达到的目标 在开发过程中可对系统将来可能的扩充与修改做准备。在开发过程中可对系统将来可能的扩充与修改做准备。第3章 需求工程与需求分析30【例【例1】假设需要制造一个带有四个按钮和两个灯泡的盒子并具有以下功能：】假设需要制造一个带有四

29、个按钮和两个灯泡的盒子并具有以下功能： 有四个按钮输入，分别称为有四个按钮输入，分别称为B1，B2，B3和和B4； 有两个灯泡作为输出，分别称为有两个灯泡作为输出，分别称为L1和和L2； B1是打开电源的按钮；是打开电源的按钮； B4是关闭电源的按钮；是关闭电源的按钮； B2和和B3 是操作按钮；是操作按钮； 在在B1被按下后及被按下后及B4被按下前，系统应称为电源打开状态；被按下前，系统应称为电源打开状态； 在在B4被按下后及被按下后及B1被按下前，系统应称为电源关闭状态；被按下前，系统应称为电源关闭状态； 在电源关闭状态下，在电源关闭状态下，B2和和B3按钮不起作用；按钮不起作用； 在电源

30、关闭状态下，灯应不亮；在电源关闭状态下，灯应不亮； 从最近一次电源打开状态算起，如果从最近一次电源打开状态算起，如果B2被按下的次数比被按下的次数比B3被按下的次被按下的次数多，数多，L1亮，否则亮，否则L2亮。亮。 任何时候都不能有一个以上的灯泡亮；任何时候都不能有一个以上的灯泡亮； 如果其中的一个灯泡出现故障，另一个灯泡应以如果其中的一个灯泡出现故障，另一个灯泡应以2秒钟的间隔闪烁，而秒钟的间隔闪烁，而不管不管B2和和B3的操作过程。当的操作过程。当B4按下时，闪烁停止；当按下时，闪烁停止；当B1被按下时，闪被按下时，闪烁重新开始。当故障被排除后闪烁停止，系统恢复正常状态。烁重新开始。当故

31、障被排除后闪烁停止，系统恢复正常状态。第3章 需求工程与需求分析31疑问？疑问？ 1. 对于在灯泡出现故障时是否要记录下对于在灯泡出现故障时是否要记录下B2和和B3的操作过程的操作过程 2. 系统记录或不记录系统记录或不记录B2和和B3的操作，对的操作，对于故障排除后系统的反应如何于故障排除后系统的反应如何第3章 需求工程与需求分析323.4.2 非功能性需求非功能性需求 非功能性需求即为软件的非功能性需求即为软件的“约束约束”:非功能性需求非功能性需求过程需求过程需求产品需求产品需求外部需求外部需求交付需求交付需求实现方法需求实现方法需求标准需求标准需求可用性需求可用性需求效用需求效用需求可

32、靠性需求可靠性需求可移植性需求可移植性需求可重复需求可重复需求安全保密性需求安全保密性需求性能需求性能需求应用需求应用需求法规需求法规需求费用需求费用需求互操作需求互操作需求第3章 需求工程与需求分析333.4.3 需求分析文档需求分析文档 1需求规格说明书的作用需求规格说明书的作用 为用户、分析人员和软件设计人员之间的理为用户、分析人员和软件设计人员之间的理解和交流提供了方便；解和交流提供了方便； 支持目标软件系统的确认；支持目标软件系统的确认； 起到控制系统演进的作用。起到控制系统演进的作用。 2什么样人阅读需求规格说明书什么样人阅读需求规格说明书 必须阅读需求规格说明书的是各种背景和技术

33、必须阅读需求规格说明书的是各种背景和技术能力都不同的人：客户和使用者，分析人，设能力都不同的人：客户和使用者，分析人，设计师和工程师，项目管理者等。计师和工程师，项目管理者等。第3章 需求工程与需求分析343.4.3 需求分析文档需求分析文档3需求规格说明书编写分类需求规格说明书编写分类 按方法分类：形式化方法和非形式化方法按方法分类：形式化方法和非形式化方法非形式化的需求规格说明书是用自然语言写的，可以用图表和其非形式化的需求规格说明书是用自然语言写的，可以用图表和其 他符号帮助理解，也可以用标准化的格式来编制。他符号帮助理解，也可以用标准化的格式来编制。形式化的需求规格说明书是用完全精确的

34、语法和语义来表达。形式化的需求规格说明书是用完全精确的语法和语义来表达。半形式化的需求规格说明书也很有用。它采用了一些符号，但对半形式化的需求规格说明书也很有用。它采用了一些符号，但对这些符号并没有给予精确的定义。这些符号并没有给予精确的定义。 按文档内容的性质分类：操作性和说明性按文档内容的性质分类：操作性和说明性操作性的需求规格说明书通过说明所要求的行为来描述要求哪种操作性的需求规格说明书通过说明所要求的行为来描述要求哪种系统，通常提供一个系统模型作为模拟系统行为的抽象装置。系统，通常提供一个系统模型作为模拟系统行为的抽象装置。说明性的需求规格说明书用纯粹的说明方式来描述系统的特性。说明性

35、的需求规格说明书用纯粹的说明方式来描述系统的特性。第3章 需求工程与需求分析353.4.3 需求分析文档需求分析文档 4需求规格说明书主要内容：需求规格说明书主要内容： 概述。从系统的角度描述软件的目标和任务。概述。从系统的角度描述软件的目标和任务。 数据描述数据描述 数据流图数据流图 数据字典数据字典 系统接口说明系统接口说明 内部接口说明内部接口说明 功能描述功能描述 功能功能 处理处理 设计的限制设计的限制第3章 需求工程与需求分析363.4.3 需求分析文档需求分析文档 性能描述性能描述 性能指标性能指标 测试种类测试种类 预期的软件响应性能预期的软件响应性能 其它其它 参考文献目录参

36、考文献目录 附录附录第3章 需求工程与需求分析373.5 验证验证第3章 需求工程与需求分析383.5.1 需求说明的特征需求说明的特征 1. 完整性完整性 每一项需求都必须将所要实现的功能描述清楚，以使每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信开发人员获得设计和实现这些功能所需的所有必要信息。息。 2. 正确性正确性 每一项需求都必须准确地陈述其要开发的功能。做出每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵

37、触需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：用户参与的需求评审将导致此类说法：“那些毫无意那些毫无意义，这些才很可能是他们所要想的。义，这些才很可能是他们所要想的。”其实这完全是其实这完全是评审者凭空猜测。评审者凭空猜测。第3章 需求工程与需求分析393.5.1 需求说明的特征需求说明的特征 3. 可行性可行性 每一项需求都必须是在已知系统和环境的权能和限制每一项需求都必须是

38、在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获范围内可以实施的。为避免不可行的需求，最好在获取（取（elicitation）需求）需求(收集需求收集需求)过程中始终有一位软过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。在一起工作，由他负责检查技术可行性。 4. 必要性必要性 每一项需求都应把客户真正所需要的和最终系统所需每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。遵从的标准记录下来。“必要性必要性”也可以理解为每项也可以理解为每项需求都是用来授权

39、你编写文档的需求都是用来授权你编写文档的“根源根源”。要使每项。要使每项需求都能回溯至某项客户的输入，如使用实例或别的需求都能回溯至某项客户的输入，如使用实例或别的来源。来源。第3章 需求工程与需求分析403.5.1 需求说明的特征需求说明的特征 5. 可修改性可修改性 在必要时或为维护每一需求变更历史记录时，应该修在必要时或为维护每一需求变更历史记录时，应该修订订SRS。这就要求每项需求要独立标出，并与别的需。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在求区别开来，从而无二义性。每项需求只应在SRS中中出现一次。这样更改时易于保持一致性。另外，使用出现一次。

40、这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。说明更容易修改。 6. 可跟踪性可跟踪性 应能在每项软件需求与它的根源和设计元素、源代码、应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（需求以一种结构化的，粒度好（fine-grained）的方式）的方式编写并单独标明，而不是大段大段的叙述。编写并单独标明，而不是大段大段的叙述。第3章 需求工程与需求分析413.5.1 需求说明的特

41、征需求说明的特征 7. 划分优先级划分优先级 给每项需求、特性或使用实例分配一个实施优先级以指明它在特定给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。管理者在开发或节省预算或调度中就丧失控制自由度。 8. 无二义性无二义性 对所有需求说明的读者都只能有一个明确统一的解释，由于自然语对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言极易导致二义性，所以尽量

42、把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需言表达出来。避免二义性的有效方法包括对需 求文档的正规审查，求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。编写测试用例，开发原型以及设计特定的方案脚本。 9. 可验证性可验证性 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。验证，则确定其实施是否正确就成为主观臆断，

43、而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。一份前后矛盾，不可行或有二义性的需求也是不可验证的。第3章 需求工程与需求分析423.6 软件原型系统开发软件原型系统开发第3章 需求工程与需求分析43传统模型的工作特点传统模型的工作特点 传统软件生存期模型的典型代表是传统软件生存期模型的典型代表是“瀑布模瀑布模型型”。这种模型将软件生存期划分为若干阶段，。这种模型将软件生存期划分为若干阶段，根据不同阶段的工作特点，运用不同的方法、根据不同阶段的工作特点，运用不同的方法、技术和工具来完成该阶段的任务。技术和工具来完成该阶段的任务。 传统思想之所以强调每一阶段的严格性，尤其传统

44、思想之所以强调每一阶段的严格性，尤其是开发初期要有良好的软件说明，主要是源于是开发初期要有良好的软件说明，主要是源于过去软件开发的经验教训，即在开发的后期或过去软件开发的经验教训，即在开发的后期或运行维护期间，修改不完善的规格说明要付出运行维护期间，修改不完善的规格说明要付出巨大的代价。巨大的代价。 第3章 需求工程与需求分析44什么是原型系统开发什么是原型系统开发 建立系统模型以后，还要进行检查。建立系统模型以后，还要进行检查。除了静态检查外，系统描述可以部除了静态检查外，系统描述可以部分地模拟执行，将执行情况与对外分地模拟执行，将执行情况与对外部现实世界系统观察得到的系统跟部现实世界系统观

45、察得到的系统跟踪信息进行对照，检查模型是否符踪信息进行对照，检查模型是否符合要求。这种建立系统模型并模拟合要求。这种建立系统模型并模拟执行和检查的办法叫做系统原型开执行和检查的办法叫做系统原型开发。发。 第3章 需求工程与需求分析45软件系统的快速原型的概念的形成软件系统的快速原型的概念的形成 在实际工作中，特别是对于一些大型的软件项在实际工作中，特别是对于一些大型的软件项目，在开发的早期用户往往对系统只有一个模目，在开发的早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面糊的想法，很难完全准确地表达对系统的全面要求，软件人员对于要解决的应用问题认识更要求，软件人员对于要解决

46、的应用问题认识更是模糊不清。是模糊不清。 随着开发工作向前推进，用户可能产生新的要随着开发工作向前推进，用户可能产生新的要求，或因环境变化，要求系统也随之变化；开求，或因环境变化，要求系统也随之变化；开发者又可能在设计与实现的过程中遇到一些没发者又可能在设计与实现的过程中遇到一些没有预料到的困难，需要以改变需求来解脱困境。有预料到的困难，需要以改变需求来解脱困境。第3章 需求工程与需求分析463.6.1 软件原型化方法概述软件原型化方法概述 通常，原型是指模拟某种产品的原始模通常，原型是指模拟某种产品的原始模型。在软件开发过程中，原型是软件一型。在软件开发过程中，原型是软件一个早期可运行的版本

47、，它反映最终系统个早期可运行的版本，它反映最终系统的部分重要特性。的部分重要特性。 系统原型是软件系统的初始版本，它可系统原型是软件系统的初始版本，它可用来展示一些概念，给出设计选择、发用来展示一些概念，给出设计选择、发现问题和可能的解决方案。其目的就是现问题和可能的解决方案。其目的就是为了有效的控制开发成本，使开发人员为了有效的控制开发成本，使开发人员可以较早地在原型系统上验证自己的设可以较早地在原型系统上验证自己的设计。计。第3章 需求工程与需求分析47软件原型支持需求工程过程的活动软件原型支持需求工程过程的活动 1.需求的导出需求的导出 系统原型允许用户在上面实验，以便了解系统系统原型允

48、许用户在上面实验，以便了解系统如何支持他们的工作的。在这个过程中，用户如何支持他们的工作的。在这个过程中，用户可能产生有关需求的许多新的想法，同时发现可能产生有关需求的许多新的想法，同时发现系统的优点和不足，进而提出新的系统需求。系统的优点和不足，进而提出新的系统需求。 2.需求的有效性验证需求的有效性验证 原型系统可以暴露出错误和遗漏的东西。一原型系统可以暴露出错误和遗漏的东西。一个经过描述的功能可能是很有用且已经是定义个经过描述的功能可能是很有用且已经是定义了的，但是，当这个功能模块与其他模块一起了的，但是，当这个功能模块与其他模块一起工作时，用户可能发现他们最初的想法是错误工作时，用户可

49、能发现他们最初的想法是错误的或是不完善的，必须修改系统描述以反映对的或是不完善的，必须修改系统描述以反映对需求的新的理解。需求的新的理解。第3章 需求工程与需求分析48系统原型开发的优点系统原型开发的优点 1.开发人员和用户之间的理解偏差在功能开发人员和用户之间的理解偏差在功能展示显露出来。展示显露出来。 2.开发小组可能会在原型设计中发现需求开发小组可能会在原型设计中发现需求的不完善和不一致。的不完善和不一致。 3.可以迅速展示一个应用系统对管理的可可以迅速展示一个应用系统对管理的可行性和作用。行性和作用。 4.原型可以用作书写产量原型可以用作书写产量-质量系统描述的质量系统描述的基础。基础

50、。 5.原型可支持用户的训练和系统的测试。原型可支持用户的训练和系统的测试。第3章 需求工程与需求分析49原型开发的过程模型原型开发的过程模型第3章 需求工程与需求分析50研究发现系统原型开发的其它优点研究发现系统原型开发的其它优点 Gordon和和Bieman经过研究发现，在软件过程经过研究发现，在软件过程中使用原型还具有如下的优点：中使用原型还具有如下的优点： 1.提高了系统的实用性。提高了系统的实用性。 2.使系统与用户需求更贴近。使系统与用户需求更贴近。 3.提高了系统的设计质量。提高了系统的设计质量。 4.提高了系统的可维护性。提高了系统的可维护性。 5.减少了开发的投入。减少了开发

51、的投入。 研究发现，用原型法来提高系统的实用性和研究发现，用原型法来提高系统的实用性和更好地满足用户需求并不一定意味着开发成本更好地满足用户需求并不一定意味着开发成本提高。提高。第3章 需求工程与需求分析513.6.2 软件过程中的原型开发软件过程中的原型开发 原型开发的种类有两种：原型开发的种类有两种： 1.进化式原型进化式原型 采用进化式的系统开发方法，就是在系统尚未采用进化式的系统开发方法，就是在系统尚未完善的时候就呈现给用户，边修改边完善，在完善的时候就呈现给用户，边修改边完善，在完善过程中逐渐地把需求弄明白。完善过程中逐渐地把需求弄明白。 2.抛弃式原型抛弃式原型 采用原型开发方法进

52、行需求分析和有效性验证，采用原型开发方法进行需求分析和有效性验证，评估一结束，就抛弃掉原型，重建一个完整的评估一结束，就抛弃掉原型，重建一个完整的系统。系统。第3章 需求工程与需求分析52两点重要区别两点重要区别 1.进化式原型的目标是给用户一个实用的进化式原型的目标是给用户一个实用的系统。原型开发必须从对用户需求把握系统。原型开发必须从对用户需求把握最准的部分做起，最优处理这部分。而最准的部分做起，最优处理这部分。而对用户需求把握程度较差的部分和模糊对用户需求把握程度较差的部分和模糊的需求安排得稍后一些，可以在用户明的需求安排得稍后一些，可以在用户明确要求后再处理。确要求后再处理。 2.抛弃

53、式原型开发的目标是验证和导出需抛弃式原型开发的目标是验证和导出需求。此时应从理解得不够好的那部分需求。此时应从理解得不够好的那部分需求开始实现，因为要从目标中发现问题，求开始实现，因为要从目标中发现问题，对明确的需求就没必要去做原型。对明确的需求就没必要去做原型。第3章 需求工程与需求分析53进化式原型开发进化式原型开发 进化式原型开发的思路是：先给出一个进化式原型开发的思路是：先给出一个系统的最初实现，让用户去使用和评论，系统的最初实现，让用户去使用和评论，再不断进行细化和完善，经过多个这样再不断进行细化和完善，经过多个这样的反复过程后形成最后完善的应用系统。的反复过程后形成最后完善的应用系

54、统。 进化式开发已经成为快速应用开发进化式开发已经成为快速应用开发(RAD)和联合应用开发和联合应用开发(JAD)技术中的一部分技术中的一部分,已成为一个软件开发的主流技术。已成为一个软件开发的主流技术。第3章 需求工程与需求分析54进化式原型开发进化式原型开发第3章 需求工程与需求分析55进化式原型开发方法的优势进化式原型开发方法的优势 1.加快系统交付的进度加快系统交付的进度 现在的商业节奏加快意味着软件支持能否快速现在的商业节奏加快意味着软件支持能否快速到位是最根本的。在某些情况下，快速交货就到位是最根本的。在某些情况下，快速交货就比提供完备功能或保证长期可维护性更为重要。比提供完备功能

55、或保证长期可维护性更为重要。 2.用户的参与用户的参与 用户在软件开发过程中的介入不仅仅意味着系用户在软件开发过程中的介入不仅仅意味着系统可以更好地理解软件需求，还意味着可以使统可以更好地理解软件需求，还意味着可以使用户逐渐喜欢系统，在工作中依赖它。用户逐渐喜欢系统，在工作中依赖它。第3章 需求工程与需求分析56进化式原型开法与快速开发方法的共同基本性质进化式原型开法与快速开发方法的共同基本性质 1.描述、设计和实现三个过程是交叉进行的描述、设计和实现三个过程是交叉进行的 ，没有详细的系统描述，设计文档一般都依赖于没有详细的系统描述，设计文档一般都依赖于开发系统所使用的工具，用户需求文档只描述

56、开发系统所使用的工具，用户需求文档只描述系统的最重要的特征。系统的最重要的特征。 2.系统是逐渐增进的。在每一次增进过程中，最系统是逐渐增进的。在每一次增进过程中，最终用户和其他系统项目的相关人员都参与到设终用户和其他系统项目的相关人员都参与到设计和评估中来。他们可能提出对系统改进的意计和评估中来。他们可能提出对系统改进的意见。新的需求又会在随后的版本中被实现。见。新的需求又会在随后的版本中被实现。 3.采用了快速开发技术。采用了快速开发技术。 4.系统用户界面都是交互式开发系统来实现的。系统用户界面都是交互式开发系统来实现的。第3章 需求工程与需求分析57进化式原型开发方法应注意的问题进化式

57、原型开发方法应注意的问题 1.管理问题管理问题 大型系统软件管理机构建立起来以处理软件过程模型。大型系统软件管理机构建立起来以处理软件过程模型。软件过程模型定期产生可交付的文档来评估项目进展软件过程模型定期产生可交付的文档来评估项目进展的情况。原型的开发太快，以致产生大量的系统文档。的情况。原型的开发太快，以致产生大量的系统文档。 专业技术技能不可能应用到每个开发的团队。专业技术技能不可能应用到每个开发的团队。 2.维护问题维护问题 连续不断地对原型的修改很可能导致系统的崩溃。连续不断地对原型的修改很可能导致系统的崩溃。 如果快速原型开发中使用了某项专门的技术，有可能如果快速原型开发中使用了某

58、项专门的技术，有可能在以后寻找具有相关知识的人来维护系统变得十分困在以后寻找具有相关知识的人来维护系统变得十分困难。难。 3.契约问题契约问题 客户和软件开发商之间正规的契约模型是基于系统描客户和软件开发商之间正规的契约模型是基于系统描述的。述的。第3章 需求工程与需求分析58增量开发方法增量开发方法 该开发方法避免了进化式原型开发中的该开发方法避免了进化式原型开发中的经常性变更问题。即首先建立一个总的经常性变更问题。即首先建立一个总的框架，以后就以该框架结构为基础进行框架，以后就以该框架结构为基础进行开发。开发。 在增量开发方法中，必须给出每一部分在增量开发方法中，必须给出每一部分的需求和文

59、档。使得用户的意见能及时的需求和文档。使得用户的意见能及时地反馈，以减少错误的出现。地反馈，以减少错误的出现。第3章 需求工程与需求分析59增量开发方法增量开发方法第3章 需求工程与需求分析60抛弃式原型开发抛弃式原型开发 抛弃式原型开发的根本作用是弄清楚需抛弃式原型开发的根本作用是弄清楚需求和为管理人员评估过程风险提供额外求和为管理人员评估过程风险提供额外的信息。的信息。 在抛弃式原型开发中，我们只注重其功在抛弃式原型开发中，我们只注重其功能，而忽略其质量标准和性能指标，使能，而忽略其质量标准和性能指标，使这些功能经过原型设计而得到深刻理解。这些功能经过原型设计而得到深刻理解。 经过评估，原

60、型被抛弃，不再作为系统经过评估，原型被抛弃，不再作为系统开发的基础。其原型开发和最终系统开开发的基础。其原型开发和最终系统开发使用的语言也往往不一样。发使用的语言也往往不一样。第3章 需求工程与需求分析61抛弃式原型开发抛弃式原型开发第3章 需求工程与需求分析62抛弃式原型方法存在以下问题抛弃式原型方法存在以下问题 1. 为了尽快拿出原型，系统可能做了许多为了尽快拿出原型，系统可能做了许多简化，因而不可避免要遗漏一些重要特简化，因而不可避免要遗漏一些重要特性。性。 2.在客户和承包商之间没有一个能写进合在客户和承包商之间没有一个能写进合同的对于原型实现的合法规定。同的对于原型实现的合法规定。