只要是软件企业，我就没见过有谁说自己在需求这块没有问题的。

作为软件的源头，需求做的好坏基本可以决定项目的成败。作为乙方的软件公司，不能要求客户们成为工程师一般的“专业人士”，便只能给自己寻到两条出路：

第一，便是固守“专业人士”的底线，照着自己的“专业路子”做，再想方设法“教育”客户。

第二，就是老实听话，让干啥干啥，让咋改咋改；反正需求注定要变，还不如消停一点，换个良好的客户满意度。

在我看来，这两种应对需求问题的思路，都是消极地破罐子破摔。客户和开发团队之间就像是三维空间中，两条不相交的平行线一般自说自话。除了不断增加返工、成本与各种“并发症”外，没啥实质性的益处。

20世纪末，人们提出了“需求工程”的概念，希望借助工程概念的方式，解决日益严重的需求的问题。

需求工程是指，应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。——百度百科

需求工程的核心，是需求建模与技术。随着软件的不断发展，需求工程也不断地演化与发展：

软件的巨大普适性，涉及到诸如行业、人员角色、文化、社会背景、商业目标、利益协商等越来越多的非技术因素。时至今日，需求工程的技术也已经不再是核心问题了。而那些非技术的、社会性的因素在需求中的占比却不断升高，上升为需求问题的主要矛盾了。

因为这些技术、非技术与社会性因素的影响，几乎不会有客户能够给出对软件要解决的问题的全面说明。而只能是部分的、片面的、片段的“只言片语”。而需求人员面对的挑战，便是将这些结合起来，分析、重组、还原成需求的全局。这便需要需求工程转而面向服务分析的发展原因。

软件是用来解决客户在现实世界中遇到的问题的系统。因此，对软件的认知不应该仅仅是软件本身，还应扩展至软件服务。外延的扩大，可以让需求工程的关注点从技术延伸至非技术因素与社会因素。将软件开发当成一个系统工程来处理，如此构建出的整体软件服务，才能切实应对现实世界中的问题；如此系统化的需求工程才能兼具全面性与正确性。

由此可见，想要解决现实中的问题，软件只是整个系统的一部分。在软件之外还有硬件工程与人力工程。因此，我们经常抱怨的那个需求，也不应该仅仅指软件需求，而应该是系统的，包含硬件工程与人力工程的需求。

这个范围的延伸，非常好的诠释了软件行业中的一种现象——售前阶段，项目组已经开始进行需求分析，撰写技术方案，提供报价依据。这时，我们做的需求，主要面向的是系统工程的需求。而签订合同后，进一步做的需求，则是面向软件工程的需求。（见下图）

目前需求工程的主要任务：

• 明确系统目标和应用环境。说明软件系统的总体目标，以及达成这些目标的功能、上下文环境、实现方式和方法、限制和约束等。也就是要说明软件为什么需要，以及需要做什么。

• 将现实映射到软件。将目标、功能、环境和约束等，“翻译”成软件的准确的规格说明。

• 动态管理目标、功能、环境和约束。由于现实世界是一个动态变化的世界，因此需求工程需要综合的、动态的、平衡的管理目标、功能、环境和约束在软件生命周期中的演化和分布情况。

系统工程的需求是对应系统目标和应用环境的，是直接映射到现实问题的，需要动态的管理。软件工程的需求是仅仅针对软件本身的。

需求人员认为系统工程的需求应该全面而正确地来自于客户，自己只应该负责软件工程的需求。然而，客户在这方面，比需求工程师还外行。他们需要需求工程师站在系统工程的角度，借助软件，解决他们在现实世界中遇到的问题。这便是需求问题一直以来面对的鸿沟。