軟體需求

---

---

軟體需求是對目標系統功能和特性的描述。需求傳達了使用者對軟體產品的期望。從客戶的角度來看，需求可能是顯而易見的或隱藏的，已知的或未知的，預期的或意外的。

需求工程

從客戶那裡收集軟體需求，分析並記錄這些需求的過程稱為需求工程。

需求工程的目標是開發和維護複雜的、描述性的“系統需求規格說明”文件。

需求工程流程

這是一個四步流程，包括：

• 可行性研究
• 需求收集
• 軟體需求規格說明
• 軟體需求驗證

讓我們簡要了解一下這個過程：

可行性研究

當客戶聯絡組織以開發所需產品時，他們會提出一個關於軟體必須執行的所有功能以及期望軟體具有的所有特性的粗略想法。

參考這些資訊，分析人員會詳細研究所需系統及其功能是否可行。

此可行性研究側重於組織的目標。本研究分析軟體產品是否可以在實施方面、專案對組織的貢獻、成本限制以及根據組織的價值觀和目標方面具體實現。它探討了專案的技術方面和產品，例如可用性、可維護性、生產力和整合能力。

此階段的輸出應為一份可行性研究報告，其中應包含充分的意見和建議，供管理層參考，說明是否應開展該專案。

需求收集

如果可行性報告對開展專案持肯定態度，則下一階段將從收集使用者的需求開始。分析人員和工程師與客戶和終端使用者溝通，瞭解他們對軟體應該提供的功能以及他們希望軟體包含哪些功能的想法。

軟體需求規格說明

SRS是由系統分析師在收集完來自各個利益相關者的需求後建立的文件。

SRS定義了目標軟體將如何與硬體、外部介面互動，以及操作速度、系統響應時間、軟體跨各種平臺的可移植性、可維護性、崩潰後恢復速度、安全性、質量、限制等。

從客戶那裡收到的需求是用自然語言書寫的。系統分析師有責任以技術語言記錄需求，以便軟體開發團隊能夠理解和使用。

SRS應具備以下特點：

• 使用者需求以自然語言表達。
• 技術需求以結構化語言表達，在組織內部使用。
• 設計描述應以虛擬碼編寫。
• 表單和GUI螢幕截圖的格式。
• DFD等條件和數學符號。

軟體需求驗證

在開發需求規格說明後，將驗證此文件中提到的需求。使用者可能會要求非法的、不切實際的解決方案，或者專家可能會錯誤地解釋需求。如果在萌芽狀態時沒有解決，這會導致成本大幅增加。需求可以根據以下條件進行檢查：

• 如果它們可以在實踐中實現
• 如果它們有效，並且符合軟體的功能和領域
• 是否存在任何歧義
• 如果它們是完整的
• 如果它們可以被證明

需求獲取流程

可以使用以下圖表描述需求獲取流程

• 需求收集 - 開發人員與客戶和終端使用者討論，瞭解他們對軟體的期望。
• 整理需求 - 開發人員根據重要性、緊迫性和便利性對需求進行優先順序排序和排列。

• 協商與討論 - 如果需求不明確或各個利益相關者的需求之間存在衝突，則需要與利益相關者進行協商和討論。然後可以對需求進行優先順序排序並進行合理妥協。

  需求來自各個利益相關者。為了消除歧義和衝突，需要對其進行討論以確保清晰度和正確性。不切實際的需求會得到合理的妥協。

• 文件化 - 所有正式和非正式、功能性和非功能性需求都將被記錄下來，並提供給下一階段處理。

需求獲取技術

需求獲取是指透過與客戶、終端使用者、系統使用者以及其他對軟體系統開發有利益關係的人員溝通，找出目標軟體系統的需求的過程。

有各種方法可以發現需求

訪談

訪談是收集需求的有效媒介。組織可以進行多種型別的訪談，例如

• 結構化（封閉式）訪談，其中要收集的每個資訊都事先決定，它們遵循模式並嚴格遵守討論事項。
• 非結構化（開放式）訪談，其中要收集的資訊沒有事先決定，更靈活，偏差更小。
• 口頭訪談
• 書面訪談
• 一對一訪談，在兩人之間進行。
• 小組訪談，在參與者之間進行。由於涉及眾多人員，因此有助於發現任何遺漏的需求。

調查

組織可以透過詢問各個利益相關者對即將推出的系統的期望和需求，在他們之間進行調查。

問卷調查

將一份包含預定義的一組客觀問題和相應選項的文件分發給所有利益相關者進行答覆，然後收集和整理這些答覆。

此技術的缺點是，如果問卷中沒有提到某個問題的選項，則該問題可能會被忽略。

任務分析

工程師和開發人員團隊可以分析需要新系統進行的操作。如果客戶已經有一些軟體來執行某些操作，則會對其進行研究，並收集提議的系統的需求。

領域分析

每個軟體都屬於某個領域類別。該領域的專家可以極大地幫助分析一般和具體的需求。

頭腦風暴

在各個利益相關者之間進行非正式的辯論，並將他們的所有意見記錄下來以供進一步的需求分析。

原型設計

