要求管理

项目举例

下面的数据来自当前的项目，能够让人明显看出，需要在分析的标准和指令中管理多大数量的单项要求。

–    机械指令 2006/42/EC	44 项要求（章节 1.7.4，附件 I）
–    ANSI Z535.6:2011：	16 项要求
–    DIN EN 82079-1:2013：	424 项要求
–    VGB-R 171:2010-04:	76 项要求（附件 D）
	560 项要求

具体的数量可能因分析情况的不同而有巨大的差异，并且与下文要介绍的因素有很大关系。例如，如果采用更细致的方法，可以从 ANSI Z535.6 中分离和描述明显更多的单项要求。

挑战与解决方法

表述不清、各项要求的结构划分不够干脆以及冗余和状态不明，这些不仅会让检查清单难以使用，而且会造成过后无法更新和维护要求资料。最晚在这个时候，人们就会明白，为何专业且有效地处理要求会成为一个独立的方法学领域，也就是要求工程（Requirements Engineering）。这就让我们有了充分的理由，将要求工程（Requirements Engineering）的各个模块也应用到技术文档中。

向软件开发学习

从很多年前起，人们在开发功能软件的时候就会碰到这么一个问题：如何在功能范围越来越宽，创新周期越来越短的情况下恰当且有效地掌控复杂度和动态特性。

在 IT 领域，选择需求工程方法在很多年前就已成为“常识”，在克服学习曲线之后，用户就有了一个经过实践检验且有相应系统支持的有效操作模型来减少混乱。在这里，对于技术文档来说，重要的并不是通过代码管理和测试用例管理，以系统支持的方式将各项要求联系起来，重要的是明确的结构化记录各项要求的具体方法 (要求记录管理（Requirements Documentation Management）)。

下面，本文将选取要求管理领域几个对此特别有帮助的方面并简要地描述其特点。

独立的要求具有可检查性

一项要求是否能被检查，基本前提是要具有明确性。若要清楚地确定满足程度，一项要求中就不能有多项子要求。在修改标准规定的时候，这里意外地成为了主要的投入项，标准来源因为具有各种类型的总结、 概括和重复，所以尤为突出。

表述模式是清楚的前提

一项独立的要求，应该采用容易理解的方式进行记录。能够帮助记录和编辑使用说明书内容的表述模式，也有助于简化人们对各项要求的解读过程。变化多样的句式和不同的术语对于理解要求毫无益处。一般来说，只需不超过五个规定的、以句子模块的形式使用的表述模式，就足以从标准和指令文件中采集要求。

减少冗余，降低复杂程度

一个最迟在分析完第二个标准或者指令之后就会出现的现象是，有的要求必须体现在多个标准或者指令中，因此必须进行多个来源的多次记录。解决这一冗余问题的最简单方法是，为该要求提供一个有代表性的名称，与所有的记载位置对应。

Excel 或者有效的系统支持

一般来说，Excel 表格是人们从标准和指令中系统性地采集和管理有效要求所用的第一个系统。在实践中，所使用的列数显示了，用于管理和使用的有效数据模型的广泛性。以下的描述内容源于实践：

简要、清楚的要求名称

• 简要的要求说明
• 要求/记载位置的来源（标准/指令的编号、版本日期、标准/指令的名称、语言、章节/子章节、页码）
• 要求的原始文本（注意，这里可能存在版权和著作权风险）
• 要求的分类（系统性的分类是搜索要求的基础）
• 要求的状态（草稿，已批准）
• 应用提示和示例
• 实现要求的措施
• 实现或者完成状态（已计划，已实现）
• 实现程度（未实现、部分、完全实现）
• 责任

Excel 的限制

将标准和指令中的多个记载位置与一个明确的要求对应起来（比例 1:n），这个问题很快会让 Excel 达到极限。用于进行无冗余管理的数据结构，需要有数据库提供的合适的系统支持。在这里，查找合适的要求管理系统是有帮助的。

企业中的组织措施

要求管理的组织方面经常会被人们忽视。或者用简单的语言来说就是，谁来创建第一个要求列表，以后由企业中的谁来更新要求，以及谁来安排以定期评审或者一次性检查的方式来应用这个检查清单？谁来实施建立在检查基础之上的措施并且谁来监督必要的措施是否得到维持？

一个企业只有通过合适的形式解决了这些问题，才能长期确保以最佳方式创建并且更新的要求列表得到有效使用。