| 需求工程:基础、原理和技术6 |
| 波尔(Klaus Pohl) |
| 计算机科学丛书 |
| 17：自然语言文档、18：组织自然语言需求 |
第17章 自然语言文档
17.1 自然语言需求
使用术语“自然语言需求”来表示使用自然语言描述的需求。将术语“自然语言需求”和“文本需求”作为同义词。
定义17-1:自然语言需求(文本需求)
一个自然语言需求是一个使用自然语言描述的需求。
如果功能性需求使用自然语言进行描述，那么该功能性需求的3个传统视图(数据、功能和行为视图）常常交织在一个已文档化或已规约的需求中。
功能和质量这两方面需求应该被分开描述，即使其中的质量方面在逻辑上与功能方面相关联。
对质量需求和功能性需求的分别描述避免了某些需求被忽视所带来的风险。
17.2 需求文档
需求文档通常会按照一个通用的参考结构来组织。
17.2.1 需求文档的类型
一个需求文档可能因以下这些目的而创建：
❑便于用户、领域专家、需求工程师、软件开发人员等之间的交流；
❑作为创建体系结构设计的一个参考模型；
❑在委托开发任务时用于协商；
❑作为客户与合同商之间订立合约的基础；
❑作为产生诸如用户手册或维护手册等手册的基础；
❑作为项目规划、监控和控制的基础。
17.2.2 要求汇总书
**注：德国规范，可借鉴参考
要求汇总书定义了对于承约商必须提交的产品项和服务的所有需求。同时也详细说明用户视角的需求，包括对于系统和开发过程的所有相关约束。
定义17-2:要求汇总书
要求汇总书包含系统愿景的定义和系统本质目标(功能和质量)的描述，同时列举4个上下文刻面中重要的上下文方面以及它们与愿景和所定义的系统目标之间的关系。
一份要求汇总书，包括：
❑创建责任汇总书：要求汇总书中的抽象需求、约束以及相关上下文方面的描述可以作为创建定义了更详细需求的责任汇总书的基础。
❑竞标与合约协商：要求汇总书可以作为投标邀约以及后期合约协商的基础。
❑评价潜在的可替代实现：要求汇总书可以作为项目工作量和持续时间估算的基础。
❑风险评估：要求汇总书支持开发项目的风险评估。进行不同的可行性分析，以调查和评估所开发系统的不同风险。
17.2.3责任汇总书
**注：德国规范，可借鉴参考
责任汇总书描述要求汇总书的实现，并定义了实现系统的详细需求。责任汇总书详细描述了要求汇总书中记录的需求和约束。
定义17-3:责任汇总书
责任汇总书对要求汇总书中所描述的愿景和系统目标(抽象功能和质量)进行了细化。 如有必要，在考虑对系统技术实现的设想时，责任汇总书也可以对要求汇总书中定义的约束进行细化。
责任汇总书是如下系统开发活动的重要输入：
❑项目规划：将要执行的活动(如设计、编码或测试活动)、里程碑和执行活动所需的资源都将基于责任汇总书中描述的需求和约束来进行定义。
❑体系结构设计：体系结构只有在详细的功能和质量需求以及设计约束都是已知的情况下才能够进行恰当的定义。
❑实现：开发人员需要阅读责任汇总书，从而理解他们将要实现的需求。
❑测试：定义的需求及其验收准则。
❑系统验收：定义系统实现必须满足的验收准则。责任汇总书常被用作系统验收的参照。
❑合约管理：是所订立合约的重要部分。
❑系统使用和维护：是系统运行和维护的参考文档。
❑变更管理：责任汇总书用来分析因解决相关缺陷所需的潜在纠正活动所带来的影响。
17.3 需求文档的质量准则
解释3个应用于整个文档的基本质量准则：完整性、一致性、可修改性和可读性。
完整性
有两种基本的完整性：第一，每个需求应该被完整地规约;第二，所有相关的需求都必须被定义，即没有遗漏任何相关需求。
定义17-4:软件需求规约的完整性
一个软件需求规约是完整的，当且仅当它包含如下元素：
a)所有重要的需求，无论是与功能、性能、设计约束、属性还是外部接口相关；特别地，系统规约所要求的所有外部需求都应该是经过探讨并被接受的。
b)在所有可能的情形下，软件对所有可能的输入数据的响应的定义。注意，对有效和无效输入数据的响应进行规约都是非常重要的。
c)对软件需求规约中所有的图形、表格和图表的标记和引用，以及对所有术语和度量单位的定义。
提示17-1:在需求文档中所识别出的不足(“待决定项”,即TBD)
(1)通过为每一个问题明确地定义一个“待决定项”,对在单个需求中发现的不足以及在需求文档中缺失的需求等进行文档化描述。
(2)对于每一个待决定项，描述该问题存在的原因。
(3)对于每一个待决定项，定义该问题应当何时解决。
(4)如果可能，可以描述待决定项应当如何解决以及负责解决该待决定项的涉众。
一致性
一个需求文档中的每一个需求(内部)都被一致地定义，并且文档中所定义的需求之间不存在不一致性。
区分3种需求文档中的不一致性：
❑对于真实世界方面/对象的不一致描述：两个或多个需求使用不同的术语描述真实世界中的同一个现象。
❑真实世界方面/对象属性的不一致：两个或多个需求中所描述的真实世界现象的属性相互矛盾。
❑动作规约的不一致：两个或多个需求中所描述的两个或多个动作之间存在逻辑或时序上的冲突。
可修改性与可读性
一个需求文档的结构和风格支持简单、完整和一致的需求修改，同时修改后能保持这个结构和风格
文档应该具有一致的结构,每个需求应该具有唯一标识,同时应该避免冗余，并且所定义的需求应该是原子的。
提示17-2:在需求文档中避免冗余
在进行需求修改时，冗余通常会导致需求规约出现缺陷，因为在集成相应的变更时很容 易忽略—处或多处冗余的地方。为此，你应当：
(1)尽可能在需求文档中避免冗余。
(2)当冗余不可避免时，使用交叉引用；交叉引用支持一致的变更集成。
17.4 使用自然语言的优点和缺点
17.4.1 使用自然语言的主要优点
使用自然语言的需求有3个基本的优点:
❑普遍。
❑灵活。
❑可理解。
17.4.2使用自然语言的主要缺点
不同理解存在两种主要的原因：
❑描述不充分：与一个需求相关的某些细节没有进行描述，不同的涉众可能会做出不同的细节假设，从而产生对同一需求的不同理解。
❑自然语言的缺陷：由自然语言所固有的二义性所导致。
词法二义性
两种主要的原因：
❑同义词。
❑多义词。
同义词和多义词问题是需求工程中二义性固有的来源。
语法二义性
如果有两个或两个以上合法的语法树可以被指派给相同的句子，并且其中每一个语法树都会使得句子产生不同的含义，那么就出现了语法二义性。
语义二义性
其在特定的上下文中存在多种解释， 即可出现语义二义性。
引用二义性
如果一个句子中的一个词或短语引用了一个对象，并且对于该对象是什么存在不同的解释，那么引用二义性就出现了。
术语的模糊性
术语的外延是指由术语所指代的所有对象组成的集合。如果一个术语的外延不能被确切地 知道，或者至少有一个已知的边界案例存在，那么该术语就被认为是模糊的。边界案例是指对于某个对象无法确定其是否属于某个术语的外延。
**注：有关术语的外延的，通俗的解释即是，一个术语指代的一类对象，这类对象要么不可准确的被认知，或者是至少有一个已知的对象在这个术语的指代类型下，显得似是而非，无法准确判断是否属于该属于的指代。就是出现了对这个术语的模糊性。严格的术语应该是具有共识的指代一类对象，对于一个对象属于或不属于这个术语指代的类型都很清晰。
17.5 避免歧义的技术
3种已被证实的用于减少自然语言需求二义性的技术：术语表、语法需求模式和受控语言。
17.5.1 术语表
定义17-5:术语表
术语表是作为一种语言(术语学)一部分的技术术语的汇总。术语表定义了每一个术语的特定含义。术语表还可以包括对相关术语的引用以及辅助解释术语的例子。
提示17-3:术语表结构
在术语词汇表中定义一个术语时可以使用如下结构：
❑术语：
❑术语名
❑定义：
❑定义文本
❑同义词：
❑同义词-1;[…]
❑相关术语：
❑术语-1;[…]
❑示例/反例：
❑对于示例/反例的引用
提示17-4:创建术语表
(1)为术语表中的词条定义一个结构，并让所有编辑术语表词条的作者共同使用。
(2)经常检查术语表的结构。
(3)询问具有不同背景的涉众，以提供他们对术语的定义并对所获得的定义进行统一。
(4)如果你对术语是否应该出现在术语表中存有疑问，那么宁可对这个术语进行定义也 不应该遗漏它。
(5)让具有不同背景的涉众评审术语词条，对现有的定义给出评价，并找出缺失的术语。
(6)如有可能，以超文本的形式提供在线术语表。
(7)如有可能，提供在局域网或互联网上管理术语表的支持。例如，通过建立wiki使得 涉众能够对术语定义进行评论并建议新的术语词条。
17.5.2 语法需求模式
定义17-6:语法需求模式
语法需求模式定义了使用自然语言描述需求的一种语法结构，以及语法结构中每一个组 成部分的含义。
17.5.3受控语言
受控语言是一种通过在自然语言上施加精确定义的约束而定义的技术语言。
定义17-7:受控语言
一种受控语言为一个特定的领域定义了一套受限的自然语言文法(语法)以及一组在描述与目标领域相关的陈述的受限语法中允许使用术语(包括术语的语义)。
由于加入了限制，受控语言的表达能力要弱于自然语言。受控语言非常适合于需求规约,尤其在考虑已被精确界定并且充分理解的领域时。
第18章 组织自然语言需求
需求文档通常不仅包含需求制品(即所描述的目标、场景、功能需求、质量需求和约束), 还包含重要的系统上下文信息。
18.1 需求文档的参考结构
18.1.1 参考结构的优点
使用参考结构组织需求文档具有如下的几个优点：
❑经过证明的结构：参考结构反映了最佳实践经验。
❑完整性参考：对于检查所描述的信息是否与预定义的结构相符合提供便利。
❑关注于内容：关注于需求规约中的实际内容而不需要处理文档的结构。
❑同样的信息在同样的位置上：参考结构定义了哪些信息应该在文档中的哪个部分进行描述。
❑工具支持：创建参考结构以及使用参考结构创建需求文档已经有了广泛的工具支持。
18.1.2 IEEE 830-1998标准的参考结构
内容目录
1.引言
1.1目的
1.2范围
1.3定义、首字母缩略词、缩写词
1.4参考文献
1.5概述
2.总体描述
2.1产品视图
2.2产品功能
2.3用户特性
2.4约束
2.5假设与依赖
3.特定需求
附录
索引
第一部分：引言
包含以下5节：
❑目的：本节说明需求规约的目的和使用它的受众 。
❑范围：本节包含待开发软件产品的名称、软件产品能做什么的描述。
❑定义、首字母缩略词、缩写词：需求规约的缩写语。
❑参考文献：本节由需求规约中所参考的所有文档 明所使用的版本和文档的来源。
❑概述：本节提供需求文档内容及结构的概览。
第二部分：总体描述(Overall Description)
由5节构成：
❑产品视图：本节描述对于其他相关产品的依赖。
❑产品功能：本节包括关于软件所具有的主要功能的简要描述。
❑用户特性：本节描述影响软件产品需求的各种用户和用户组的特性。
❑约束：本节定义限制了软件开发过程中的选项的总体约束。
❑假设与依赖：本节明确描述当前规约所基于的假设。
第三部分：特定需求
“特定需求”是软件需求规约中最大的一个部分。这部分需求必须在一定的细节水平上详细定义，从而使软件的设计和实现满足所定义的需求。此外，这部分需求应该能支持测试工程师定义测试制品以及检查系统是否满足需求。
提示18-1:第三部分需求规约：特定需求
进行需求规约时应当考虑以下这些方面：
(1)每一个需求都应该具有唯一的识别符；
(2)每一个需求应该满足已定义的质量准则(正确性、无二义性、完整性、一致性、可 验证性、可追踪性等);
(3)每一个需求都应当定义验收准则；
(4)如果可以的话，应记录每一个需求规约对其他部分或早期文档的交叉引用信息；
(5)需求应该按照尽可能提高可读性和可理解性的方式进行组织。
软件需求规约第三部分可能包含的内容
3.特定需求
一外部接口
一用户接口
一硬件接口
一软件接口
一通信接口
一功能
一性能需求
一逻辑数据库需求
一设计约束
一标准符合性
一硬件限制
一[…]
一软件系统属性
一可靠性
一可用性
一保密安全性
一可维护性
一可移植性
一[…]
一其他需求
❑外部接口：详细定义软件需求规约第二部分“总体描述”中描述的接口。详细说明了输入的来源和输出的目的地、与其他输入/输出的关系、所使用的数据和命令格式、输入和输出的合法范围和精度。
❑功能需求：该节定义了软件在“接受和处理输入，处理和生成输出”时必须执行的所有功能。包括输入的合法性检查和对异常的响应。还必须定义输出与输入的关系。
❑性能需求：定义软件系统的所有性能需求。这些性能需求都应该按照可测量的方式进行定义。
❑逻辑数据库需求：数据库中应该存储的信息定义逻辑需求。包括数据实体以及它们之间的关系、完整性约束和使用频率。
❑设计约束：定义用于系统设计的所有约束。包括由硬件限制或者由其他标准所带来的约束。
❑软件系统属性：定义软件系统的附加质量需求，包括与可靠性、可用性、保密安全性、可维护性和可移植性相关的需求。
❑其他需求：本节定义附加需求。
第三部分“特定需求”的内容组织
介绍两种组织形式：
❑系统模式：按照系统的不同运行模式来组织的。这种组织形式特别适合在不同运行模式下具有非常不同的行为的系统。这种系统甚至会具有针对各种模式的不同功能集。
3.特定需求
3.1外部接口需求
3.1.1用户接口
3.1.2硬件接口
3.1.3软件接口
3.1.4通信接口
3.2功能需求
3.2.1模式1
3.2.1.1功能需求1.1 …
3.2.1.n功能需求1.n
3.2.2模式2
…
3.2.m模式m
3.2.m.1功能需求m.1
…
3.2.m.n功能需求m.n
3.3性能需求
3.4设计约束
3.5软件系统属性
3.6其他需求
❑用户类：结构是根据不同的用户 组来组织的。这种组织形式特别适合为不同用户组提供不同功能的系统。
3.特定需求
3.1外部接口需求
3.1.1用户接口
3.1.2硬件接口
3.1.3软件接口
3.1.4通信接口
3.2功能需求
3.2.1用户类1
3.2.1.1功能需求1.1
…
3.2.1.n功能需求1.n
3.2.2用户类2
…
3.2.m用户类m
3.2.m.I功能需求m.1
…
3.2.m.n功能需求m.n
3.3性能需求
3.4设计约束
3.5软件系统属性
3.6其他需求
第三部分的其他需求组织形式还包括：
❑对象：按照系统所表达的现实世界方面(上下文方面)来组织需求，即按照主体刻面中的实体来组织。
❑特征：按照系统的特征来组织需求，这些特征在不同的系统接口上表现为可见的服务形式。
❑激励：按照导致特定系统功能执行的外部激励来组织。
❑响应：通过描述产生特定响应所需的所有功能的方式来组织。
❑功能层次：按照系统功能的层次分解来组织需求。
18.2 对需求定义属性
这些信息应该以一种结构化的方式进行描述。包括：
❑需求优先级；
❑需求类型；
❑需求文档化的状态；
❑需求实现的状态；
❑需求的稳定性；
❑需求的来源；
❑需求的验收准则；
❑需求中存在的冲突；
❑针对该需求达成的共识。
需求属性
属性可以指派给一个需求制品，与所选择的文档化格式无关。
一个需求属性的定义中通常至少由属性的名称、语义、取值范围以及属性值的语义组成。
定义18-1:需求属性
一个需求属性定义为属性名称、相关的属性语义、为属性定义的取值范围以及这些值的语义。
属性模式
属性模式定义了针对特定需求类型的属性集。
定义18-2:属性模式
属性模式为特定的需求类型定义了一组属性。针对每一个属性，属性模式定义了唯一的属性名、属性语义、属性的取值范围以及值的语义。
系统开发期间需要从预定义范围取值中为每一个属性指派一个取值。
**注：属性模式，实际上是指一个预设的条目集合，其中的元素用于表达这个属性的具体值，或者是用某个条目用于表达特定的属性值。
18.3 需求属性
国际系统工程协会的需求工作组对于需求属性进行了一个全面的汇编。
将需求属性分为7种类型：
18.3.1标识属性(类型1)
这个类型的属性包括所有确保需求唯一识别的属性。标识属性的典型实例是需求的识别符及其名称。
| 属 性 名 | 语义(概要) | 取值范围(概要) | 属性值语义(概要) |
| 识别符 | 确保需求制品唯一标 | Identifier =[GISIR]”-“ Category”-“Number Category ={Digit} Number ={Digit} Digit =[011121…1819] | G=需求制品是一个目标 S=需求制品是一个场景 R=需求制品是一个面向方案的需求 Category=定义该制品的章节 Number=该类型需求的数量 |
| <<unique >> | 刻画需求的唯一名称 | 字符序列 | 与自然语言中名称的含义相同 |
18.3.2 上下文关系(类型2)
包括与需求的来源(即，涉众、文档或其他系统)的关系、与对需求制品的定义影响最大的上下文刻面之间的关系等。
| 表18-2刻画需求制品和上下文之间关系的属性 | |||
| 属性名 | 语义(概要) | 取值范围(概要) | 属性值语义(概要) |
| 来源 | 说明需求的来源 | 涉众、文档、系统 | 派生自上下文刻面的特定含义(见5.1节) |
| 上下文刻面 | 说明影响该需求定义的主要刻面 | “主体刻面” “使用刻面” “IT系统刻面” “开发刻面” | 派生自上下文刻面的特定含义(见5.1节) |
| 理由 | 说明定义该需求的理由 | 文档类型(例如，访谈 记录、商业计划) | 由特定项目或特定公司的文档类型 定义 |
| 责任人 | 说明负责该需求的涉众 | 来自一个上下文刻面的 涉众 | 派生自上下文刻面的特定含义(见 5.1节) |
| 使用涉众 | 说明从该需求中受益的涉众 | 涉众标识符的集合 | 派生自涉众标识符 |
18.3.3文档化方面(类型3)
由捕获与需求文档化相关信息的属性构成，包括用于描述需求的文档化和规约格式、需要考虑的文档化和规约规则，以及需求的文档化和规约方面确认的情况。
| 表18-3 定义文档化方面的属性 | |||
| 属 性 名 | 语义(概要) | 取值范围(概要) | 属性值语义(概要) |
| 文档化格式 | 说明描述该需求所允许的格式 | 自 然 语 言 、 U M L 或 SysML模型、场景模板、 目标模板 | 派生自指派给该属性的值的含义 |
| 文档化规则 | 说明描述该需求时需要考虑的规则 | 对于文档化规则的引用 | 说明定义相应文档化规则的制品 (如文件) |
| 规约格式 | 说明所允许的需求规约格式 | 自 然 语 言 、 U M L 或 SysML模型、场景模板、 目标模板 | 派生自指派给该属性的值的含义 |
| 规约规则 | 说明在规约需求时需要考虑的规则 | 对于规约规则的引用 | 说明定义相应规约规则的制品(如 文件) |
| 文档的确认状态 | 说明文档当前的确认状态 | “未经检查” “在检查中” “部分检查” “已检查 ” “修订中” “已发布” | 未经检查=需求制品未经确认并且不在检测中 在检查中=需求当前正在进行确认 部分检查=需求经过部分确认，但并不处于检查中 已检查=对该需求的确认已完成 修订中=需求制品当前正在被修订 已发布=需求制品已检查，相关的修订已经被确认和集成 |
| 规约的确认状态 | 说明当前规约的确认状态 | “未经检查” “在检查中” “部分检查过” “已检查” “修订中” “已发布” | 见“文档的确认状态”属性 |
18.3.4 内容方面(类型4)
由描述与需求制品内容相关的信息的属性构成。包括需求类型(如目标、场景、功能需求、质量需求 或约束)、需求的简要概述、创建者提供的附加信息、内容的状态(如设想、大致内容)以及与其他开发制品的交叉引用。
| 表18-4刻画内容方面的属性 | |||
| 属性名 | 语义(概要) | 取值范围(概要) | 属性值语义(概要) |
| 需求类型 | 描述根据所选择的需求分 类模式确定的需求类型 | “功能需求” “质量需求” | 功能需求=描述系统功能方面的需求 质量需求=描述系统的质量方面的需求 |
| 简短描述 | 简要概括需求的内容 | 自然语言文本 | 派生自自然语言文本的含义 |
| 附加信息 | 包含由创建者提供的附加信息 | 自然语言文本 | 派生自自然语言文本的含义 |
| 交叉引用 | 描述与其他开发制品的关系 | 对需求制品(如，目标、 场景、面向方案的需求) 以及开发制品(如，组件、 测试用例)的引用 | 派生自指派给该属性的值的含义 |
| 内容状态 | 描述了需求内容的完整性 | “想法” “大致内容” “详细内容” | 想法=概略性的内容，因此不完整 大致内容=实质内容已经存在，但是缺少细节 详细内容=内容是完整的，并包含 相关的细节 |
| 内容的确认状态 | 描述了需求的内容方面当前的确认状态 | “未经检查” “在检查中” “部分检查” “已检查” “修订中” “已发布” | 参见表格18-3,“文档的确认状态”属性 |
18.3.5 协商方面(类型5)
由描述与协商相关的需求制品信息的属性构成。包括涉众关于该需求的协商状态、从共识角度出发的需求确认状态、已知的需求冲突以及冲突解决中所做出的决策。
| 表18-5刻画协商方面的属性 | |||
| 属性名 | 语义(概要) | 取值范围(概要) | 属性值语义(概要) |
| 协商状态 | 描述该制品当前的共识程度 | “未知” “冲突” “协商中” “达成共识” | 未知=该需求中是否存在冲突是未知的 冲突=涉众之间对于该需求存在已知的冲突 协商中=需求当前处于协商中，有望达成共识 达成共识=涉众对这项需求达成共识 |
| 所取得共识的 确认状态 | 说明所取得的共识当前的确认状态 | “未经检查” “在检查中” “部分检查” “已检查” “修订中” “已发布” | 参见表格18-3,“文档的确认状态” 属性 |
| 所识别的冲突 | 说明所识别的关于当前需求的冲突 | 所记录的冲突集合 | 派生自指派给该属性的值的含义 |
| 决策 | 描述为在当前需求上取得一致所做出的决策 | 在协商过程中所记录的决策的集合 | 派生自指派给该属性的值的含义 |
18.3.6 确认方面(类型6)
由描述与需求制品确认相关的信息的需求属性构成。需求确认关注于从三个维度(内容、文档化和共识)对需求的质量进行检查。
| 表18-6刻画确认方面的属性 | |||
| 属性名 | 语义(概要) | 取值范围(概要) | 属性值语义(概要) |
| 入口准则符合性 | 描述制品是否已经符合所定义的确认活动入口准则 | “符合” “不符合” | 符合=需求制品满足所定义的确认的入口准则 不符合=需求制品不满足所定义的确认的入口准则 |
| 确认技术 | 说明用于确认需求的技术 | 确认技术的名称，包括对技术描述的引用 | 派生自每个确认技术名称的含义 |
| 当前确认步骤 | 说明当前所执行的确认技术 的步骤 | 确认技术的步骤的名字 | 所指的步骤当前正在被执行以确认需求 |
| 总体确认状态 | 说明文档化、内容和共识3 个维度上确认的当前总体状态 | “未经检查” “在检查中” “部分检查” “已检查” “修订中” “已发布” | 参见表格18-3,“文档的确认状态”属性 |
18.3.7 管理方面(类型7)
用于描述需求制品的管理信息和当前管理状态。
进一步分为：
❑状态属性：描述需求制品状态的需求属性。
❑管理属性：描述关于需求制品的管理信息的需求属性。
用于描述状态的属性
需求属性风险、关键性、优先级和项目状态描述了关于需求的不同状态。
| 表18-7文档化需求状态信息的属性 | |||
| 属性名 | 语义(概要) | 取值范围(概要) | 属性值语义(概要) |
风险 | 描述与需求相关的风险(例 如，与进度安排或所需的资源 相关的风险) 计算方式：例如，风险=发 生的概率×影响 | “高” “中” “低” “无” | 例如，按照项目计划： [高 中 低]=按照满足项目计划的最后期限将需求风险分为高、中、或低 无=该需求不会导致与满足项目计划中的最后期限相关的风险 |
| 关键性 | 需求的关键程度，例如按照 人员受到伤害的风险 | “关键” “非关键” | 关键=需求中的错误(在抽取、文档化或实现等期间引入的)可能威胁人体健康 非关键=需求中的错误不会危及人体健康 |
| 优先级 | 描述需求对于实现系统所定 义的总体目标等的重要性 | “高” “中” “低” | 例如，对系统的成功而言： 高=需求的实现是必需的 中=需求的实现是重要的 低=需求的实现是可选的 |
| 稳定性 | 度量需求在项目开发过程中 发生变更的可能性 | “稳定” “基本稳定” “易变” | 稳定=变更的可能性接近于零(<2%) 基本稳定=变更的可能性较低(<30%) 易变=改变的可能性高(≥30%) |
| 生存周期阶段 | 说明需求生存周期中的当前 阶段 | “构思” “已规约” “开发” “集成” “安装” “运行” “支持” | 构思=需求没有完全抽取/文档化 已规约=需求已完全被抽取并文档化 开发=需求正在进行设计和实现 集成=需求正在被集成到现有系统中 安装=需求正随着当前系统发布版本进行安装 运行=需求的系统发布版本已处于运行中 支持=需求当前处于维护和支持中 |
描述管理信息的属性
包括需求的作者、当前版本、变更历史以及计划实现或已经实现该需求的系统发布版本。还应记录实现该需求所估计的工作量和成本以及实际花费的工作量和成本。
| 表18-8文档化一般的管理信息的属性 | |||
| 属 性 名 | 语义(概要) | 取值范围(概要) | 属性值语义(概要) |
| 作者 | 说明需求制品的作者 | 标识符的集合，这些标识符用来指代制品的作者(例如，姓、身份证号) | 派生自识别符的含义 |
| 版本 | 需求的版本号 | 版本号={数字}”.”{数字 } 数字={0,1,2, … , 8,9} | 分隔点前面的数字增加时，代表已达到新的里程碑或进行了重大的变更。对于一些小的变更，只需增加分隔点后面的数字 |
| 变更历史 | 对该需求已执行的变更列表 | 文本化描述的集合 | 派生自各个文本化描述的含义 |
| 系统发布版本 | 说明计划实现或已经实现需求的系统发布版本 | 系统发布版本集合 | 计划实现或已经实现需求的发布版本号 |
| 预计工作量 | 实现需求的预计工作量，例如通过应用工作量估算模型获得 | 以人日为单位的正整数 | 数值代表了以人日为单位的实现需求的估计工作量 |
| 当前工作量 | 为了实现需求已经耗费的工作量 | 以人日为单位的正整数 | 数值代表了以人日为单位的为实现需求已经花费的工作量 |
| 预计成本 | 实现需求的预计成本，例如通过应用成本估计模型获得 | 以欧元等货币为单位的正整数 | 数值代表了以欧元等货币为单位的实现需求的预计成本 |
| 当前成本 | 为了实现需求，已经耗费的成本 | 以欧元等货币为单位的正整数 | 数值代表了以欧元等货币为单位的 实现需求已花费的成本 |
18.4模板和信息模型
18.4.1基于模板的文档化
通过使用模板，需求以及与需求相关的信息都可以很容易并且有效地以一种结构化的方式 进行文档化。
应用参考模板文档化需求的优势包括：
❑确定所需的信息：
❑检查空缺：如果一个或多个属性没有被指派值，那么模板中相应的描述项为空。因此， 基于模板的文档化为需求文档化过程中检查空缺提供了便利。与非结构化的需求描述相 比，基于模板的文档化大大降低了在此方面所需的工作量。
❑培训员工：信息的组织和属性的定义为新员工的培训提供了便利。员工可以在需求文档 中选择性地查找信息。此外，模板的结构表明了哪些信息对于某一特定任务而言是重 要的。
❑相同信息在相同位置：基于模板的规约带来了如下好处：
–信息比较：比较相同类型的不同需求变得非常容易。
–选择性访问：读者可以选择性地访问所描述的信息。
参考模板中所定义的属性被分为两类：
❑基本文档化：包括所有甚至对于最初的需求草稿而言也是必不可少的属性。
❑详细文档化：包括在所有需求的详细描述中所需的附加属性。
18.4.2基于信息模型的文档化
信息模型定义了与描述特定类型的需求制品相关的属性。基于信息模型的需求文档化提供了与基于参考模板的需求文档化相同的优势。 信息模型定义了属性(以及需求类型)之间的关联关系。
信息模型使用统一建模语言(Unified Modeling Language,UML描述。
信息模型定义了需求的类型、属性、关系和一致性约束。需求管理工具可以基于所记录的需求信息生成需求视图。
信息模型可以(甚至必须)进行细化。所使用的需求工程工具应当支持针对信息模型所定义的规则和约束的检查。
抽象类“需求制品”是制品类型“目标”、“场景”和“面向方案需求”的泛化。
场景提供了一个或多个目标满足的示例。
从一个场景可以派生出一个或多个面向方案的需求；
每一个面向方案的需求都应与一个或多个场景相关联。
目标可以指派给任意数量的对于该目标的实现存在贡献作用的面向方案的需求。
每一个面向方案的需求必须至少与一个目标相关联。
3种需求制品类型之间关系的简化模型
18.5 建立文本需求视图
一个视图代表着需求库中所记录的信息的一个子集。
在实践中，视图常常与特定的角色相绑定。针对开发项目中的每一个角色 (如，产品经理、项目经理、开发人员)定义一个仅包含该角色特定任务和职责所需的信息的特定视图，从而避免信息过载。
18.5.1 在需求库基础上生成视图
可以使用如下基本操作来创建需求库上的一个视图：
❑制品类型的选择：选择视图中所包含的特定的制品类型、属 性类型、和/或关系类型。
❑信息类型实例的选择：实例选择，可以为每一个制品类型(或其属性)定 义具体值(或值的范围)。只有那些与所定义的值(或值的范围)相符的实例才会被包括在视图之中。
❑基于关系的选择：基于所记录的特定关系类型的关系进行选择。
❑制品的生成：从需求库中已记录的信息中生成(派生)出来的。
理想情况下，一个视图的定义使得该视图包含与该视图相关的角色所需要的所有信息，但不包含与其相关角色无关的任何信息。
18.5.2 生成需求文档
用于生成视图的机制也可以用于自动化或半自动化地生成需求文档。
生成一个需求文档：一个概要的抽象综述
