那麼，產品設計，就從需求分析開始吧。
本來是要推薦這本書給周圍的朋友，因爲裏面關於軟件需求分析的講些，融合了很多關於如何提問題的思考，如何溝通的思考，如何進行事務分析的思考，如何運用軟件工程的知識。
但是裏面的內容確實晦澀難懂，需要花費很大精力，才能看全，看懂書上的知識和經驗，而且看懂了，也難以在實際工作中按順序實踐，索性，只推薦了一兩個，就放棄了。
我想，可以試試重新整理書本的內容，重新組織，再來回答：軟件需求實踐，可以怎麼實踐落地。
先從一個案例開始。
有一個醫院希望建設一個醫院信息管理系統，以提高醫院的信息化管理水平。這個信息系統包含體檢模塊。這裏忽略業務目標的推導，直接輸出關於體檢業務的需求分析結果。
需求分析的結果，不涉及任何軟件系統的開發。這個結果把軟件系統當成一個黑盒子，它告訴我們，在業務環境下，進行業務操作，需要系統協助做些什麼事情。
而需求分析的過程，就是提出問題，尋找答案，輸出結果的過程。
“需求定義的過程，提出企業/組織要解決的問題
需求定義核心輸出兩類內容：
- 業務目標：
例如，體檢管理要解決的問題是預約安排不合理的問題，同時避免出現體檢部門超負荷。
當然，醫院本身也有可能通過多個信息系統的打通，來解決醫院內部信息孤島的問題，從而方便各類信息的流轉，例如從門診到住院的信息的打通，就可以方便住院人員的全流程服務。而針對如住院，體檢，急診等各項業務的信息管理，也都有相關的業務目標，這些目標可以進一步梳理。
- 項目範圍
a. 劃分主題域
什麼是主題域，我個人覺得挺難理解的，但是在醫院裏，我們講將系統劃分成住院管理，門診管理，體檢管理、門診管理，就很好理解，而這些就主題域，簡單地講，就是和業務部門一一對應的（當然，業務部門要非常清晰的職責劃分）。
b. 確定主題域的用戶
如門診部門使用系統的有體檢者，前臺工作人員，客服工作人員等
【配圖】
c. 初步梳理事件和報表
如門診管理主要事件有：
- 體檢者進行體檢申請
- 客服中心查詢體檢情況
- 系統通知用戶取報告
如體檢管理輸出的報表有： - 體檢申請表
- 體檢登記表
- 體檢報告
-
各體檢項統計表
![]()
.
需求捕獲的過程，探索用戶需求的答案
需求捕獲的過程，是通過需求調研，輸出更詳細的用戶活動，以及每個活動的步驟的過程。
這個階段，主要是從用戶的角度，出發挖掘：
- 每個事件下，有哪些活動。
例如：事件“體檢者做體檢申請”，那麼可能會經過的步驟如下所示。這就是需求捕獲需要挖掘的第一個層次的答案。
- 每個活動，都需要經過哪些步驟
例如，針對以上事件下的活動，體檢者填寫體檢單，那麼我們要問，填寫體檢單的步驟有哪些？這就是需求捕獲要挖掘的第二個層次的答案。
而在這個過程，就是用戶需求逐步清晰的過程
當然本書關於需求調研放在需求捕獲的 階段，我個人覺得是可以斟酌的。按正常的項目過程，可能從項目立項的時候，需求調研就已經開始了。只是書本把需求調研的過程集中在這個部分進行描述而已。
不過這並不影響本書的理論的完整性。
本章有兩個亮點：
介紹需求調研過程的一些溝通原則，和溝通的話術。
很多書都會講需求調研的過程步驟，很少有工具書同時指導你如何溝通，作者提供給我們更深層次的需求調研的溝通過程，不讓需求調研只做表面功夫。介紹了需求調研結果的記錄工具。
另外，需求調研結果的記錄工具，很多工具也很少講，然後就直接過渡到了建模和設計的過程了。本書把用戶需求和軟件需求切割開，這個需求調研結果記錄的工具應該功不可沒
另外，本文章最前面，我沒有直接定義業務需求，用戶需求，和軟件需求。因爲在想，大部分人應該都跟我一樣，沒有了解需求分析的過程之前，這三個概念直接拋出來，還是似懂非懂。
這裏應該就可以稍微講下我對這三類需求的理解了。
還是從體檢系統出發：
業務需求就是業務目標，是企業/組織希望通過系統要解決的問題。
-
用戶需求就是何人做何事，在主題域劃分爲事件的時候，用戶需求已經開始了。最終就變成了用戶的實際操作步驟。當然，用戶需求的組織過程（如主題域，事件，活動等）也屬於用戶需求的一部分。
![]()
-
軟件需求，是把系統當成和人交互的另外一個人，把用戶需求，轉化爲用戶和系統交互的具體過程。同樣地，軟件需求的組織過程（主題域轉化爲子系統，業務事件和活動轉化爲業務流程，報表，數據，用戶等抽象爲類對象）也屬於軟件需求的一部分。
![]()
.
“需求建模的過程，組織軟件需求的答案，輸出結果。