在軟件開發中，需求分析和需求管理一直被認為是軟件開發成功與否的關鍵。
在CMMI中，需求管理是CMMI2級的過程域，需求開發是CMMI3級的過程域。
在瀑布型生命周期當中，安排了需求分析階段，一般也安排需求分析里程碑評審。
瀑布型生命周期存在了很多年，曾經幾度寫入到軟件開發的國際標準、國家標準當中。

由于瀑布型生命周期如瀑布般順流而下，在設計階段開始后，根據需求文檔的結果來開
展工作，要求需求文檔的結果比較清晰、穩定。所以對于需求確認，往往地采用簽字的
方式，希望各方慎重、全面、充分的確定需求。

簽字確認需求文檔這個做法幾乎成為一個標準過程，在大大小小的軟件開發中出現。
那么軟件工程發展了這么多年之后，發現經簽字確認的需求仍然有大量的變更，不禁要
問：需求文檔需要簽字確認嗎？
在軟件沒有開發的時候，分析需求需要各類想象，對于目前一般規模的商業軟件（全部
12人月工作量以上）而言，而無論做得如何仔細，就算訪問所有的干系人，也不能把所
有環節全部考慮到。而在軟件開發的過程中，時間在推移，隨著時間的推移，用戶的需
求會不斷的發掘、修正；開發人員對軟件需求的認知也是隨時間推移而漸漸的清晰。而
隨著軟件的開發部署，經過初步的使用，變更的要求、升級的要求就自然的產生了。

所以需求在變化，或者說需求在演化，這是客觀規律。

在需求的演化之中，簽字確認有用嗎？ 當然有用，用處是在這個簽字的一瞬間保留了需
求的一張快照，這張快照對于履行合同是有用的，在短期內指導后續的工作，但是除此
之外并沒有太大的用處。因為這演化中的需求會漸漸地與這張快照不一樣。

傳統的瀑布型生命周期中就需要設計需求變更管理流程，每一次的變更都需要多方的簽
字確認。為了維護一致性，還需要追溯需求文檔、設計文檔、代碼、測試用例的一致性
。需求變更成為不少項目風險的最大來源，成為大量項目不成功的最大原因。

簽字的另一個問題是簽字很麻煩，對于甲方而言，簽字意味著責任，往往要拖到最后，
認為各方面都沒有問題后才能簽字。而需求分析或變更都是后續工作的前提，簽字的拖
期也將推遲后續工作的開展。

因此簽字確認需求文檔的弊端有：
1，? 簽字不能真正的確認需求。
2，? 簽字過程慢。

所以，值得回過頭來反思：簽字確認的需求有用嗎？有沒有更好的方式？
如果需求文檔寫在軟件運行之后，那么以軟件運行的截屏為主體的需求文檔肯定比軟件
運行之前想象之中的需求文檔更加精準，而且書寫文檔所費工作量大大減少，而且這個
需求文檔經過簡單的轉換，就可以成為用戶文檔。

總結

以上是生活随笔為你收集整理的需求文档可以不签字吗？ 之一的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。