Needs与Requirements，需要、要求、需求辨析

上一篇文章中，Moonriver 提出：“建议开展一项专题讨论：need与requirement 中文如何讲？这是个基础，否则很容易引起混淆。如果requirement 译成“需求”，那么中文的“要求”对应什么英文呢？中文中的“要求”与“需求”不应等同吧。这个问题不应回避和模糊”。 上述词汇从词义本身、经济、心理学等方面有不同的特征，本文仅从系统工程应用的角度来对它们进行初步辨析，水平有限，不一定准确，希望大家在评论中回复，共同参与讨论。

1. need(s)与requirement(s)辨析

1.1SEHBK4对needs与requirements的描述

在系统工程手册4.0(SEHBK4)中对needs与requirements是这样描述的：

[4] Needs— Per the Oxford English Dictionary, a need is a thing that is wanted or required. For a system, needs are often capabilities or things that are lacking but wanted or desired by one or more stakeholders. These can be viewed in at least three contexts in which SE is performed: (i) projects with customers internal to the enterprise that is doing the engineering, (ii) development under an agreement with an external entity, and (iii) entrepreneurial product development in anticipation of future sales.

Requirements— Requirements are formal structured statements that can be verified and validated. There may be more than one requirement defined for each need.

Note: One underlying principle illustrated by Figure 4.1 is that when a decision is made to satisfy a need, that need gives rise to a corresponding requirement or set of requirements.

上面几段文字翻译成中文后大致是这样的：

Needs —— 根据牛津英语词典，needs是想要或需要的事物。对于系统来说，needs往往是一个或多个利益相关方缺乏但想要或期望的能力或事物。在系统工程执行中，至少有三方面情况：（一）做工程的企业内部客户的项目（此处感觉比较别扭），（二）与外部实体在协议下开发，和（三）用于未来销售的企业产品开发。

Requirements —— Requirements是正式的结构化的可以被验证和确认的描述。每一个needs以有超过一个定义的Requirement。

注：图4.1所示的一个基本原则是，当一个决策是要满足一个need，那么“need”将产生一条对应的requirement或requirements集。

1.2 ISO/IEC/IEEE 29148对Requirement的定义

在ISO/IEC/IEEE 29148中requirement的定义如下：

[4.1.17]Requirement —— statement which translates or expresses a need and its associated constraints and conditions

NOTE Requirements exist at different tiers and express the need in high-level form (e.g. software component requirement).

Requirement——转换或表达需要（Need）及其相关的约束和条件的表述

注意，requirement存在不同的层级，并且表达高层级形式的need.

上面的这段话可以从INCOSE系统工程手册图4.1得到印证

[5.2.3]Defining requirements begins with stakeholder intentions (referred to as needs, goals, or objectives), that evolve into a more formal statement before arriving as valid stakeholder requirements. Initial stakeholder intentions do not serve as stakeholder requirements, since they often lack definition, analysis and possibly consistency and feasibility. Using the Concept of Operations to aid the understanding of the stakeholder intentions at the organizational level and the System Operational Concept from the system perspective, requirements engineering leads stakeholders from those initial intentions to structured and more formal stakeholder requirement statements. These statements are well-formed and meet the characteristics of subclauses 5.2.4, 5.2.5, and 5.2.6.

定义Requirements开始于利益相关者的意图（简称为need、目的或目标），即在到达成为有效的利益相关者需求之前演变成更正式的表述。最初的利益相关者意图不作为利益相关者Requirements，因为它们往往缺乏定义、分析和可能的一致性和可行性。使用运行概念在组织层面上帮助理解利益相关者的意图，并且使用系统运行概念从系统角度帮助理解利益相关者的意图，需求工程引导利益相关者从最初的意图达到结构化且更加正式的利益相关者Requirements陈述。这些陈述是格式完整的且符合5.2.4、5.2.5和5.2.6的特点。

1.3 need与requirement 的区别

从INCOSE系统工程手册以及ISO/IEC/IEEE 29148对need与requirement的描述，我们从need与requirement的关系，need与requirement所表述内容的完整性、一致性、准确性，need与requirement的表达方式等几方面对两者比较如下：

