8.1 從需求與流程進入資料分析
資料分析與資料建模
8.1.1 資料支持系統功能
一項功能需求通常隱含多項資料需求。FR-11要求系統允許隊長上傳專題文件，至少涉及文件名稱、格式、大小、上傳時間、所屬報名及上傳者等資料。BR-13又要求文件採PDF格式且單一檔案不得超過20 MB，因此格式與大小不只是畫面欄位，也是必須檢查的資料限制。
資料分析的目的不是把每個畫面欄位抄成一張表，而是找出系統必須長期理解的業務事實：
- 哪些事物需要被獨立辨識？
- 需要記錄哪些資訊？不會再使用的資料無需記錄。不記錄的資料將來無法出現在資訊系統。
- 不同資料之間如何連結？
- 哪些資訊可以省略？不填也沒關係。哪些資訊必須存在？沒資訊就不該允許繼續系統操作。
- 哪些資訊可以補輸入？可以暫時存在，直到執行哪一個功能之前才規定一定要輸入？
- 哪些限制來自正式需求或業務規則？
8.1.2 資料模型與其他分析模型
不同模型從不同角度描述同一系統：
| 模型 | 主要問題 | 對資料建模的貢獻 |
|---|---|---|
| 需求規格 | 系統必須滿足什麼 | 提供資料限制與業務規則 |
| 使用案例 | 參與者要完成什麼目標 | 找出輸入、輸出及持久保存的資訊 |
| 活動圖 | 工作如何進行 | 找出流程中被建立、讀取或改變的資料 |
| 資料模型 | 系統必須知道哪些事實 | 組織實體、屬性、關係與限制 |
資料模型不能取代流程模型。資料的實體關聯圖（Entity Relationship Diagram, ERD）中的兩個實體有關係，不代表流程一定依某個順序進行；活動圖中的箭頭也不等於資料實體之間的關係。
8.1.3 資料分析的範圍
系統包括很多功能，這些功能涉及不同的資料，為了簡化分析，系統分析人員應先決定某一資料模型涵蓋哪些業務範圍，再逐步把所有資料都納入。例如，Case M01可以分成報名與文件上傳、評審分派、評分與更正、結果確認與公告四個範圍。局部模型可先處理其中一項，再逐步整合。
不屬於目前需求範圍的資料不應因為「未來可能有用」就加入。例如，若系統不處理學生修課紀錄，就不應把完整選課資料納入競賽報名模型。系統不可能無限擴大，已經確認不在系統範圍內的資料，無需納入。
8.1.4 資料分析的主要產出
資料分析通常產生：
- 資料實體及其定義。
- 重要屬性與識別方式。
- 實體之間的關係、基數與選擇性。
- 資料字典與允許值說明。
- 唯一性、必填、參照及狀態限制。
- 模型元素與需求來源的追蹤關係。
- 假設、風險及待確認事項。