本人一直从事需求上线升级、维护、反馈优化的事项，几年来也参与了大大小小几百个需求，早期自己也是参与了接手需求、与客户反复交互、分析、设计、开发、测试、写文档、打包交付、上线支持、后续问题跟踪等各环节事项。但后期做的最多的还是现场需求发布后的评审、升级方案、版本升级、问题处理、反馈优化等事项，这里就以一个需求实施者的身份来看下需求的各环节。
首先我们接到需求，有文档形式、邮件形式、书面形式、口头的也有，显然这么多的形式对需求的管理是不利的，必须以某种形式为标准，其它的一概不能接受。 我们现在采用的是标准的文档格式，要求写明需求提出人、时间、需求范围、实施范围、针对那快提的需求、系统或业务现状、需求要达到的目的、必要的图表说明、联系方式等等。从这里可以看到对提需求的人要求是很高的，不是每个人都能提出需求的，需求有针对业务的、针对运营支撑的、针对系统优化的，显然对业务或系统不熟悉，是不可能提出高质量的需求。
需求按照标准拿到了，下面就要与客户反复交互了，一般是集中开需求讨论会，个别的电话邮件沟通，包括需求提出人、系统分析师、项目经理、开发人员等，大家面对面地对每个需求从业务、技术、系统配置要求、数据库的承受能力等方面进行分析讨论，最后得出那个需求可行、那个不可行、以及需求的轻重缓急等（经济效益就不提了，有时钱不是放在第一位的，有些方面的因素可能比钱更重要），最后要得出一个量化的、细分的、可实现的需求方案。还有一个问题，就是如果双方在某个需求上无法达成一致意见怎么办，一方说能做，另一方说不能做，或者一方说必须这样实现，另一方又说只能那样实现，在意见不同的情况下如何解决呢，目前是由系统分析师来决定的，他说能实现或不能实现，别人都没什么意见，因为他是权威是专家，双方都信任他，显然要成为这样的人，必须要对业务、技术、系统了如指掌，而且还要有沟通的技巧、丰富的经验，否则是难于做到的。
设计、开发、测试等方面就没必要说了，到这里基本上也就水到渠成了，剩下的就是一些体力活了。这里重点提下文档，需求交给客户后，客户别的不看，看的就是文档，如果文档分类混乱、版面布局不合理、全是一堆文字等，那客户根本不看直接就给你打回去了，对于客户来说，他不可能去看你的程序文件吧，看的就是文档，如果就像上面的文档，那么其它的东西也好不到那里去。文档的质量体现了需求的质量，一份合格的需求文档，至少要有分析手册、设计手册、测试手册、测试报告、实施手册、维护手册、用户手册、需求说明书等基本的说明文档，各文档要目录清晰、内容简明扼要、语言要有针对性、简繁适中、图为并茂、重点部分特别提示等。而且文档也是后续系统维护扩展的重要资料，否则后续的工作就很困难了。
上线、使用、反馈环节是对需求的真正检验，一个经不起检验的需求不能称之为需求，需求就是解决实际问题的、是要创造价值的，不是用来看的，只有经过使用，才能得出它的性能、作用、价值，在使用中不断发现问题解决问题，使需求不断的健壮完善。例如，以前开发过一个需求，技术也能实现，也利于业务提升，但上线后导致BOSS接口调用量增加了一倍多，差点把BOSS搞瘫了，结果这个需求使用了1小时，就紧急下线了。很显然这个需求当初考虑不足，忽略了第三方系统的承受能力（现使用的好多需求都是与第三方系统有交互的，因此在分析设计时必须要考虑外围系统的承受能力、接口的同步机制等因素），否则其它部分做的再好，也是没有使用价值的。
最后聊下需求的生命周期，任何事物都是有生命周期的，需求也不例外，各个方面的因素导致需求到了淘汰的阶段，必定是要淘汰的。如客户的业务发生改变，有些业务淘汰了，显然相应的需求就会被淘汰。现在进入移动互联网时代，客户要搞集中化、虚拟化业务，减少资源提高效率，显然那些无法适应的需求也要被淘汰的；例如，2010年的NGCC项目，原来的3.0系统无法达到集中化、虚拟化，那整个系统都要淘汰，别说几个需求了。还有像偶然的突发事件，如近几年针对08年南方雪灾、08年奥运会、2010年亚运会等推出了相应的紧急需求，在这些事件结束后，这些需求自然也就结束了。等等还有别的什么原因，这里就不说了。
不同行业有不同的需求，同一行业不同单位的需求也是不同的，必须具体问题具体分析，从来没有什么标准和模板，现在网上也有好多什么需求分析宝典、指南来介绍这些东西，个人觉得可以参考，但别照着全做，那只是别人的并不是你的，你只能根据你的实际来做适合你的需求，要借鉴、分析、改进、优化、创新，走适合自身的需求之路，做到“青，取之于兰，而青于兰；冰，水为之，而寒于水。”
