【PM】【需求】项目管理-需求：管理软件需求分析过程

文章概括为，纵向，横向，从面到点，最后是需求质量控制。

软件的需求分析必须要有对原业务的一个深入了解、提取、抽象、升华的过程。

软件的需求分析是从用户的业务中提取出软件系统能够帮助用户解决的业务问题，通过对用户业务问题的分析，规划出我们的软件产品。这个步骤是对用户业务需求的一个升华，是一个把用户业务管理流程优化，转化为软件产品，从而提升管理而实现的质的飞跃，这一步是否成功，直接关系到开发出来的软件产品能否得到用户认可，顺利交付给客户，客户能否真正运用我们的产品帮助他解决业务或管理问题。

按照软件工程对软件开发过程的描述，需求阶段我们可以细分为需求调研和需求分析两个小阶段，需求调研需要充分细致的了解客户目标，用户业务内容、流程等，这是一个对需求的采集过程，是进行需求分析的基础准备。当我们已经了解、理解了用户的业务，于是可以开始分析需求了。软件系统的需求分析可以由产品工程师或系统分析员或两者分阶段合作完成全部的需求分析工作。

一、 提取出核心、主要、急迫的业务，明晰业务流程

通过需求调研，我们会发现用户各方面的业务很多，从大处着眼，包括用户的各种业务项目、业务流程，再明细到业务过程的每一个单据，每一条记录，如生产过程中每一个环节的记录，办公中的每一个通知，甚至包括文件 刊的收发，计划生育指标统计等等。如此繁杂的各类业务，我们从何下手时需要我们回头去查看软件的项目规格说明书，再次温故客户对软件项目或产品的最初提出的需求目标和范围，我们的软件主要是为用户解决什么样的问题。从众多的业务中提取出用户核心的、主要的、急需的业务，这些是我们软件需求主要关心所在。写一篇文章需要重点突出，主次分明，我以为规划一个软件产品也是同理。

从用户繁杂的业务中进行业务、业务流程的提取，把那些分布在各个部门的同一种业务提取出来。比如物资的管理，涉及到生产部门的需用计划，汇总到物资部门的采购计划，计划的审批，采购合同，物资采购，物资部门的收发存业务，生产部门的物资领用消耗等等，我门需要分析用户的这个业务流程中哪些是系统能帮助管理的，哪些是要在系统外处理的，充分分析了用户现有的业务和业务流程，我们进入下一步骤。

二、 运用管理思想，优化业务流程

我们提供的是管理软件产品，要帮助用户解决的是管理问题，那么用户是这样的业务流程，就需要我们分析这样的流程合理吗，还有缺陷吗，怎样做能提高效率、解决问题，可以运用更先进的管理思想吗……。一般情况下，我们需要从两个方面考虑业务流程的优化。一是我们采用了 络计算机这些新的技术手段，较之原先手工、电话等方式在信息的传递、信息的共享、数据的处理等方面将会带来新的方式，必将改变原有的业务流程。另一方面就是我们根据对用户业务的理解，考虑是否可以运用先进的管理思想，比如MRPII、ERP、SCM、CRM、JIT、EIA、E-Business等等管理模型，进行现有业务流程的重组或优化。当然一旦牵涉到业务流程的修改一定要与客户的中高层管理者进行充分的沟通，只有客户认同方可确定，因为这一定会在软件实施时需要相应的管理制度配套执行。

三、 进行业务分类，规划系统蓝图

以上都明确了以后，我们可以描绘系统蓝图了。系统有几个子系统，每个子系统有哪些模块，各个模块处理哪些业务，很重要的一点还有各子系统模块之间的数据接口关系，基础数据从哪里进入，通过哪些处理生成哪些结果等等。这个过程需要整理、抽象用户业务，规划软件实现，规划软件系统模块间的逻辑关系。因为系统的页面实现是按照系统模块的规划，所以应尽量采用用户易理解、熟悉的方式、词语进行模块的描述。例如ERP系统中的物资管理子系统，首先明确这个子系统是ERP系统中进行物资相关的业务处理系统，同时它为主生产系统、成本管理子系统提供生产物资供应、领用消耗核算等的数据支持。因此在规划子系统模块时，按照业务过程模型，应包含物资需用计划、物资采购计划、出入库管理、库存管理等主要业务模块，再考虑软件运行必须的初始数据设置，增加一个基础信息维护模块(包括物资大类、物资编码等信息维护)，还有考虑到不同用户对此系统的不同需求，如更多的生产人员、管理人员的需求，再单独增加一个综合查询和分析模块。另外还有与物资采购相关的业务如采购合同，可以放到合同管理子系统统一考虑，这里只做查询。这样规划出了软件系统对物资管理业务的处理，检查一下是否包含了物资管理中所有核心、主要的业务，这时我们发现还有比如物资采购、验收、盘库等业务还是需要物资管理业务人员来完成，系统可以做到的就是记录结果。软件系统是管理的辅助系统，不能完全代替人的所有工作。管理软件再加上管理制度、业务人员的操作才构成一套完整的管理体系。