原型設計是在不新增詳細功能的情況下構建使用者介面，以便使用者能夠解釋目標軟體產品的特性。它有助於更好地瞭解需求。如果客戶的終端沒有安裝任何軟體供開發人員參考，並且客戶不瞭解自己的需求，則開發人員會根據最初提到的需求建立原型。將原型展示給客戶，並記錄反饋。客戶反饋作為需求收集的輸入。

觀察

專家團隊訪問客戶的組織或工作場所。他們觀察現有已安裝系統的實際工作情況。他們觀察客戶終端的工作流程以及如何處理執行問題。團隊本身會得出一些結論，這些結論有助於形成對軟體的預期需求。

軟體需求特徵

收集軟體需求是整個軟體開發專案的基礎。因此，它們必須清晰、正確和明確定義。

完整的軟體需求規格說明必須：

• 清晰
• 正確
• 一致
• 連貫
• 易於理解
• 可修改
• 可驗證
• 優先順序
• 明確
• 可追溯
• 可靠來源

軟體需求

我們應該嘗試瞭解在需求獲取階段可能出現哪些型別的需求，以及軟體系統期望哪些型別的需求。

從廣義上講，軟體需求應分為兩類：

功能需求

與軟體功能方面相關的需求屬於此類。

它們定義軟體系統內部和外部的功能。

例如：

• 提供給使用者用於搜尋各種發票的搜尋選項。
• 使用者應該能夠將任何報告發送給管理層。
• 使用者可以被分成組，並且可以為組分配不同的許可權。
• 應遵守業務規則和管理功能。
• 開發軟體時，保持向下的相容性。

非功能需求

與軟體功能方面無關的需求屬於此類。它們是軟體的隱式或期望特性，使用者會對此做出假設。

非功能需求包括：

• 安全
• 日誌記錄
• 儲存
• 配置
• 效能
• 成本
• 互操作性
• 靈活性
• 災難恢復
• 可訪問性

需求在邏輯上被分類為

• 必須有：沒有它們，軟體就不能說是可操作的。
• 應該有：增強軟體的功能。
• 可以有：即使有這些需求，軟體仍然可以正常執行。
• 願望清單：這些需求與軟體的任何目標都不匹配。

在開發軟體時，必須實現“必須有”，而“應該有”則需要與利益相關者進行討論和協商，而“可以有”和“願望清單”可以保留用於軟體更新。

使用者介面需求

UI是任何軟體或硬體或混合系統的關鍵部分。如果軟體：

• 易於操作
• 響應迅速
• 有效處理操作錯誤
• 提供簡單而一致的使用者介面

使用者接受度很大程度上取決於使用者如何使用軟體。UI 是使用者感知系統的唯一途徑。一個性能良好的軟體系統也必須配備有吸引力、清晰、一致且響應迅速的使用者介面。否則，軟體系統的功能將無法以方便的方式使用。如果一個系統提供了有效使用它的方法，則稱其為好的系統。使用者介面需求簡述如下：

• 內容呈現
• 輕鬆導航
• 簡潔介面
• 響應式
• 一致的 UI 元素
• 反饋機制
• 預設設定
• 有目的的佈局
• 策略性地使用顏色和紋理。
• 提供幫助資訊
• 以使用者為中心的方法
• 基於群組的檢視設定。

軟體系統分析師

IT 組織中的系統分析師是一個人，他分析擬議系統的需求，並確保需求被正確地構思和記錄。分析師的角色從 SDLC 的軟體分析階段開始。分析師有責任確保開發的軟體滿足客戶的需求。

系統分析師擁有以下職責

• 分析和理解預期軟體的需求
• 理解專案將如何為組織目標做出貢獻
• 識別需求來源
• 需求驗證
• 開發和實施需求管理計劃
• 業務、技術、流程和產品需求的文件化
• 與客戶協調，對需求進行優先順序排序並消除歧義
• 與客戶和其他利益相關者最終確定驗收標準

軟體度量和衡量

軟體度量可以理解為量化和象徵軟體各種屬性和方面的過程。

軟體度量為軟體過程和軟體產品的各個方面提供度量。

軟體度量是軟體工程的基本需求。它們不僅有助於控制軟體開發過程，而且還有助於保持最終產品的質量優良。

根據湯姆·德馬科（一位軟體工程師）的說法，“你無法控制你無法衡量的東西。”從他的話中可以清楚地看出軟體度量的重要性。

讓我們來看一些軟體度量

• 規模度量 - LOC（程式碼行數），大多以交付的原始碼行數千計計算，表示為 KLOC。

  功能點計數是軟體提供的功能的度量。功能點計數定義了軟體功能方面的規模。

• 複雜度度量 - 麥凱布環複雜度量化了程式中獨立路徑數量的上限，這被認為是程式或其模組的複雜度。它透過使用控制流圖以圖論的概念表示。

• 質量度量 - 缺陷、其型別和原因、後果、嚴重程度的強度及其影響定義了產品的質量。

  在開發過程中發現的缺陷數量以及產品安裝或交付到客戶端後客戶報告的缺陷數量，定義了產品的質量。

• 過程度量 - 在 SDLC 的各個階段，使用的辦法和工具、公司標準以及開發的效能都是軟體過程度量。
• 資源度量 - 投入、時間和使用的各種資源，代表了資源測量的度量。