要求

在产品开发和流程优化中，要求是特定设计，产品或过程旨在满足的单一记录的物理或功能需求。它通常是在工程设计方面正式使用的，包括在系统工程，软件工程或企业工程中。这是一个广泛的概念，可以与系统，组织，组织，内部用户或其他利益相关者俱有价值和实用性的系统，属性，功能，特征或质量，使其具有任何必要的（或有时是所需的）功能。要求可能具有不同级别的特异性；例如，需求规范或要求“规格”（通常不准确地称为“ spec/specs，但实际上存在不同的规格））是指明确的，高度客观/高度客观/清晰（通常定量）要求（或有时，一组要求）可以通过材料，设计，产品或服务来满足。

一组要求用作产品开发设计阶段的输入。要求也是验证过程的重要输入，因为测试应追溯到特定要求。要求显示特定项目需要哪些元素和功能。当使用软件开发或敏捷方法的迭代方法时，系统要求将与设计和实现并行开发。随着瀑布模型的要求，请在设计和实施之前制定。

术语的起源

至少从1960年代开始，该术语要求已在软件工程社区中使用。

根据IIBA知识®2版2版的业务分析指南（Babok），一个要求是：

利益相关者需要解决问题或实现目标所需的条件或能力。
解决方案或解决方案组件必须满足或拥有的条件或能力，以满足合同，标准，规格或其他正式强加的文档。
如（1）或（2）中的条件或能力的记录表示。

该定义基于IEEE 610.12-1990：IEEE软件工程术语标准词汇表。

产品与过程要求

可以说与两个领域有关：

产品需求规定系统或产品的属性。
流程需求规定了开发组织将要执行的活动。例如，流程要求可以指定必须遵循的方法，以及组织必须遵守的限制。

产品和过程要求密切相关；可以说产品要求指定支持流程需求所需的自动化，同时可以说要说出要指定支持产品需求所需的活动。例如，可以强制实施最大开发成本要求（流程要求）以帮助达到最高销售价格要求（产品要求）；通过强加要求遵循特定开发样式（例如，面向对象的编程），样式指导或审核/检查过程（过程要求）的要求，通常可以解决产品的维护（产品要求）。

要求类型

需求通常分为开发过程中不同阶段产生的类型，分类法取决于所使用的整体模型。例如，国际商业分析研究所在其业务分析知识体系中设计了以下方案（另请参见FURP和要求类型）。

建筑要求: 架构要求通过确定系统结构和系统行为的必要集成，即系统体系结构，以说明必须完成的工作。; 在软件工程中，它们被称为架构上的重要要求，该要求被定义为那些对软件系统架构产生可衡量影响的要求。

业务需求: 组织的目标，目标或需求的高级陈述。他们通常描述组织想要实现的机会或他们想解决的问题。在商业案例中经常说明。

用户（利益相关者）要求: 关于特定利益相关者或一群利益相关者的需求的中层陈述。他们通常描述某人想要如何与预期的解决方案进行互动。通常是高级业务需求和更详细的解决方案要求之间的中点。

功能（解决方案）要求: 通常是解决方案所需的功能，行为和信息的详细说明。示例包括格式化文本，计算一个数字，调节信号。它们有时也被称为功能。

服务质量（非功能）要求: 通常，解决方案必须保持有效的条件的详细陈述，解决方案必须具有的质量或必须在其中运行的约束。示例包括：可靠性，可检验性，可维护性，可用性。它们也被称为特征，约束或iTies 。

实施（过渡）要求: 通常，仅需要从企业的当前状态到所需的未来状态的过渡所需的能力或行为的详细说明，但此后不再需要。例子包括招聘，角色变化，教育，数据从一个系统迁移到另一个系统。
监管要求: 法律（联邦，州，市或区域），合同（条款和条件）或政策（公司，部门或项目级别）定义的要求。

好的特征

