功能性需求與非功能性需求

---

---

軟體開發中需求概述

功能性需求

定義系統應該做什麼。它們定義系統必須具備的特定行為、特性和功能，以滿足使用者的需求。這些需求通常表示為系統應執行的操作或任務。

示例

• 使用者身份驗證 - 系統必須允許使用者使用使用者名稱和密碼登入。

• 資料處理 - 系統必須即時處理和驗證使用者輸入。

• 報表 - 系統必須每月生成銷售報表。

非功能性需求

定義系統應該如何執行。它們定義系統必須遵守的質量屬性、效能標準和約束。這些需求側重於可用性、可靠性、安全性、可擴充套件性等方面。

示例

• 效能 - 系統必須能夠處理多達1000個併發使用者，響應時間小於2秒。

• 安全性 - 系統必須確保所有敏感資訊的加密。

• 可用性 - 系統必須易於使用，並且殘疾使用者也能訪問。

功能性需求的型別

• 使用者介面需求 - 與UI元件、佈局和設計相關的需求（例如，搜尋欄）。

• 業務需求 - 描述業務規則和策略（例如，系統應根據位置應用稅率）。

• 資料管理需求 - 定義系統應如何處理資料輸入、儲存和處理。

• 管理需求 - 系統管理的功能，例如使用者角色管理或訪問控制。

用例示例

描述一個功能性需求示例以及它如何幫助實現業務目標。

非功能性需求的型別

效能需求

• 響應時間 - 系統對給定輸入或請求做出反應所需的時間。

• 吞吐量 - 指系統在給定時間段內可以處理資料或完成任務的速率。

• 延遲 - 指使用者操作與系統相應響應之間的時間延遲。

示例

響應時間 - 對於93%的使用者，頁面應在2秒內載入。

可擴充套件性需求

系統處理資料量、使用者或事務增長能力。

示例 - 系統應支援多達10,000個併發使用者。

安全需求

資料保護、加密和訪問控制的需求。

示例 - 密碼必須在儲存之前進行雜湊和加鹽處理。

可用性需求

與系統易用性和可學習性相關的需求。

示例 - 所有核心功能都應在不超過三次點選的情況下即可訪問。

可靠性和可用性需求

定義系統的預期正常執行時間和容錯能力。

示例 - 系統應具有99.9%的正常執行時間。

可維護性和可移植性

易於維護、除錯和遷移的需求。

示例 - 程式碼應遵循已記錄的標準以確保可維護性。

法律和合規性需求

系統必須遵守的法規和標準（例如，GDPR - 通用資料保護條例）

示例 - 使用者必須同意根據GDPR使用資料。

收集需求的技術

與利益相關者和使用者面談以瞭解預期。

調查問卷收集來自廣大受眾的反饋。

研討會和頭腦風暴會議用於協作需求收集。

觀察和跟班以瞭解現實世界中的使用者互動。

文件分析現有系統和策略。

原型和模型以視覺化需求並收集反饋。

記錄功能性和非功能性需求

需求文件

• 軟體需求規格說明書 (SRS) 文件 - 用於詳細捕獲功能性和非功能性需求。

• 敏捷使用者故事和驗收標準 - 定義每個需求的“完成”狀態。

使用圖表

• 用例圖 - 視覺化功能性需求。

• 流程圖和序列圖 - 用於流程流和系統互動。

非功能性文件

• 質量屬性場景 - 在場景中描述非功能性需求（例如，“如果伺服器發生故障，系統應在3分鐘內恢復”）。

• 最佳實踐 - 確保需求清晰、可測試且具有優先順序。

管理功能性和非功能性需求的挑戰

• 模糊性和誤解 - 模糊的需求會導致誤解。使用清晰具體的語言。需求變更：需求可能會頻繁變更；使用敏捷方法來提高靈活性。

• 功能性目標和非功能性目標之間的衝突 - 可能需要權衡（例如，安全與可用性）。

• 優先順序問題 - 可能會忽略高優先順序的非功能性需求（如安全性）。

• 利益相關者一致性 - 確保所有利益相關者都同意優先順序和定義。

管理和驗證需求的最佳實踐

• 讓利益相關者參與 - 定期獲得利益相關者的反饋，確保需求與預期相符。

• 對需求進行優先順序排序 - 根據業務重要性對功能性和非功能性需求進行排名。

非功能性需求測試

負載測試用於效能需求。

可用性測試用於使用者體驗。

安全審計用於安全和合規性需求。

迭代審查和改進，定期檢查需求的完整性和相關性。

使用自動化，使用JIRA、Confluence和Trello等工具即時跟蹤需求的可追溯性。

總結

對功能性和非功能性需求採取平衡的方法對於構建強大、以使用者為中心的軟體系統至關重要。本文重點介紹了這些需求的定義、型別以及收集、記錄和驗證這些需求的方法，確保軟體專案與使用者的期望和技術標準相符。