本文出自:【ouyida3的部落格】
近期在做專案時，依據專案計畫，在使用者輸出了《需求書》後，須要我在2天編寫出《需求規格說明書》。可是就這個說明書是什麼，要編寫什麼我和使用者產生了較大分歧。甚至對專案還產生了一些不好的影響，比方被領導臭罵。
軟體project裡對於軟體專案各個過程須要輸出的文件都有明白的定義，可是每乙個方**又是不太一樣，比方cmmi和敏捷的類似性就不大。當提到使用者故事那應該是敏捷而不是cmmi，當說起需求規格說明書就應該不是敏捷的。
叫什麼名字事實上我不太關注。拋開這些定義，乙個真實的需求分析到軟體設計的過程是如何呢？
created with raphaël 2.1.0使用者提出需求使用者與需求分析人員共同確認需求軟體設計人員進行設計
cmmi在上述的第一步，會輸出《使用者需求規格說明書》，第二步會輸出《軟體需求規格說明書》，第三步會輸出《軟體概要設計說明書》。
當然，使用者需求稱為客戶需求也行，軟體需求規格說明叫做軟體規格需求說明都能夠。這些我不關注。
我想表達的是，《使用者需求規格說明書》是業務人員寫的。《軟體需求規格說明書》是技術人員寫的，假設是甲乙方的專案，那就是甲方的技術部寫。而《軟體概要設計說明書》是乙方輸出。
因此。假設假設我並非甲方人員。讓我寫《需求規格說明書》，不管是使用者需求還是軟體需求，都是不合適的。回到主題。明顯須要我寫的僅僅能是《軟體需求規格說明書》。可是專案計畫裡簡簡單單的寫上需求規格說明書是不恰當的。
先說說沒有什麼：一定不涉及技術元素，比方選擇什麼技術路線。選擇什麼程式語言等等。
也沒有什麼資料庫的設計。
一定要技術人員和使用者都看得懂。這樣使用者能夠依據這個來驗收，技術人員也能夠依據它來進行概要設計。
當然。也要依據使用者的需求書來驗收，可是畢竟它和軟體系統脫離的，有些關於系統操作類的精確事項無法描寫敘述到。
舉個樣例，比方有四個不同的業務人員各自提出需求。他們之間的需求肯定有類似的地方，也有不同的地方。那麼《軟體需求規格》就須要把同樣點歸併，不同點如何體現編寫出來，而且與四個業務人員確認，這樣合併能否滿足了這個需求。假設有一些現存的老系統，那麼也須要說明對老系統進行什麼樣的改造（非技術類說明）。
上面的樣例，能否2天編寫完畢？我覺得要看系統大小。假設是10人月以上的系統。2天是遠遠不足夠的。
依據經驗。我個人覺得是1人月的系統。大概須要2人天寫這玩意。
敏捷強調小步快跑。所以由使用者寫使用者故事，完後直接就分析故事排計畫，簡單一些設計文件後就直接編碼開幹了，**是最好的設計。通過不斷的迭代完好。可是大專案、大系統，還是須要一些文件統籌設計的。
具體可看mike cohn大師寫的書《使用者故事與敏捷方法》
需求規格說明書
團隊專案之需求規格說明書 任務描述 根據需求分析階段性成果物 編制完整的需求規格說明書 任務目的 一方面鍛鍊需求分析文件編寫能力，另一方面通過對內容評價，掌握需求分析方法 引言部分及階段報告 葉鴻 主要 其他成員參與討論 專案概述部分 張瑞源 主要 其他成員參與討論 功能需求部分 童子銘 主要 其他...
python需求分析說明書 需求規格說明書
1 概述 summary 1.1 專案的目的與目標 purpose and aim of project 學員體能成績管理系統需求說明書是為了讓系統的涉眾就該系統的需求達成一致認可，明確該系統的需求，為後續的開發工作提供依據。通常，該需求規格說明可以作為產品設計的主要依據，並作為程式設計師編碼時了解...
軟體需求規格說明書
在整理完與使用者的談話稿，交付使用者審閱後，下一步是制定軟體需求規格說明書了，貌似和客戶簽約需要依據這份規格說明書，一旦確定，雙方達成協議簽字後，使用者如需更改增加功能是需要再付費的。主要內容有 1.簡介 1.1 目的 1.2 應用範圍 1.3 術語及縮寫定義 2.全面描述 2.1 系統用例圖 2....