不同作家的良好需求特征各种说明，每个作者通常都强调最适合其一般讨论或所解决的特定技术领域的特征。但是，通常承认以下特征。

特征	解释
统一（粘性）	要求解决一件事。
完全的	该要求在一个地方充分说明，没有丢失的信息。
持续的	该要求与所有其他权威外部文档完全一致并不矛盾。
非偶联（原子）	要求是原子，即，它不包含连词。例如，“邮政编码字段必须验证美国和加拿大邮政代码”应写入两个单独的要求：（1）“邮政编码字段必须验证美国邮政代码”和（2）“邮政编码字段必须验证加拿大邮政代码” 。
可追溯	该要求满足利益相关者所说的全部或部分业务需求和权威记录。
当前的	该要求尚未通过时间的流逝而过时。
明确	该要求是简洁的，而无需求助于技术术语，首字母缩写词（除非需求文件中的其他地方定义）或其他深奥的词。它表达了客观的事实，而不是主观意见。它只能受到一种解释。避免了模糊的主题，形容词，介词，动词和主观短语。避免使用负面陈述和复合语句。
指定重要性	许多要求代表了利益相关者定义的特征，其缺乏将导致重大甚至致命的缺陷。其他代表如果时间和预算许可，则可以实施的功能。要求必须指定重要性。
可验证	可以通过基本可能的方法来确定要求的实现：检查，演示，测试（仪器）或分析（包括经过验证的建模和仿真）。

还有更多属性需要考虑有助于需求质量。如果要求遵守数据完整性规则（例如），则准确性/正确性和有效性/授权也值得属性。可追溯性证实了需求集可以满足需求（不再是所需的需求）。

在上面的某些情况下，添加了可观察到的外部可观察的，即要求的需求指定了用户可观察或经历的产品的特征。这样的拥护者认为，指定内部体系结构，设计，实现或测试决策的要求可能是限制，应在要求文档的约束部分中清楚地阐明。对比的观点是，这种观点在两个点上失败了。首先，该视角无法认识到用户可能无法感知的需求支持用户体验。例如，与外部第三方业务合作伙伴接口的要求可能支持向用户提供地理编码信息的要求。该接口将是用户无法察觉的，尽管通过接口获得的信息肯定不会。其次，约束限制了设计替代方案，而需求指定设计特征。为了继续该示例，选择Web服务接口的要求与与单个登录体系结构兼容的方法的约束限制设计替代方案不同。

确认

所有要求均应可验证。最常见的方法是通过测试。如果不是这种情况，则应使用另一种验证方法（例如，对设计的分析，演示，检查或审查）。

通过其结构，某些要求是无法验证的。其中包括说该系统必须永远不会或始终显示特定属性的要求。正确测试这些要求将需要无限的测试周期。必须重写此类要求以进行验证。如上所述，所有要求都必须是可验证的。

在软件级别无法验证的非功能要求仍然必须保存为客户意图的文档。但是，它们可能可以追溯到过程要求，这些过程被确定为满足它们的实际方式。例如，可以通过使用配对编程的过程要求替换未置换后门的非功能要求。其他非功能要求将追踪到其他系统组件，并在该级别进行验证。例如，系统可靠性通常通过系统级别的分析来验证。具有复杂安全要求的航空电子软件必须遵循DO-178B开发过程。

导致系统或软件要求的衍生的活动。需求工程可能涉及项目的可行性研究或项目的概念分析阶段和需求启发（收集，理解，审查和阐明利益相关者的需求）和需求分析，分析（检查一致性和完整性），规格（记录记录要求）和验证（确保指定的要求正确）。

要求易于歧义，不完整和不一致问题。已证明诸如严格检查之类的技术可以帮助解决这些问题。在需求阶段可以解决的歧义，不完整和不一致的情况通常比在产品开发的后期阶段发现这些相同问题时要纠正的成本数量级要小。需求分析努力解决这些问题。

