軟需---需求工程概述

需求工程概述

在這裏插入圖片描述

需求工程的重要性

  1. 軟件項目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根”
  2. 需求分析奠定了軟件工程和項目管理的基礎
  3. 開發軟件系統最困難的部分就是準確說明開發什麼。最困難的概念性工作是編寫出詳細的需求,包括所有面向用戶、面向機器和其它軟件系統的接口
  4. 需求是產品的根源,需求工作的優劣對產品影響最大
  5. 軟件需求是決定軟件開發是否成功的關鍵因素

什麼是軟件需求

IEEE軟件工程標準詞彙表

  • ①用戶解決問題或達到目標所需的條件或能力。
  • ②系統或系統部件要滿足合同、標準、規範或其它正式規定文檔所需具有的條件或能力。
  • ③一種反映上面①或②所描述的條件或能力的文檔說明。

軟件需求的分類

目標需求

  • 反應組織機構或客戶對系統和產品提出的高層次的目標需求,其限定了項目的範圍和項目應達到的目標

業務需求

  • 主要描述軟件系統必須完成的任務、實際業務或工作流程等。軟件開發人員通常可以從業務需求進一步細化出具體的功能需求和非功能需求。

功能需求

  • 指開發人員必須實現的軟件功能或軟件系統應具有的外部行爲。

性能需求(非功能需求)

  • 指實現的軟件系統功能應達到的技術指標,如:計算效率和精度、可靠性、可維護性和可擴展性等。

約束與限制

  • 指軟件開發人員在設計和實現軟件系統時的限制,如:開發語言、使用的數據庫等。

需求規格說明

完整性

  • 不能遺漏任何必要的需求信息。遺漏需求將很難查出。
  • 每一項需求都必須將所要實現的功能描述清楚 。
  • 開發人員可以從需求規格說明中獲得設計和實現這些功能所需的所有必要信息。

正確性

  • 每一項需求都必須準確地陳述其要開發出的功能性。
  • 只有用戶代表才能確定用戶需求的正確性,這就是爲何一定要有用戶的積極參與的原因。
  • 沒有用戶參與的需求只是評審者憑空猜測。

可行性

  • 每一項需求都必需是在已知系統和環境的權能和限制範圍內可以實施的。
  • 最好在獲取需求過程中,始終有一位軟件工程小組的組員與需求分析人員或考慮市場的人員在一起工作,由他來負責技術可行性上的檢查。

必要性

  • 每一項需求都應把客戶真正所需要的和最終系統所需遵從的標準記錄下來。
  • “必要性”也可以理解爲每項需求都是用來授權你編寫文檔的“根源” 。
  • 要使每項需求都能回溯至某項客戶的輸入,如使用實例或別的來源。

劃分優先級

  • 給每項需求、特性或使用實例分配一個實施優先級以指明它在特定產品中所佔的分量。
  • 不劃分優先級,將導致項目管理者在開發或節省預算或調度中就喪失控制自由度 。

無二義性

  • 對所有需求說明的讀者都只能有一個明確統一的解釋。
  • 儘量把每項需求用簡潔明瞭的用戶性的語言表達出來。
  • 避免二義性的有效方法包括對需求文檔的正規審查,編寫測試用例,開發原型以及設計特定的方案腳本。

可驗證性

  • 檢查一下每項需求是否能通過設計測試用例或其它的驗證方法,如用演示、檢測等來確定產品是否確實按需求實現了。
  • 如果需求不可驗證,則確定其實施是否正確就成爲主觀臆斷,而非客觀分析了。
  • 一份前後矛盾,不可行或有二義性的需求也是不可驗證的 。

需求工程定義

  1. 需求工程是應用工程化的方法、技術和規格來開發和管理軟件的需求。
  2. 需求工程的任務就是獲取、分析和表達軟件的需求
  3. 軟件需求工程主要包括需求的開發活動和需求的管理活動。

其它一些基本概念

用戶

  • 利用計算機系統所提供的服務的人
  • 直接操作計算機系統的人,就是直接使用軟件系統的人

客戶

  • 掌握經費的人,通常有權決定軟件需求。客戶可以是用戶,也可以不是用戶。
  • 正式接受新開發或修改後的硬件和軟件系統的某個人或組織

軟件開發人員

  • 爲客戶開發軟件系統的人

項目相關人員(利益相關方)

  • 提出和定義軟件需求相關的人,包括所有用戶、客戶和軟件開發人員

練習題

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章