通過這乙個月的閱讀，我終於讀完了《軟體需求模模式》這本書，前兩個讀書筆記已經把這本書的幾種模式介紹了，之前有基礎需求模式，資訊需求模式，資料實體需求模式，使用者功能需求模式。這次介紹的是效能需求模式，適應性需求模式，訪問控制需求模式和商業需求模式。
效能需求模式包括五種的效能的需求模式：影響時間（系統需要多少時間完成乙個請求）、動態容量（系統能夠同時處理多少件事）、吞吐量（系統處理時間的速率）、靜態容量（系統可以儲存多少某種型別煩的實體）和可用性（什麼時候系統對使用者是可用的，以及多麼可靠）。
當我們對效能的某方面定義時，如果他值得定義，那就仔細考慮定義好；若不值得，就省略他。在做需求的過程中經常遇見效能問題：1.編寫容易等同於實現困難。2.我們定義乙個完整的執行還是只是軟體。3.效能指標適用於系統的哪個部分？4.避免武斷的效能指標。5.效能因素對系統有多大的影響？6.怎樣可以測量實際的效能？7.到什麼時候效能指標需要滿足？8.在每乙個需求中之定義乙個效能指標。9.如果效能指標沒有達到該怎麼辦。在具體分析那五個需求模式時，都有各自的注意事項和處理步驟。
適應性需求模式通常有助於產生跟健壯的系統，並滿足特定的目標。但有些適用性使用很昂貴。其中主要包括6方面：可伸縮性（準備好處理業務容量的增加）、可擴充套件性（能夠容易的插入額外的軟體）、安裝性（安裝系統的容易程度）、非狹窄性（避免限制在其他地方安裝）、多樣性（同時支援多個公司、貨幣等）、多語言（同時支援多語言使用者介面）。軟體會慢慢變老，在不斷地修改中，對系統構架施加額外的壓力。所以重構，有意識的整理軟體，可以看做減緩衰老程序的一種努力。可以更有效的減緩退化的過程。可擴充套件性是一種適用性，有助於延長軟體的壽命。適用性是系統設計色的基礎，而且適用性需求和效能需求有複雜的關係。適用性需求主要影響軟體的性質；效能需求則主要影響所需要的硬體，要特別注意適應性和效能之間的長期和短的權衡。
訪問控制有3個主要活動組成：1.使系統知道有關人員（使用者註冊）2.確認使用者是譯制人員（使用者認證）3.控制使用者可以做什麼和看什麼（使用者授權）。訪問控制需求模式適唯一的有關安全的需求模式，但對訪問控制進行需求分析時，要包括：使用者類別、使用者詳細資訊（身份詳細資訊、認證資訊、事實、選擇、訪問許可權）、註冊流程、密碼、使用者認證和確認、許可權等。
商業需求模式包括費/稅和多組織單員（業務結構，辦事處，公司等）多組織單元需求包括：單元型別名稱、單元型別定義、父單元型別、特徵、預計的例項數等，還可以額外的包括訪問控制、單元識別符號等。費/稅需求包括：名稱、基礎、起源、條件、什麼時候徵收、付款人、收款人、費率的決定因素、系統的責任、參考。還可以額外的包括特殊情況和因素、人為干涉、費用金額的理由。
讀完這本書，我有了很大的進步，書中描述的37個模式，為編寫軟體需求提供了特定情形中的框架。是我對每一種模式詳細描述需要包括哪些資訊，提醒常見缺陷，以及建議需要考慮的額外的需求有了很深的了解。無論使用傳統的分析方法或敏捷方法，都可以學習如何使用需求的模式，從而為成功的軟體開發編寫一致的、有效的需求。我從中學到了：識別系統間的介面、技術以及文件需求。定義詳細的資訊需求，包括歸檔、資料型別以及資料實體。指定系統的可用性、容量、伸縮性、擴充套件性以及易用性。定義訪問控制，包括使用者註冊、認證以及授權。指定查詢、報表、計算公式以及費和稅的需求。最重要的之學會了如何編寫自己的需求模式。
《軟體需求》讀書筆記四
需求捕獲應該是主動的 需求捕獲應該是聚焦的 案例 小趙問監控中心的小張 你對這個系統有什麼需求？小張說 我想到的功能包括值班日誌 告警的聲光提示 基於簡訊的告警通知.老李問小徐 當監控中心收到乙個告警的時候，希望以什麼形式來體現？收到後，你們一般會進行什麼樣的處理？小張的提問使得捕獲過程很發散，而老...
《軟體需求》讀書筆記03
業務需求代表了需求鏈中最高層的抽象 他們為軟體系統定義了專案檢視和範圍。軟體功能需求必須根據使用者的需求來考慮，且要與業務需求所設定的目標相一致。對不利於實現專案業務目標的需求應該排除在外。乙個專案可能包括一些與軟體沒有直接關係的需求，例如 硬體的購買 產品的安裝 維護或廣告。但在此，我們只關心與軟...
《軟體需求》讀書筆記02
需求 需求收集方法 軟體需求可以來自方方面面，這取決於所開發產品的性質和開發環境。需從不同使用者代表和 收集需求，這說明了需求工程是以相互交流為核心的性質。下面是幾個軟體需求的典型 1 訪問並與有潛力的使用者 為找出新軟體產品的使用者需求，最直截了當的方法是詢問他們。2 把對目前的或競爭產品的描述寫...