業務需求代表了需求鏈中最高層的抽象：他們為軟體系統定義了專案檢視和範圍。軟體功能需求必須根據使用者的需求來考慮，且要與業務需求所設定的目標相一致。對不利於實現專案業務目標的需求應該排除在外。乙個專案可能包括一些與軟體沒有直接關係的需求，例如：硬體的購買、產品的安裝、維護或廣告。但在此，我們只關心與軟體產品有關係的業務需求。如果乙個專案缺乏明確的規劃和良好的資訊交流途徑，那將是十分糟糕的。如果專案的參與者持有不同的目標和優先權，那麼他們只能各抒己見，無心工作。如果專案的風險承擔者在產品所能滿足的業務需要和產品所能提供的利益問題上不能達成一致的意見，那麼需求決不會穩定。乙個清晰的專案檢視和範圍過於分散在多個地方開發，在這樣的專案中，地理位置上的分離使專案開發組成員必須天天進行相互溝通才能保證他們之間能進行更有效的合作。業務需求中某些特性最初被列入規格說明，而後又被刪除，最後又加入，則說明此業務需求未完全定義好。在確定詳細的功能需求之前，必須很好地解決專案的檢視和範圍問題。對範圍和侷限性的明確說明將在很大程度上有助於對所建議特性的**和最終產品的發行。乙個明確定義了專案檢視和範圍的文件也可以為所建議的需求變更的決策提供參考。
專案檢視可以把專案參與者定位到乙個共同和明確的方向上。專案檢視描述了產品所涉及的各個方面和在乙個完美環境中最終所具有的功能。相反的，範圍描述了產品應包括的部分和不應包括的部分。範圍的說明在包括與不包括之間劃清了界線，當然，它還確定了專案的侷限性。專案的業務需求在檢視上和範圍上形成文件，這些必須在建立專案之前起草。開發商業軟體的公司經常編寫市場需求文件，其實這種文件也是為了類似的目的，但這種文件較為詳細地涉及關於目標市場部分的內容，這是為適應商業的需要。檢視和範圍的文件為專案的主辦者或具有同等地位的人所擁有。業務需求是從各個不同的人那裡收集來的，這些人對於為什麼要從事該專案和該專案最終能為業務和客戶提供哪些價值有較清楚的了解。它們包括主辦者、客戶、開發公司的高階管理人員及專案的幻想者.
專案檢視和範圍的文件（vision and scope document）把業務需求集中在乙個簡單、緊湊的文件裡，這個文件為以後的開發工作奠定了基礎。專案檢視和範圍文件包括了業務機遇的描述、專案的檢視和目標、產品適用範圍和侷限性的陳述、客戶的特點、專案優先級別和專案成功因素的描述。這必須是乙個相對簡短的文件，也許只有3～8頁紙，這取決於專案的性質和大小。
關聯圖:軟體專案範圍的描述為我們正在開發的系統和宇宙萬物之間劃清了界線。關聯圖通過正在開發的系統或正在討論的問題和外部世界之間的聯絡來描述這一界線。關聯圖確定了通過某一介面與系統相連的外部實體（稱為「端點」或「外部實體」），同時也確定了外部實體和系統之間的資料流和物流。我們把關聯圖作為按照結構化分析所形成的資料流圖的最高抽象層。可以把關聯圖寫入專案檢視和範圍文件或軟體需求規格說明中，或者作為系統資料流模型的一部分。
業務需求代表了需求鏈中最高層的抽象：他們為軟體系統定義了專案檢視和範圍。軟體功能需求必須根據使用者的需求來考慮，且要與業務需求所設定的目標相一致。對不利於實現專案業務目標的需求應該排除在外。乙個專案可能包括一些與軟體沒有直接關係的需求，例如：硬體的購買、產品的安裝、維護或廣告。但在此，我們只關心與軟體產品有關係的業務需求。如果乙個專案缺乏明確的規劃和良好的資訊交流途徑，那將是十分糟糕的。如果專案的參與者持有不同的目標和優先權，那麼他們只能各抒己見，無心工作。如果專案的風險承擔者在產品所能滿足的業務需要和產品所能提供的利益問題上不能達成一致的意見，那麼需求決不會穩定。乙個清晰的專案檢視和範圍過於分散在多個地方開發，在這樣的專案中，地理位置上的分離使專案開發組成員必須天天進行相互溝通才能保證他們之間能進行更有效的合作。業務需求中某些特性最初被列入規格說明，而後又被刪除，最後又加入，則說明此業務需求未完全定義好。在確定詳細的功能需求之前，必須很好地解決專案的檢視和範圍問題。對範圍和侷限性的明確說明將在很大程度上有助於對所建議特性的**和最終產品的發行。乙個明確定義了專案檢視和範圍的文件也可以為所建議的需求變更的決策提供參考。
專案檢視可以把專案參與者定位到乙個共同和明確的方向上。專案檢視描述了產品所涉及的各個方面和在乙個完美環境中最終所具有的功能。相反的，範圍描述了產品應包括的部分和不應包括的部分。範圍的說明在包括與不包括之間劃清了界線，當然，它還確定了專案的侷限性。專案的業務需求在檢視上和範圍上形成文件，這些必須在建立專案之前起草。開發商業軟體的公司經常編寫市場需求文件，其實這種文件也是為了類似的目的，但這種文件較為詳細地涉及關於目標市場部分的內容，這是為適應商業的需要。檢視和範圍的文件為專案的主辦者或具有同等地位的人所擁有。業務需求是從各個不同的人那裡收集來的，這些人對於為什麼要從事該專案和該專案最終能為業務和客戶提供哪些價值有較清楚的了解。它們包括主辦者、客戶、開發公司的高階管理人員及專案的幻想者.
專案檢視和範圍的文件（vision and scope document）把業務需求集中在乙個簡單、緊湊的文件裡，這個文件為以後的開發工作奠定了基礎。專案檢視和範圍文件包括了業務機遇的描述、專案的檢視和目標、產品適用範圍和侷限性的陳述、客戶的特點、專案優先級別和專案成功因素的描述。這必須是乙個相對簡短的文件，也許只有3～8頁紙，這取決於專案的性質和大小。
關聯圖:軟體專案範圍的描述為我們正在開發的系統和宇宙萬物之間劃清了界線。關聯圖通過正在開發的系統或正在討論的問題和外部世界之間的聯絡來描述這一界線。關聯圖確定了通過某一介面與系統相連的外部實體（稱為「端點」或「外部實體」），同時也確定了外部實體和系統之間的資料流和物流。我們把關聯圖作為按照結構化分析所形成的資料流圖的最高抽象層。可以把關聯圖寫入專案檢視和範圍文件或軟體需求規格說明中，或者作為系統資料流模型的一部分。
《軟體需求》讀書筆記四
需求捕獲應該是主動的 需求捕獲應該是聚焦的 案例 小趙問監控中心的小張 你對這個系統有什麼需求？小張說 我想到的功能包括值班日誌 告警的聲光提示 基於簡訊的告警通知.老李問小徐 當監控中心收到乙個告警的時候，希望以什麼形式來體現？收到後，你們一般會進行什麼樣的處理？小張的提問使得捕獲過程很發散，而老...
《軟體需求》讀書筆記02
需求 需求收集方法 軟體需求可以來自方方面面，這取決於所開發產品的性質和開發環境。需從不同使用者代表和 收集需求，這說明了需求工程是以相互交流為核心的性質。下面是幾個軟體需求的典型 1 訪問並與有潛力的使用者 為找出新軟體產品的使用者需求，最直截了當的方法是詢問他們。2 把對目前的或競爭產品的描述寫...
《軟體需求》讀書筆記01
許多軟體問題都源於收集 記錄 協商和修改產品需求過程中的方式不當，包括資訊收集方式不正規，沒有明確提出想要的功能，假設是未經過溝通的錯誤假設，需求的定義不夠充分，以及未經仔細考慮進行需求變更等。在軟體開發中遇到的問題時，人們常常輕率地將其忽略。軟體專案中40 60 的缺陷都是由需求分析階段的過失所致...