軟體工程學習筆記《三》需求獲取
阿新 • • 發佈：2018-11-09
文章目錄
軟體工程學習筆記《目錄》
需求工程師
當代的需求工程師需要具備的能力
- 分析問題和解決問題的能力
- 人際溝通及交流的能力
- 軟體工程師知識和技能
- 應用領域有關知識
- 書面語言組織和表達能力
當代的需求工程師需要努力的方向
- 識別錯誤假設
- 確保一致性
- 提升依從性
- 減少彼此誤解
- 提升支援速度和效率
- 提升客戶滿意度
- 撰寫優質文件
當代的需求工程師需要注意的錯誤
- 干擾
- 沉默
- 過度規約
- 矛盾
- 含糊
- 向前引用
- 不切實際與一廂情願
需求的定義
需求是人們要解決的某個問題或達到某種目的的需要，是系統或其組成部分為滿足某種書面規定（合同，標準，規範等）所要具備的能力。需求將作為系統開發，測試，驗收,提交的正是文件依據。
需求目標
對產品及其與環境的互動進行更深入的瞭解，識別系統需求，設計軟體體系結構，建立需求與體系結構元件的關聯，在體系結構設計實現過程中進一步識別矛盾衝突，並通過干係人之間的協調磋商解決問題。
需求分析的實質
概念建模——選擇常用的建模語言，進行功能建模和資訊建模
需求分析的關鍵
體系結構設計與需求分配
應該涵蓋的內容？
- 為什麼設計該系統
- 由誰使用
- 要做什麼
- 系統要涉及哪些資訊
- 對解決方案有什麼額外限制
- 如何使用該系統
- 質量需達到什麼程度
需求規約（作為較客觀的參照）
單個需求項的質量
- 準確
- 正確
- 可行
- 可證
整個需求集合的質量
- 顯示
- 精確
- 全面
- 一致
需求分析
產品/過程
- 產品需求
- 過程需求
產品需求
- 功能性需求
- 非功能性需求
需求分類的合理使用
-
關注特殊的需求特徵
-
關注需求語義特徵
- 明確指出系統必須支援的行為
- 排序那些不可接受的系統行為
- 明確指出系統的最好支援的行為
-
對那些適用範圍受限的關注點和橫切關注點區別對待
-
需求的分類主要用於為需求的抽取提供啟發式的規則
- 避免忽略某些關鍵的需求型別
- 通過已知矛盾的需求型別發現具體需求間的矛盾和衝突
-
業務需求
- 業務需求又叫業務目標：攜程旅行的業務：買飛機票；公司目標：成為認為想買飛機票首先想到的公司
-
使用者需求
- 有時候被稱為“使用者介面需求”，系統的使用者需求指其滿足會影響系統的使用者接收程度的需求
-
系統需求
- 系統需求的滿足使得系統實現預期的功能，他從使用者的角度描述系統做什麼，與系統是由什麼硬體和軟體實現無關。
-
軟體設計規約
- 系統的API需要同時支援C++和Java來讓程式設計師訪問系統服務
-
軟體需求
- 軟體需求是指關於系統中軟體部分的需求，它滿足幫助實現系統需求
-
功能性需求
- 又稱“行為需求”，指滿足系統需求需要提供的功能
-
質量需求
- 關於“提供的服務好到何種程度”的問題。訂票系統的訂票請求響應時間要小於1分鐘
-
依從性需求
- 指要著重描述軟體對國家法律，國際公約，社交法則，文化與政治習慣，標準等環境約束的滿足要求。兩列火車間的最小間距應滿足國際鐵路運輸安全規範中的最壞情況停車距離
-
體系結構設計需求
- 分散式約束：要求軟體系統元件滿足目標組織由於地理自然分佈導致的對系統裝置節點的分佈要求，以及資料的分散式儲存與處理要求。
例如：會議排程系統應與分佈在世界各地的參會者的郵件服務系統和電子日程管理系統協同工作 - 安裝約束：要求軟體系統能夠在目標實現環境下正常執行
例如：會議排程系統應在微軟和IOS上
- 分散式約束：要求軟體系統元件滿足目標組織由於地理自然分佈導致的對系統裝置節點的分佈要求，以及資料的分散式儲存與處理要求。
-
設計開發約束
- 指對軟體系統設計過程的約束，包括：開發成本，開發週期，產品特徵的變化性，可維護性，可移植性，可重用性等。
例如，動車控制軟體應在兩年內投入使用。會議日程安排系統應根據會議型別動態調整
- 指對軟體系統設計過程的約束，包括：開發成本，開發週期，產品特徵的變化性，可維護性，可移植性，可重用性等。
需求之間存在重疊
- 功能性需求與非功能性需求間的劃分並非絕對的，可能存在重疊
- 是一個功能性需求，也是安全性需求
需求獲取方式
面談
問卷
群體誘導
參與調查
文件分析
會議
頭腦風暴
需求討論會
情景分析
概念建模
競爭性需求分析
A/B測試
如何選擇需求方案？
如何撰寫需求文件？
軟體需求規格說明
需求文件的組織形式
規格說明SRS的風格
撰寫原則例項
