筆者正在學習《軟體工程-實踐者的研究方法》這本書，記錄下一些讀書筆記，共勉！
市場條件變化十分迅速，客戶和終端使用者的需求在演變，從業者必須使軟體工程工作保持敏捷，要限定過程應是靈活機動的、有適應能力的和精益的以適應現代商務的需求。
敏捷可以應用於任何乙個軟體過程（溝通、策劃、建模、構建和部署），過程的設計應該使專案團隊適應於任務，並且使任務流水線化，在了解敏捷開發方法的流動性的前提下進行計畫的制定，消除所有最基本軟體產品並精簡軟體開發過程，強調這樣乙個增量交付策略：根據具體的產品型別和執行環境，盡可能快地將切實可行的軟體交付給使用者。
敏捷過程能夠降低變更的成本，因為軟體以增量方式發布，而且在增量內部變更能得到較好的控制。
1.1敏捷原則
（1）我們最優先要做的是通過盡早、持續的交付有價值的軟體來使客戶滿意；
（2）即使在開發的後期，也歡迎需求變更，敏捷過程利用變更為客戶創造競爭優勢；
（3）經常交付可執行軟體，交付的時間間隔可以從幾個星期到幾個月，間隔越短越好；
（4）在整個專案開發期間，業務人員和開發人員必須天天在一起工作；
（5）圍繞有積極性的個人構建專案，給他們提供所需的環境和支援，並信任他們能夠完成工作；
（6）在團隊內部，最富有效果和效率的資訊傳遞方法是面對面交談；
（7）可執行軟體時進度的首要度量標準；
（8）敏捷過程提倡可持續的開發速度，責任人、開發者和使用者應該能夠長期保持穩定的開發速度；
（9）不斷的關注優秀的技能和好的設計會增強敏捷能力；
（10）簡單是必要的；
（11）最好的架構、需求和設計出自於自組織團隊；
（12）每隔一定時間，團隊會反省如何才能更有效的工作，並相應調整自己的行為。
1.2 人的因素
1.3 應用最廣泛的敏捷過程模型：極限程式設計 （extreme programming, xp）
極限程式設計過程分為策劃、設計、編碼和測試4個框架活動的規則和實踐。
理解需求的重要性：「我知道你認為你理解我說的是什麼，但是你並不理解的是：我所說的並不是我想要的」
2.1 需求工程 （requirement engineering，re）
需求工程指致力於不斷理解需求的大量任務和技術。需求工程通過執行7個不同的活動來實現：起始、匯出、精化、協商、規格說明、確認和管理。
匯出：詢問客戶、用於和其他人，系統和產品的目標是什麼、想要實現什麼、系統和產品是如何滿足業務要求、最終系統是如何用於日常工作；
精化：將起始和匯出階段的資訊進行擴充套件和提煉，開發乙個精確的需求模型，用以說明軟體的功能、特徵和資訊的各個方面。
規格說明：基於計算機的系統和軟體的環境下，屬於規格說明對不同的人有不同的含義。乙個規格說明可能是乙個說明文件、圖形化的模型、形式化的數學模型、一組使用場景 、乙個原型或上述任意組合。
確認：對需求工程的產品進行評估，檢查規格說明，保證無歧義的說明的所有的系統需求、已檢測出不一致性並得到糾正、工作產品符合過程、專案和產品建立的標準。
需求管理：用於幫助專案組在專案進展中標識、控制和跟蹤需求以及需求變更的一組活動。
建立規格說明的大綱：
目錄
版本歷史
1 導言
2.1 產品願景
2.2 產品特性
2.3 使用者型別和特徵
2.4 操作環境
2.5 設計和實現約束
2.6 使用者文件
2.7 假設和依賴
3 系統特性
3.1 系統特性1
3.2 系統特性2 ……
4 外部介面需求
4.1 使用者介面
4.2 硬體介面
4.3 軟體介面
4.4 通訊介面
5 其他非功能性需求
5.1 效能需求
5.2 安全需求
5.3 保密需求
5.4 軟體質量屬性
6 其他需求
附錄a： 術語表
附錄b： 分析模型
附錄c： 問題列表
2.2 建立根基
起始階段，首先需要確認該項目的利益相關者（直接或間接從正在開發的系統中獲益的人），如業務執行管理人員、產品管理人員、市場銷售人員、內部和外部客戶、終端使用者、顧問等。需求工程師應建立乙個人員列表。不同的利益相關者提出的需求可能是重複的、矛盾的或者有某種關聯的，因此需求工程師的下一步工作是將利益相關者提出的需求進行分類整理。第三步是根據需求的分類和目標，確定在利益相關者之間要團結協作，並與軟體工程人員緊密協作。這一步需求工程師需要劃分利益相關者和開發人員的職責、標識公共區域（都同意的需求）和矛盾區域。
2.3 匯出需求
質量功能部署（quality function deployment，qfd）：是一種將客戶要求轉化成軟體技術需求的質量管理技術。在此過程中，qfd確認三類需求：正常需求（開會時客戶確定的需求）、期望需求（隱含在產品或系統中，但客戶沒有顯式說明，但缺少這些將導致使用者不滿，如人機互動的容易性、安裝的簡易性）和令人興奮的需求（客戶期望之外的特點，實現這些將使客戶非常滿意）。
使用者場景：收集需求時，逐步具體化系統功能和特性的整體願景。
匯出工作產品：工作產品包括要求和可行性陳述、系統或產品範圍的界限說明、系統技術環境的說明、需求列表、一些使用場景、任何能更好定義需求的原型等。
2.4 開發用例
用例講述了能表達主體場景的故事：終端使用者如何在乙個特定環境下和系統互動。這個故事可以是敘述性的文字、任務或互動的概要、基於模板的說明或圖形表示。用例是從終端使用者角度描述了軟體或系統。
撰寫用例首先要確定參與者，然後再開發用例。參與者是任何與系統或產品通訊的事務，且對系統本身而言參與者是外部的。參與者並不等於系統的終端使用者。
2.5 構建需求模型
需求模型為基於計算機的系統提供必要的資訊、功能和行為域的說明。
2.6 協商需求
在多數情況下，讓利益相關者以成本和產品投放市場的時間為背景，平衡功能、效能和其他的產品或系統特性。協調的目的是保證所開發的專案計畫，在滿足利益相關者要求的同時反映軟體團隊所處真實世界的限制。
協商需求一般有以下活動：
2.7 確認需求
需求模型的每乙個元素都已建立後，需要檢查一致性、是否有遺漏以及是否有歧義。
總結：需求工程的任務是為設計和構建活動建立乙個可靠堅固的基礎。需求工程發生在於客戶溝通活動和為一般的軟體過程定義的建模活動過程中。軟體團隊成員要實施7個不同的需求工程職能：起始、匯出、精化、協商、規格說明、確認和管理。
軟體工程 軟體工程系統定義 需求開發與需求管理
系統定義階段 需求分析概述 軟體需求分析層次 需求分析的過程 需求開發 需求管理 待更新 更新日誌 最近更新 系統定義是軟體生命週期的第一階段，有著根據使用者的具體要求解決系統做什麼的重要任務。系統定義階段主要完成三部分，即問題提出 可行性研究 需求分析 問題提出與可行性分析兩部分的工作內容需體現在...
軟體工程 過程模型 敏捷開發
軟體的概念 軟體是在計算機系統支援下能夠完成特定功能和效能的程式 資料和相關文件 軟體 知識 程式 資料 文件 軟體危機 軟體危機是指落後的生方式無法滿足迅速增長的計算機需求，從而導致軟體開發和過程維護出現一系列嚴重問題的現象。軟體工程的概念 軟體工程定義的第一部分內容要求，軟體開發 維護 和執行的...
軟體工程學習筆記（三）軟體需求工程
軟體需求 以清晰 簡潔 一致且無二義性的方式，描述使用者對目標軟體系統在功能 行為 效能 設計約束等方面的期望，是在開發過程中對軟體系統的約束 軟體需求分類 需求工程過程 需求基線 評審通過後的srs就形成了軟體開發工作的需求基線，作為客戶方和開發方之間的乙個需求約定 軟體需求分析的任務不應包括結構...