今天是第二次讀軟體需求這本書，經過上次的閱讀，我知道了軟體需求的三個層次，分別是：業務，使用者和功能。在專案中它們在不同的時間來自不同的**，也有著不同的目標和物件，並需以不同的方式編寫成文件。業務需求不應包括使用者需求，而所有的功能需求都應該源於使用者需求。同時你也需要獲取非功能需求，如質量屬性。
那麼怎麼獲取需求呢？
首先要確定需求開發過程，確定如何組織需求的收集，分析，細化並核實的步驟，並將它們寫成文件。
然後編寫專案檢視和範圍文件，專案檢視和範圍文件應該包括高層的產品業務目標，所有的實用例項和功能需求都必須遵從能達到的業務需求。專案檢視說明使所有專案參與者對專案的目標能達成共識。而範圍則是作為評估需求或潛在特性的參考。
接著將使用者群分類並歸納各自特點，選擇每類使用者的產品代表，建立起典型使用者的核心隊伍，讓使用者代表確定使用例項，召開應用程式開發聯絡會議，分析使用者工作流程，確定質量屬性和其它非功能需求，通過檢查當前系統的問題報告來進一步完善需求，跨專案重用需求。
那麼需求分析包括哪些事情呢？
需求分析包括提煉、分析和仔細審查已收集到的需求，以確保所有的風險承擔者都明白其含義並找出其中的錯誤、遺漏或其它不足的地方。
當需求分析完了之後就到了需求驗證，驗證是為了確保需求說明準確、完整地表達必要的質量特點。具體包括以下的步驟：1.審查需求文件2.以需求為依據編寫測試用例3.編寫使用者手冊4.確定合格的標準。
接下來就到了需求管理了，那麼怎麼進行需求管理呢？
1.確定需求變更控制過程2.建立變更控制委員會3.進行需求變更影響分析4.跟蹤所有受需求變更影響的工作產品5.建立需求基準版本和需求控制版本文件6.維護需求變更的歷史記錄7.跟蹤每項需求的狀態8.衡量需求穩定性9.使用需求管理工具。
以上就是我第二次讀軟體需求的閱讀筆記。
02需求工程軟體建模與分析閱讀筆記之二
此次閱讀了解到了什麼是優秀的需求。1 完整性 優秀的需求都是完整的，他不需要做更多的擴充套件就可以充分的說明使用者需要的系統功能。每乙個需求的描述都應該包含開發人員設計和實現這項功能需要的所有資訊，這樣在開發過程中，他們才可以被獨立出來，單獨對待。在需求開發的過程中，對於不清晰的資訊可以標記為tbd...
《軟體需求》閱讀筆記之二
這次閱讀的這本書的第二部分。第二部分講述了軟體需求的步驟，以及文件的內容。首先是專案檢視與範圍文件，這就需要通過業務需求來確立，確立了範圍之後就不要 超出這個範圍，如果超出了就會可能變成使用者不喜歡的累贅，進而可能導致了這款軟體 的失敗。其次是尋找客戶的需求，針對這一點我們需要尋找使用者代表，確立典...
02有效需求設計閱讀筆記之二
近期讀了這本書的一部分內容，沒有讀太多，對裡邊有乙個章節感悟比較深，主要講到了需求分析中人物干係的方面內容，和王老師在講課時這關於需求分析這一塊也曾強調過要想做好需求分析，需要了解系統使用人群之間的關係以及企業或部門的人事分布。所以這章對我來說很有用。只有明確的客戶群 才能讓我們很好去研究，學會用客...