軟件工程學習筆記《目錄》

軟件工程學習筆記《目錄》

需求工程師

當代的需求工程師需要具備的能力

• 分析問題和解決問題的能力
• 人際溝通及交流的能力
• 軟件工程師知識和技能
• 應用領域有關知識
• 書面語言組織和表達能力

當代的需求工程師需要努力的方向

• 識別錯誤假設
• 確保一致性
• 提升依從性
• 減少彼此誤解
• 提升支持速度和效率
• 提升客戶滿意度
• 撰寫優質文檔

當代的需求工程師需要注意的錯誤

• 干擾
• 沉默
• 過度規約
• 矛盾
• 含糊
• 向前引用
• 不切實際與一廂情愿

需求的定義

需求是人們要解決的某個問題或達到某種目的的需要，是系統或其組成部分為滿足某種書面規定（合同，標準，規范等）所要具備的能力。需求將作為系統開發，測試，驗收,提交的正是文檔依據。

需求目標

對產品及其與環境的交互進行更深入的了解，識別系統需求，設計軟件體系結構，建立需求與體系結構組件的關聯，在體系結構設計實現過程中進一步識別矛盾沖突，并通過干系人之間的協調磋商解決問題。

需求分析的實質

概念建模——選擇常用的建模語言，進行功能建模和信息建模

需求分析的關鍵

體系結構設計與需求分配

應該涵蓋的內容？

• 為什么設計該系統
• 由誰使用
• 要做什么
• 系統要涉及哪些信息
• 對解決方案有什么額外限制
• 如何使用該系統
• 質量需達到什么程度

需求規約（作為較客觀的參照）

單個需求項的質量

• 準確
• 正確
• 可行
• 可證

整個需求集合的質量

• 顯示
• 精確
• 全面
• 一致

需求分析

產品/過程

• 產品需求
• 過程需求

產品需求

• 功能性需求
• 非功能性需求

需求分類的合理使用

• 關注特殊的需求特征

• 關注需求語義特征

  • 明確指出系統必須支持的行為
  • 排序那些不可接受的系統行為
  • 明確指出系統的最好支持的行為

• 對那些適用范圍受限的關注點和橫切關注點區別對待

• 需求的分類主要用于為需求的抽取提供啟發式的規則

  • 避免忽略某些關鍵的需求類型
  • 通過已知矛盾的需求類型發現具體需求間的矛盾和沖突

• 業務需求

  • 業務需求又叫業務目標：攜程旅行的業務：買飛機票；公司目標：成為認為想買飛機票首先想到的公司

• 用戶需求

  • 有時候被稱為“用戶接口需求”，系統的用戶需求指其滿足會影響系統的用戶接收程度的需求

• 系統需求

  • 系統需求的滿足使得系統實現預期的功能，他從用戶的角度描述系統做什么，與系統是由什么硬件和軟件實現無關。

• 軟件設計規約

  • 系統的API需要同時支持C++和Java來讓程序員訪問系統服務

• 軟件需求

  • 軟件需求是指關于系統中軟件部分的需求，它滿足幫助實現系統需求

• 功能性需求

  • 又稱“行為需求”，指滿足系統需求需要提供的功能

• 質量需求

  • 關于“提供的服務好到何種程度”的問題。訂票系統的訂票請求響應時間要小于1分鐘

• 依從性需求

  • 指要著重描述軟件對國家法律，國際公約，社交法則，文化與政治習慣，標準等環境約束的滿足要求。兩列火車間的最小間距應滿足國際鐵路運輸安全規范中的最壞情況停車距離

• 體系結構設計需求

  • 分布式約束：要求軟件系統組件滿足目標組織由于地理自然分布導致的對系統設備節點的分布要求，以及數據的分布式存儲與處理要求。
    例如：會議調度系統應與分布在世界各地的參會者的郵件服務系統和電子日程管理系統協同工作
  • 安裝約束：要求軟件系統能夠在目標實現環境下正常運行
    例如：會議調度系統應在微軟和IOS上

• 設計開發約束

  • 指對軟件系統設計過程的約束，包括：開發成本，開發周期，產品特征的變化性，可維護性，可移植性，可重用性等。
    例如，動車控制軟件應在兩年內投入使用。會議日程安排系統應根據會議類型動態調整

需求之間存在重疊

• 功能性需求與非功能性需求間的劃分并非絕對的，可能存在重疊
  • 是一個功能性需求，也是安全性需求

需求獲取方式

面談

問卷

群體誘導

參與調查

文檔分析

會議

頭腦風暴

需求討論會

情景分析

概念建模

競爭性需求分析

A/B測試

如何選擇需求方案？

如何撰寫需求文檔？

軟件需求規格說明

需求文檔的組織形式

規格說明SRS的風格

撰寫原則實例