寫在前面
如果你明確清晰知道需求規格說明書是什麼，則可以忽略此文章。如果你不清晰，建議還是閱讀一下本文，不然也許早晚會碰釘子。
轉載請標明出處：
http://blog.csdn.net/ouyida3/article/details/47683191
本文出自:【ouyida3的博客】
起因
最近在做項目時，根據項目計劃，在用戶輸出了《需求書》後，需要我在2天編寫出《需求規格說明書》，但是就這個說明書是什麼，要編寫什麼我和用戶產生了較大分歧，甚至對項目還產生了一些不好的影響，比如被領導臭罵。
需求書的定義
軟件工程裏對於軟件項目各個過程需要輸出的文檔都有明確的定義，但是每個方法論又是不太一樣，比如cmmi和敏捷的相似性就不大。當提到用戶故事那應該是敏捷而不是cmmi，當說起需求規格說明書就應該不是敏捷的。
叫什麼名字其實我不太關注，拋開這些定義，一個真實的需求分析到軟件設計的過程是怎樣呢？
cmmi的輸出
cmmi在上述的第一步，會輸出《用戶需求規格說明書》，第二步會輸出《軟件需求規格說明書》，第三步會輸出《軟件概要設計說明書》。
當然，用戶需求稱爲客戶需求也行，軟件需求規格說明叫做軟件規格需求說明都可以，這些我不關注。
我想表達的是，《用戶需求規格說明書》是業務人員寫的，《軟件需求規格說明書》是技術人員寫的，如果是甲乙方的項目，那就是甲方的技術部寫；而《軟件概要設計說明書》是乙方輸出。因此，假設如果我並不是甲方人員，讓我寫《需求規格說明書》，無論是用戶需求還是軟件需求，都是不合適的。回到主題，明顯需要我寫的只能是《軟件需求規格說明書》。但是項目計劃裏簡簡單單的寫上需求規格說明書是不恰當的。
軟件需求規格說明書有什麼
先說說沒有什麼：一定不涉及技術元素，比如選擇什麼技術路線，選擇什麼編程語言等等。也沒有什麼數據庫的設計。
一定要技術人員和用戶都看得懂。這樣用戶可以根據這個來驗收，技術人員也可以根據它來進行概要設計。
當然，也要根據用戶的需求書來驗收，但是畢竟它和軟件系統脫離的，有些關於系統操作類的精確事項無法描述到。
舉個例子，比如有四個不同的業務人員各自提出需求，他們之間的需求肯定有相似的地方，也有不同的地方，那麼《軟件需求規格》就需要把相同點歸併，不同點如何體現編寫出來，並且與四個業務人員確認，這樣合併是否能滿足了這個需求。如果有一些現存的老系統，那麼也需要說明對老系統進行什麼樣的改造（非技術類說明）。
談談時間
上面的例子，能否2天編寫完成？我認爲要看系統大小。如果是10人月以上的系統，2天是遠遠不足夠的。根據經驗，我個人認爲是1人月的系統，大概需要2人天寫這玩意。
談談敏捷
敏捷強調小步快跑，所以由用戶寫用戶故事，完後直接就分析故事排計劃，簡單一些設計文檔後就直接編碼開幹了，代碼是最好的設計，通過不斷的迭代完善。但是大項目、大系統，還是需要一些文檔統籌設計的。詳細可看Mike Cohn大師寫的書《用戶故事與敏捷方法》
轉載請標明出處：
本文出自:【ouyida3的博客】
2015.8.15
