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

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

在第9章學習中，

需求文檔應該是由形式化，結構化，陳訴一致的樣式，確定的態度，定量化，言簡意賅的自然語言（用戶術語）編寫，需要通過風險承擔者確認需求的定義恰當。
軟件需求規格說明，應當是能使非計算機人士能清楚明白操作流程和運作邏輯，所以允許加註釋留白以及勾畫等，這一點出乎我的意外。我們需要編寫可以驗證的可接受的風險程度的需求規格說明書，所以用詞不能含糊，說明必須清楚，前因後果，來龍去脈，定量定時的，不能讓用戶不知所措。
另外，我們知道編寫過程中會有多次修改，為了編寫需求規格說明書時易於刪減修改，方便我們在這樣反復的過程中能夠回顧歷史，常采用層次化或者序列化的標誌

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

在第10章的學習中，

為了描述系統中所發生的過程，我們需要學習建立模型（使用CASE工具），學習圖形化的原則與含義。通過學習我對數據字典（為了方便多個程序員編寫出現的數據差異，可先形成統一），數據流圖-運作過程/操作步奏，關聯圖黑匣子，逐步細化，0層數據圖，
實體聯系圖（名詞動詞形式），狀態轉換圖，狀態轉化圖的一種--對話圖（方便界面設計指南），類圖等的規則有所了解。但是，對於這一部分我認為還是要通過實際聯系來得到深刻理解。

《軟件需求》讀後感04