質量關是每項需求正式進入需求說明書地方。我們在分析需求的時候，通常是把想到的各種各樣的想法都記錄下來，需求可能出現在任何地方，我們捕獲了需求之後，並不會直接分析需求，有必要存在，也不考慮需求的完整性和一致性。而有了質量關之後，我們就要完整的看某一項需求了，考慮這個需求是否完整，是否合適放入到需求說明書中，如果這個需求不夠完整，沒有存在的必要，那就會把它排除在外，或者直接放棄這個需求。之所以這樣做，是為了在後期軟體開發時，避免出現無用需求，如果到那時再改的話，將花費大量的人力物力。
有了需求之後，就要經過質量關的檢查了，就像食品檢查一樣，只有檢驗合格的產品，才能出了產品線進入我們的銷售渠道。首先應該先檢查它的完整性，需求的描述，需求存在的理由，需求的**，從各個方面對需求進行檢查，即需求是否還存在遺漏的地方。有了需求，就一定要承擔相應的風險責任，那麼我們就要衡量，我們所要承擔的風險，是否與我們的需求相匹配，簡單的說就是值不值得，值得就做，不值得就pass。和目標的相關性也要檢查，就是我們做的這個需求，是不是真的是使用者需要的，和我們的業務目標是否相關。總的來說就是，你這個需求，首先要完整，其次，你要對我們這個軟體有用，讓使用者滿意，沒有用的需求，或者使用者覺得不喜歡不滿意，那也就沒必要存在了。
原型的建立也很重要，它能讓使用者更加明白我們要做的東西，簡單易懂。我們寫出一種情況，就好像書上說的，我有乙個電吹風，做電吹風這個東西，功能性需求那當然就是能吹熱風，非功能性需求那就多了，就需要和使用者進行交流了。
比如說，我想自己調節吹涼風或是熱風，我希望電吹風可以有多個檔位而不是只有快和慢兩檔，或者說我想讓電吹風有時間計時功能，到了之間就自動停止等等。通過對場景的模擬，來看使用者想要什麼。因為有的時候你問他，你想要什麼功能，可能他也說不出來個一二三，或者他只會說，我想要乙個可以吹頭髮的電吹風。所以這個時候我們就需要模擬一些場景，來引導使用者說出他們真實的想法，真實的需求。遇到這種情況，你想怎麼辦，會比直接問，你想要什麼功能要好的多。
我們的需求規格說明書也是需要檢查的，主要就是檢查需求是否有遺漏，是否有衝突的和是否有二義性的。比如涉及到個人隱私資訊的東西，是否考慮到資訊保安方面的東西了。使用者用這個軟體，個人資訊不被洩露這是最基礎的。需求中用字一定要精準，避免存在二義性，像「應該」、「大概」這些詞都不應該出現在需求說明書上。
需求分析說明書是我們需求分析的最終結果，一定要再三檢驗之後，才能進入到真正的開發階段，需求分析和軟體開發的重要性是同等的，並不存在孰輕孰重的問題，如果連需求分析這個基礎的做不好，就像蓋樓一樣，地基不行，蓋出來的樓也一定不合格。
**自
2020122702 掌握需求過程 2
編寫需求規格說明書是指得到要構建的產品的完整描述的任務。在需求分析的過程中，要把我們的每一步記錄下來，這並不是簡簡單單的寫報告而已，而是發現問題，理清自己思路的乙個很好的方式。需求產品說明書的完整是乙個開發軟體的必備條件，它必須包含清晰 完整 可測試的指令，說明必須構建什麼，清楚自己的目標。所以編寫...
2020122602 掌握需求過程 1
需求必須在你開始構造乙個事物前，就要想好了。這本書前面所介紹的大部分就是如何才能知道這些需求，並且保證這些需求是正確的。書上的圖很簡潔明瞭的告訴我們，需求分析與系統分析在開發過程中的關係。在開發的前期，或者說是準備時期，需求活動佔主導地位，我們需要對現有的資料進行大量細緻的分析，要弄明白我們的產品是...
04掌握需求過程閱讀筆記之一
本次，我學習了業務用例，即萬無一失的工作劃分方法，從而為需求調研鋪平了道路。1.確定用例 用例及其用例 use case 這個術語最先由 ivar jacobson在1987年提出,用於描述系統及其使用者之間的互動。jacobson需要將系統分解為較小的單元,因為他感到物件模型不具備可擴充套件性。所...