目錄
一、軟件需求概述
真題示例:?
二、質量功能部署(QFD)
三、需求開發流程
需求獲取
需求分析
需求定義(SRS)
需求驗證
真題示例:?
四、需求管理
真題示例:
一、軟件需求概述
軟件需求分為三個層次:
- 業務需求:企業/客戶的高層次目標(如項目投資人、市場部門提出)。
- 用戶需求:用戶的具體任務或目標(通過訪談、問卷調查獲取)。
- 系統需求:包括功能需求、非功能需求和設計約束。
- 功能需求:系統必須實現的具體功能(如拼寫檢查)。
- 非功能需求:系統質量屬性(如性能、可靠性)。
- 設計約束:限制條件(如必須使用國產數據庫)。
真題示例:?
軟件需求開發是指從情況收集、分析和評價到編寫文檔、評審等一系列產生需求的活動,分為獲取情況、分析、( )和評審四個階段。
A. 制訂規格說明 B. 形成需求基線 C. 跟蹤需求變更 D. 控制需求版本
?軟件需求開發分為獲取情況、分析、制訂規格說明和評審四個階段。制訂規格說明即輸出《軟件需求規格說明書》,作為開發基線。形成需求基線是需求驗證確認后用戶簽字后的結果;跟蹤需求變更和控制需求版本屬于需求管理的范疇,并非需求開發階段的內容。
某軟件公司正在承擔開發一個字處理器的任務。在需求分析階段,公司的相關人員整理出一些相關的系統需求,其中:
- “找出文檔中的拼寫錯誤并提供一個替換項列表來供選擇替換拼錯的詞”屬于( );
- “顯示提供替換詞的對話框以及實現整個文檔范圍的替換”屬于( );
- “用戶能有效地糾正正文檔中的拼寫錯誤”屬于( ) 。
A. 業務需求 B. 用戶需求 C. 功能需求 D. 性能需求
?用戶需求、功能需求、業務需求
-
“找出文檔中的拼寫錯誤并提供一個替換項列表來供選擇替換拼錯的詞”
這一需求描述了用戶希望系統能夠幫助他們完成的具體任務,屬于用戶需求。它從用戶角度出發,明確了用戶希望通過系統實現的目標(檢測錯誤并提供替換選項)。 -
“顯示提供替換詞的對話框以及實現整個文檔范圍的替換”
這一需求具體說明了系統需要實現的功能模塊(如對話框的顯示和全局替換功能),屬于功能需求。它定義了系統如何通過技術手段滿足用戶需求。 -
“用戶能有效地糾正文檔中的拼寫錯誤”
這一需求是公司開發該功能的高層次目標,屬于業務需求。它反映了組織開發系統的業務動機(提升用戶體驗和產品競爭力)。
這種分類確保了需求從抽象目標到具體實現的層次遞進,符合軟件工程的需求分析方法。
二、質量功能部署(QFD)
將用戶需求轉化為技術需求,分為三類:
- 常規需求:用戶明確提出的功能,實現越多越滿意。
- 期望需求:用戶默認應具備的功能(未實現會導致不滿)。
- 意外需求:超出用戶預期的功能(實現可提升滿意度,但不影響購買決策)。?
三、需求開發流程
-
需求獲取
- 方法:用戶訪談、問卷調查、采樣、情節串聯板、聯合需求計劃(JRP)。
-
需求分析
- 目標:確保需求無二義性、可測試、完整。
- 任務:繪制系統上下文圖、創建原型、確定優先級、建立數據字典等。
- 結構化分析模型:
- 功能模型:數據流圖(DFD)。
- 行為模型:狀態轉換圖(STD)。
- 數據模型:E-R圖。
- 數據流圖
-
數據流圖描述數據在系統中如何被傳送或變換,以及如何對數據流進行變換
的功能或子功能,用于對功能建模,數據流圖相關概念如圖: -
? -
數據流圖是可以分層的,從頂層(即上下文無關數據流)到0層、1層等,頂
層數據流圖只含有一個加工處理表示整個管理信息系統,描述了系統的輸入和
輸出,以及和外部實體的數據交互。數據流圖示例如下: -
-
-
- 目標:確保需求無二義性、可測試、完整。
-
需求定義(SRS)
- 輸出《軟件需求規格說明書》,作為開發基線。
- 方法:
- 嚴格定義:假設所有需求可預先明確。
- 原型法:通過迭代模型逐步確認需求。
-
需求驗證
- 步驟:評審(正式/非正式) + 測試(概念測試用例)。
- 確認后需用戶簽字,形成需求基線。
真題示例:?
需求獲取是確定和理解不同的項目干系人的需求和約束的過程,需求獲取是否科學、準備充分,對獲取出來的結果影響很大。在多種需求獲取方式中,( )方法具有良好的靈活性,有較寬廣的應用范圍,但存在獲取需求時信息量大、記錄較為困難、需要足夠的領域知識等問題。( )方法基于數理統計原理,不僅可以用于收集數據,還可以用于采集訪談用戶或者是采集觀察用戶,并可以減少數據收集偏差。( )方法通過高度組織的群體會議來分析企業內的問題,并從中獲取系統需求。
選項內容
A. 用戶訪談 B. 問卷調查 C. 聯合需求計劃 D. 采樣
-
用戶訪談靈活性高但依賴領域知識。
-
采樣通過統計學方法減少偏差。
-
聯合需求計劃(JRP)是群體會議驅動的需求獲取方式。
-
問卷調查更適用于大規模數據收集。
四、需求管理
- 需求基線:通過評審的需求說明書,變更需走流程。
- 變更控制委員會(CCB):審批和監督需求變更。
- 雙向跟蹤:
- 正向跟蹤:檢查用戶需求是否全部實現。
- 反向跟蹤:檢查系統功能是否均源于用戶需求。
- 常見風險:用戶參與不足、需求蔓延、模糊需求等。
真題示例:
( )是關于需求管理正確的說法。
A. 為達到過程能力成熟度模型第二級,組織機構必須具有3個關鍵過程域
B. 需求的穩定性不屬于需求屬性
C. 需求變更的管理過程遵循變更分析和成本計算、問題分析和變更描述、變更實現的順序
D. 變更控制委員會對項目中任何基線工作產品的變更都可以做出決定
A.CMM二級要求6個關鍵過程域(需求管理、項目計劃、項目跟蹤、配置管理、質量保證、子合同管理)
B. 需求的穩定性(如變更頻率)是重要屬性
C. 正確順序應為:問題分析和變更描述→變更分析和成本計算→變更實現
D. 變更控制委員會(CCB)負責審批所有基線產品的變更?
在結構化分析中,用數據流圖描述( )。當采用數據流圖對一個圖書館管理系統進行分析時,( )是一個外部實體。
A. 數據對象之間的關系,用于對數據建模
B. 數據在系統中如何被傳送或變換,以及如何對數據流進行變換的功能或子功能,用于對功能建模
C. 系統對外部事件如何響應,如何動作,用于對行為建模
D. 數據流圖中的各個組成部分
A. 讀者 B. 圖書 C. 借書證 D. 借閱
-
數據流圖描述內容:
數據流圖(DFD)的核心是展示數據流動和功能變換,屬于功能建模工具。A選項描述的是E-R圖(數據庫),C選項描述的是狀態轉換圖。 -
圖書館系統的外部實體:
- 外部實體指系統外的人或組織
- 讀者是系統使用者,屬于外部實體
- 圖書、借書證、借閱都是系統內部數據