《軟體需求》讀後感04

今天閱讀了第二部分的第8章後部分，第9章和第10章：聆聽客戶的意見，編寫需求文件，需求的圖形化分析。

需求分析的定位是做什麼而不是怎麼做，例項圖是具有功能性質的，不宜太多或者太細。

在第9章學習中，

需求文件應該是由形式化，結構化，陳訴一致的樣式，確定的態度，定量化，言簡意賅的自然語言（使用者術語）編寫，需要通過風險承擔者確認需求的定義恰當。

軟體需求規格說明，應當是能使非計算機人士能清楚明白操作流程和運作邏輯，所以允許加注釋留白以及勾畫等，這一點出乎我的意外。我們需要編寫可以驗證的可接受的風險程度的需求規格說明書，所以用詞不能含糊，說明必須清楚，前因後果，來龍去脈，定量定時的，不能讓使用者不知所措。

另外，我們知道編寫過程中會有多次修改，為了編寫需求規格說明書時易於刪減修改，方便我們在這樣反覆的過程中能夠回顧歷史，常採用層次化或者序列化的標誌，同時我們需要養成善於記錄，待確定，分類標註的習慣。

在學習過程中，和昨天一樣的感悟確實和老師講的一樣，在開發專案整個過程中，書寫將佔據很大一部分時間。不僅是業務需求——專案檢視和範圍，使用者需求——使用例項文件，還有功能需求文件和非功能需求文件，包含了專案外部和內部，前景和當下，軟體和硬體，前端和後台功能例項等等內容。

在第10章的學習中，

為了描述系統中所發生的過程，我們需要學習建立模型（使用case工具），學習圖形化的原則與含義。通過學習我對資料字典（為了方便多個程式設計師編寫出現的資料差異，可先形成統一），資料流圖-運作過程/操作步奏，關聯圖黑匣子，逐步細化，0層資料圖，

實體聯絡圖（名詞動詞形式），狀態轉換圖，狀態轉化圖的一種--對話圖（方便介面設計指南），類圖等的規則有所了解。但是，對於這一部分我認為還是要通過實際聯絡來得到深刻理解。