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

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

 

 

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

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

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

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

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

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

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

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

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

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

四、 详细描述软件功能点

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

需求分析的表现方式，我们现在采用需求规格文档，UML语言描述的用例图、类图、活动图，还有实体关系图、界面原型等等，从不同角度、不同需求描述规划出的软件全貌。

五、 需求分析的质量控制

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

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

 

 

 

在做项目时，经常会碰到这样的事情.
客户向我们反映在和你们的工程师谈论需求时，他们总是满口答应没问题。可是，当他们做好以后，拿过来一看，根本就不是这么回事。而开发人员也在诉苦：用户什么都不懂，而且他们的需求老是变动，时间又这么紧,你让我们怎么办？
我觉得如果开发人员在做需求分析时,如果注意以下几点,也许可以避免被动的局面. 

1、掌握相关的行业知识
在和客户沟通之前，最好了解一下相关的行业知识。
有一个项目管理人员说：行业知识可有可无，作为需求人员，最重要的是和客户沟通。最好把客户讲的东西都记下来。然后，由项目组决定后，再把意见反馈给用户。这种沟通方式，既不能有效的发现问题，也容易延误项目时间。
 
2、重在沟通
沟通的方式可以是访谈和调研、会议、电话、电子邮件、小组讨论、模拟演示等不同形式。我的意见是最好是与客户面对面的沟通。金庸武侠小说中的高手过招，都是面带微笑，不露声色，比拼的是内力。面对面的沟通，就是比拼内力。所以，一定要把准备工作都做好了。
沟通其实也是在相互妥协。对用户合理的要求，要尽量满足。用户的一些不合理的要求，要想办法避免。要委婉地提醒用户，如果这样做，可能要增加项目时间，或者对运行环境有更高的要求。
沟通一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。

3、深究细节
不要等到项目做好后，才让客户发现问题。
客 户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终  出来的系统是很难完全符合客户的业务流程的.这时，在客户看来当然需要更改.但这种更改却被我们看成了需求的更改。既然是需求的更改,那么就需要增加项目   成本(资源)或延长项目时间。我看过一篇文章,说要要想项目成功,就得和用户建立亲密的伙伴关系.可是,这种以需求的更改为理由让用户从口袋里掏钱,亲兄  弟也不干阿.
所以,需求分析不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。

需求是最重要的工作，也是最麻烦的。 客户是不懂需求的，他们的脑海里面没有这个概念， 他们只希望你做出能用的系统 ，用着顺手就好。
我认为做需求有几个地方是比较关键的
1.人际交往能力 。这是最根本的 不用多说
2.了解需求后及时做出demo让客户确认，确认后要签字。这一点非常重要，很多时候我们了解了需求就闷头开发，等开发完毕后，却不是客户想要的东西，造成巨大浪费；签字是为了让客户认真对待这个demo
3.能用就好，不要过多追求。程序员往往追求完美，想一下子把工作做到位；而最有效率的方法是尽快看到结果 然后再慢慢完善。在项目初期需求会经常改变，这样的目的也是避免把过多时间耗在无用的需求上。

做过软件的人都听过这样的抱怨：需求变化太快，软件系统经常要修改，都连续加班几个星期了……

通常面对这样的问题，要如何解决呢?

首先，问题的根源是：需求不断变化。

很多人都有这样的经历，在捕获需求时，根据客户的阐述，做了记录，然后开发出了软件，客户却说很多地方不符合他们的意思，又要求修改。

我们分析一下捕获需求过程中存在的问题。

客户很可能对软件方面的知识知之甚少，他并不知道你需要知道什么。

比如说，一个业务流程，从业务逻辑到能转化成软件实现很可能会有问题。这就是所说的信息化过程中需要进行的业务改造，因为能输入计算机，并输出结果的一  定是能进行形式化处理的内容，这也是很多企业员工抵制信息化的原因之一，因为信息化会导致人的因素会被相对削弱，他们的工作过程也会完全被透明化。

这样，我们就一定要让客户知道你要知道的是什么。如何做到呢?

对于产品类的项目，你的客户不是一个，那么就要广泛的去征求意见，需求调查问卷通常对全面了解客户需求有一定的作用。

对于特定客户，需要和他们直接沟通交流。

和客户交流要注意方式方法，不能盲目约见，下面是一些行之有效的方法。

一、 会面前做充分的准备

