最近在做需求評審員的工作，陪著不同的人，參與不同的需求評審，有些感觸：到底需求評審員要做的工作是什么？需求評審需要明白些什么？
似乎答案很簡單，需求評審員就是需要讓需求明確起來，讓測試，開發(fā)，需求方都能對需求（這里的需求當然也包括需求實現(xiàn)方式）達成一致。排除各種需求之間的業(yè)務(wù)系統(tǒng)干擾。確保讓需求與最后實現(xiàn)的產(chǎn)品保持最大限度地一致。似乎這就是前期需要開展需求評審最主要的目的。那么需求評審員在里面需要做到哪些？怎么樣的需求評審?fù)瓴拍苷f明已經(jīng)完成評審工作了？
起先，一直很迷糊，需求方在實現(xiàn)需求的時候，到底是如何實現(xiàn)的。也去咨詢了一些需求方，大致明白了一些。如果把需求當作一份設(shè)計圖，那么一開始最原始的需求并是圖紙上的幾個重要的點，需要如何把這些點聯(lián)系起來，搭建成一個基礎(chǔ)的架構(gòu)，是需求方要做的。PD是需求方的最后一層，美化這個基礎(chǔ)架構(gòu)，搭建虛擬圖，同時做好需求設(shè)計與技術(shù)方的溝通。那么需求評審要做的，就是擔任設(shè)計圖的檢測員，或者說與PD搭檔結(jié)對設(shè)計的工作（這里與開發(fā)結(jié)對開發(fā)的思想一致，需求評審員不是對需求挑刺的，是PD的需求最好拍檔）?？紤]需求架構(gòu)的不完善點，補充或者修改需求實現(xiàn)方式。讓需求更為立體。但是到底要怎么去做，也許有幾個點可以來完善：
● 基礎(chǔ)數(shù)據(jù)
（1） 理清需求內(nèi)容，從基礎(chǔ)來看，若需求包括數(shù)據(jù)獲取，那么數(shù)據(jù)從哪里獲??？有數(shù)據(jù)庫或調(diào)用他人接口，即使是調(diào)用接口，也需要明確接口的實現(xiàn)方是哪里，是否會有隱藏的數(shù)據(jù)讀取以及數(shù)據(jù)處理。
（2） 數(shù)據(jù)讀取，這里主要適用于針對不同用戶展示不同數(shù)據(jù)的需求。數(shù)據(jù)讀取的前后順序，以及數(shù)據(jù)讀取的方式，是否滿足用戶體驗（當然要先確認數(shù)據(jù)讀取的方式是正確的，這部分需求方一般已經(jīng)有方案）。
（3） 數(shù)據(jù)存儲，主要有兩種，一種是數(shù)據(jù)庫表直接存儲，一種是利用緩存。我們有時候的程序會考慮到性能的問題，為了減輕數(shù)據(jù)庫的訪問，一般會采用緩存的形式來存取數(shù)據(jù)。那么我們就需要知道功能實現(xiàn)中該緩存的存儲機制以及清除緩存數(shù)據(jù)的操作。往往功能實現(xiàn)后，清除緩存數(shù)據(jù)是容易忽略的一點。而數(shù)據(jù)庫表的存儲就需要列出明確涉及到的數(shù)據(jù)庫表，存儲的字段特點，新功能需要附上數(shù)據(jù)庫表結(jié)構(gòu)，數(shù)據(jù)字段是個可以琢磨的點。
● 頁面展現(xiàn)
（1） 字體截取及限制，適用于有嚴格界面展示要求的需求。例如手機上，適用于小屏幕查看的話，過長的顯示，如果瀏覽器同時沒有做好界面限制的話，就會出現(xiàn)一團一團的字體。用戶體驗就會很糟糕。
（2） 圖片范圍，特別是涉及到廣告頁面，以及需要在不同瀏覽器下展示的功能。需要先明確需求中需要的圖片，考慮到性能還需要對圖片的大小做限制，尤其是對手機上瀏覽，需要考慮到圖片展示帶來的流量。
（3） 順序，返回結(jié)果較多的處理，通常需要考慮展現(xiàn)排序的問題。需要清楚排序的操作是在數(shù)據(jù)庫表中已經(jīng)處理完畢直接讀取的，還是在程序中處理后展示的。對不同的結(jié)果需要采用不同的測試方式。
● 功能邏輯
一般需求上都對功能邏輯這一塊描述的最清楚，那么需求評審需要做的就是在理順功能實現(xiàn)邏輯后，在需求是否可作，需求各方面涉及方是否清楚，需求是否對其他功能有影響等幾面展開思考。所謂走到需求前面去，最主要的就是解決需求中的實現(xiàn)邏輯問題，拋出更好的解決方式。當然個人覺得，如果在需求評審時，能夠理清楚需求是否可作，直接否決需求實現(xiàn)，從而能夠避免一些不必要需求浪費人力物力。這才是需求評審最重要的。所以在實現(xiàn)需求前，需求評審文檔上的需求背景，是最需要關(guān)注的。
洋洋灑灑談了一些對需求的看法。當然，完善需求方面上面的幾個點還是遠遠不足的。僅僅也限于個人思考，記錄下來，希望有更多的想法沉淀，
歡迎大家能夠?qū)ν晟菩枨笥懈嗟囊庖姟?/P>