筆者正在學習《軟體工程-實踐者的研究方法》這本書，記錄下一些讀書筆記，共勉！

1.敏捷

市場條件變化十分迅速，客戶和終端使用者的需求在演變，從業者必須使軟體工程工作保持敏捷，要限定過程應是靈活機動的、有適應能力的和精益的以適應現代商務的需求。
敏捷可以應用於任何一個軟體過程（溝通、策劃、建模、構建和部署），過程的設計應該使專案團隊適應於任務，並且使任務流水線化，在瞭解敏捷開發方法的流動性的前提下進行計劃的制定，消除所有最基本軟體產品並精簡軟體開發過程，強調這樣一個增量交付策略：根據具體的產品型別和執行環境，儘可能快地將切實可行的軟體交付給使用者。
敏捷過程能夠降低變更的成本，因為軟體以增量方式釋出，而且在增量內部變更能得到較好的控制。

1.1敏捷原則

（1）我們最優先要做的是通過儘早、持續的交付有價值的軟體來使客戶滿意；
（2）即使在開發的後期，也歡迎需求變更，敏捷過程利用變更為客戶創造競爭優勢；
（3）經常交付可執行軟體，交付的時間間隔可以從幾個星期到幾個月，間隔越短越好；
（4）在整個專案開發期間，業務人員和開發人員必須天天在一起工作；
（5）圍繞有積極性的個人構建專案，給他們提供所需的環境和支援，並信任他們能夠完成工作；
（6）在團隊內部，最富有效果和效率的資訊傳遞方法是面對面交談；
（7）可執行軟體時進度的首要度量標準；
（8）敏捷過程提倡可持續的開發速度，責任人、開發者和使用者應該能夠長期保持穩定的開發速度；
（9）不斷的關注優秀的技能和好的設計會增強敏捷能力；
（10）簡單是必要的；
（11）最好的架構、需求和設計出自於自組織團隊；
（12）每隔一定時間，團隊會反省如何才能更有效的工作，並相應調整自己的行為。

1.2 人的因素

敏捷開發關注個人的才智和技巧根據特定人員和團隊來塑造過程。要求團隊成員及團隊本身具備以下一些特點：

• 基本能力：內在才能和特定的軟體技能；
• 共同目標：團隊為完成同一個任務而瞄準同一個目標；
• 精誠合作：專案組之間、專案內部成員之間精誠合作；
• 決策能力：具有掌握自身命運的自由；
• 模糊問題解決能力：不斷面對不確定的問題並良好解決；
• 相互信任和尊重：以形成一個強有力的組織；
• 自組織：①敏捷團隊組織自身以完成工作；②團隊組織最能適應當前環境的過程；③團隊組織最好的進度安排以按期交付產品。

1.3 應用最廣泛的敏捷過程模型：極限程式設計 （eXtreme Programming, XP）

極限程式設計過程分為策劃、設計、編碼和測試4個框架活動的規則和實踐。

• 策劃：需求獲取，使XP團隊技術成員理解軟體的商業背景，充分感受要求的輸出、主要特徵和功能。使用者的需求產生了多個“故事”，每個“故事”根據優先順序有權值。使用者可以隨時增加、修改故事和故事的權值。
• 設計：XP設計嚴格遵守保持簡潔的原則；
• 編碼：首先開發用於檢測本次增量產品的測試單元，然後編碼，最後測試；
• 測試：“在編碼之前簡歷單元測試是XP方法的關鍵因素。”

2.理解需求

理解需求的重要性：“我知道你認為你理解我說的是什麼，但是你並不理解的是：我所說的並不是我想要的”

2.1 需求工程 （Requirement Engineering，RE）

需求工程指致力於不斷理解需求的大量任務和技術。需求工程通過執行7個不同的活動來實現：起始、匯出、精化、協商、規格說明、確認和管理。

• 起始：專案起始階段中，要建立基本的理解，包括對問題、誰需要解決方案、所期望解決方案的性質、與專案利益相關者和開發人員之間達成初步交流合作的效果。
• 匯出：詢問客戶、用於和其他人，系統和產品的目標是什麼、想要實現什麼、系統和產品是如何滿足業務要求、最終系統是如何用於日常工作；
• 精化：將起始和匯出階段的資訊進行擴充套件和提煉，開發一個精確的需求模型，用以說明軟體的功能、特徵和資訊的各個方面。
• 協商：解決客戶過高需求與有限業務資源衝突的過程，讓客戶、使用者和其他利益相關者對各自需求排序，按優先順序討論衝突；
• 規格說明：基於計算機的系統和軟體的環境下，屬於規格說明對不同的人有不同的含義。一個規格說明可能是一個說明文件、圖形化的模型、形式化的數學模型、一組使用場景 、一個原型或上述任意組合。
• 確認：對需求工程的產品進行評估，檢查規格說明，保證無歧義的說明的所有的系統需求、已檢測出不一致性並得到糾正、工作產品符合過程、專案和產品建立的標準。
• 需求管理：用於幫助專案組在專案進展中標識、控制和跟蹤需求以及需求變更的一組活動。

建立規格說明的大綱：
目錄
版本歷史
1 導言
1.1 目的
1.2 文件約定
1.3 適用人群和閱讀建議
1.4 專案範圍
1.5 參考文獻
2 總體描述
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個不同的需求工程職能：起始、匯出、精化、協商、規格說明、確認和管理。