有效沟通需求–需求特征

有效沟通需求所涉及的所有各种筛选器都面临着巨大的挑战，以确保发件人的需求意图将是各种利益相关方所接收，解释和理解的内容。无论采用何种沟通方式，有关需求的关键考虑因素是需求实际上是关于清晰有效的沟通。需求是我们用来传达利益相关方对设计，构建和代码团队的期望和需求的语言，以及本博客系列第3部分中包含的图1右侧所示的整个收件人范围。。重要的是要了解何时需要更正式的需求沟通，何时需要非正式但有效的需求沟通就足够了。当与存在合同的客户签订正式的具有约束力的协议，并且需要完成针对系统工程方法所定义的系统验证时，基于文本的“应”需求陈述方法最为合适。

沟通–无论形式如何，本质上都是模棱两可的。根据假设，环境，思维导图以及发送者和接收者的过滤器，单词通常具有不同的含义。环境（如过滤器）用于编码，解码，解释和理解消息。例如，单词“ check”具有多种含义，所有含义都取决于使用该单词的环境。消息的有效性通常取决于发送方和接收方的假设（通常没有明确说明）。

遵循最佳实践来减少歧义是需求作者的工作，以使需求陈述和需求集具有“与需求表达相关的定义的改进分类法”，INCOSE写作需求指南（INCOSE-TP-2010-006-01，2017）和BABOK（IIBA，2015）。为了帮助促进需求的有效沟通，已经定义了这些特征，以便如果需求（无论形式如何）都具有这些特征，则更有可能发生需求的有效沟通。INCOSE写作需求指南（INCOSE-TP-2010-006-01，2017）还包括一组规则，如果遵循，将导致具有这些特征的需求和一组需求。需求编写者需要接受这些规则的使用方面的培训，以编写格式正确的需求和具有格式正确的需求声明特征的一组需求。

格式正确的需求陈述的特征

“与需求表达相关的定义的改进分类法”和INCOSE写作需求指南（INCOSE-TP-2010-006-01，2017）的定义的关键要素需求说明包括：正式转换和约定的义务。可以通过陈述格式正确的需求的特定特征来进一步详细说明这两个要素中的每一个，这将有助于确保定义的要素是正确的。

正式转型。在定义中包括此要素可以清楚地表明，需求是对利益相关方需求进行工程分析的结果。对于每一个“需求”，需求工程师或业务分析师都会问：实体必须做什么或必须具备什么特性才能实现需求？这项工程分析导致一个或多个需求。鉴于需求是形式转换的结果，结构良好的需求表达的以下特征包括：

Ø 必要的：需求定义了基本能力，特征，约束或质量因子。如果未将其包含在一组需求中，则将存在功能或特性方面的缺陷，而这些缺陷无法通过实施其他需求来解决。

Ø 单一的：需求应说明单个功能，特征，约束或质量因数。

Ø 符合的：独立需求应符合批准的传达需求的标准样式和样式。

Ø 适当的：需求的具体意图和详细程度适合于它所引用的实体的（抽象）层面。

Ø 正确的：需求必须是对其进行转换的实体需求的准确表示。

商定的义务。在定义中包含此要素可以清楚地表明，在需求有效之前，客户和提供者都必须同意需求声明。注意：我们使用的术语“客户”是指请求工作产品的实体。客户可以是企业内部的，也可以是企业外部的。许多人可能希望对系统征税，但是在该需求得到正式同意并成为合同的一部分（“合同”是指购方与供应商之间的关系）之前，它不是有效的系统需求。理性的开发者为什么会同意没有这些特征的需求？由于需求将成为履行义务的公平协议的一部分，因此得出了需求的以下特征。

明确的：需求的陈述方式只能以一种方式解释。

完整的：需求充分描述了满足实体需求的必要能力，特性，约束或质量因子，而无需其他信息即可理解需求。

可行的：可以在具有可接受风险的实体约束（例如成本，进度，技术，法律，道德，法规）内实现需求。

可验证的：需求的结构和措辞使之可以在需求存在的层面上证明（验证）其实现，以使客户满意。

格式正确的需求集的特征

给定需求说明是由于将一个或多个需求正式转换为实体的约定义务而产生的，因此一组需求是对应于代表实体的约定义务的一组需求的正式转换而产生的。同样，该定义的关键要素是正式的转变和商定的义务。因此，可以通过陈述一组精心编写的需求的特定特征来进一步详细说明这两个要素。

正式转型。由于需求集是形式转换的结果，因此得出了需求集的以下特征：

完整的：需求集独立存在，因此它可以充分描述必要的功能，特性，约束，接口，标准，法规和/或质量因素，从而满足实体需求，而无需其他信息。

一致的：一组需求包含唯一的需求，这些需求与集合中的其他需求不冲突或不重叠，并且它们使用的单位和测量系统是同质的。一组需求中使用的语言是一致的（即，在整个需求集中使用相同的词表示相同的意思）。

商定的义务。由于这组需求是公平履行义务的结果，因此得出了该组的以下特征：

可行的：可以在具有可接受风险的实体约束（例如，成本，进度，技术，法律，道德，法规）内实现需求集。

