5.4 需求的分析与系统需求的定义

5.4.1 需求的分析

经过需求调查获得需求信息后，就应该进行需求分析了。需求分析首先是对收集的需求信息加以研究，看是否有不全面、不完整、不清晰的地方，如有必要再进行信息的收集，然后反复进行研究讨论。还要看是否有冲突和矛盾的地方，如果有矛盾还需要进行协商。

需求分析可以通过下面四项活动来进行。

（1）运用分析（或称要求分析）。分析待开发的系统预定的目标，这可以从系统实现后对目前现状或已有的系统有什么进步来分析，以明确系统的价值。最好能对目标加以量化。

（2）功能分析（或称功能定义）。将运行的目标转化为必须执行的功能。

（3）可行性的确定（物理确定）。确定其能否实现。

（4）需求的证实。在一定的准则下确定需求是否现实。

需求分析也可以建立一些模型，特别是概念模型，理清各种因素之间的关系。通过这样的分析，逐步形成对系统需求的较完整的概念。然后就可以进行需求定义了。

在进行需求分析的过程中，委托者（用户）和系统分析人员的发言权是不对等的，常常是谁在这一方面的知识和经验多，谁的发言权就多一些。例如对有关系统中的业务活动来说，委托方的发言权就多一些；而谈到有关系统功能和结构等问题时，系统分析人员的发言权就多一些。在进行过程中，发言权也是在不断转移之中。在这个过程中，双方的知识与经验应该是互补的。要营造一种气氛，让大家都能畅所欲言，而在经过讨论之后，能够理性地达成共识。

一般来说，开始时委托者（用户）对于待建立的系统还不够了解，需要系统分析人员进行解释和启发。在有了一些理解后，往往对系统期望过高，认为可以解决当前存在的所有问题，因此会提出过多的功能需求，并且希望在很短的时间内看到成效。但是，由于技术、人力等资源的限制，并不一定能够在设定的时间期限内满足用户所有的期望，因此在需求分析中，也包括系统的可行性研究部分内容。

在当前工程建设实践中，通常要进行可行性分析。从项目管理的视角来看，系统可行性研究是立项的基础，因为立项要有充分的根据，这些根据就是在需求分析阶段明确了委托者用户）的需要之后，再根据资源等条件和对风险的估计，确定所提出的需求能否被满足。在项目管理中，可行性研究是必需的一步。如果能够满足，则可以立项，转入下一阶段。如果有些方面难以满足，则应研究能否调整需求，实在不能满足，则宣布系统是不可行的。过去认为系统可行性研究的结果总应该是可行的，实际上有的项目就是不可行的，这时放弃这一项目是明智的，因为可以避免日后因进退两难而造成损失。

5.4.2 系统需求的定义

需求的定义是在需求调查和需求分析的基础上，根据调查和分析的结果，准确地定义系统的需求。需求的定义是把需求形式化和格式化。

系统需求要用正式的文档《系统需求说明书》来表述，对一些工程系统（如产品或软件开发）则还要有《系统需求规格说明书》。有了这样的文件，后面的工作就有了依据。

应该强调指出的是：这些说明书主要说明的是“做什么”，而不是“怎样做”。

系统需求说明书的编写应该满足下列要求：

（1）明确而无歧义。

（2）前后一致而无矛盾。

（3）需求与资源（包括人力、物力、资金、信息等）能够对应。

（4）能够使用定量指标的应尽可能使用。有些只能定性描述的也不强求定性。

对于操作性的需求，按照系统的概念，可以用列举输入因素和输出因素以及其对应关系的方式来表述。

系统需求说明书的编制完成，标志着整个系统需求已经从一些散乱的想法整理成为有明确内容且有条理性的需求说明了。

5.4.3 需求定义的工作难点

有一句谚语说：良好的开始就是成功的一半。因此做好系统工程开始的一项工作——需求定义，对于项目的成败关系是极为重大的。但是在进行需求定义时，确实会遇到很多困难。根据以往的经验，下面的一些问题值得重视。

（1）对需求定义的态度问题。无论是委托者还是系统的开发者，都会产生不重视这个重要阶段的问题。特别是从开发者一方来看，会认为需求应该是由委托者提出的，开发者只要按照他们提出的需求去进行以后的工作就行了。其实需求的定义还得靠开发者对用户进行深入细致的调查，必要时还得加以启发，才能获得用户真正的需求信息。有时候，开发者能够发掘出委托者原来没有想到的需求，而使系统的功能得到进一步的提高。也有可能是开发者通过调查发现某些需求是不必要的或者根本不可能实现的，及早向委托者提出，以免日后产生矛盾。

（2）委托者或用户本身对需求的认识和表述问题。过去的经验证明，委托者或用户自己常常是对需求也不明确，有的是不具体，有的是不全面，有的是需求自相矛盾。还有就是委托者或用户心里明白，但是说不清楚（“言不尽意”），因为涉及隐性知识。这就需要双方通过多次讨论交谈，使得用户对需求的认识得以逐步明确、具体、全面、深入。

（3）需求定义的困难还存在于双方在知识方面的差距。特别是开发者是系统工程方面的专家，对于任务领域的专业知识是有限的，除非他多年来从事同一领域中的开发，积累了大量领域知识。另外，委托者或用户一般缺少有关系统工程方面的知识。这样就使得双方缺少共同语言。为了减少这方面的困难，开发者应该事先补充一些领域知识。

（4）在定义需求时，人们容易重视主要需求，忽视次要需求；重视本单位、本部门的需求，忽视其他方面的需求。就像本书前面举的一个水利工程例子，有多个利益相关主体，人们常常忽视间接受到影响的主体或者弱势群体（例如移民）的需求。又如城市公共交通建设容易忽视附近居民希望减少噪声的需求，等等。

（5）委托者或用户的需求经常需要变更也是困难问题之一，因为这涉及返工以及对进度、经费的影响。

（6）在需求定义的过程中，有时候会遇到委托方催促尽快进行而忽视对需求的深入研究，这时如果为了赶进度而草率从事，会产生很大的风险，使得日后难以弥补。

（7）国外在需求定义阶段十分重视文档的编写，每一阶段都要形成文档。这也是他们从以往的教训中总结出来的。在系统工程方法运用的初期，他们也是不重视把双方的共识用文档记录下来，结果一遇变动，就无法肯定当初是怎样安排的，引起许多混乱。我国在管理工作中，双方的许多协议仅凭口头制定，缺乏用书面形式固定下来的习惯，形成日后的许多纠纷，这一点值得我们注意。我们长期以来不善于编制文档，常常是嫌麻烦、怕困难而放松这方面的要求，甚至于讥讽其为文牍主义，领导也听之任之，这个不良习惯实在应该改一改。

当然还有其他一些困难。总而言之，对需求定义工作的困难和长期性必须有足够的认识，特别是这项工作不仅涉及技术问题，而且也涉及复杂的认知和心理活动以及人际关系，必须做好充分准备，才能立于不败之地。

在某些工程项目中，需求的定义已经成为一个重要的独立的任务，在某些领域（例如软件业）中甚至出现了需求工程这样的专门领域，对需求问题做了很细致的研究，其中某些方面值得一般系统工程的需求分析借鉴。