項目前期會需要進行需求、目標、范圍等的確認，同時在這當中，我們總是會強調要將確定好的內容進行書面簽字確認，所以也就是說，項目組要提前將內容進行撰寫。

　　同理項目需求管理也需要有這些操作流程，在進行需求管理時，關于文本撰寫這一塊也是有其具體講究所在。下面就將說說到底應該怎樣進行需求文檔的撰寫與修正。

　　一、初步需求文本撰寫

　　需求類別和模板確定之后，就要分配給項目相關負責人去撰寫需求。對中大型項目來說，撰寫需求說明書的人應該有多個，所以需要切分工作任務。

　　切分的原則是：每個任務盡可能獨立，任務的安排盡可能并行;每個任務必須要確定完成時間，如果時間不滿足項目進度，需調配其它人力資源進行協助;有些項目比較特殊，可能現有項目成員的專業能力無法覆蓋，此時需要引入外部專家或者將這部分任務外包出去。

　　為了把控需求收集的進度，需求撰寫計劃中要安排幾個檢查點。假如需求撰寫的排期是1個月，那么就可以設置3個檢查點。每到一個檢查點，各個需求撰寫人需將成果匯總到項目經理手里做審查，根據審查的意見或建議迅速調整或整改。

　　二、內容審查簽字確認

　　當需求文檔完成審查之后，即可交付給業務負責人做確認。為了加速業務負責人確認需求文檔的時間，可以邀請業務負責人參加需求評審會，或者講述一遍業務需求，然后再讓業務負責人線下確認，如果有修改意見，可約定郵件或者備注形式反饋，同時要跟對方說清楚確認完成時間。

　　三、反復討論認證修改

　　當業務在確認需求說明書的過程中有反饋意見提出時，需盡快討論并確認意見的合理性，對合理的需求需盡快更新到需求說明書中，再次提交確認，必要時可能需要再次訪談。

　　例如，自己從業務入手，整理業務的流程，畫出業務流程執行的yes線和no線，no線其實就是可規劃的幾個產品方向。然后針對不同的產品方向做進一步評估，看哪一個方向是眼下可行性最高，價值最大的。拿著選定的產品方向思路，和業務相關的同事去驗證，看這個產品是否對她們業務有幫助，在這個過程中，逐漸就明確需求了。

　　項目需求文檔既不屬于技術文檔也不屬于個人報告類，因為需求是客戶提出的“想法”，也是項目組之后實現目標的“來源”，因此大家在撰寫需求文檔時，既需要條理客觀，也要經過思維分析后的描述，同時還要注意其中的語言色彩既要讓大家能明確知曉是要做什么，又不會容易產生理解誤差。

　　而且就像需求本身也不是一次就能確認的，需求文本作為需要大家明確確認的文檔事實，更是如此。