|
|
作为一名汽车行业Tier1的系统工程师，我们每天都在看客户的需求，也在书写我们系统级别的需求。需求的质量直接影响着我们是否正确的理解客户需求，我们能否正确的把需求传递给软件工程师。那么我们编写或者审核文本需求时，可以基于一些原则来提高我们的需求质量。
目标读者
《Guide for Writing Requirements》是一本专门介绍如何在系统工程的上下文中表达文本需求。其目的是汇集各种现有标准的建议，形成一套单一的、全面的特征和规则。
自然语言是表达需求的一种不完美的方式。要做到清晰、准确和避免模棱两可是一项艰巨的工作。然而，它仍然是唯一的通用表达方式，涵盖了所需的各种概念。
方法
这篇文章及后续文章介绍了编写需求的基本特征和实用规则。特征表达了为什么规则是一个好方法，而规则则表达了如何编写需求。换句话说，特征在于问题域，规则在于解域。作出这种区分是健全的需求管理的一个原则。
在这种情况下，呈现特征是很重要的，因为单凭规则集永远无法完美完整地表达如何实现良好表达需求的目标。需求的多样性意味着规则必须不断地适应特定的情况。鉴于这一现实，对基本特征的理解有助于对规则的调整。
除此之外，人类的本性就是这样，如果我们知道为什么我们应该应用规则，我们中的许多人会有更好的动机去应用规则。
概念
有必要先解释一些概念，能更好地理解特征和规则。
•抽象级别。在系统工程中，需求存在于多个抽象级别，范围从客户需求的最高级别表达到最低级别的设计。在这些层中，需求的表达方式不同，因此表达它们的规则也不同。随着需求的开发——以及解决方案的设计——通过抽象层向下进行，我们期望需求的陈述变得越来越具体。在最高层次上，理想的需求是开放方案的，因此不是特定于一个解决方案，并规定了一系列可能的解决方案。在最低级别，需求陈述将完全特定于所选的解决方案。我们考虑在这些层之间进行单独的划分:问题领域中的需求和解决方案领域中的需求。虽然有相当多的迭代,问题域被认为是开始一个业务需求与系统需求规范的认可和结束(ISO / IEC 29148),这是一组与实现无关的需求在系统级别(需要表达“是什么”的系统)。“如何”实现系统的定义属于解决方案领域。虽然这里包含的许多规则同样适用于问题域和解决方案域，但本文关注的是解决方案域—即系统需求及其下面的需求集。
•可追溯性的要求。随着设计的进行，需求沿着抽象层向下流动。这个流程有两个方面:分配和分解。需求的分配发生在级别边界上，即它们从级别n分配到级别n+1。例如，子系统上的需求将从上面的系统中分配。双向跟踪应该存在于分配的需求和它的源之间。一旦分配，需求就可以分解为设计过程的一部分。这在需求之间引发了多对多父/子关系，在这种关系中，子需求是用来满足其父需求的。双向跟踪也应该存在于父需求和子需求之间。本文将在此意义上使用所分配的术语，parent和child。
•类型的需求。处理功能和功能的需求可能以不同的方式表达，与指定其他系统属性的约束和需求不同(通常被混淆地称为“非功能”需求——这个术语在本文中不会再次使用)。本文旨在涵盖需求类型的全部范围。
•要求和特定的学科。需求表达的方式受到底层规程的强烈影响，例如拥有需求的验证、安全性、安全性、可靠性等。通过所有权，我们指的是产生需求或者负责满足需求的规程。该指南旨在涵盖跨学科的需求表达，以及产品生命周期的所有阶段，例如开发、生产、操作、维护、演进和处置。
文章结构
本文侧重于需求的编写，并处理需求的以下方面:个别需求陈述的特征、需求集合的特征、个别需求陈述的属性，以及个别需求陈述的规则。
需求陈述的特征。在定义需求时，应该注意确保需求得到适当的设计。本指南阐述了需求声明(基于ISO/IEC 29148)的下列特点:
•必要的。
•独立实现。
•明确。
•完整性。
•单一性。
•可行性。
•可验证。
•正确。
•符合性。
一组需求陈述的特征。本文详细阐述了一组需求的以下特征，应该处理这些特征以确保这组需求共同提供了一个满足涉众意图和约束的可行解决方案。这些包括(根据ISO/IEC 29148):
•完整性。
•一致性。
•可行性。
•界限。
需求陈述的属性。除了上面列出的特征，个别的需求陈述可能有许多附加的属性(或者作为数据库中的字段，或者通过与其他工件的关系):
•与需要保持一致。
•对齐设计。
•与证据一致。
•优先级。
个别语句的规则。本文还提供了许多编写单独语句的规则，这些规则支持单独语句的特征和属性以及一组需求的特征。
翻译自：INCOSE 《Guide for Writing Requirements》 2012 April 12 |
|
发表于 2022-11-27 10:40:12