第三章 需求分析
軟體工程中包含需求、設計、編碼、測試
-. 需求開發
: 需求獲取、需求分析、編寫規格說明書、需求驗證
a 需求獲取
確定需求開發過程確定如何組織需求的收集、分析、細化、核實的步驟,並編寫文件
b 需求分析
繪製關聯圖、建立開發原型、分析可行性、確定需求優先順序、為需求建立模型、編寫資料字典、應用質量功能調配
c 編寫規格說明書
專案檢視和規範文件包含了業務需求,而是用例項文件則包含了使用者需求
d 需求驗證
審查需求文件、依據需求編寫測試用例、編寫使用者手冊、確定合格的標準
二、需求管理
需求開發的結果應該有專案檢視和規範文件、使用例項文件、軟體需求規格說明及相關分析模型。
快速建立軟體模型：
模型與工具
資料模型--實體-關係圖
功能模型--資料流圖
行為模型--狀態轉換圖
軟體需求規格說明：
自然語言、準確、具體描述系統的資料需求、功能需求、效能需求、可靠性和可用性、出錯處理需求、介面需求
約束、逆向需求。
軟體效能: 響應時間、併發使用者數、吞吐量、效能計數器、tps、hps。
軟體可靠性:軟體可靠性是軟體系統在規定的時間內及規定的環境條件下,完成規定功能的能力。
資料物件:
外部實體、事物、行為、事件、角色、單位、地點、結構
資料物件間彼此間是關聯的,它只封裝了資料、沒有對資料的操作
屬性:定義了資料物件的性質,屬性用識別符號表示
聯絡:資料物件彼此間相互連線的方式稱為聯絡
也稱為關係
實體-關係圖的符合簡稱er圖
第一正規化：每個屬性值必須是原子值,即僅僅是乙個簡單值而不包含內部結構
第二正規化: 滿足第一正規化,而且每個非關鍵字由關鍵字決定
第三正規化: 符合第二正規化的條件,每個非關鍵字屬性都僅由關鍵字決定,而且乙個非
關鍵字屬性不能僅僅是另乙個非關鍵字局性的進一步描述
狀態轉換圖(狀態圖)
描述系統的狀態及引起系統狀態轉換的事件,來表示系統的行為.
事件：是在某個特定時刻發生的事件,它是引起系統動作或從乙個狀態轉換的另乙個狀態的外界事件的抽象
層次方框圖
是用樹形的一系列多層次的矩形資料的層次結構。
驗證軟體需求的途徑與方法
一致性:
完整性：
實現性有效性
用於需求分析的軟體工具:
psl/psa系統用描述從系統資訊流、系統結構、資料結構、資料匯出、系統規模
系統動態、系統性質、專案管理。
問答1.什麼是需求分析，需求分析階段的基本任務？
需求分析:開發人員準確地理解使用者的需求，進行細緻的調查分析，將使用者非形式的需求陳述轉化為完整的需求定義，再由需求定義轉換到相應的需求規格
說明的過程。
基本任務：
(1)問題識別:雙方確定對問題的綜合需求，這些需求包括功能需求、效能需求、環境需求、使用者介面需求
(2)分析與綜合:匯出軟體的邏輯模型
(3)編寫文件：編寫需求規格說明書，初步使用者使用手冊、確認測試計畫、修改完善軟體開發計畫
2.什麼是結構分析方法?該方法使用什麼描述工具？
sa，面向資料流進行資料分析的方法。採用自頂向下逐層分解的分析策略。
頂層抽象地描述整個系統，
中間層則是從抽象到具體的過渡,使用資料流圖，資料字典，作為描述工具，使用結構化語言，判定表，判定樹描述加工邏輯。
底層具體地畫出系統工程的每個細節
3. 結構化分析方法通過那些步驟來實現？
1.了解當前系統的工作流程，獲取當前系統的物理模型
2.抽象當前系統的邏輯模型
3.建立目標系統的邏輯模型
4.作進一步補充和優化
4.畫資料流圖應該注意什麼事項？
命名：不能使用缺乏具體含義的名字，加工名能反映出處理的功能。
畫資料流圖而不是控制流：資料流名稱只能是名稱或名詞短語，整個圖中不反映加工的執行順序。
一般不畫物質流。
每個加工至少有乙個輸入資料流和乙個輸出資料流，反映出此加工資料的**與加工的結果。
編號：某個加工分解成加工一張資料流圖是，上層為父圖，下層為子圖。子圖應編號子圖上的所有加工也應編號
子圖的編號應與父圖的編號相對應。
父圖與子圖的平衡：子圖的輸入輸出，資料流通父圖相應加工的輸入輸出資料流必須一致。
區域性資料儲存：當某資料流圖中的資料儲存不是父圖中相應加工的外部介面，而只是本圖中某些加工之間的資料介面，則稱這些資料儲存
為區域性資料儲存。
8. 什麼是idef方法？idef0方法有哪些特點？
idef方法是美國空軍針對計算機輔助製造工程專案中用於進行複雜系統分析和設計方法。是在結構化分析方法基礎上
提出來的。
idef0描述系統的功能活動及聯絡，建立系統的功能模型
idef1描述系統的資訊及聯絡，建立系統的資訊模型。
idef2進行系統模型，建立系統的動態模型
idef0特點:
1.採用方框和箭頭等簡單圖形符號描述系統的活動和資料流，描述活動所受的約束條件及實現機制
2.採用嚴格的自頂向下、逐層分解的方式建立系統功能模型。
9.sa方法優缺點（sa是一種結構化分析方法，適用於開發資料庫處理型別軟體的需求分析。利用圖形等半形式化工具表達需求、簡明）
1.sa方法是乙個靜態模型，沒有反應處理的順序，即控制流程。
2.sa方法使用dfd在分析與描述「資料要求」方面有侷限的，只有與資料庫技術的實體練習圖（er）結合起來
3.dfd不適合描述人機介面系統的要求，一些人機互動頻繁的軟體系統。
4.sa方法要與形式化方法結合起來，才能更精確地描述軟體需求
5.要借助需求分析工具，提供需求分析的質量及效率
需求分析 軟體工程第三章
基本任務 對目標系統提出完整 準確 清晰 具體的要求，即準確的回答 系統必須做什麼？這個問題。為什麼需要需求分析 因為在可行性研究階段，我們是以最小的 和最短的時間內確定是否存在可行的解法方法，忽略了很多細節，在這個階段需要詳細描述。分析方法必須遵守的準則 1 必須理解並描述問題的資訊領域，根據這條...
軟體工程 第三章 需求分析
1.需求分析的定義 在軟體工程中，需求分析是指在開發乙個新的或公升級乙個已有的軟體系統時描寫新系統的目的 範圍 定義和功能時所要做到工作。確定好顧客需求 2.需求分析的目的 準確地理解使用者需要什麼，反覆調查分析，做出乙個軟體需求規格說明書 3.需求分析的特點 1 使用者與開發人員很難進行交流 2 ...
《軟體工程》第三章 需求分析 作業
1 需求分析是軟體定義時期的最後乙個階段，是開發人員經過深入細緻的調研和分析，準確理解使用者和專案的功能 效能 可靠性等要求。該階段是分析系統在功能上需要實現什麼，而不考慮如何去實現。2 基本任務是準確地回答 系統必須做什麼 這個問題，確定系統必須完成哪些工作，也就是對目標系統提出完整 準確 清晰 ...