需求评审的思考
近在做需求评审员的工作，陪着不同的人，参与不同的需求评审，有些感触：到底需求评审员要做的工作是什么？需求评审需要明白些什么？
似乎答案很简单，需求评审员是需要让需求明确起来，让测试，开发，需求方都能对需求（这里的需求当然也包括需求实现方式）达成一致。排除各种需求之间的业务系统干扰。确保让需求与后实现的产品保持大限度地一致。似乎这是前期需要开展需求评审主要的目的。那么需求评审员在里面需要做到哪些？怎么样的需求评审完才能说明已经完成评审工作了？
起先，一直很迷糊，需求方在实现需求的时候，到底是如何实现的。也去咨询了一些需求方，大致明白了一些。如果把需求当作一份设计图，那么一开始原始的需求并是图纸上的几个重要的点，需要如何把这些点联系起来，搭建成一个基础的架构，是需求方要做的。PD是需求方的后一层，美化这个基础架构，搭建虚拟图，同时做好需求设计与技术方的沟通。那么需求评审要做的，是担任设计图的检测员，或者说与PD搭档结对设计的工作（这里与开发结对开发的思想一致，需求评审员不是对需求挑刺的，是PD的需求好拍档）。考虑需求架构的不完善点，补充或者修改需求实现方式。让需求更为立体。但是到底要怎么去做，也许有几个点可以来完善：
● 基础数据
（1） 理清需求内容，从基础来看，若需求包括数据获取，那么数据从哪里获取？有数据库或调用他人接口，即使是调用接口，也需要明确接口的实现方是哪里，是否会有隐藏的数据读取以及数据处理。
（2） 数据读取，这里主要适用于针对不同用户展示不同数据的需求。数据读取的前后顺序，以及数据读取的方式，是否满足用户体验（当然要先确认数据读取的方式是正确的，这部分需求方一般已经有方案）。
（3） 数据存储，主要有两种，一种是数据库表直接存储，一种是利用缓存。我们有时候的程序会考虑到性能的问题，为了减轻数据库的访问，一般会采用缓存的形式来存取数据。那么我们需要知道功能实现中该缓存的存储机制以及清除缓存数据的操作。往往功能实现后，清除缓存数据是容易忽略的一点。而数据库表的存储需要列出明确涉及到的数据库表，存储的字段特点，新功能需要附上数据库表结构，数据字段是个可以琢磨的点。
● 页面展现
（1） 字体截取及限制，适用于有严格界面展示要求的需求。例如手机上，适用于小屏幕查看的话，过长的显示，如果浏览器同时没有做好界面限制的话，会出现一团一团的字体。用户体验会很糟糕。
（2） 图片范围，特别是涉及到广告页面，以及需要在不同浏览器下展示的功能。需要先明确需求中需要的图片，考虑到性能还需要对图片的大小做限制，尤其是对手机上浏览，需要考虑到图片展示带来的流量。
（3） 顺序，返回结果较多的处理，通常需要考虑展现排序的问题。需要清楚排序的操作是在数据库表中已经处理完毕直接读取的，还是在程序中处理后展示的。对不同的结果需要采用不同的测试方式。
● 功能逻辑
一般需求上都对功能逻辑这一块描述的清楚，那么需求评审需要做的是在理顺功能实现逻辑后，在需求是否可作，需求各方面涉及方是否清楚，需求是否对其他功能有影响等几面展开思考。所谓走到需求前面去，主要的是解决需求中的实现逻辑问题，抛出更好的解决方式。当然个人觉得，如果在需求评审时，能够理清楚需求是否可作，直接否决需求实现，从而能够避免一些不必要需求浪费人力物力。这才是需求评审重要的。所以在实现需求前，需求评审文档上的需求背景，是需要关注的。
洋洋洒洒谈了一些对需求的看法。当然，完善需求方面上面的几个点还是远远不足的。仅仅也限于个人思考，记录下来，希望有更多的想法沉淀，欢迎大家能够对完善需求有更多的意见。