四、 详细描述软件功能点

规划出了软件的功能模块，只是软件的功能框架结构，下一步就需要明确描述每个模块的具体内容了。包含什么内容、能做什么操作，每一个功能点的说明、优先级、业务规则、详细功能描述等等。这些也是软件需求规格必须描述的内容。

五、 需求分析的质量控制

软件需求分析直接关系到软件产品的方向，所以需求分析的质量至关重要。对于这个关键点的质量控制，则可以通过内部评审和同行评审的方式，然后是客户方的评审。项目组内部评审或同行评审主要是根据公司规范和评审人员本身的经验对需求分析中不明确、不合理、不符合逻辑、不符合规范的地方予以指正。而客户的评审主要是对描述的软件实现是否真正符合他们的需求，能否帮助他们解决问题等方面作出评定。

软件的需求分析必须要有对原业务的一个深入了解、提取、抽象、升华的过程，管理软件需求分析尤其如此。

 
2、重在沟通
3、深究细节
二、让客户打开话匣子

三、千万不要浪费客户的时间

四、搞清能正确回答问题的人

原型对于提高客户对软件的认知程度有很好的效果，他能使客户对软件有一个直观的认识，面对原型，他们可以更好地提出他们的想法和意见，尤其对那些对软件缺乏认识的客户。

对原型的修改，再确认，最后得到稳定的原型，这些工作会让需求更稳定，减少很多实施工作中的反复修改工作或者返工。

六、充分利用需求确认会议
（此方法成本太高，个人体会）
需求确认会议通常由全体涉众(利益相关人)参加，这可是个确认需求的难得的机会，大家能聚在一起，这样的机会其实很难得，所以一定要珍惜。

在 这种会议上，一定要先针对全局性的问题(与大家都相关的问题)进行交流，千万不要针对部分人感兴趣的问题讨论个没完没了，那样的话，不感兴趣的人会走  开的，那样你再想征求与他们相关问题的意见时就找不到人了。对于只跟个别部门或人员有关系的问题你可以单独找时间根他们讨论。

如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。

　获取用户需求

　这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动（如图1所示）。

　● 了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。

　● 对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。

　● 需求分析人员对收集到的用户需求做进一步的分析和整理。下面是几条常见的准则：

　⑴对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；
 

图2 DFD示意图

　用于需求建模的方法有很多种，最常用的包括数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。DFD作为结构化系统分析与设计的主要方法，已经得到了广泛的应用，DFD尤其适用于MIS系统的表述。DFD使用四种基本元素来描述系统的行为，过程、实体、数据流和数据存储。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断活动的时序关系。图2描述的是某个项目的DFD示意图。

　ERD方法用于描述系统实体间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。需求分析阶段使用ERD来描述现实世界中的对象。ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。如果将ERD与DFD两种方法相结合，则可以更准确地描述系统的需求。

　在面向对象分析的方法中通常使用Use Case来获取软件的需求。Use Case通过描述“系统”和“活动者”之间的交互来描述系统的行为。通过分解系统目标，Use Case描述活动者为了实现这些目标而执行的所有步骤。Use Case方法最主要的优点，在于它是用户导向的，用户可以根据自己所对应的Use Case来不断细化自己的需求。此外，使用Use Case还可以方便地得到系统功能的测试用例。

　介绍了需求分析五个步骤中的前两个步骤（获取用户需求、分析用户需求），继续介绍后三个步骤（编写需求文档、评审需求文档、管理需求），并与大家讨论相关实践问题。

　1、编写需求文档

　需求文档可以使用自然语言或形式化语言来描述，还可以添加图形的表述方式和模型表征的方式。需求文档应该包括用户的所有需求（功能性需求和非功能性需求）。

　2、评审需求文档

　需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。

3、管理需求