无需求分析，不成软件

最近遇到个事情，因为没做好需求分析和设计，造成交付出来的APP就是个功能堆叠的产物，当个demo看看还勉强，实际使用全是问题，而且很多问题牵一发动全身，根本没法改，不如推到重做。

做了十几年信息化软件项目实施，深知是否进行了有效的需求分析，是一个项目能否顺利实施落地、项目成果能否真正满足用户业务应用的重中之重。今天梳理下我对需求分析的认识。

一、需求是什么？

需求 = 预期/目标 - 现状。这个说法简单，但是有些抽象，再具体一些，需求是“业务场景+问题列表+其他影响因素”。业务场景，包括了业务实体、业务规则、业务事件；问题列表，就是用户在实际工作中遇到的困难障碍，也就是软件系统需要解决的问题；其他影响因素，是实现需求的一些限制条件，例如基础软硬件环境、用户的特点等。

这样看来，需求可以分为三个层次：业务需求、用户需求、软件需求。

1、业务需求

无论是项目可研报告、项目建议书，还是招投标文件、项目合同，开头的部分都是项目背景、建设目标、建设内容，这些实际上就是业务需求，反应的是客户对于软件系统的高层次目标要求。业务需求通常是客户单位的高层管理人员提出的，从业务角度描述，用于指导软件系统的建设方向，通常隐含着高价值需求，需要深入识别、分析、挖掘出来。

2、用户需求

用户需求描述的是用户要使用软件系统做什么、怎么做、得到什么结果。通常需要在业务需求的基础上，通过需求调研，从实际使用部门/使用者获取到。用户需求来自不同部门、不同用户，通常有两个特点：零散、存在矛盾。所以，需要我们进行分析、梳理用户使用场景，形成更准确的需求说明。

3、软件需求

软件需求，是在业务需求和用户需求的基础上，进一步分析、提炼、整理形成的，用于指导开发的、更精确的需求。也就是说软件需求才是需求分析和建模的结果。

二、需求如何获取？

需求调研是和人打交道的过程，考验需求人员的沟通能力，做好需求调研的重点在于计划性和科学性。计划性体现在调研对象、时间、问题的计划，科学性是指如何有效选择调研对象、确定适合的调研方法。

1、选对调研对象、问对问题

不同层次的调研对象，决定了获取信息的方法和层次。高层管理人员解决宏观问题，中层管理人员解决结构问题/脉络问题，基层操作者/使用者解决细节问题。

也就是说需要针对不同的业务环节，设计针对性的问题，并且按照业务环节的执行者去找适合回答问题的人。

2、找到核心需求、识别隐藏需求、破除伪需求

用户的需求就像隐藏在水面下的冰山，客户描述出来的、我们看到的，只是浮出水面的部分，水面以下还隐藏着大量的需求，这里面就包含着客户的核心诉求、高价值需求。

通常浮出水面的需求，是困扰用户的问题、用户设想的解决方案，如果只接收这部分需求，就可能会造成本文开头说的问题，需求只是功能的罗列，并没有从用户的实际工作场景出发，而且用户提出的解决方案，很可能是个伪需求，并不能解决根本问题，按下葫芦起来瓢。

所以需要我们去挖掘水面之下的冰山，了解用户的实际工作场景 、作业流程，识别出隐藏需求，从全局出发，给出更适合的解决方案。更进一步，结合我们的技术优势，给出超过客户预期的解决方案（高价值需求）。

三、需求分析怎么做？

需求分析不是要分析系统如何实现需求，需求分析实际上是业务分析，以一根业务主线将零散的需求串起来，形成一个体系完整、逻辑清晰、内容准确的框架，来指导后续的设计和开发工作。

1、应用场景与业务流程分析

通过分析用户有哪些核心的应用场景，涉及哪些用户、哪些业务实体、哪些业务规则，梳理业务流程，从而理清需求的结构框架和系统流程脉络。

2、数据与数据流转分析

应用场景与业务流程的分析，是从“事件”的角度出发，除此之外还需要从“内容”的角度分析，也就是业务中涉及哪些数据、数据的来源、如何流转变化、产出哪些成果。

3、功能结构分析

功能结构分析，是软件需求中最常用的，也是最基本的，但是建议将功能结构分析放在上述两类分析之后，以业务为主线梳理功能，否则容易出现软件功能与业务的割裂，或者软件功能与业务问题关联性不强的问题。

分析之后还需要进行提炼，抽出共性部分，并且消除需求间的矛盾和冲突部分。

最终输出需求说明书和系统原型设计，以此作为与客户进行确认的需求阶段成果。

只有扎实做好了需求分析工作，才能从业务实际出发，全局考虑，利用我们的技术优势，将客户的业务需求、用户需求提炼、整合、翻译成软件需求。这样才能有效指导设计和开发，交付符合客户业务应用的成果，解决客户的实际问题，甚至超出客户预期。

最后推荐三本需求分析相关的书《软件需求最佳实践》、《掌握需求过程》、《需求分析与系统设计》。