在本階段我決定精讀《軟體需求模式》這一本書，以此來加強我對軟體需求分析這門課的學習。
這本書的譯者就在序中提到《人月神話》中的一句話：「軟體任務的最艱難之處在於取得完全和一致的規格說明，構建程式的主要核心實際上是調整和完善規格說明。」顯然，需求分析就是連線客戶和軟體開發者，或者說，連線業務與軟體的最關鍵的橋梁。需求是開發人員開發軟體的基礎，需求也是業務人員的業務目標。
首先，我們應該認識到的就是，什麼是需求？需求應該是用最清晰的文本來闡明系統所必須具有的所有功能和其他能力，即需求就是定義系統需要做什麼而不是怎麼做。本書中就定義了需求的一些基本原則：（1）定義問題，而不是解決方案。我們要理解問題的本質，在需求中明白問題是什麼，而不是應該怎麼做。（2）定義系統，而不是專案。需求所體現的是這個系統的功能，而系統就是一組目標，但是專案卻是如何完成這一目標。（3）區分正式和非正式部分。我們應該從大量的需求資訊中，通過背景知識、前後關係、流程以及結構來正確地認識到需求的正式組成部分，即系統必須做什麼，而其他的都是非正式的。（4）避免重複。每一項資訊應該只需要表達一次，重複會產生額外的工作而且加大了不一致的可能性。在認識和定義需求的同時，本書也為我們提供了乙個典型的傳統需求階段的步驟：（1）準備。（2）收集資訊。（3）編寫需求規格草稿。（4）評審規格。（5）評審後修改。
在了解了什麼是需求和需求階段的步驟之後，我進一步學習了需求規格的內容。首先是介紹部分，系統規格的介紹部分有：系統目的、文件目的、需求格式、詞彙表、參考書目以及文件歷史。其實這六個主題的目的都是為了讓開發者能夠更清楚地認識到需求，才能更好地去開發軟體。在我看來乙個好的需求分析，應該讓我們很清楚明白地認識到我們的系統本身的目的是什麼，我們要使用更簡潔明瞭的語言用來代替一些難懂的專業術語去描述每乙個需求。所以介紹部分就是讓我們更好地認識需求，才能使我們把握好開發系統的方向。其次是上下文部分，就在上課老師也讓我們練習了這一部分的內容，即上下文圖。在上下文圖中我們需要展示元件、使用者角色、範圍邊界、系統間的介面，在這之中，我們就需要對每乙個是真的事情，清楚明確地宣告為假設，同時也要把不需要的東西排除在外，最後我們要確定關鍵業務實體（即系統就是為了產生和操縱這些東西而開發的），然後構件基礎架構（支援乙個或多個需求所需的一組基礎的能力）。然後就是定義系統的核心部分——功能域部分。我們需要在需求中詳細地列舉出系統的所有功能，將其分為大量的小節而更方便管理也更容易理解，然後需要根據功能的使用頻率、發起者的相對重要性或者對業務的價值來區分不同的功能的重要性，並且從高到低依次排列。最後是主要非功能要求部分，我們需要篩選出系統功能中不重要的部分，把它們分配到規格內容的其他部分當中，而對於主題太大的不主要功能就加到「主要非功能要求」當中，並組織語言，定義最合適的標題。
通過本次的閱讀，我比較清楚地認識到了需求就是闡明系統功能或者說定義系統行為的工具，而且也學習掌握了在編寫需求文件時的一些規格內容，讓我對軟體需求在總體的分析和編寫上有了大致的了解。
2023年秋季個人閱讀計畫
精讀書目 書名 有效需求分析 徐峰著 目錄 引導篇 第0章 軟體需求全景圖 價值需求篇 第1章 目標 願景分析 第2章 干係人識別 第3章 干係人分析 詳細需求篇 第4章 業務子系統劃分 第5章 業務介面分析 第6章 業務流程識別 第7章 業務流程分析與優化 第8章 業務場景識別 第9章 業務場景分...
2023年秋季個人閱讀計畫
2016年秋季個人閱讀計畫 本學期閱讀計畫 精讀 軟體需求分析教程 全書一共雖然只有73頁，但是裡面根據例子來引出如何做需求這個主題，並且在後面闡述的過程中，還是結合例子來說的，我覺得比較適合我讀這類書的感覺。另外也是因為它比較小，所以會比較有耐心慢慢往下讀。在計畫上，第二週20頁第一篇 第三週40...
2023年秋季個人閱讀計畫
一 10月閱讀書籍 軟體需求模式 a.10月11日23點發表第一篇讀書筆記。b.10月21日23點發表第二篇讀書筆記。c.10月30日23點發表第三篇讀書筆記。二 11月閱讀書籍 需求模式 軟體建模與分析 a.11月11日23點發表第一篇讀書筆記。b.11月21日23點發表第二篇讀書筆記。c.11月...