「軟體需求分析與塑模」－ 區分功能性需求與非功能性的需求

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

所謂的功能性需求 (functional requirements) 即是使用者需要系統能為他做什麼。這往往是顯而易見的，因為，使用者可以清楚的看到系統為他服務並會有回應。例如在一個訂購系統中，功能性需求有：

• 系統接受顧客的訂購 (系統功能－place order)，並且會通知倉管該產品庫存量是否充足。
• 系統會對前一日的訂購在當夜會產生統計報表 (系統功能－process order summary report)。

系統的功能性需求源自於開發或維護中系統的問題領域 (problem domain)。例如「電子商務系統」，功能性需求有「處理訂購」、「追蹤訂購」…等。

功能性需求需直接滿足於使用系統的操作人員或相關利益關係人 (stake holder)，它是屬於系統的「顯性價值」，是與企業的需求有直接的關聯。

功能性需求的分析技術即為本書內容的重點。各類軟體開發方法論均有提供如何分析系統功能的技術。例如 Agile (敏捷式) 的「user story」、SCRUM 的「backlog」，以及行之有年的「use case (使用案例)」。本書的系統功能分析主以「使用案例」的分析技術來捕捉系統功能性需求。它既能包容其它需求分析的技術，又能很順暢橋接到結構設計與程式寫碼實作，這在後續的章節即會詳述，並會以案例研討的方式舉例說明。

非功能性的需求 (non-functional requirements) 往往是使用者所感受不到系統有直接提供服務並有回應。非功能性的需求是總體 (global) 的、模糊 (fuzzy) 的一些因素而導致系統整體的良好運作。例如：

• 系統要能處理超過1千人以上線上訂購書籍的效能 (performance issue)。
• 系統為了要能應付日增的交易處理，所以必須要能具備延展性 (scalability issue)。
• 系統的登入 (logon) 須具有密碼加密的機制 (security issue)。

系統的非功能性需求源自於開發或維護中系統的解題領域 (solution domain)。例如「電子商務系統」採以「JEE (Java Enterprise Edition) + Spring Framework」的實作解題技術框架。

非功能性需求是屬於系統的「隱性價值」。它不容易被直接感受到，只有當碰到系統整體性的震盪 (如多人操作存取時的效能與穩定問題、帳戶安全性問題)時，系統的品質問題與危機意識等才會浮現出檯面。

一般非功能性需求較被列為實作面的考量，例如下列幾個實作議題：

• 多人上線時的交易效能與穩定性。
• 安全性的考量。
• 分散式溝通議題。
• 延展性議題。
• 異地備援/災難重建議題。

非功能性需求並非採以上述所提及的系統功能分析 (如 use case) 技術，一般它可能僅以清單列表的方式註記並列為系統的一種約束 (constraint) 即可。