需求分析主要是為了減少我們與客戶間的需求雜訊，避免客戶的期望與系統分析師的認知有落差。上面是一個有趣的漫畫，讓我們了解分析需求的重要性。
一、需求工程概述
需求工程是指應用有效的方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。
1. 需求工程主要內容
在我的經驗上，一個專案做一輪需求分析的大致流程如下：通常引導用戶理解自己的需求並提供描述給需求分析人員，先做腦力激盪發散大家的想法，到一定程度後再收斂出較為現實可行的做法。最後產生出軟體需求說明 (Software Requirements Specifications, SRS)，作為用戶和開發者之間的一個協約。
而需求驗證和管理是對需求「維護」的部分，在第一次需求分析與之後迭代的需求分析中，把每次獲取的需求做恰當的整合管理。
- 需求獲取 (Requirements Elicitation) : 通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而捕獲用戶的需求。
- 需求分析 (Requirements Analysis) : 確定新系統的目的、範圍 (Scope)、定義和功能時所要做的所有工作。
- 需求規格 (Requirements Specification) : 是需求分析後的直接產物。精確的形式化的描述需求，作為用戶和開發者之間的一個協約。(此時通常會產生一個名為 Software Requirements Specifications, SRS 的文件)
- 需求驗證 (Requirements Validation) : 確認文檔和建模的產物符合客戶的需求。
- 需求管理 (Requirements management) : 支持系統的需求演進(the evolution of requirements)，如需求變化和可跟蹤性問題。
2. 需求的特徵
不完整性 (Incomplete Requirements) : Most software systems are complex and change over time, developers can never fully capture all the requirements during the system development.
不一致性 (Inconsistent Requirements) : Different users have different requirements and priorities. There is a constantly shifting compromise in the requirements. Prototyping is often required to clarify requirements.
二、需求獲取 : 產生用例
1. 用例圖 (use case diagram)
用例圖並不是畫成了圖形的用例，用例圖包含一組用例。圖形符號只給出最簡單的一個或一組用例的概要。某一參與者 (actor) 與某一用例 (use case)用線連起來，表示該參與者和該用例有交互(relationship)。參與者不一定是人，可以是其他軟體、硬體等等。
用例圖中三種用例類型 (會畫在線上)：
- Base use case : this is the case in which all go smoothly.
- Extension use case : this is the case to extend the behavior of a base case.
- Inclusion use case : this is the case in which common functionality is factored out for reuse.
2. 用例 (use case)
用例是軟體工程對系統如何反應外界請求的描述，是一種通過場景 (scenarios) 來獲取需求的技術。每個用例提供一個或多個場景，該場景說明了系統是如何和最終用戶或其它系統互動。
編寫用例時要避免使用技術術語，而應該用最終用戶或者領域專家的語言。用例一般是由軟體開發者和最終用戶共同創作的。
用例撰寫的注意事項：
- 不描述實作細節：不要描述實作細節，只講功能就好，例如不要說明資料將被存到Oracle資料庫，而說資料將被儲存就好，不要講UI上的內容，例如按下存檔按鈕。
- 不描述非功能性需求：只描述滿足業務目標的業務活動，不要講非功能性需求，例如系統每個操作要在2秒內回應，同時上線人數要達3000人等。
- 選擇合適的細節級別：選擇合適的細節級別使用例足夠短，在一次發布中能夠被一個軟體開發人員實現
用例的優點：
- 從鳥瞰的視野綜觀系統的全貌
- 容易看出所欲表達的層次，如企業層級(Business level)、使用者目標層級(User-goal level)等
- 可以利用套件界定系統的設計範圍(Boundary)。
- 避免過早涉及至細節。
3. 活動圖 (Activity Diagram)
在產生用例時，可選擇的是否畫活動圖 (activity diagram) 的圖補足用例的描述。活動圖是一個非常實用的圖款，適合用來具體呈現「企業流程」（Buisness Process）或「工作流程」（Workflow）等等的活動流程觀點。
[用心去感覺] use case, use case diagram 和 use case spec
我自己在做的時候，先畫一個用例圖 (use case diagram)，再把各個用例 (use case) 的情形用用例規格書 (use case spec) 填一填，就產生好用例囉！ 之後可以拿這些用例去做其他需求分析 : )
三、需求分析 : 產生系統架構(SA)並標上需求描述
1. 系統架構 (system architecture)
架構圖中的每一條線對應到一個需求描述 (除了non-functional requirement)，需求描述的分類如下：
- Functional requirements : describe system services or functions
- Non-functional requirements : constraints or goals on the system or on the development process
- Interface requirements : define the message passing between subsystems and external environment
- External interface requirement
- Internal interface requirement
三、需求規格 : 產生SRS (System Requirement Specification)
至此我們可以產生需求分析最重要的文件：軟體需求規格說明 (SRS, system requirement specification) 。
軟體需求規格說明是軟體系統需求的規格化說明，是對將要開發系統的行為的說明。它包括功能性需求及非功能性需求，非功能性需求對設計和實現提出了限制，比如性能要求，質量標準，或者設計限制。
下面是一份SRS通常需要的內容：
- System Architecture
- Requirements Description
- Functional requirements
- Non-functional requirements
- Interface requirements: external and internal
- Scenarios and Operational concept
- Use case diagram
- Use case specifications
- Sequence diagrams (optional but useful to visualize the interactions between object instances when programming)
- Traceability matrix
References
台大李允中教授講義 (研究所課程)
交大王豐堅教授講義 (大學部課程)
[系統開發生命週期]Use Case Diagram概述
[系統開發生命週期]Use Case Diagram補完
從鳥瞰的觀點看 Use Case Diagram
Creately - 超級好用的use case線上繪圖工具
UML Use Case Include
wiki - use case
物件導向實例 – 以 DCOM 實踐一個簡單的聊天室 作者：朱子、吳明皓，寫得超好推薦閱讀！
發表文章