Need	Requirement
Need是Requirement的输入内容之一	Requirement是Need经过需求分析后的结果
一个need可以对应一条requirement或者requirement集	Requirement(s)一定是为了满足某一个need的
Need只是站在某个具体的利益相关方自己的立场所表达的意图与期望	Requirement必须综合了各方立场的表达
Need表达意图与期望时不会特别的考虑完整性，在特定的Context下很多隐含的信息被省略，因此容易被“断章取义”	Requirement必须对意图与期望进行完整的表达，必须结合特定Context挖掘出所有的隐含信息、约束、交互、关键特性等。
Need所表达的意图与期望不考虑约束或约束隐含在特定Context中	Requirement一定有约束去描述范围与边界
Need所表达的意图与期望不考虑是否同其他相关方的意图与期望冲突	Requirement必须是经过多方权衡与协商后达成的共识
Need所表达的意图与期望是否可行没有经过科学的定义与分析	Requirement是必须经过定义与分析的可行的描述，而且是可验证的描述
Need所表达的意图或期望本身可能是一种不准确的表达，因为利益相关方有时候并不那么专业。如“更快的马”	Requirement是经过分析后对意图与期望的准确表达
Need仅仅表达某一相关方主观上的愿望，并不考虑能否实现	Requirement不仅仅是一种主观愿望，还必须考虑客观上可实现

1.4 need与requirement 的中文翻译

笔者在学习研究系统工程的过程中，将need(s)翻译成“需要”， requirement(s)翻译成“需求”，这一结果是依据汉典对“需要”与“需求”的解释进行翻译的。

◎ 需求xūqiú (1) [demand; requirement]∶购买商品或劳务的愿望和能力 需求曲线 (2) [requirement]∶需要的东西 政府对汽车的需求 ◎ 需要xūyào (1) [need; want; require; demand]∶应该有,必须有;必要,有理由要 儿童们需要牛奶 (2) [needs]∶对事物的欲望或要求 经济上的需要 从战争的需要出发

辞海对“需要”与“需求”的解释：

词汇	需要
释义	xū yào/yāo ①要求得到；必须有；应该要：他需要一个助手｜你需要深刻反省｜他的病需要到县里去看。②愿望；要求：符合需要｜满足用户需要。③个体对内外环境的客观需求在脑中的反映。它常以一种“缺乏感”体验着，以意向、愿望的形式表现出来，最终导致为推动人进行活动的动机。需要总是指向某种东西、条件或活动的结果等，具有周期性，并随着满足需要的具体内容和方式的改变而不断变化和发展。

词汇	需求
释义	xū qiú 1.索取﹐求索。 2.需要﹐要求。

从辞海对“需要”的解释看，需要①要求得到；②愿望；③个体对内外环境的客观需求在脑中的反映。它常以一种“缺乏感”体验着，以意向、愿望的形式表现出来，最终导致为推动人进行活动的动机。需要从字面意义看主要体现“需”，是对缺乏却想拥有的某种事物在头脑中的反应，是一种主观的意愿。这与牛津词典对“need”的解释比较接近。

需求，从字面意义看体现在“需”与“求”两方面，因此需求不仅仅是一种主观的意愿——“需”，同时还必须考虑客观的实现——“求”。也就是要将“需”的主观愿望通过“求”转换成客观的、可实现的事物。

从上述分析看，将need翻译成“需要”，requirement翻译成“需求”是相当合适的。

2. 需要与需求的比较

从上一节的内容来看，需要与需求的差别主要体现在，需要主要体现“需”，是对缺乏却想拥有的某种事物在头脑中的反应，是一种主观的意愿。需求不仅仅是一种主观的意愿——“需”，同时还必须考虑客观的实现。下面借助经济学上的解释来阐明需要与需求的区别。在工程上，也有类似的意思，需求是为了满足需要的，是考虑需要如何实现的。需要与需求的比较可以参考need与requirement的比较。

需要

是有机体感到某种“缺乏”而力求获得满足的心理倾向，是内外环境的客观要求在头脑中的反应。它源于自然性要求和社会性要求，表现为物质需要和精神需要。需要常以一种“缺乏感”体现，以意向、愿望的形式变现出来，最终发展为推动人进行活动的动机。需要总是指向某种东西、条件或活动的结果等，具有周期性，并随着满足需要的具体内容和方式的改变而不断变化和发展。

需求

是指人们在欲望驱动下的一种有条件的、可行的，又是最优的选择，这种选择使欲望达到有限的最大满足，即人们总是选择能负担的最佳物品。表现在消费者理论中就是在预算约束下达到最高无差异曲线。