可理解的：必须编写一组需求，以便清楚地知道实体期望什么以及它与它所属于的系统的关系。

能够被验证的：必须能够被证明需求集将在约束条件（例如成本，进度，技术，法律和法规遵从性）之内导致实体需求的实现。

注意，“可行的”是单个需求说明和一组需求的特征。尽管个别需求可能是可行的，但鉴于分配给开发工作的时间表和预算，这组需求可能包含一些不可行的需求。

还应注意，“完整”是单个需求说明和一组需求的特征。尽管适用于单个需求声明的完整性很容易理解，但作为一组需求的特征的完整性很难实现。您怎么知道一组需求是完整的？您怎么知道缺少了什么？

需求集的另一个特征是“一致性”。您如何知道您的需求是否一致，即一个需求与另一个需求发生冲突？当一个需求与另一个需求有依赖关系时，可能会发生这种情况。如果一个变更，则另一个需要变更。

这些问题的答案是图表，模型和模板！如果编写需求集就像编写文档一样，则很难确定您是否错过了某些内容，或者是否存在不一致和冲突。但是，如果您在需求开发过程中使用图表，故事板或模板，则确保您包含了所有需要包含的内容并且所包含的内容与其他内容一致且不冲突的过程将更加容易。

在解决正确性，完整性和一致性时，特别是对于复杂系统而言，无论是独立图还是使用系统工程工具开发的模型的可视化图都是必需的。功能流程图将导致列出所有必需的功能及其关系，输入和输出。外部接口图或环境图，有助于识别您所关注的系统与其他系统之间的所有交互（接口）。数据流程图，状态和模式图，泳道图等也是如此。这些图还提供了从中导出需求的环境。用于组织针对您的域剪裁的需求的模板，还将有助于在需求集中包括所有各种类型和类别的需求。如前所述，图和模型倾向于集中在功能，性能和接口需求上。使用模板将解决其他非功能性需求，例如质量（缺陷），标准，法规和物理特性。

使用系统工程工具解决正确性，完整性和一致性将导致需求集来自底层数据集，该数据集不仅代表需求，而且代表构成系统集成数据和信息模型的各种图表和可视化效果正在开发中。因为所有各种可视化都来自集成的数据和信息模型，所以一个地方的变更将反映在变更可能影响的所有其他可视化中，从而使图和需求所传达的内容保持一致。

需求属性

属性是需求表达中包含在需求表达中的附加信息，以帮助管理该需求。可以将属性分为以下四个主要类别：

帮助定义需求及其意图的属性。

与利益相关的实体和系统验证相关联的属性。

帮助维持需求的属性。

显示适用性并允许复用的属性。

从沟通的角度来看，通常需要传达的信息多于需求声明中包含的信息，例如，原理，跟踪到父级，跟踪到源，关键性，优先级，风险，实施状态，验证方法，验证状态，需求所有者，适用性等。理由可能是最重要的属性，因为它可以包含有助于确保每个人（当前和将来）理解需求的原因，意图，数字来源，环境和假设的信息。需求的正确性可以基于需求属性。需求属性不仅有助于有效的沟通，而且不仅有助于管理需求，而且还有助于产品开发活动。

INCOSE写作需求指南（INCOSE-TP-2010-006-01，2017）和论文“使用属性管理需求”均包含44个属性的列表以及描述。每种方法以及有关属性使用的指南，这些属性可用于更好地理解和管理您的需求。我有关属性的博客系列也讨论了这些属性。

分包思维

需求是用于传达利益相关方对开发人员，设计人员，构建者，编码人员，测试人员和其他利益相关方系统利益的需求的语言。越来越多的争论是关于哪种沟通方式（形式和媒体）是最好的。通常在实践传统系统工程的企业，采用MBSE的企业和遵循敏捷原则的企业之间进行辩论。根据特定企业中要传达的特定事物，领域，文化，人员和流程，通常提倡一种沟通方式（在许多情况下充满激情）。

在讨论了“需求”一词的含义之后，我讨论了有关需求沟通的最有效手段（形式和媒体）的辩论，回到了沟通理论的基础，并表明在所有情况下都没有单一的解决方案。那。不能使用适合所有情况的单一形式或媒介有效传达需求。为了成功交付成功的产品，业务分析师和系统工程师应根据他们正在沟通的内容和与之沟通的受众，使用最合适的形式和媒介。

在很多情况下，基于文本的需求确实比沟通需求的替代形式具有很多优势，条件是需求陈述是明确的并且符合格式正确的需求的特征。在传达需求时，需要考虑几个关键因素，包括：环境，接收者的过滤器，时间和形式。

总之，每种沟通手段都有其价值。但是，没有任何一种方法足以清楚，完整和有效地传达需求。各种手段中的每一种都基于基于所传达消息的意图的观点，表示系统的可视化（图形或文本）。从这个角度出发，为了有效地传达需求，可视化集需要基于目标系统的基础通用集成数据和信息模型。这有助于保持各种可视化的一致性-一个可视化变更可以立即反映在所有其他可视化中，无论是基于图表还是基于文本。