編寫需求規格說明書是指得到要構建的產品的完整描述的任務。在需求分析的過程中，要把我們的每一步記錄下來，這並不是簡簡單單的寫報告而已，而是發現問題，理清自己思路的乙個很好的方式。需求產品說明書的完整是乙個開發軟體的必備條件，它必須包含清晰、完整、可測試的指令，說明必須構建什麼，清楚自己的目標。所以編寫需求規格說明書並不是一件容易的事，但我們可以借助一些輔助手段來完成這份說明書，那就是我們常見的模板。
就好像我們在寫實驗報告的時候，老師會給我們參考的模板一樣，編寫需求規格說明書時，也有相應的模板輔助參考。書中就介紹到了volere需求規格說明書模板，因為之前已經有了很多這方面的說明書案例，所以也稱volere模板是「站在巨人的肩膀上」完成的。模板中包含了四大塊主要內容。第一部分是限制條件，主要包括了產品的目標，產品的使用者等等，這一部分其實和軟體的相關功能之類的沒有什麼聯絡，但卻與我們軟體開發的過程緊密相連，其中的很多條件都直接的決定了開發出來軟體的***壞。之後就是功能性需求和非功能性需求了，這部分我們聽到的次數多，也了解的多，對每項功能都要描述的清楚詳細，邏輯縝密。最後一部分就是專案問題了，有關軟體一些後續的問題。
編寫需求規格說明書並不是一朝一夕之事，而是逐步補充逐步完善的過程。這並不是一項獨立出來的活動，而是與我們的開發過程緊密相連。不過理科生確實是在編寫文件這方面有點天生的神經大條，很多地方都想當然了，寫的不是很詳細。所以我應該在編寫文件這方面再多下點功夫，讓文件能夠真正的記錄下我的開發過程，而不僅僅是乙份有字的單薄檔案而已。
乙個軟體完成之後，一定會有相應的完成標準，或者說是驗收標準。這個功能實現了沒有，介面設計的符合了使用者的要求沒有，這些都是需要標準的。對於功能性需求的驗收，當然就是以功能有沒有實現為標準，要不就是實現了，符合標準，要不就是沒有實現，不符合標準，這個沒有中間值。而對於非功能性需求的標準，就比較多樣了，功能完成了這還不算，我們還需要知道是怎樣完成的，即對於完成的過程描述要更加精準。比如說，我的軟體執行計算速度很快，那麼就一定要精準到有多快，精準到時間，即完成這個操作有多少毫秒。
最重要的方面驗收完之後，還有一些細節的東西需要檢驗，比如有關文化政策方面的問題，軟體後期維護的問題，或者是法律相關的問題，我們都要考慮好。軟體是乙個共通的整體，一定要每個部分都完成了標準，才能算是乙個合格的軟體。
制定標準的時候，也要嚴格的按照我們的需求分析來規定，即我一開始是想做成乙個什麼軟體，我現在做出來的軟體和我當初設想的軟體是否一樣。因為我們並不是軟體的使用者，我們要站在使用者的角度來考慮問題，使用者不需要知道你用了什麼技術，寫了什麼**，他只看最後的軟體是否和自己的心意，用起來是不是比不用要方便許多。所以非功能性需求這一方面，我們做出的標準就要細緻些，站在使用者的立場，來測試這個軟體，因為他們才是真正的使用者。
**自
2020122702 掌握需求過程 3
質量關是每項需求正式進入需求說明書地方。我們在分析需求的時候，通常是把想到的各種各樣的想法都記錄下來，需求可能出現在任何地方，我們捕獲了需求之後，並不會直接分析需求，有必要存在，也不考慮需求的完整性和一致性。而有了質量關之後，我們就要完整的看某一項需求了，考慮這個需求是否完整，是否合適放入到需求說明...
2020122602 掌握需求過程 1
需求必須在你開始構造乙個事物前，就要想好了。這本書前面所介紹的大部分就是如何才能知道這些需求，並且保證這些需求是正確的。書上的圖很簡潔明瞭的告訴我們，需求分析與系統分析在開發過程中的關係。在開發的前期，或者說是準備時期，需求活動佔主導地位，我們需要對現有的資料進行大量細緻的分析，要弄明白我們的產品是...
04掌握需求過程閱讀筆記之一
本次，我學習了業務用例，即萬無一失的工作劃分方法，從而為需求調研鋪平了道路。1.確定用例 用例及其用例 use case 這個術語最先由 ivar jacobson在1987年提出,用於描述系統及其使用者之間的互動。jacobson需要將系統分解為較小的單元,因為他感到物件模型不具備可擴充套件性。所...