第三章 需求分析
需求的定義、分類。
1）使用者解決問題或達到目標所需的條件或能力。
2）系統或是系統部件要滿足的合同、標準、規範或其他正規文件所需要具有的條件或是能力。
3）一種反映上面所描述的條件或是能力的文件說明。
需求就是以一種清楚簡潔，一致且無二義性的方式，對乙個待開發系統中各個有意義方面的陳述的集合。
需求分析的目的：準確定義使用者的需求i，進行細緻的調查分析，將使用者的非形式化要求i轉化為完整的需求定義，再將需求定義轉換為相應的形式的規格說明。
需求層次。
業務需求。
反映了組織機構或者客戶對系統或是產品高層次的目標要求，它們在專案檢視與範圍文件中予以說明。
是組織或客戶對於系統的層次 目標要求，定義了專案的遠景和範圍，即確定軟體產品的發展方向、功能範圍、目標客戶和價值**。
業務需求的內容：
業務：產品術語哪些業務的範疇？應該完成什麼功能？需求為什麼服務？
客戶：產品區別於其他競爭產品的特定是什麼？
價值：產品的價值體現在什麼方面？優先順序：產品功能特性的優先順序次序是什麼？
使用者需求。
使用者需求是從使用者的角度來描述系統功能需求和非功能需求，通常只涉及系統的外部行為，而不涉及系統內部特性。
使用者需求描述：原則：應該易於使用者的理解。一般不採用技術性很強的語言，而是採用自然語言。
問題：自然語言表達容易含糊和不準確。
系統需求。
系統需求是更加詳細的描述系統應該做什麼，通常包括許多不同的分析模型，諸如物件模型、資料模型、狀態模型等。
系統需求的描述：結構化英語（pdl），視覺化模型，形式化方法。系統需求主要是面向開發人員進行描述，是開發人員進行設計的基礎。
需求的質量特性。
正確性：需求規格說明對系統功能、行為、效能等的描述必須與使用者的期望相吻合，代表了使用者的真正的需求。審查需求的正確性應該考慮的問題
使用者參與需求過程的程度如何？每乙個需求描述是否準確的反映了使用者的需要？系統使用者是否已經認真考慮了每一項描述？需求可以追溯到**嗎？
完整性：需求規格說明應該包括軟體要完成的全部任務，不能遺留任何必要的需求資訊，注重使用者的任務而不是系統的功能有助於避免不完善。審查需求的完整性應該考
慮的問題。是否存在遺漏的功能或業務過程？在每個定義的功能之間是否有介面？是否有資訊或訊息在所定義的功能之間傳遞？是否定義了功能的使用者？是否已經清楚的定義
了使用者與功能之間的互動？是否定義了與外部過程和系統之間的介面？所描述的功能是否可以對映到業務過程中？文件中是否存在待確定的需求引用？文件中是否存在未定義的
術語和引用？文件的各個部分都完整嗎？需求包括非功能屬性說明嗎？是否考慮了軟體的效能？是否考慮了安全性的要求？是否考慮了可靠性？是否考慮了系統容量問題？
無二義性。
需求規格說明中的描述對所有人只能有一種明確統一的解釋，由於自然語言極易導致二義性，所以盡量把每一項需求用簡潔明瞭的使用者型的語言表達。
審查需求的無二義性應該考慮的問題：需求規格說明是否有術語詞彙表？具有多重含義或未知含義的術語是否已經定義？需求描述是否可量化和可驗證?每一項需i去都有測試準則嗎？
可驗證性。
需求規格說明中描述的需求都可以運用一些可行的手段對其進行驗證和確認。
審查需求的可驗證應該考慮的問題。在需求文件中是否存在不可驗證的陳述，諸如「使用者介面友好」，「容易」，「簡單「，」快速「、」健壯「，」最新技術「等？
所有的描述都是具體的可測量的嗎？
一致性。
需求規格說明對各種需求的描述不能存在矛盾，如術語使用衝突、功能和行為特性方面的矛盾以及時序上的不一致等。審查需求的一致性應該考慮的問題：文件的組織形式是否易於一致？不同功能的描述之間是否存在矛盾？是否存在有矛盾的需求描述或術語？文件中是否存在時序上的不一致？
可修改性。
需求規格說明的格式和組織化方式應保證後續的修改能夠比較容易的協調一致。我們可以使用目錄表、索引和相互參照列表等方法。
審查需求的可修改性應該考慮的問題。是否存在明顯的需求交叉引用？是否與內容列表和索引？是否存在冗餘的需求，即同乙個需求的描述出現在的文件的不同大方？如果存在，它們是交叉引用嗎？
可跟蹤型。
可跟蹤性意味著每一項需求都能與其對應的**、設計、源**和測試用例聯絡起來。可跟蹤性的兩種方式：每一項都可以在早期的文件中追溯到其**，例如備忘錄、法規、會議記錄等。每項需求都有唯一的名稱或索引號，與後期實現對應。
測試基礎系列之需求分析
一 前言 半年前，就準備開始寫部落格來分享我在測試中的點點滴滴，也是記錄下我自己的足跡。但由於工作太忙，一直沒有開始。萬事開頭難 現在終於開始寫了，所有的觀點均是個人理解，有什麼不對地方，希望大家能指出。測試基礎系列是基於我理解的測試流程來寫的，軟體測試流程在我的另一篇文章 聊聊測試管理 管事篇 中...
初學軟工 需求分析
需求分析作為軟體工程中不可或缺的一項重要的內容，在許多的方面都有重要的作用，可以說需求分析做不好，將來的軟體驗收和維護都會遇到很大的困難甚至要進行軟體的重構，下面來看一下我的導圖 一 需求分析的任務 1 構造模型 首先就是要構造目標的業務模型，從原系統的模型出發經過轉化最後形成現有系統的模型 2 分...
軟工 軟體需求分析
一 需求分析的任務 1 確定對系統的綜合需求 2 分析系統的資料需求 3 匯出系統的邏輯模型 4 修正系統開發計畫 5 開發原型系統 二 需求分析的原則1 必須能夠表達和理解問題的資料域和功能域 2 按自頂向下 逐層分解問題 3 要給出系統的邏輯檢視和物理檢視 三 資料流圖 1 特性 抽象性 概括性...