在需求之间有一个工程经济折衷，这太模糊了，而那些如此详细的要求

花很长时间才能生产 - 有时到完成一旦完成
限制可用的实施选项
生产昂贵

敏捷的方法是通过高级基础要求来克服这些问题的一种方法，并以及时或最后一个负责任的时刻详细阐述细节。

记录要求

通常，要求写作为不同利益相关者之间交流的一种手段。这意味着对于普通用户和开发人员来说，要求都应该易于理解。记录要求的一种常见方法是说明系统必须做什么。示例：“承包商必须在XYZ日期之前交付产品。”其他方法包括用例和用户故事。

需求的变化

需求通常随着时间而变化。一旦定义和批准，要求应属于变更控制。对于许多项目，在系统完成之前会更改要求。这部分是由于计算机软件的复杂性以及用户在看到它之前不知道想要什么的事实。需求的这种特征导致了要求管理研究和实践。

问题

竞争标准

关于什么是什么要求以及应如何管理和使用它们，有几种相互竞争的观点。 IEEE和IIBA是该行业的两个主要机构。这两个群体都对要求是不同但相似的定义。

关于软件要求的必要性和影响的争议

许多项目取得了成功，几乎没有关于要求的协议。此外，一些证据表明，指定要求可以降低创造力和设计性能要求阻碍创造力和设计，因为设计师过度关注提供的信息。更一般而言，一些研究表明，软件需求是在没有明显要求的情况下，将设计决策歪曲为要求所产生的幻想。

同时，大多数敏捷软件开发方法质疑需要预先描述软件需求的需求，他们认为这是一个移动的目标。取而代之的是，例如，极端编程使用用户故事非正式地描述了要求（简短的摘要符合索引卡，以解释系统应该做什么的一个方面），并认为开发人员有责任直接要求客户澄清。敏捷方法试图在一系列自动接受测试中捕获需求。

要求蠕变

随着时间的流逝，范围蠕变可能会发生。在需求管理中，允许更改需求，但如果不充分跟踪或先进的步骤（业务目标，则用户需求）不会被其他监督或作为成本和潜在程序故障处理，那么需求更改很容易并且可能发生。比开发人员能够生产工作的速度更快，因此需要更快的变化，因此倒退的努力。

多种要求分类法

根据哪个框架正在运行，有多种要求的分类法。（例如，IEEE，VICE IIBA或美国国防部的陈述标准）。不同的语言和过程在不同的场所或随意的语音中会导致混淆和偏离所需过程。

处理腐败

人类运行的过程在治理中受到人类缺陷，在这种情况下，便利或欲望或政治可能会导致进程的例外或彻底颠覆该过程，并偏离教科书的方式。示例包括：

没有严格的过程没有尊重 - 如果例外或更改很常见，例如运行它几乎没有独立性或权力的组织，或者在记录中不可靠和透明，则可能导致整体过程被忽略。
新的球员想要做一个言论 - 已经开发的某些东西（例如软件解决方案），或者是一个新创建的Office对象，用于当前项目的当前开发，因为它们在用户需求时不存在，因此他们开始努力回溯和重新循环项目。
在线之外着色 - 可能的优先级。
迟到了 - 例如，在开发之前几乎没有努力在要求上启发。这可能是由于认为他们将获得相同的好处，无论个人参与如何批判。

在美国国防程序中，一些要求问题的历史示例是

五角大楼战争中描绘的随意运动运动的M-2布拉德利问题；
F-16战斗机黑手党概念的F-16增长归因于F-15计划试图破坏竞争的F-15计划，或者将当地欲望的单个办公室侵蚀了轻量级和低成本的概念。
热情1998年“净准备”导致其任务是从网络准备就绪的办公室，在办公室定义要求过程之外的关键绩效参数，并且与该办公室先前定义的过程不一致，他们对kpp的定义或某些努力可能不合适或能够定义构成“ Net-Ready”的内容。

要求