需求過程把重點放在提交的產物上，我們需要得到這些產物，從而建立可測試和可跟蹤的需求規格說明書。這些提交的產物為管理專案提供了早期的衡量標準。我們可以對收集、提取、編寫和檢查需求的過程進行剪裁，以便讓這些過程能適合技術和文化環境。需求模板和需求項框架是提交產物的例子，我們可以根據自己的環境和術語來剪裁。一般的過程提供了理解需求概念的關鍵。
專案啟動是一項突發性的活動，通過這個活動收集讓我們的專案啟動所需要的各種資訊，並確定專案可行而且資金充足。啟動階段確定產品要做為起一部分的工作，並確定產品要實現的準確目標。啟動階段提供的其他產品對限定產品範圍要有所幫助，並將作為後續需求收集活動的輸入資訊。啟動階段提交的產物為產品奠定了基礎：產品的目的——關於產品應該達到的業務目標的乙個簡短的、可度量的陳述；客戶——該產品是為誰構建的；顧客——對商業產品來說，誰將購買該產品；風險承擔者——哪些人在產品中擁有既得的利益；使用者——誰將操作該產品，他們的能力如何；限制條件——是否有些設計方案必須採用，對專案解決方案可以提供多少時間和經費；名稱——該專案使用哪些術語；相關事實和假定——每個人都需要知道的是什麼；工作的範圍——什麼是產品和專案的邊界；估算的費用——實現產品需要花費多少工作量或資金；風險——揭示專案面臨的主要風險的乙份簡短風險分析，這些提交產物放在一起，可以提供足夠的資訊，以得到啟動階段的最終產物；繼續或終止的決定——該專案是否可行，考慮得到該項目的成本，是否值得！
通過引入業務事件的思想，我們可以合理的切出一部分工作，用於進一步的建模和研究。通過理解每個相鄰系統對工作的影響，我們理解了產品範圍的限制。通過對工作行為建模，我們得到了範圍。我們不是通過預先假設會有乙個使用者和計算機，或者通過考慮現有的技術來得到這個結果的。通過使用業務事件來分割工作，我們有了乙個指導方法，來發現所有的工作部分。這些工作部分處於相同業務上的原因而結合在一起。事件驅動的用況是事件響應（活動和資料）的一部分。這些事件響應應由產品來執行。參與者被挑選出來與用況進行互動，很大程度上基於他們對那部分工作的期望。用況成為了需求的「錯」。也就是說，我們研究每個用況並確定他們的需求。通過把系統分解成這些小的、方便的單元，我們能理解期望產品完成的真正的工作，我們才能構建真正相關的、有用的產品。
在網中捕捉到的任何不恰當的需求將被質量關過濾。所以，如果在網羅過程中發現了一些無關的需求，不必太在意。質量關將減少需求的數量，只保留哪些最恰當的。在這個階段應該注意發現所有的需求，不要遺漏任何需求。在實踐上，這意味著收集過多的需求總要好過收集太少的需求。傾聽是最重要的需求收集技巧。
功能性需求指明了產品必須要做的事情。為了實現存在的根本理由，產品必須執行一些動作，功能性需求與這些動作有關。他們應該做到能形成乙份完整的、盡量避免二義性的產品功能描述。做到這一點最容易的方法是編寫乙個場景，把用況分解為一系列的步驟，檢查每個步驟，匯出它的功能性需求。
非功能性需求是產品必須具備的屬性。非功能性需求並不改變產品的功能。非功能需求增加了產品的功能——他增加了一些處理，使產品更易於使用、更安全或者互動性更強。
編寫需求規格說明書是指得到要構建的產品的完整描述的任務。這其實不是一項單獨的活動，而是在網羅和做原型的活動中，當發現需求時就完成了編寫需求的一部分工作：在質量中，確保每一項需求是有完整上網時候就完成了其餘部分的工作。編寫乙個好的需求規格說明書能夠得到數倍的回報——構建工作更為精確，維護使用費用更少，產品反應了顧客的需要和想法。
掌握過程需求
今日閱讀了 掌握需求過程 這本書，書中從基本事實 需求過程 確定業務問題的範圍 業務用例 工作調研 場景 理解真正的問題 開始解決方案 今日業務分析策略，功能需求 非功能需求 驗收標準和理由 質量關 需求與迭代開發 復用需求 溝通需求 需求完整性十七個方面對於需求過程進行詳細講解。目前讀到第四章，先...
《掌握需求過程》閱讀筆記（一）
掌握需求過程 閱讀筆記 一 在準備做乙個系統之前，我們首先必須要能明白我們做這個系統的目的是什麼，做這個系統能給顧客的工作流程帶來什麼變化？要知道這些問題，我們必須知道什麼是需求，所謂需求就是那些您必須在開始構建產品之前發現的東西。需求的發現是在開始做系統的最開始，是最重要的，如果乙個系統之前的準備...
《掌握需求過程》學習筆記
這幾天讀了 suzanne robertson,james robertson 的 掌握需求過程 本書用乙個接乙個的步驟 乙個接乙個的模板 乙個接乙個的例子，向我們展示了乙個經過業界檢驗的需求收集和驗證過程。從專案啟動 專案計畫 專案實施 專案監控 專案結束主線角度描述了需求的目標與範圍 需求規格說...