本書分為三大部分：

　　第一部分先介紹了一些基本的需求工程定義和一些優秀的需求分析所具有的特性。我希望你與你的重要客戶能一起閱讀第 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)是指邏輯上相關的功能需求的集合，給用戶提供處理能力并滿足業務需求。

　　在軟件需求規格說明中說明的功能需求充分描述了軟件系統所應具有的外部行為。軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用。對一個復雜產品來說，軟件功能需求也許只是系統需求的一個子集，因為另外一些可能屬于軟件部件。

轉載于:https://www.cnblogs.com/BUANG/p/5041612.html

總結

以上是生活随笔為你收集整理的01《软件需求分析教程》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。