就壞事了。爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。同時也解決不了問題。所以，在評審會的過程中，我們要盡可能的是在闡述事實與證據(jù)，而并不是從你心底要如何地說服別人。
   人們在很多時候分不清楚自己究竟是“堅持真理”還是“固執(zhí)己見”。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應當養(yǎng)成良好的習慣：不要一棍子打死異己的觀點，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。試著從不同的角度去看同樣的問題。
{項目名稱}評審報告_需求
基本信息
工作產(chǎn)品.版本號
名稱，標識符，版本，作者，時間
工作產(chǎn)品標識號
評審方式
第幾次評審
工作產(chǎn)品存放路徑
評審地點
評審時間
參與人員
評審人員名字
工作單位或部門
職務職稱
簽字
問題記錄及處理意見
問題編號
位置
問題描述
問題類型
嚴重程度
Problem A
Problem B
評審結論
評審結論
[ ] 工作產(chǎn)品合格，“無需修改”或者“需要輕微修改但不必再審核”。
[√] 工作產(chǎn)品基本合格，需要作少量的修改，之后通評審組長檢查即可。
[ ] 工作產(chǎn)品不合格，需要作比較大的修改，之后必須重新對其評審。
簽字
需求承諾（Requirement Consent） 
    什么是需求承諾，是指開發(fā)方和客戶方的責任人對通過了同行評審的需求階段的工作產(chǎn)品，作出承諾，同時該承諾具有商業(yè)合同的同等效果。 需求承諾如下：
需求承諾
XXX項目需求文檔_《XXX需求說明書》，版本號：X.X.X,是建立在XXX與XXX雙方共同對需求理解的基礎之上，同意后續(xù)的開發(fā)工作根據(jù)該工作產(chǎn)品開展。如果需求發(fā)生變化，雙方將共同遵循項目定義的“變更控制規(guī)程”執(zhí)行。需求的變更將導致雙方重新協(xié)商成本、資源和進度等。
甲方簽字
乙方簽字
    不少人會草率地對待需求承諾：不就是在一張紙的最后一行文字下面簽字嗎，反正已經(jīng)評審過了，我就簽吧。但他將來變更需求時可能會表示不瞞：“不錯，我是簽字了，但是我并沒有閱讀文檔。是你們要我在文檔上簽字的，我是相信你們才這么做的。”為了避免發(fā)生此類糾紛，人們在作出承諾之前務必要認真閱讀文檔，一定要明白簽字意味著什么。
需求跟蹤(Requirement Track)
    為什么要進行需求跟蹤？在整個開發(fā)過程中，進行需求跟蹤的目的是為了建立和維護從用戶需求開始到測試之間的一致性與完整性。確保所有的實現(xiàn)是以用戶需求為基礎。對于需求實現(xiàn)是否全部的覆蓋。同時確保所有的輸出與用戶需求的符合性。
需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤：
   正向跟蹤：以用戶需求為切入點，檢查《用戶需求說明書》或《需求規(guī)格說明書》中的每個需求是否都能在后繼工作產(chǎn)品中找到對應點。
   逆向跟蹤：檢查設計文檔、代碼、測試用例等工作產(chǎn)品是否都能在《需求規(guī)格說明書》中找到出處。
    正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護《需求跟蹤矩陣》。需求跟蹤矩陣保存了需求與后續(xù)開發(fā)過程輸出的對應關系。矩陣單元之間可能存在“一對一”、“一對多”或“多對多”的關系。
見下表：簡單的需求跟蹤矩陣示例。
需求代號
需求規(guī)格說明書V1.0
設計文檔V1.2
代碼1.0
測試用例
測試記錄
R001
標題或標識符
標題或標識符
代碼文件名稱
測試用例標識或名稱
R002
…
…
…
…
…
…
…
…
…
簡單的需求跟蹤矩陣示例1 
    使用需求跟蹤矩陣的優(yōu)點是很容易發(fā)現(xiàn)需求與后續(xù)工作產(chǎn)品之間的不一致，有助于開發(fā)人員及時糾正偏差，避免干冤枉活。
    很多人有這樣的誤解：如果依照“需求開發(fā)－系統(tǒng)設計－編碼－測試”這樣的順序開發(fā)產(chǎn)品，由于每一步的輸出就是下一步的輸入，所以不必擔心設

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html