軟體需求的獲取和分析是軟體系統開發中的一項重要任務，正確獲取軟體需求是軟體技術人員必須掌握的基本技能。此書從軟體需求工程的角度出發，以需求開發過程為主線，完整描述了需求獲取、需求分析、需求驗證、需求規格說明和需求管理等需求工程活動。此書站在開發者的立場，側重於實踐者的技術與方法，系統全面地介紹了軟體需求工程的各項進展，努力促進需求工程領域理論、方法和技術的全面融合應用，以指導需求工程各階段的系統化實踐。
對於我們這種在校大學生來說，工程專案的概念是十分抽象的，乙個專案開發的前提自然是有需求，那需求的獲取以及如何根據需求來構建專案，這些都是十分重要的環節。若是我們一門心思埋頭研究敲**，那終歸也只是會敲**，而專案的需求獲取以及模型的構建相關的知識可以幫助我們提公升眼界，提公升我們的層次，而這本書就可以助我們一臂之力。簡單來說，這本書中的知識可以幫助我們學習到更專業的知識，幫助我們從碼農的角度提公升到設計師開發者的角度。
首先開篇看到的是需求原：需求分析基本原則：
1 定義問題，而不是解決方案。需求定義「做什麼，而不是怎麼做」，意思是需求的目的不是企圖定義任何的解決方案。這是重要的特點，是不可違反的規則。
2 定義系統，而不是專案。需求定義了系統需要做什麼：他們是一組目標。專案是在一段時間內動員一組人來完成這些目標。需求不涉及系統如何完成目標，這意味著不要涉及實現乙個解決方案的專案的任何事情，而且編寫每個需求規格應該是長期有效的，適用於多個系統，這些系統可能在不同的時間以不同的方式開發：需求可能被束之高閣，然後一兩年後拿出來，或者幾年時間內我們可能開發乙個替代系統。
3 區分正式和非正式部分。需求規格像乙個合同，它定義了系統的**商或開發者必須交付的東西。但是大量的合同約束宣告遠遠不能讓我們正確的理解它，它需要背景知識、前後關係、流程以及結構。這些材料都不是合同約束。它幫助把規格分為約束部分和非約束部分。需求本身由需求規格的正式部分組成，是系統必須做什麼的正式定義。其他的都是非正式的。
4 避免重複。如果可行，每一項資訊只表述一次。重複產生了額外的工作而且加大了不一致的可能性。敏捷需求流程的原則：區分問題和解決方案是最重要的，定義需求後，一定要記錄他以便別人可以找到。需求模式剖析：基本細節、適用性、內容、模板、例項、額外需求、開發考慮、測試考慮。需求規格的內容可以分為四部分：「介紹部分」，「上下文部分」，「功能域部分」和「主要非功能要求部分」。
這些原則還是多的但並不難理解，我們做軟體畢竟不是給自己用，而是最終要交給客戶，因此有了這些原則我們便可以在需求分析中少走許多彎路，更接近問題的本質。
《需求工程 軟體建模與分析》閱讀筆記03
一 需求工程過程概念介紹 一 概述 1.規格說明 需求工程過程是系統開發中需求開發活動的整合，它以使用者所面臨的業務問題為出發點進行分析和各種轉換，最終產生乙個能在使用者環境下解決使用者業務問題的系統方案，並將其文件化為明確的規格說明。2.生命週期 需求工程也有屬於它自己的生命週期模型，即存在針對需...
《需求工程 軟體建模與分析》閱讀筆記三
需求管理是來完成需求開發結束後，保障系統質量的乙個管理活動。需求管理在實踐中的作用有 增強專案涉眾對複雜產品特徵在細節和相互依賴關係上的理解 增進了專案涉眾之間的交流 減少了工作量的浪費，提高了生產力 準確反映社會的狀態，有助於專案決策 改變專案文化，使得需求的作用得到重視和有效發揮。維護需求基線 ...
《需求工程 軟體建模與分析》閱讀筆記一
軟體經歷了以 機器 為中心，以 應用 為中心，以 企業 為中心的發展過程，隨著 應用 為中心的軟體發展，原來的個體化 軟體作坊式 的軟體開發模式顯示出了很多的問題，針對這些問題，人們在不斷地討論與制定對策，在軟體開發技術和軟體開發過程與管理方面都取得了很多進步。根據很多方面的調查顯示，在所有的軟體開...