需求不等于需要。形成需求有三个要素：对物品的偏好，物品的价格和手中的收入。需要只相当于对物品的偏好，并没有考虑支付能力等因素。一个没有支付能力的购买意愿并不构成需求。需求比需要的层次更高，涉及的因素不仅仅是内在的。所以在经济学中，必须注意不要将两者混淆。经济学的基础分析工具是需求与供给理论，而非需要与供给理论。

例如：

头发脏了，需要清洁头发，这是需要。

低端消费者选择飘柔日常护理(9.9)，中等收入选择飘柔精华护理（25），高收入人群选择沙宣（60），这三种选择就是需求。

3. “需求”与“要求”比较

在中文中，很多时候我们会使用到“需求”与“要求”，那么，二者之间是一回事吗？它们之间存在什么样的差别？在系统工程应用实践中应该如何去区别？在辞海、汉典、汉语大辞典中都没有对二者有太多详细的描述。经过笔者多方查找，在GB/T19001-2008中找到了比较详细的描述。下面我们从这两个词语本身的属性、惯常的用法等方面对二者进行辨析。

3.1 GB/T19001-2008对“要求”的定义

GB/T19000-2008 对要求的定义 [3.1.2]要求：明示的、通常隐含的或必须履行的需求或期望 a)“明示的”可以理解为是规定的要求 b)“通常隐含的”是指组织、顾客和其他相关的惯例或一般做法，所考虑的需求或期望是不言而喻的 c)“必须履行的”是指顾客或相关方要求的或有强制性标准要求的 d)要求可以由不同的相关方提出，不同的相关方对同一产品的要求可能是不相同的 e)要求可以是多方面的，当需要特指时，可以采用修饰词表示

3.1 “要求”与“需求”的区别

要求	需求
定义：明示的、通常隐含的或必须履行的需求或期望	1）购买商品或劳务的愿望和能力 2) 需要的东西
“通常隐含”是指组织、顾客和其他相关方的惯例或一般做法，所考虑的需求或期望是不言而喻的。	与ISO/IEC/IEEE 29148：2011中所描述的过程需求比较类似，过程需求包括：符合国家、省或地方的法律，其中包括环境法律、行政需求、采办方/供应商关联需求、以及具体的工作指令。 过程需求也可以通过企业政策或惯例施加到程序大纲中。 系统或系统元素实施过程的需求（如某项特定设计方法）通常体现在项目协议文件中，如合同、SOW和质量计划。
要求可由不同的相关方提出。很多时候还表示是建立在自己意愿基础上来强烈指导别人的决定。
要求由于其本身所包含的动词属性，往往具有比较强烈的意愿，表达一种强制性：如：“提出领土要求”	需求没有这种强制性色彩，一般没有“提出领土需求”的说法
通常是建立在自己意愿基础上，如“单方面要求”	没有“单方面需求”的说法
要求往往不具备太多的协商余地	需求通常是可以协商的

3.3 结论

“要求”与29148中的“过程需求”，是一种约定俗成的隐含的过程约束，往往带有一定的强制性与暴力色彩（如果没有暴力色彩，提出领土要求时就不需要打仗了），或者从单方面意志出发，表达一种强制性意愿。

因此，“要求”只是需求中表达了强制性意愿的那部分需求，是需求中的“过程需求”部分，通常在需求中表现为“标准、规范、法律、法规、行政命令、企业程序、合同文件”等。

3.4 附：ISO/IEC/IEEE29148的“过程需求”

Process requirements.These are stakeholder, usually acquirer or user, requirements imposed through the contract or statement of work. Process requirements include: compliance with national, state or local laws, including environmental laws; administrative requirements; acquirer/supplier relationship requirements; and specific work directives. Process requirements may also be imposed on a program by corporate policy or practice. System or system element implementation process requirements, such as mandating a particular design method, are usually captured in project agreement documentation such as contracts, statements of work, and quality plans.

过程需求 —— 这些都是利益相关者（通常是采办方或用户）通过合同或SOW施加的需求。过程需求包括：

符合国家、省或地方的法律，其中包括环境法律、行政需求、采办方/供应商关联需求、以及具体的工作指令。

过程需求也可以通过企业政策或惯例施加到程序大纲中。

系统或系统元素实施过程的需求（如某项特定设计方法）通常体现在项目协议文件中，如合同、SOW和质量计划。