這本書的譯者就在序中寫到：「需求是平衡的藝術，既要對開發人員有指導意義，又要能幫助解決業務問題，如何在兩者之間取得平衡，本書中的大量例項對此有自己的獨特見解」。顯然，需求分析就是連線客戶和軟體開發者，或者說，連線業務與軟體的最關鍵的橋梁。需求是開發人員開發軟體的基礎，需求也是業務人員的業務目標。
首先，我們應該認識到的就是，什麼是需求？需求應該是用最清晰的文本來闡明系統所必須具有的所有功能和其他能力，即需求定義了系統必須做什麼和它必須完成的行為。本書中就定義了需求的一些基本原則：（1）定義問題，而不是解決方案。我們要理解問題的本質，在需求中明白問題是什麼，而不是應該怎麼做。（2）定義系統，而不是專案。需求所體現的是這個系統的功能，而系統就是一組目標，但是專案卻是如何完成這一目標。（3）區分正式和非正式部分。我們應該從大量的需求資訊中，通過背景知識、前後關係、流程以及結構來正確地認識到需求的正式組成部分，即系統必須做什麼，而其他的都是非正式的。（4）避免重複。每一項資訊應該只需要表達一次，重複會產生額外的工作而且加大了不一致的可能性。在認識和定義需求的同時，本書也為我們提供了乙個典型的傳統需求階段的步驟：（1）準備。（2）收集資訊。（3）編寫需求規格草稿。（4）評審規格。（5）評審後修改。
在了解了什麼是需求和需求階段的步驟之後，我進一步學習了需求規格的內容。首先是介紹部分，系統規格的介紹部分有：系統目的、文件目的、需求格式、詞彙表、參考書目以及文件歷史。其實這六個主題的目的都是為了讓開發者能夠更清楚地認識到需求，才能更好地去開發軟體。在我看來乙個好的需求分析，應該讓我們很清楚明白地認識到我們的系統本身的目的是什麼，我們要使用更簡潔明瞭的語言用來代替一些難懂的專業術語去描述每乙個需求。所以介紹部分就是讓我們更好地認識需求，才能使我們把握好開發系統的方向。其次是上下文部分，就在上課老師也讓我們練習了這一部分的內容，即上下文圖。在上下文圖中我們需要展示元件、使用者角色、範圍邊界、系統間的介面，在這之中，我們就需要對每乙個是真的事情，清楚明確地宣告為假設，同時也要把不需要的東西排除在外，最後我們要確定關鍵業務實體（即系統就是為了產生和操縱這些東西而開發的），然後構件基礎架構（支援乙個或多個需求所需的一組基礎的能力）。然後就是定義系統的核心部分——功能域部分。我們需要在需求中詳細地列舉出系統的所有功能，將其分為大量的小節而更方便管理也更容易理解，然後需要根據功能的使用頻率、發起者的相對重要性或者對業務的價值來區分不同的功能的重要性，並且從高到低依次排列。最後是主要非功能要求部分，我們需要篩選出系統功能中不重要的部分，把它們分配到規格內容的其他部分當中，而對於主題太大的不主要功能就加到「主要非功能要求」當中，並組織語言，定義最合適的標題。
通過本次的閱讀，我比較清楚地認識到了需求就是闡明系統功能或者說定義系統行為的工具，而且也學習掌握了在編寫需求文件時的一些規格內容，讓我對軟體需求在總體的分析和編寫上有了大致的了解。
01軟體需求模式閱讀筆記之一
什麼是需求？需求就是定義系統需要做什麼而不是怎麼做。需求定義了必須解決的問題 系統的目的是什麼，以及為了達到目的系統需要的所有功能。需求中不止乙個合適的細節層次，需求最重要的是定義了系統必須做什麼和它必須能完成的行為。首先我們要了解需求的一些基本原則 定義問題，而不是解決方案 定義系統，而不是專案 ...
軟體需求閱讀筆記01
軟體需求實際就是 業務知識 問題列表 其他元素 軟體需求的三層次 業務需求 使用者需求 軟體需求。需求也有著三種型別 功能需求 非功能需求 設計約束。不完整的需求 缺乏使用者參與 不切實際的使用者期望 需求變更頻繁 提供了不再需要的 敗因解決方案 1 不完整的需求 採用業務導向讓使用者參與到完整性評...
軟體需求閱讀筆記01
在資訊化高速發展的今天，構建與時俱進的資訊化系統已成為所有 企事業單位的重點課題之一。然而在軟體專案實施過程中，進度超期 經費超預算 變更頻繁的現象層出不窮，甚至有許多專案根本無法達到預期的目標，更談不上為業主創造真正的效益。歸根結底，軟體需求實踐這一共同的軟肋是問題的根源。隨著資訊化應用的逐漸深入...