通常会面前的问题列表准备时间要远远多于会面的时间。通常客户在连续和你交谈2个小时之后，就会失去热情和耐心，这是大部分人的共同特点。所以充分的准备工作很重要。

如 果你去客户那捕获需求，通常客户会说，我需要做一个什么样的系统，然后我可以用它来做这个，那个，还有那个……，然后就不知道该说什么了。这  时，你一定要拿出事先准备的问题列表，针对每个大的功能的每一个功能点进行提问，一个都不能放过。对非功能的需求也同样不能放过，如客户需要的系统至少连  续运行多少小时不出问题，系统在若干数量的访问者访问时的响应时间范围等。

如果你在会面前没有对客户提供的资料，表格等进行全面研究，对客户需求就不可能调查全面，你可能需要反复去约见他，这样你会给客户留下工作效率低的印象，他对你会逐渐的感到厌烦，对你未来的工作表现会失去信心。

二、让客户打开话匣子

对客户进行提问，引导客户说出他们的需求，是非常关键的，这里面的学问也是很大的。

有一些人通常会问这样的问题：“你们的工作流程是什么样的?”，这种问题是非常经典的无效问题。

当你向客户提出问题的时候，你可以先进行换位思考，如果有人问你这个问题你该怎么回答呢?是不是很好回答呢?如果连你也觉得这个问题并不好回答时，就需要考虑换个问法了。

通常人们在谈论自己很熟悉的东西时，都会有说不完的话，对于客户自己每天做的工作，他为什么没办法对你谈呢?

问恰当的问题，问能让客户打开话匣子的问题，你就胜利了。

这 时你会面前的准备工作就显得尤为重要了，你要针对他们要做的软件的功能，一部分一部分的问，不能着急，要深入，并细致，对于他们如何处理这些事情的操  作习惯等都要重视，因为要改变他们的习惯，让他们适应你的软件的一种新的操作方法通常是会降低客户满意度的，甚至他们会要求你进行修改。

对于你对某些功能的猜想和假设，也一定要问客户，是不是根本就不需要，客户有时会碍于情面不好意思说出你的想法是没有必要的或是错误的，这时你一定要足够敏感，并勇于否定自己，这样会减少不必要的开发工作，也会给客户留下你很尊重事实的良好印象。

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

和客户面谈时特别要注意一点，就是千万不能浪费客户的时间，让他觉得非常无聊，这是捕获需求最大的忌讳。

一旦你犯了这样的错误，你再想约见他就难了，他很可能不愿意再和你会面了。尤其是企业中的领导，他们通常是日理万机，能抽出时间和你会面，你应该感到很荣幸，因此要格外珍惜会面的时间。

这也是很多作需求的人员常常抱怨的问题，“客户经常没时间见我，我有什么办法”，如果你遇到了这类问题，你一定要反省一下自己，是不是曾经犯过这样的错误，下次一定不要再犯了。

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

不同的问题需要问不同的人，需求中有很多是细小的操作级别的问题，也有很多是关乎全局的问题，这就要求一定要搞清楚什么问题去问什么人。

很多捕获需求的人员抱怨说，“客户答不上这些问题，他们自己都不知道要怎么做”，如果你碰到了这种事情，就要反省一下，你问对人了吗?

客户中有一些是大干部，有些是中层管理人员，还有操作人员。对于操作细节上的问题，一定要去问那些负责操作的人员，他们会更清楚每个步骤需要怎么去操作，如果你去问大干部这些问题，你通常会被搪塞，或者以工作太忙，还有其他得事等原因被打发掉。

对于关乎全局的问题，操作级别的人员给出的答案通常是不权威的，即便他们回答了你，你也一定要去大干部那里确认一下，再开始开发工作，否则你会后悔的。

五、发挥原型的效力

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

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

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

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

 

 

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

　获取用户需求

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

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

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

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

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

 图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、管理需求

 项目管理：怎样做需求分析 收藏 

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

　获取用户需求

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

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

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

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

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

　图1 获取用户需求的活动

　⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；

　⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。


● 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动：

　⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；

　⑵使需求符合系统的整体目标；

　⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。

　分析用户需求

　在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。分析用户需求需要执行下列活动：

　● 以图形表示的方式描述系统的整体结构，包括系统的边界与接口；

　● 通过原型、页面流或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价；

　● 系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等；

　● 以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。 　　

　图2 DFD示意图

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

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