本書分為三大部分：
第一部分先介紹了一些基本的需求工程定義和一些優秀的需求分析所具有的特性。我希望你與你的重要客戶能一起閱讀第 2章（關於客戶與開發者之間的夥伴關係）；第 3章介紹了許多需求開發和管理的改進熟練程度的好方法（良好的習慣做法）。第 4章有助於計畫怎樣將新的策略融入小組的開發過程中。方法是基於對附錄中當前需求實踐自我測試的回答。第 5章則介紹了一些通常與需求相關的專案風險。
第二部分介紹了許多關於需求開發的技術。首先是定義專案的業務需求，專案檢視(vision)及涉及的範圍(scope)。接下來的章節介紹怎樣為專案尋找合適的客戶代表，獲取（elicit）使用者需求，編寫功能需求文件及質量屬性文件。第 10章介紹了一些分析模型，這些模型可用於不同範圍的需求分析。第 12章介紹了軟體原型的結構和應用。第二部分中的其它章節還**了定義需求優先順序的方法及驗證需求分析是否正確的方法。
第三部分的主題是需求管理的原則和策略。這部分還特別介紹了處理需求變更和評價每項變更對專案影響的技術。第 18章介紹了怎樣把需求跟蹤能力和單個需求相關的內容需求**到與需求相關的設計、**等）聯絡起來。第三部分的內容包括一些商業工具的說明，這些工具能增強你管理專案需求的能力。
你一定知道：乙個不能讓你進行一項基本操作的軟體產品是多麼令人煩惱。你不會感謝開發者，儘管他最終會滿足你主要的需求變更。但從開發者角度，你也知道，當使用者在整個系統已經完成後，再提出一些功能要求是多麼煩人的事。同時，由於修改系統的請求會打斷你當前的專案，也是令人很不愉快的。而且往往這種修改請求還要求你優先處理。
其實，在軟體開發中遇到的許多問題，都是由於收集、編寫、協商、修改產品需求過程中的手續和作法（方法）失誤所帶來的。
在軟體工程中，所有的風險承擔者（stakeholder）都感興趣的就是需求分析階段。這些風險承擔者包括客戶、使用者、業務或需求分析員（負責收集客戶需求並編寫文件，以及負責客戶與開發機構之間聯絡溝通的人）、開發人員、測試人員、使用者文件編寫者、專案管理者和客戶管理者。這部分工作若處理好了，能開發出很出色的產品，同時會使客戶感到滿意，開發者也倍感滿足、充實。若處理不好，則會導致誤解、挫折、障礙以及潛在質量和業務價值上的威脅。因為需求分析奠定了軟體工程和專案管理的基礎，所以所有風險承擔者最好是採用下面提供的有效的需求分析過程。
（1）了解軟體需求開發中使用的一些關鍵名詞。
（2）警惕在軟體專案中可能出現的與需求相關的一些問題。
（3）知道優秀的需求規格說明應該具有的特點。
（4）明白需求開發與需求管理之間的區別。
並沒有乙個清晰、毫無二義性的「需求」術語存在，真正的「需求」實際上在人們的腦海中。任何文件形式的需求（例如：需求規格說明）僅是乙個模型，一種敘述（lawrence 1998）。我們需要確保所有專案風險承擔者在描述需求的那些名詞的理解上務必達成共識。
軟體需求包括三個不同的層次——業務需求、使用者需求和功能需求——也包括非功能需求。業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在專案檢視與範圍文件中予以說明。使用者需求(user requirement)文件描述了使用者使用產品必須要完成的任務，這在使用例項（use case）文件或方案指令碼（scenario）說明中予以說明。功能需求(functional requirement)定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。所謂特性(feature)是指邏輯上相關的功能需求的集合，給使用者提供處理能力並滿足業務需求。
在軟體需求規格說明中說明的功能需求充分描述了軟體系統所應具有的外部行為。軟體需求規格說明在開發、測試、質量保證、專案管理以及相關專案功能中都起了重要的作用。對乙個複雜產品來說，軟體功能需求也許只是系統需求的乙個子集，因為另外一些可能屬於軟體部件。
《需求工程 軟體建模與分析》01
一 滿足需求就是解決問題 問題解決的 兩個方面 問題域與解系統 首先，我們需要簡要了解這兩點的概念。第一，問題域是需求的背景，要理解需求就必須先理解問題域。問題域的背景資訊又被稱為問題域特性 problem domain feature 與需求相區別的是，問題域是自治的，它有自己的執行規律，而且這些...
需求分析01 需求分類
最完美的創業團隊是乙個會寫 有點商業感覺，又有審美的技術人員，比如facebook的扎克伯格，初創團隊的商業事情由產品經理兼著思考，產品做出來之後，會引入第三個角色，運營，是產品經理讓產品有用，技術讓產品可用，設計讓產品好用。產品經理的主要職責分為兩塊 1 評估產品機會 2 定義要開發的產品。那麼產...
軟體需求分析教程閱讀筆記二
管理人員在要求開發乙個系統時並不會理解進行需求分析的重要性，他們只知道能不能盡快開發出相應的系統來方便使用，但是如果不做好需求分析，最終開發出的系統也不會有人用。客戶的需求認識並不像軟體開發人員這樣，了解的比較清楚，客戶通常並不懂得從系統的實際使用者處得到資訊的重要性，然而從產品的實際使用者處收集需...