软件需求分析师一方面需要在产品规划和设计上投入较大精力，同时在重大项目上也会起到非常重要的作用，需求分析师承担好项目中需求分析的职责将提升项目的整体质量。那么需求分析师如何在项目中发挥到自己的作用呢，我有幸参与了“深圳”的一个较大规模的业务管理软件的升级项目，在此项目中感受颇深，以下5个方面是我在实际工作中总结出来比较重要的。
1. 准确全面地获取和分析需求
这个是需求分析师最基本的职责，也是需求工作的真正开始。需求获取和分析一定要注意准确性和全面性。
继项目合同后，需求是客户和乙方单位谈论最多的事情，客户方立项的时候都会对项目有一个总体的愿景，需求分析师必须有能力去理解客户方提出的愿景，如果具备一定的管理知识以及业务知识，会可以更好地理解客户所提出的这些愿景。但不管怎样在用户工作现场做一次业务调研是非常非常有必要的，因为每一家客户的实际业务都会有所不同，对现场实际业务了如指掌将非常有利于理解这些客户提出的这些愿景，更为重要的是可以和客户一起商讨他们提出的这些愿景如何转化为软件需求，不然你会觉得在整个需求讨论会里非常地被动，客户方项目负责人怎么说你就怎么去做，更为要命的是客户方项目负责人也都不了解实际业务，这种双方都在拍脑袋讨论问题的方式将会是一个很大的隐患。同时在设计新的功能模块的时候，对现场实际业务的熟悉也会显得非常重要，你在设计的时候能够根据现场业务实际情况去改变流程、改变操作方式，这将会使得后期的实施工作更加容易和顺利。所以说对实际业务的熟悉对准确地去获取和分析需求至关重要。
我参与的“深圳”这个项目属于系统升级项目，我们在公司开发出一个版本后，拿到现场做部署的时候发现，新系统好多地方都不及原来他们使用的系统，并且好多功能新系统都没有，这真是给我们当头一棒，在上线前试用的过程中修改和增加了很多功能，导致开发人员在现场驻扎了2、3个月去弥补之前需求调研没有调研到的需求，导致项目延期，让全项目组人员为我们需求人员弥补失误所付出的代价很惨重。所以在调研和分析需求的时候，一定要调研实际业务流程里的每一个岗位、了解清楚原来系统和新系统的差别以及客户方系统用户所在各部门之间的利害关系等等，保证获取和分析需求的全面性。
如上图，需求的全面性和准确性能够包含此次项目的问题范围，那么需求工作才算合格。
2. 控制和引导客户的需求
在和客户讨论需求的时候，客户的思维非常发散，你要控制不住他，他就控制住了你。并且客户方的项目负责人一般是该单位技术部门的，虽然在和我们乙方讨论问题的时候都比较强硬，但是他们面对真实使用该系统的业务部门时，就蔫了，业务部门的不良反应给他们的压力非常大，他们不愿意看到业务部门不高兴，最业务部门将抱怨捅到大领导那，落得个做事不利。所以接下来的就是让我们改程序，改到业务部门满意为止。
所以说如果在讨论需求的时候你被客户方的项目负责人拉着鼻子走，后果会很严重，有做不完的新需求和反复改来改去的问题。如果你想控制住客户方的项目负责人，你就得有真本事才行，除了出色的沟通能力外，更加专业和贴合实际业务的解决方案是非常重要的，这就需要需求分析师和实际业务部门建立良好的联系，对每一个解决方案都必须充满信心，如果你所做的解决方案能得到实际业务部门认可，客户方的项目负责人也就会慢慢地信任你，听你的了，因为既达到了他所要求的目标又能让业务部门满意，何乐而不为呢。
3. 保证系统的用户体验质量
我为什么将用户体验放在单独的一个要点呢，因为它实在是太重要了，我们在“深圳”项目上也在用户体验上载了很大的跟头。
先说系统上线之前在试用界面，我们程序所修改的问题类型。如下图。
再说上线后两周内修改问题类型，如下图。
除了这两个图片反应的问题外，还有一个由于用户体验造成的更为严重的问题。系统两个大的功能模块重新进行了交互设计。一个模块实在太难用，用户被里面的操作流程搞得云里雾里，总怕操作出错，并且实际上还是出错了，这个模块交互设计花了1天时间，开发加实施花了一周时间；另一个模块是财务相关的，由于界面的可用性很差，导致财务人员经常操作失误，数据库里产生了很多财务错误帐，这个模块交互设计花了大概2天时间，开发加实施花了两周时间，同时由于财务数据有误，导致开发人员驻扎在现场专门处理这些错误账务，为这事，搞得我们项目组和客户方都很头疼。
这两个模块的改进设计只花了两三天的时间，而开发实施和纠错缺花了一个多月，这个时间比也相当地高，如果能更早地重视用户体验设计，并加入到项目中，这些时间和资金都是可以节省下来的。
4. 编写高质量需求文档
当你已经将客户的愿景以及自己的调研成果转化为软件需求，并且客户和项目团队达成了一致的解决方案的时候，接下来的工作重点就是编写一份高质量的需求文档，这个需求文档将会被四种人阅读，客户方项目负责人、项目团队里的领导、项目团队里的开发人员以及测试人员。目前公司都有需求说明书的模板，但是在此项目中，有三点感受比较深。
第一个是需求文档的版本问题，在讨论需求的初期，客户的反复无常导致需求文档一直都在变动，中间出过有4、5个提交给客户的版本，并且由于项目组人员流动的原因，这几个版本一共经过三个人之手，我们每一个人都是在讨论过一轮需求后从头开始写，几个版本下来后让客户也晕了，每个版本里面同样的问题，解决方案有些不一样。所以需求文档一定只能有一个版本，每一次更新都在一个版本里面进行，并且做详细的版本更新记录。
第二个是需求的描述问题，给开发人员的需求必须是明确的无二义的，这次项目需求文档写的时候，让程序员还有自己发挥的空间，开发完了客户不是很满意，又做一些反复修改，同时在需求文档里面没有加上交互设计的约束，导致开发出来的模块很难用，也导致了上面提到的悲惨教训。
第三个是在写需求的时候，没有考虑这个需求是否可测，每一个需求、每一个解决方案在写进需求文档的之前都要想好是否可以被测试和被验证，譬如“深圳”项目中有一个需求是“增加勾选项：上传图片成功后删除源文件，勾选上后上传成功后删除源文件，不勾选不删除源文件”，这个需求开发人员做出来了，但是当时没有写清楚“上传成功的标准”，测试人员测试的时候只能说看到系统提示上传成功了，并且源文件也被删除了，说明此需求测试通过。但是其实图片根本没有上传成功，图片目录里没有此图片，其实程序存在bug。所以说在写需求的时候一定要考虑这句话是否可以测试、可以被验证，如何测试、如何验证。
5. 管理好每一个需求
项目中需求变更避免不了，在“深圳”这个项目非常的多，在系统试用阶段，新需求有230个，占了整个修改问题的38%，如下图。
这些新需求都是在试用中与实际业务摩擦出来的，这个一般避免不了，前期很难考虑全面。但是不能碰到问题就给改，一定要在内部讨论和外部讨论后再做修改，内部讨论是指项目组内的，主要考虑修改的工作量、紧迫度（用户对此需求的渴望程度）以及风险。
如上图，可以简单按照紧迫度和风险，来判断问题的修改优先级。
外部讨论是指和其他用户及部门商讨是否需要修改，业务管理系统涉及到的部门比较多，经常是众口难调，一定要在协调好各部门的意见后再做修改，尽量不使用增设配置项开关的方法去避免部门之间的不一致，因为带来的维护难度加大，并且让不同部门之间直接交流也避免让自己夹在中间难受。同时修改的时候一定要做记录什么时候提出的、谁提出的，在这个项目里面有很多修改了，然后又修改回来的问题，但是和客户去争论的时候也拿不出证据说什么时候谁说要改的，很郁闷。
除了需要管理好这些变更的需求，也要管理好需求文档里的所有需求，要做到把关作用，每一次版本补丁的更新之前，都要检查一遍程序，保证系统的质量，让现场的用户为我们测试软件的后果很严重，带来的都是抱怨和不满，虽然能够加快项目的进度，但是未经测试和验证的版本尽量不要放到用户的面前。
从项目的初期到结束，需求分析师的职责其实是从一个专业的设计师到非正式的管理者的过程，前期重点的工作是通过专业的调研方法、分析方法需找问题的有效解决方案，是从设计师角度去考虑问题，需要的是探索能力和新能力；而在项目的中期和后期，更多的工作是非正式管理性质的，要从管理者角度考虑问题，需要更多的是执行力和协调沟通能力，以需求为中心，协调好客户、用户、开发、测试人员以及服务人员。
一个只会传递需求、解释需求的需求分析师只能说是及格；在项目中能够创新，拿出精彩的解决方案，同时又能让开发团队顺利做出来才是优秀的需求分析师，即创造力和执行力。