如何保证需求分析到位 减少需求变更与反工

      写这篇文章目的依旧是针对系统需求分析工作写的。在软件行业，系统需求分析工作的岗位安排可以是需求分析师（员）、业务分析师（员）和需求工程师，而需求分析的工作也可以归由产品经理（人员）或项目经理兼顾进行，有些需求工作可以放到售前。同时需求分析人员工作与架构师也是有交叉的，两者的关系与区别可见本人之前的一篇文章《软件系统分析师与架构师技能大PK》，可见一斑。
        需求分析本身也是一项工程，如果把需求分析当作需求工程的建设也是一种比较专业的看待了。做软件系统需求工作的内容包括：需求开发与需求管理两部分。需求开发包括需求获取、需求分析、需求报告；需求管理包括需求变更管理和需求跟踪。在此处本人整理了一个MM图来做说明。

 

关于需求分析工作的内容可以参见本人文章《浅谈信息系统需求》

2012以来，随着以Ipone4为代表的智能手机推向市场，移动互联网技术快速雄起，由此而来C端互联网经济得以快速发展，2016年2017年发展达到顶峰，可说，你只要有一个好的方案或点子，或OTO或BTC 的，只要有个好的点子加了一点口水能力，很快都会成为成功人士，就是这样，风口上的猪也一样可以飞。经过几年的江糊混战和急速发展，几家互联网巨头浮现出来，它们的触伸向各个角落，而其他小微的C端企业已无法企及，能取得最好的结果就是被巨头们收购，由此到18年下半年发展已慢慢趋向缓和，这些年C端互产网产业迅猛发展，我们得出了一个在大家看来是铁一样的真理，那就是抓着流量和用户体验你可以占地为王了。时间到2018年下半年开始，互联网市场风头开始转向B端，说那么多C端互联发展的事，与其就是介绍一下互联网市场情况，不如说是为软件的需求分析目标做一个铺垫。而如果互联网技术要走向B端，那么总结的两个关键点，一个流量指标一个用户体验指标的真理可以继承到50%，那就是后者用户体验，而流量放到B端的互联网技术真没什么瓜葛，完成失效。

本文所及的业务分析、需求分析、需求调研、变更等等话题都是专针对面向B端的互联网技术而来，更确切的说是面向企业或政府的管理软件项目管理技术而来。

与C端互联网产品最大不同点是企业管理信息系统或政务信息系统的开发更偏向与业务，以围绕管理业务做系统开发。可以说是以业务驱动或以领域驱动的软件开发。

最早几年，我是服务于大型企业的信息部门，建设开发软件系统基本上都是为本公司其它业务部门而开展，即软件的用户都是其它各业务部门。一部分自研软件，一部分外购软件，而外购包括购买成品和定制开发两种，而定制开发的项目对需求的把握由为重要，可见本人文章《客制化信息系统项目管理必须重视的几方面工作》略有描述。不管自研还是外购的软件，业务与需求分析工作都是不可避免的，对于外购来说，那就是看本项工作内容放到甲方还是乙方，而我们单位选择的是需求放甲方，也就是说把详细的需求描述清楚后把需求分析的成果作为乙方的项目建设输入。当然很多公司外购方式是需求工作也交由给乙方。而那是在甲方企业信息部门没有系统开发团队或没有信息部门的情况下所选择的外购方式。

对于面向企业的管理系统和政务软件系统的需求分析工作是举足轻重的，不可逾越的过程。起初面得各种情况，对需求工作内心是疑虑的，可见本人文章《做需求分析师的几点困惑》略有描述，但在工作过程中悟出的放之四海皆准的东西。   要写的内容也很多，作为需求分析工作的正文，以上的述说只是一个引言，但本文不是要写具体需求分析工作的工作内容，也不是写如何做好这些工作内容，为了不造成文章的头重脚轻的后果，下文就直入主题的开展写作了。

如何让需求分析到位呢，业务与需求分析员的工作包括从需求调研到需求报告和规格书的产出及后续开发过程中的沟通整个过程，还是需求的变更控制过程。那么影响到分析成果的关键环节就是对业务领域的熟悉度及描述业务的能力。具体来说就是需求调研、需求分析、需求文档编码的方法与策略的把控力度。而要保障不出现重大反工，那就后续需求变更控制和整个开发过程的沟通也一样重要。

    理论的东西往往是建立在一定设定好的条件基础上，软件设计的说法叫假设性约束，以下总结的几方面不是理论的总结，而是结合理论在工作实践的中几点干货。

一、从组织上偏向业务吧

我们可以在团队中安排一名等业务的专家，如果公司内部没有条件，那么也可以取得甲方的支持，这个角色可以由甲方安排人员，可以寻求咨询单位的帮助，当然成本控制和商务上的配合是有必要。C端产品研发型公司可以按互联网技术专业分划分部分，那么我们呢，我们更合适以业务领域划分部门，如PDM部门、MES部、管线部等。

二、调研也是要讲究策略的

不要以为甲方业务部门帮你解答业务问题是免费义务的劳动，不要以为甲方或业务部门领导指派了，就什么都能调研到了。你必须自己通过各种办法各种渠道掌握信息，熟悉业务需求。适当的利用商务渠道和商务人员是有必要的，适当的运用私人关系也是有必要的。见另一篇文章《工厂项目调研》讲了讲项目需求调研的故事。

三、分析的方法有多种，选择合适的。

不管什么方法，先建立好业务模型再建立需求，再到系统模型再到系统架构。

四、如何表述好需求

需求分析的主要成果，一是需求分析报告，二是软件需求规格说明书。那么如何写好它们，这个有国标，有公司模板，有UML规范，有CMMI规范，好吧，够多了。找合适自己的吧，不同项目不同方法，不同环境不同方法。这里告诉你一个比较万能的方法，那就是整个软件工程过程用例一条线走到底。业务用例à需求用例à设计用例à测试用例 。

五、如何沟通：

拿着图、拿着原型沟通吧。当然不是一开始就要整理一个原型，那效率太低，代价太大，我们的目标是以沟通清楚达成共识为主，所以看情况吧，能文字说清的就不要用图，能图说清的就不要用原型，能原型说清的就不用界面。当然口头的沟通与交流那就更得运用得当了。甭想着甲方或领导会签字。还是多发挥你的沟通水平吧。可以看看我的另一篇文章《项目管理中的沟通技巧》。

六、压轴

好吧，一点作为压轴，那就是对需求边界的把控，这是做需求工作核心的内容，需求边界决定着项目开发范围和工作量，决定着合同大小，决定着项目是事往下走。在编程开发的世界里，我们有面向过程的编程、面向对象的编程、面向服务的编程、面向组件的编程、面向方面的编程，这么多编程方法，和几个原则，比如封装原则 比如开闭原则 ，这些同样可以引入做需示分析，有利于对需求边界的所控。 当然这一点得需求分析人员和项目经理协作才能达成，与此同时项目管理中的项目范围管理也是一个很重要的工作。

项目的性质、规模、干系人都是多样的，如何在需求阶段把握好需求，除了理论上的论述，更重要的是在工作实践中总结摸索，当然应对各种情况还需要一个悟字。

按说以上每一点都可以整到几页纸的通篇文章，但出于本文篇幅的考虑，丛简介绍。